Tracking code changes

xorl has asked for the wisdom of the Perl Monks concerning the following question:

This might be OT since it isn't strictly Perl related (feel free to consider and mark it OT if it is).

I'm now in a job that has a lot (and I mean a lot) of code in many languages not just perl. Code is editied by any number of people on a team and sometimes even by people on other teams. This makes things difficult when some "Java Coder" mucks around with my Perl or PHP scripts and I need to track down and fix what they broke.

At my previous job I use to use CVS, but that project has finally died it seems. I'm looking now at setting up subversion, however I thought I'd ask here first if anyone uses something different or better.

My needs are mainly to be able to rollback to a certain date as well as track who made what changes. At first this will only be used for our websites which are mainly html, php, and perl (although there are some .doc and .ppt that would need to be treated as a binary). It would need to run on Linux (RHEL 4).

I would really like to be able to push this company wide. To do this, it would need some sort of graphical interface that Windoze and non-Windoze users could easily learn (I usually prefer a CLI, so hopefully it will still have a good one). It would need to handle all sorts of code and binary objects (If the language exists we have production systems using it). It would also need to be able to protect certain code to be edited by only certain people or teams.

Does anyone have any recommendations? Are there other issues I haven't considered?

Thanks

Comment on Tracking code changes

Replies are listed 'Best First'.
Re: Tracking code changes by imp (Priest) on Aug 23, 2006 at 12:45 UTC
I have been using subversion for about 2 years and have no complaints. A few items worth noting: Decent documentation Handles binary files, unlike cvs Performs a 2-way diff to reduce bandwidth, unlike cvs Preserves revision history for copied/renamed files TortoiseSVN is a windows shell extension, so GUI folks can use windows explorer to work with svn. Trac is a nice product that combines repository browsing, wiki, and issue tracking. Try the demo Update I found this book very helpful: Subversion Version Control: Using the Subversion Version Control System in Development Projects	[reply]
Re: Tracking code changes by Velaki (Chaplain) on Aug 23, 2006 at 12:42 UTC
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."	[reply]
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]
Re: Tracking code changes by jhourcle (Prior) on Aug 23, 2006 at 13:22 UTC
If you'd like alternatives to look at, wikipedia has a Comparison of Revision Control Software, with lists of GUIs for 'em (if you link to the details on the software -- in the list, it just mentions platforms / frameworks used) I'm guessing there's probably other comparisons out there with more detail -- each of the individual product's pages, or their official sites would probably explain why they think they're better than the others in their field, if you wanted to see which would best fit your needs	[reply]
Re: Tracking code changes by Fletch (Bishop) on Aug 23, 2006 at 13:26 UTC
SVN's the all but de facto open source SCM. There's some GNU projects using arch, but the lion's share is probably on SVN. It's not perfect but it's workable, and you can use it as a central backend for svk. If want commercial, Perforce usually gets good comments (and that's what Perl itself is managed with as they give free licenses to open source projects).	[reply]
Re: Tracking code changes by tirwhan (Abbot) on Aug 23, 2006 at 14:34 UTC
There appears to be a growing trend away from the traditional centralized SCM systems (such as CVS, Subversion, Perforce) towards truly distributed systems (such as svk, arch, darcs or git). Which will fit better for your organisation is something that only you can decide, but you could take a look at this journal-entry by mugwumpjism on use.perl.org which is the first of four articles looking at different SCM systems, I found those rather helpful (and after trying it out I agree with the authors endorsement of git). All dogma is stupid.	[reply] [d/l]
Re: Tracking code changes by McDarren (Abbot) on Aug 23, 2006 at 13:08 UTC
I have used both CVS and SVN a bit, but certainly not enough to profess to be an expert with either, nor to be in a position to strongly recommend one over the other. However, given that one of the main goals of the Subversion project was to "write a new version control system from scratch, retaining the basic ideas of CVS, but without the bugs and misfeatures.", you would have to assume that SVN is probably a better choice. Assuming of course, that those original goals have been realised :) Cheers, Darren :)	[reply]