One of the reasons why programmers prefer SVN over CVS is the former allows atomic commits ? What does this mean ?
Asked
Active
Viewed 7,019 times
35
-
[This might help someone](https://medium.com/@fagnerbrack/one-commit-one-change-3d10b10cebbf), it explains what it is (it uses git as an example, but might be able to be applied for other VCS) – Fagner Brack May 07 '16 at 13:55
3 Answers
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.
Michael Kohne
- 10,038
- 1
- 36
- 45
-
9An 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 04 '12 at 12:35
-
2
-
@JoachimSauer It should be pointed out that while checking out either gets you all the changes or none local changes might still result in a conflict. Which need to be resolved. This though has nothing to do with the atomicy feature and can occur with or without it. – Th 00 mÄ s Sep 04 '12 at 13:12
-
@ThomAS: true, I was mostly thinking of the use-case of a CI-environment: check out/update into an unmodified/clean copy of the source. – Joachim Sauer Sep 04 '12 at 13:14
-
1Oh, broken state check-ins can happen in SVN all right... While atomic commits are nice and all, but there are ways to circumvent this in SVN; since you can select what files to add/remove/commit in SVN thus changing the changeset, the repository can be left in a broken state due to programmer lazyness or stressy situations. I'm usually filled with rage when someone do these kinds of commits and leaves the build broken. – Spoike Sep 04 '12 at 13:21
-
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 04 '12 at 13:31
-
1Does CVS commit files one at a time; or try and commit them all at once but fails messily? Rational Clearcase does the former and I'm curious about the relative levels of fail. – Dan Is Fiddling By Firelight Sep 04 '12 at 13:40
-
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 04 '12 at 13:49
-
1@shabunc - At least it wasn't [VSS](http://www.highprogrammer.com/alan/windev/sourcesafe.html)! – CraigTP Sep 04 '12 at 15:04
-
@Spoike: Name one VCS where you can't get the same kind of issue when someone forgets to add a new file to the repository. – SamB Sep 04 '12 at 16:03
-
4Also, 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 04 '12 at 16:09
-
@SamB: VMS, which has version control built into the file system, so saving a file adds it to version control (not that it's truly a panacea either, but it does prevent that particular problem). – Jerry Coffin Sep 04 '12 at 18:30
-
2@Spoike That isn't "broken state" from the perspective of the repository. It's a perfectly good state that happens to have bugs or fail at compilation because of a programmer error. With CVS, you can get inconsistencies even if there is no programmer error. – Andres F. Sep 05 '12 at 17:10
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.
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.
-
isn't it a good thing then ? Otherwise a partial commit would result in files being out of sync . – Geek Sep 04 '12 at 12:24
-
2