Comments on: Chapter 2: Tools http://cafe.elharo.com/web/refactoring-html/chapter-2-tools/ Longer than a blog; shorter than a book Fri, 19 Mar 2010 02:32:48 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Samuel A. Falvo II http://cafe.elharo.com/web/refactoring-html/chapter-2-tools/comment-page-1/#comment-346898 Samuel A. Falvo II Tue, 03 Feb 2009 01:57:28 +0000 http://cafe.elharo.com/uncategorized/chapter-2-tools/#comment-346898 I find distributed version control (e.g., Mercurial, Git, et. al.) to be overwhelmingly superior to Subversion. It is my personal opinion that anyone considering the use of Subversion should look into a DVCS, for the simple reason that it allows collaborators to share an ad-hoc repository amongst themselves without affecting the rest of the organization. When merges are required, the release manager can then pull directly from the ad-hoc repository just as if it were any other employee. This also greatly facilitates code reviews, particularly amongst geographically dispersed coding centers. In fact, using a DVCS with a _pull_ (rather than _push_) policy results in all sorts of benefits from the RM's point of view. First, the RM always pulls from trusted sources. This means that, in order for anyone to commit changes to the code base, it has to go through at least one trusted engineer before it lands in the RM's patch queue. This pretty much enforces a policy of peer code review. Second, the pull policy reduces the need for process documentation and certification effort (and, thus, reduces the amount of training needed) for commit access, thus bringing new hires up to speed faster. I find distributed version control (e.g., Mercurial, Git, et. al.) to be overwhelmingly superior to Subversion. It is my personal opinion that anyone considering the use of Subversion should look into a DVCS, for the simple reason that it allows collaborators to share an ad-hoc repository amongst themselves without affecting the rest of the organization. When merges are required, the release manager can then pull directly from the ad-hoc repository just as if it were any other employee. This also greatly facilitates code reviews, particularly amongst geographically dispersed coding centers.

In fact, using a DVCS with a _pull_ (rather than _push_) policy results in all sorts of benefits from the RM’s point of view. First, the RM always pulls from trusted sources. This means that, in order for anyone to commit changes to the code base, it has to go through at least one trusted engineer before it lands in the RM’s patch queue. This pretty much enforces a policy of peer code review. Second, the pull policy reduces the need for process documentation and certification effort (and, thus, reduces the amount of training needed) for commit access, thus bringing new hires up to speed faster.

]]> By: John Cowan http://cafe.elharo.com/web/refactoring-html/chapter-2-tools/comment-page-1/#comment-237681 John Cowan Thu, 12 Jun 2008 16:31:20 +0000 http://cafe.elharo.com/uncategorized/chapter-2-tools/#comment-237681 Oh please, <i>please</i> tell them not to use Visual SourceSafe! Even @#$% <i>Microsoft</i> doesn't use VSS any more -- that is one can of dog food that is way past its pull date. It stinks on ice. Can you say "random database corruption"? If they are using VSS, tell them the first priority is to switch to Subversion <i>before</i> refactoring anything. Oh please, please tell them not to use Visual SourceSafe! Even @#$% Microsoft doesn’t use VSS any more — that is one can of dog food that is way past its pull date. It stinks on ice. Can you say “random database corruption”?

If they are using VSS, tell them the first priority is to switch to Subversion before refactoring anything.

]]>