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 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 interface". SVN wins out because so many people are familiar with it, or CVS or RCS, so nobody has to retrain. Most of the distributed VCS -- darcs, arch, git, hq, monotone -- do things rather differently from CVS and SVN so you have to retrain a little. SVK is the exception in that it retains the SVN interface, but it comes at a cost as any compromise will.

      Other cons include the relative instability of the distributed version control market. Being so new, its rapidly evolving and there's lots and lots of them out there. Which do you pick? If you pick the flavor-of-the-month will it still be popular next month? Currently git is the thing. Before that it was darcs. Before that it was arch. With traditional version control that risk doesn't exist. You use SVN because its pretty much killed everything else off and nobody's bothering to write new non-distributed VCS anymore. 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.

      • 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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.