0

I am investigating trying to get my team at work to move from CVS to SVN, in my opinion SVN has many advantages over CVS however moving a legacy system and team from something that has been used for 10+ years will prove difficult.

I'm trying to second guess questions that will be asked when I present why we should move to SVN and was wondering if you could fill in appropriate answers (or even why SVN is worse at this).

I'll also try to explain the way we work at the moment and would appreciate it if you could say what will have to change!

Currently we have to main sections of our CVS, HEAD (Production) and testing (TEST)

Code from TEST is built nightly and if the build succeeds is tagged with a new CVS tag. Once we are happy with it we pull that tag from TEST into HEAD and then make a final build and deploy to users.

We extensively use the CVS $Header$ feature, which often causes collisions when merging with code (especially reverse merge).

As CVS deals with files individually rolling back a broken commit (or even seeing the files changed) proves very difficult (file by file).

On check-in CVS tends to think you've touched lots of files that you haven't gone near

In summary, how will changing to SVN affect us?

Thanks for your time,

Pez Cuckow
  • 14,048
  • 16
  • 80
  • 130

1 Answers1

1

We extensively use the CVS $Header$ feature, which often causes collisions when merging with code (especially reverse merge).

Subversion is smart enough to ignore expanded keywords in performing merges & diffs.

As CVS deals with files individually rolling back a broken commit (or even seeing the files changed) proves very difficult (file by file).

Because of how Subversion revisions are stored/committed, it's actually easier to roll back an entire commit (revision) than to cherry-pick individual items from a single commit (or even a group of commits) to roll back. See http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

On check-in CVS tends to think you've touched lots of files that you haven't gone near

I can't say I've ever seen this with Subversion. Perhaps CVS is picking up the changes because the last modified time has been changed, but the file contents haven't? Subversion uses the file's mtime to determine if a change may have happened, then performs an MD5 comparison between the current copy & a pristine copy of what last came from the repository. If the mtimes don't match, but the MD5s do, it's not flagged as a change.

alroc
  • 27,574
  • 6
  • 51
  • 97