Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Fear branching vs Embrace branching 14 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You've nailed something down that's been bugging me for a little while. I'm a definite subversion user but I've been increasingly getting the feeling that subversion doesn't quite fit my way of working. Thus I've been looking at git lately.

    The thing is though, that I have no fear of branching because there's a "recipe" for merging and I don't have to think too much about it other than to record revision numbers in the log. So I'm all for branching in subversion. Also though, I tend to not do any complica

    • The thing is though, that I have no fear of branching because there's a "recipe" for merging and I don't have to think too much about it other than to record revision numbers in the log.

      Bingo; I think you just identified a huge chunk of my fear: I barely had merging in CVS down, and I don't yet fully understand the "recipe" for it in Subversion. So, schwern (or anybody), should I spend time getting really comfortable with merging in subversion and then move to SVK, or will SVK make all of that into time wasted?

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Merging in SVN is currently pretty dumb because you have to do all the book-keeping yourself, recording what revisions have already been merged into what branch. Its tricky and its time consuming and its easy to forget and you have better things to do. You should do it once or twice manually just to understand what's involved in keeping a branch up to date and so you can better appreciate never having to do that again. I had to write svn merge tools back when svnmerge sucked. Its not fun.

        After that I'd

        • Thanks for the advice! :)

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

    • there's a "recipe" for merging and I don't have to think too much about it other than to record revision numbers in the log.

      You shouldn't have to think about it at all. Its a rote task. Book-keeping. Monkey work. The sort of things computers are very good at. Humans are very bad and prone to make mistakes.

      You might want to look at SVK or the Fisher Price version svnmerge [orcaware.com]. svnmerge does for you what you're currently doing by hand.

      Also though, I tend to not do any complicated merges because they are to

      • You shouldn't have to think about it at all. Its a rote task. Book-keeping. Monkey work. The sort of things computers are very good at. Humans are very bad and prone to make mistakes.
        Not quite. There will *always* be cases where a merge has to be manual. It's just not possible to 100% automate merging. SVN could do it better, but it'll never be Monkey Work.

  • Sounds wonderful, and the future is so bright we gotta wear shades. But I'm just barely getting the hang of subversion now (even though I've been watching it since before it was a 0.1 release). I want to take the jump to SVK at some point. In fact I want my entire home directory on every box I use, at home and at work, to be versioned through SVK. But I'm not there yet, and by the time I am there will hopefully be lots of really good SVK tutorials to choose from to get me there. :)

    I guess I do fear br

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • So now that there are tools that can accommodate all development styles, are you saying folks should agree on a development method/protocol and then pick a tool that fits how they want to work? Or are you saying that since the tools now support it, everyone should use distributed since it is, by default, the best way to go? That is, is there a pro/con list for distributed vs. centralized?
    • Its more like this: Traditional VCS can support development models A, B and C. Distributed VCS can still support development models A, B and C but also D, E and F.

      Just because you use a distributed VCS doesn't mean you have to be distributed, you can continue to have a trunk-centric project if you like. It allows you to choose your development model without being restrained by your tools. The choice is now yours, not your VCS.

      That's the essential pro. The con list boils down to "I have to learn a new in

      • SVK is the exception in that it retains the SVN interface, but it comes at a cost as any compromise will.

        If you have time to elaborate on that it would be most appreciated. :)

        SVK allows you to hedge your bets since it can be used as a client to an existing SVN repository, have your cake and eat it, too.

        Since I'm not yet familiar with the cons I certainly can't say for sure, but it sounds to me like that's going to outweigh any of them. :)

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers

  • ... not because merging is painful, but because reviewing and integrating anything more than you can produce in a few hours of work is painful.

  • This is probably the first pragmatic and intelligent post I've seen on the subject instead of the usual, "Because Linus says so!" arguments I've read elsewhere.

    Many thanks.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.