Source Control system for not-so-smart programmers

Question

Problem:

A huge code base spanning to several million SLoC, maintained(support/active enhancements etc) by a horde of second/third rate programmers(most of them who do not really care). Decades ago, few smart guys had put in place a wrapper that uses CVS underneath and this system is being used by current generation of developers (90% of them have not used CVS directly, or heard of/used another command line source control system).

Effect:

Usage of CVS and multiple teams working across multiple modules, inevitably => CVS branch merges to trunk. This would be an activity practised in the most religiously and ritualistically possible way. [=> brute force; planned weeks ahead, involving a dozen guys for 2/4 days. Hundreds(sometimes thousands) of sources handled, manually. Funny part is, the people involved are not the original owners of the fix, and they simply go by checking the diffs; really, am not kidding!] This leads to a lot of inconsistency in the sanity of the libraries/modules/functionality and too much of effort is spent to correct defects due to regression during these merges.

And now, the question:

What alternative source control system can bring in some positive change and improve the lives of programmers/managers and everyone else in the environment?

Since everyone around there seems to have drunk the KoolAid (and sing "This-is-how-things-are-done-everywhere") without even giving a thought about finding an alternative, it is high time someone does that. But considering the sort of people who would use the system, the following aspects are to be kept in mind.

1. Simple to use && understand, even Joe Coder should be able to use it without fuss. (Anyway this won't be needed, as the wrapper would hide real under-the-hood stuff from folks)
2. A HUGE codebase (consisting of sources across multiple languages), with multiple(around 30) active branches at any given time.
3. Easy merges to various branches. (considering that volume of changes is quite huge)
4. Commercial support for the system would be sweet, if available.
5. Development happens on UNIX servers (Should run on HP-UX/Solaris at least)
6. Should scale well (thousands of users/hundreds of thousands of sources)
7. Good Documentation
8. Simple/lucid browser based interface to compare/view changes/copies.
9. There are no binary files in repository, so need not bother about them.
10. Provision for importing current repository contents into the new system.

So, please suggest. Is there hope && a way out? :) Am pretty sure stuff like git would be rejected outright (they believe "git is only for smart folks")

EDIT: I too have Mercurial and BitKeeper in mind, and have mentioned it to folks up the chain. Hoping for the best! Thanks! :)

Answer 1

You may have heard the old saying about good, fast and cheap. The same applies here. With a rich feature set come some degree of complexity. I don't believe that you can fulfill that list of requirements without picking a tool that is going to involve some complexity. I wish you luck in trying, but if it were me I would pick a good tool and invest some time into training the users.

Answer 2

Am pretty sure stuff like git would be rejected outright (they believe "git is only for smart folks")

If it's purely a matter of "perception" - that they "perceive" git to be too complex, try suggesting Mercurial or Bazaar - they might not be familiar enough with them to have formed an inaccurate preconception.

Answer 3

Mercurial would be my suggestion. To avoid the "complexity," perception, take a look at this site.

It is "A friendly introduction to the Mercurial DVCS by Joel Spolsky," and it provides an excellent tutorial for users (and a subversion recovery portion) which takes them through step by step editing, committing, merging, etc.

Answer 4

I'll throw out the suggestion of moving to Subversion. It's not the sexy distributed source control that all the cool kids are using, but, and this is the reason I am suggesting it, SVN should be an easy migration from CVS. It's established, well-used, and conceptually similar to CVS in some respects. (Now, if your developers are so far removed from even that, it might not help.)

Many, many people have done this migration. There are utilities out there to migrate your code from CVS to SVN (but not without some pain).

It should address most of your requirements (though how easy merging can be is debatable).

Bottom line is: your challenge isn't the technology. It's the adoption. If your team doesn't want to change, it won't. And sadly, any solution will be doomed. You have to convince them they need a change first. The best bet is to appeal to their laziness (I mean that in a positive way) and show that "life will be better" if they change.