35

One of the reasons why programmers prefer SVN over CVS is the former allows atomic commits ? What does this mean ?

Improve this question
1

3 Answers 3

Reset to default
69

It means that when you do a commit to the version control system either everything you want to commit goes in, OR nothing does.

In CVS, when you try to commit it's possible for the commit to succeed on several files, then fail on several others (because they've changed). This leaves the repository in an unfortunate state because half of your commit isn't there, and it's likely that you've left things in a state where they won't compile or worse. Now you've got to hurry up and integrate whatever changes so that you can commit the other files before someone else needs to update and gets your broken set of changes.

In SVN this won't happen - SVN will either commit everything you've changed, or it will fail the whole changeset. Thus, you'll never leave the repository in a broken state due to commit issues.

Improve this answer
13
  • 9
    An important result of this is that if you check out in any given state then the result is always a consistent state (barring any user-mistake such as forgetting to commit a file, of course): It's either from before the commit or from after the commit and nothing in between. In CVS it could be from "half-way through the commit". The SVN behaviour is very nice for things like continuous integration. For CVS systems those systems used to enforce a "quiet period" where they only used a given check-out if no more commits where done a given number of seconds/minutes after the checkout.
    – Joachim Sauer
    Sep 4, 2012 at 12:35
  • 2
    dark memories on using CVS stroke me while I've been reading this.
    – shabunc
    Sep 4, 2012 at 12:47
  • 9
    @Spoike - true, but that's a deliberate act. In CVS, problems can happen through no fault of your own, while in SVN you have to work at it.
    – Michael Kohne
    Sep 4, 2012 at 13:31
  • 3
    @DanNeely - CVS commits them one by one. That's why you get partial commits - some of the files go through, then it stops when it hits one that it can't commit (due to a conflict). It's a result of CVS having originally grown out of RCS, I think.
    – Michael Kohne
    Sep 4, 2012 at 13:49
  • 4
    Also, note that with CVS, even if you don't hit an error and everything gets committed, someone with a faster connection could update their source tree halfway through the commit, leaving them in an inconsistent state. (And I expect the timestamps would be just as spread out, so that trying to check out the tree as-of a date/time that fell in the middle of a commit would have similar results.)
    – SamB
    Sep 4, 2012 at 16:09
15

This is explained eg in Bye-bye CVS. I've been Subverted article written by Andy Lester:

If I try to commit in Subversion, but one of the files has a conflict, or is out-of-date, none of the files commits. In CVS, you’ve got a half-commited set of files that you have to fix RIGHT NOW.

The fact that CVS forces programmer to fix the merge immediately is as counter-productive as it gets. Compared to that, an option to delay / cancel / carefully merge changes is a substantial benefit.

Other benefits of SVN over CVS explained in above article are:

  • Local versions of everything you do
     
    If you want to cvs diff, you have to be able to connect to your repository. No net connection, no diffing. Subversion stores local pristine copies of what you’re working on, so svn diff will work just fine. Want to start over? svn revert works unconnected, too.

  • Symbolic names of revisions
     
    HEAD is the name of the tip of the trunk in CVS, but I’ve always wanted to be able to say “-r-1″ like I could way back when in PVCS days. With CVS, I have to do a cvs log on what I’m editing, and then subtract one. That’s no fun. With Subversion, I can say svn diff -r PREV.

  • Real status reporting
     
    In CVS, the only way you can see if something on the server is newer is to cvs update and hope that whatever comes down doesn’t cause any conflicts. With the svn status command, I get real status, so I can see if there are conflicts BEFORE I do an update.

  • Helpful handling of merge conflicts
     
    In CVS, if there are conflicts, you get conflict markers in your file. In Subversion, you get conflict markers, PLUS a copy of your original, pre-conflict file, PLUS the version that came down from the server, PLUS the version that you were originally editing. Then, you must explicitly svn resolve filename.txt to tell Subversion that you’ve fixed the problem. No more accidentally commiting back into CVS with conflict markers still there.

Improve this answer
8

It means that all changes to all files are committed in a single transaction, so either all succeed or none.

This means that you are less likely to get partial edits checked in to the repository which cause builds to fail. You can still get people forgetting to check in all the relevant files, but that's a process issue rather than a problem with the versioning system.

Improve this answer
2
  • isn't it a good thing then ? Otherwise a partial commit would result in files being out of sync .
    – Geek
    Sep 4, 2012 at 12:24
  • 2
    yes its a good thing, partial commits are bad
    – jk.
    Sep 4, 2012 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.