Comments on: 4 Signs You Are Fighting Your Version Control Tool http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/ Technology and Geek Stuff by Eric Burke Thu, 04 Nov 2010 22:37:00 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: Frank C http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/comment-page-1/#comment-104 Frank C Fri, 28 Sep 2007 17:21:06 +0000 http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/#comment-104 #1 usually starts when you delete code written by 'The Expert' who's been with the company 10 years or so and you get yelled at for doing it. At one such company, I saw massive amounts of commented out code that had DO NOT DELETE!!! headers on each section. #2 happens when branching isn't well supported in the VCS or when departmental policies don't set check-in/check-out and branching procedures #2 and #3 also often start when the VCS is hard to use or is unreliable. I've also seen #3 used as a political tools as well. #4 is a bit of "mainframe mentality" that's still around. I could see it if you were using a VCS that didn't allow developers to comment on their changes within the system or generate reports but, otherwise, use the system and create change reports as necessary. #1 usually starts when you delete code written by ‘The Expert’ who’s been with the company 10 years or so and you get yelled at for doing it. At one such company, I saw massive amounts of commented out code that had DO NOT DELETE!!! headers on each section.

#2 happens when branching isn’t well supported in the VCS or when departmental policies don’t set check-in/check-out and branching procedures

#2 and #3 also often start when the VCS is hard to use or is unreliable. I’ve also seen #3 used as a political tools as well.

#4 is a bit of “mainframe mentality” that’s still around. I could see it if you were using a VCS that didn’t allow developers to comment on their changes within the system or generate reports but, otherwise, use the system and create change reports as necessary.

]]> By: Eric Burke http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/comment-page-1/#comment-101 Eric Burke Fri, 28 Sep 2007 15:08:48 +0000 http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/#comment-101 Yikes. If you switch to a new tool, migrate the history to the new tool as well. If you can't do that, then keep the old tool around for the history up to the point of the conversion. Yikes. If you switch to a new tool, migrate the history to the new tool as well. If you can’t do that, then keep the old tool around for the history up to the point of the conversion.

]]> By: Sashidhar Kokku http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/comment-page-1/#comment-98 Sashidhar Kokku Fri, 28 Sep 2007 14:54:54 +0000 http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/#comment-98 I dont quite agree with you on no 4. Human Edited History Logs. I personally believe that this is what constitutes a manual page, detailing all changes that have happened to this file. However trivial it maybe. Tomorrow , if you change ur version control, where do you think your history will be stored. You will end up with a fresh slate of modified files. Without these audit logs, you wont be able to assign responsibility(or blame) ;) -Sashidhar I dont quite agree with you on no 4. Human Edited History Logs.
I personally believe that this is what constitutes a manual page, detailing all changes that have happened to this file. However trivial it maybe. Tomorrow , if you change ur version control, where do you think your history will be stored. You will end up with a fresh slate of modified files. Without these audit logs, you wont be able to assign responsibility(or blame) ;)
-Sashidhar

]]> By: Lucian http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/comment-page-1/#comment-97 Lucian Fri, 28 Sep 2007 13:15:33 +0000 http://stuffthathappens.com/blog/2007/09/28/4-signs-you-are-fighting-your-version-control-tool/#comment-97 Using Physical Copies as a Backup Mechanism I sometimes copy my source tree before doing a push because when I work with someone on the same branch, I often have to merge my working copy with the trunk head. Sometimes merging is not a very straight forward task and having a copy of "something that I've tested and know to be working" near helps a bit. Git firstly commits my original "something that I've tested and know to be working" work and then creates a new commit with the merging details; other SCM tools do not provide such a feature (svn, cvs...). I know I can retrieve it through git, but it's faster and more straight forward this way. Using Physical Copies as a Backup Mechanism

I sometimes copy my source tree before doing a push because when I work with someone on the same branch, I often have to merge my working copy with the trunk head.

Sometimes merging is not a very straight forward task and having a copy of “something that I’ve tested and know to be working” near helps a bit. Git firstly commits my original “something that I’ve tested and know to be working” work and then creates a new commit with the merging details; other SCM tools do not provide such a feature (svn, cvs…). I know I can retrieve it through git, but it’s faster and more straight forward this way.

]]>