Version Control Software

What do you mean by "compatible"?

If you don't insist on it being directly controlled via uVision then there is no question of compatibility!

I've used a couple of VCS, and never bothered to "integrate" either of them with uVision - just use the VCS "standalone"

Currently, I use Tortoise SVN (a front-end for Subversion) - which is controlled directly via the Explorer context (right-click) menu:
http://tortoisesvn.tigris.org/

Previously, I used QVCS - see http://www.keil.com/forum/docs/thread5120.asp

Rakesh,

I personally use a CVSNT server running on a Linux machine, and then use WinCVS as a front-end on my development station. It doesn't have all of the new bells-and-whistles that a more advanced package like SubVersion does, but it's been around for quite a while and is quite stable.

If you have a truly large development team that's going to be working on large projects, however, you might want to look at SubVersion or another system that offers "atomic commits." What this means is that if someone is committing a large batch of changes at the same time as someone else, one will succeed and the other will fail. With CVS (or anything else without atomic commits), you can get into a strange state where half of the files from each person managed to get committed before a collision and you have a big mess to sort out. These things become less worrisome with smaller teams and smaller projects.

Of course, I should point out before other do, that if you have a huge team working on a huge chunk of code for the 8051, you may have bigger problems than the version control software can fix. :)

-Jay Daniel

I wonder what constitutes "huge" in terms of a software team for an 8051?

I think five would probably qualify for a project consisting of a single 8051...?

Of course, it could be that the 8051 is just part of a much larger system...

I, too, never really bother about integrating the VCS with the editor. Given a multitasking OS and a window manager, it's just a mouse click away. Some people really prefer the integration, though.

T hear lots of good things about SubVersion.

One feature I didn't see in any of the free packages was the notion of a "change list" or "change set". This is the ability for the VCS to track all the files that change for a given reason as a unit. You don't usually edit just one file to fix a bug or add a feature; you edit several. And later, it's really handy to be able to pull out all the changes for all the files for a single reason.

I currently use Perforce. (http://www.perforce.com) It's free for two users, and used to have a free license for open source projects.

"This is the ability for the VCS to track all the files that change for a given reason as a unit."

I guess you could implement this in your usage procedures, and say that you check-in all such files together, and "tag" them as such (or whatever terminology your particular tool uses)...?

Sure, you could do that.

Or your usage procedures could say that you run "diff" against all your files, and put the diffs in a certain subdirectories depending on the version and your user name, and zip 'em to save space. You could do it all manually.

But the point of an SCM tool is that it does all that for you!

Change sets come in really handy when someone comes along and says, "oh, that bug you fixed, we need that in release 1.23 also". Click the change set, merge it over to the other branch, done. (Unless of course the source has diverged a lot, in which case you're doomed no matter what.)

I think this is a two horse race, CVS or subversion. I'm currently using CVS with WinCVS as the GUI front end, but I'm thinking of moving to subversion with the tortoise shell extensions. The main thing stopping me is the "If it aint broke .." bit.