Arguments to convince to switch from CVS to SVN

Question

The UNIX department of my company currently uses CVS as source-version control system. They use it in a very strange way: different repositories for development/testing/production code (for the same project), no one tags anything, weird directory architecture, and so on.

The system has been set for ages but now, I have an opportunity to organize a meeting where I have to suggest changes. I'd like to make them change from CVS to SVN (Mercurial or Git might be even better, however I can't really recommand using a system I don't know well, and switching to SVN will already be a great step forward).

I don't have much experience with CVS so I can't compare them efficiently: I just know it doesn't support atomic operations and that it is deprecated.

What killer arguments would you use to convince my collegues to do the switch ?

Thank you very much.

Karate

Answer 1

Hmm, this setup sounds like a distributed VCS, so Mercurial or Git may match in very well. Multi-repository-setup is the speciality of it. I personally prefer Subversion, but in your case you should take a look at these, hginit may be a good introduction to Mercurial.

Anyways, arguments for switching:

• atomic commits
• better handling of binary files
• version control of directories (only SVN)
• properties on files and directories (only SVN)

Okubo

Thanks for the arguments. My meeting is on next week: isn't it a bit risky trying to suggest a VCS I don't master ? (Mercurial) I obviously cannot learn it well until then... or can I ? – Karate

It's a bit risky so fast, you're right. But you should look into it, because the repository-setup sounds like Mercurial. – Okubo

Tool support is one of the other strong points of SVN. You don't have to choose one client, but you can decide which one is best for which scenario: TortoiseSVN, commandline, AnkhSVN, VisualSVN, Subclipse, etc. all use the same libraries and therefore on-disk format so you can switch between them whenever you want. – Guglielma

Answer 2

Actually atomic commits are a deal breaker, not some tasty feature. For example, you want to commit 50 changed files. With SVN you svn commit and it happens that network fails in the middle of commit - your commit will be ignored. With CVS you will have a half of the commit in the repository, so now everyone will update to broken code and become unhappy and the daily build can fail and make everyone even more unhappy. With svn you either have a successful commit, or it looks like you have never though of the commit - the repository is always intact.

Heraldry

Excuse my non-native english but... a deal-breaker is... what exactly ? Not sure of what it means ;) – Karate

@ereOn: He means that not having atomic commits in CVS is, by itself, enough of a reason to avoid CVS. – Inflame

Answer 3

To be honest, if you have to work hard to convince them, then they'll likely be expecting it to fail (even if only subconsciously) and your effort might be better spent elsewhere.

I'd start using hg, git, or another DVCS locally (committing to the department's CVS repos) so you can get familiar with them. Due to their distributed nature, you can start realizing the benefits yourself, start showing the benefits to colleagues individually, and eventually make a strong case for conversion backed by real experience within your projects.

Inflame

I downvoted you. It makes absolutely no sense to use a hg or git as well as CVS. If he wants to practice, practice at home. – Farias

@silky: I guess all those people writing tools to layer DVCS on top of other repos (such as hgsvn) are just wasting their time then. – Inflame

@Roger What a ridiculous comment. I won't discuss this with you any further, as it will certainly be fruitless. I was merely explaining the downvote. – Farias

Actually, that's what I do: I practice at home but even if I recognize the benefits of newer version-control system, SVN is more likely to be adopted due to its similarities with CVS. Ideally, I would impose Git or Mercurial but that's not an option. I don't think they except it to fail: they just aren't up-to-date and don't know what newer solutions are. – Karate

@ereOn: The difference is in whether they'll resist the change or whether it's just something they haven't yet had the time to implement. Because you are asking for arguments, I expect it's the former. Human nature in that case is going to exaggerate any difficulties in conversion, even if they're completely normal. – Inflame

Well, I have to admit I don't know wether they will resist the change but I prefer to have some arguments, in such a case. The general company behavior is to stick with the existing, even if everybody complains about it. – Karate

1 vote up: we're using CVS and Mercurial almost exactly the way Roger described. There are still relatively good reasons why CVS is used, but Mercurial provides so much added value that it'd be silly not to ignore it. – Eighteenmo

Answer 4

The question is - what specific problems are being experienced with the current CVS setup? Your reasons for change should address those. But if they are not experiencing any problems, change for change sake is not a good idea - CVS actually will do the job in a lot of cases. And if they are old-time UNIX guys, they probably remember some of the truly horrid version control systems from the past, and think that CVS is quite neat!

Towhead

You're obviously right: my first goal should be to address the existing issues. Actually the whole architecture is a mess, but it seems that some just say "could be worse" while I'd like to say "could be better". – Karate

It's not uncommon for people to experience problems, but not realize that they are problems and instead think that's just how things are supposed to be. – Tonita

Answer 5

File renaming/moving! Taken alone, I doubt this is a compelling reason to switch, but it did have serious implications on a project I was on, once.

See, CVS doesn't let you rename/move files. If you rename or move a file, CVS thinks that the old one disappeared and the new one appeared, and that there's no connection between them. Although there's no real loss of revision history, you'd have to know that "File X" was actually "File Y" if you go back before some certain date. Oh, and the version numbers all get reset.

The project I was working on was a open-source Java app which had just started small and grew and grew, so everything was just in the package "core.*". When the time came to re-factor and put stuff into a nice package hierarchy... well, CVS reset all of the version info because, as far as it knew, we had just deleted the whole "core/" folder and created a bunch of new files out of thin air.

Supposedly, SVN is aware of files being moved/renamed, so it doesn't break version lineage. Don't know if Git does this.

Slabber