Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re^4: [OT] Best Use of Subversion Branches in Perl Development

by mugwumpjism (Hermit)
on Mar 13, 2007 at 04:52 UTC ( #604476=note: print w/replies, xml ) Need Help??

in reply to Re^3: [OT] Best Use of Subversion Branches in Perl Development
in thread [OT] Best Use of Subversion Branches in Perl Development

Because no tool in existence understands this crazy system, and it doesn't add anything to the existing conventions used by svk and svnmerge?

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";

Replies are listed 'Best First'.
Re^5: [OT] Best Use of Subversion Branches in Perl Development
by perrin (Chancellor) on Mar 13, 2007 at 13:29 UTC

    This system is the one described by the svn book, except it uses tags in place of unstructured log messages, to avoid needing to paw through the logs to figure out when the last merge was.

    Are there useful tools that understand the properties set by svk and svnmerge? What are they? I'd be interested in trying them out.

    Switching to svk seems a little extreme as a solution for basic merging. I wouldn't suggest it to someone unless he has a need for doing off-line work or syncing multiple repositories. I could see svnmerge being a good solution in general, but Jim wanted to understand what's going on, and it's a bit hidden with svnmerge. It also doesn't save you much effort in a simple scenario like this one.

      You are not storing any indicator that a merge commit is a merge and not just a regular commit, let alone which of those other throw-away tags was the one merged in. How do you propose that any tool devised to annotate code based on history should work when faced with this system?

      $h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/." ."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
        What annotation tools are you talking about? If I had ever seen one, I'd be more interested in using techniques that work with it.

        For human use, a simple "merging tag 2.001" commit message has been fine. Maybe you're thinking of a more complex situation than Jim or I have. In my case, we always merge the tag with the latest version, so looking up the last merge isn't necessary if the tags are sequential. The additional information of which revision number the merge was hasn't ever been needed.