Re: Tracking code changes

The most important part about version control within a team structure is communication. Whether it's SCCS, RCS, CVS, SVN, ClearCase, or even dated text files, it's important to communicate with your fellow team member regarding which files you're going to edit, and what those changes might be. With concurrant systems, this becomes imperative so you don't collide and have to spend an inordinate amount of time merging the code.

Another thing to consider is which system will best suit your development style and your release management strategy. Some tools are better for a strict Develop-QA-Release cycle, whereas others support a more dynamic method, in which the cycle might be altered to suit various business imperatives.

Take a look at release strategies, and look at your developers styles. Maybe you can use one of these tools to help promote a greater sense of teamwork among the various development groups.

You may also wish to look at entire programming environments, such as Eclipse, which have the ability to embed CVS and SVN as part of their internal project management.

Hope this helped,
-v.

"Perl. There is no substitute."

Comment on Re: Tracking code changes

Replies are listed 'Best First'.
Re^2: Tracking code changes by xorl (Deacon) on Aug 23, 2006 at 14:23 UTC
The most important part about version control within a team structure is communication. You hit the nail on the head there! Previous job there were only 5 of us in the whole IT deptarment. I could yell down the hall or at my office mate and proceed. This current job, the IT dept has more people in it than my former employer had total. It's mass chaos. Most of the worker bees don't read the team leader meeting minutes and therefore miss important info and end up doing something stupid. Of course important things get left out of the minutes which is another disaster. I also won't go into the whole issue of some of the team leaders seem to forget everything said in the meetings too and direct their workers based on false assumptions. We have a mess and I'm thinking version control is the first step forcing better communication. If we can start tracking the stupidity eventually we can start holding people responsible and get them to fix their problem. I'm thinking we've got at least 10 years before things will be running close to smoothly.	[reply]
Re^3: Tracking code changes by chromatic (Archbishop) on Aug 23, 2006 at 17:55 UTC
We have a mess and I'm thinking version control is the first step forcing better communication. That's a bit backwards. Version control is a tool. Without better communication, you'll end up with a tool that some people use, some people don't, and a different kind of mess.	[reply]