Arguments to convince to switch from CVS to SVN

views:

156

answers:

+6 Q:

Arguments to convince to switch from CVS to SVN

Hi,

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.

+1 A:

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.

Roger Pate 2010-04-13 09:16:31

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.

Noon Silk 2010-04-13 09:18:58

@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.

Roger Pate 2010-04-13 09:19:51

@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.

Noon Silk 2010-04-13 09:21:37

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.

ereOn 2010-04-13 09:23:40

@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.

Roger Pate 2010-04-13 09:32:17

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.

ereOn 2010-04-13 09:37:55

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.

Tomislav Nakic-Alfirevic 2010-04-13 10:23:19

+4 A:

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.

sharptooth 2010-04-13 09:25:11

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

ereOn 2010-04-13 09:26:37

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

Roger Pate 2010-04-13 09:27:41

Ok, thanks for the update ;)

ereOn 2010-04-13 09:31:55

+1 A:

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!

anon 2010-04-13 09:29:28

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".

ereOn 2010-04-13 09:34:18

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.

Michael Borgwardt 2010-04-13 09:35:05

+4 A:

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)

Mnementh 2010-04-13 09:30:45

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 ?

ereOn 2010-04-13 09:41:08

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

Mnementh 2010-04-13 10:23:19

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.

Bert Huijben 2010-04-13 10:28:49

ansaurus

tags:

views:

answers:

Arguments to convince to switch from CVS to SVN

related questions