DGtlRift's Journal: Source Code Control

So I hit the last straw this past week with our SCCS system. At work, after doing some major changes to the software project and verifying the integrity of the software in my local development environment, I decided to check in about 80 files into the main repository. This was a good time to check in because another engineer needed to modify a couple of header files I had checked out. The files I was going to check in were c, assember (68k and PPC), header files, and a couple of other propriatary formates.

We have some home grown tools for handling check in and check out that really use SCCS for the back end.

After it had committed all the asembler files and most of the header files, it burped on a couple of header files complaining that I didn't have them checked out.

Very annoying - now I have to stop and roll back, since some lamer in our development group didn't tell me they needed a file I had and probably just blew my p file away.

I go to roll back and the guy that asked me earlier if I could surrender the files he needed had already checked out a couple of the files I just checked in - More annoying, but understandable.

He rolls back my changes for me - already other engineers are starting to notice that files are not compiling due to half the headers being in. The way our system works is that the local environment uses the headers from the main repository if there isn't a local version.

I roll everything back so then everyone can work again.

Then I go to the next issue, figuring out who blew my lock away. Checking the put logs (since our system doesn't track extraction) I guess the version and after a few tries figure out that there were about 15 revisions to both files since I checked them out, and both had some major rewrites, and the contents were also split into smaller header files. Found out the engineer that blew away my p file, and he told me that he did it because I wasn't at my desk when he came by origionally. I asked him why he didn't email, and he siad he was rushed - Really damb annoying now, and not understandable.

So... after this experience, I'm on a campain at work to move us away from SCCS (or just the whole file reserving technique) and go to something like CVS where there are no file reservations.

I've been working on mantis and I am using CVS with that and it's very slick on reconciling the diffs in most cases. Thought this would be an option.

I also looked at Subversion, it was last year when I first saw it and thought it was rather buggy - but I have heard from a source that I trust that it has come a long way since last year and is fairly stable. I like the idea that it can track file/directory renaming or moving, and that it tracks revisions on a transaction basis instead of per file.

I also looked at ClearCase, but a friend at another company hates it and says it is only as reliable as your IT department is competant. He said he lost his whole project because someone deleted it from the repository - by accident - and could not restore it. Not to mention the cost of training for our IT department.

I'd like to go with a community supported package because (in my experience) our vendor supported packages (specifically the kernel we use in our hardware platform) sucked. The amount we payed for support and the actuall support we got were completely off. Everytime we called about an issue, they would ask us what BSP we were using and we would tell them that it's our own board design and we didn't buy something off the shelf, and they would say, well it works for us on this BSP - but that's another issue.

The other reason is that the bean counters here always look at our exempt employees (I think they call us exempt because we are exempt from being payed overtime) are a fixed cost, so why not make them work twice as long instead of paying for training or buying new software.

At the moment I have looked over RCS, CVS, Subversion, GnuArch and other payware packages - I was looking for some balanced input as to what the benefits of one over another are as well as a definitive matrix breakdown of what features are are included in what - especially comparred to SCCS.

Some of the slack I am getting from most of the engineers about moving away from SCCS is that we don't have the time - we are maintaining two main versions of the product as well as bug fixes on those two plus a third and then a subbranch of one of the main versions - I argue that we could maintain the code with better ease if these were brances and tags with CVS.

The other reason is that a few engineers don't trust automated tools to reconcile the diffs between the my changes, the origional, and a thrid person. I try to explain that it wont commit until you update, and that you have to reconcile the code where diff gets confused, but he's worried about where it doesn't think it's confused and actually does the murge wrong. I'm not sure how to convince them that it can reliably figure out diff merges.

All are software enginners are in one location, but occasionally they work from home, but use a checkpoint client to log in... so I don't think we need something to handle co-locations, but it wouldn't be a negative.

Any and all input would be greatly appreciated.

pick one and go with it

[sbuckhopper]

I have found that most of these community based source code control products have their problems, but they are all far advanced from what you currently have (by the sounds of things). Pick one of the projects and go with it, we currently use CVS, but my biggest beef with it is that it does not do directory versioning. sv does do directory versioning, but is not as mature, it is also missing some other features that big vendors provide, but I can't think of them off the top of my head right this second.