Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualsamoth

Posted 22 January 2013 - 12:59 PM

No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations.
I don't get you. If you commit 20 files, Subversion first looks whether any of the 20 files was committed by anyone else in the mean time. If that's not the case, the commit will succeed, atomically, for all 20 files.

If any single file has been touched by anyone else in the mean time, the commit fails with "out of date, please update". A properly configured client will run the update automatically, too. Now changes are merged automatically to your working copy, if possible, or you are prompted to resolve conflicts. After resolving conflicts, you commit a second time. And, again, this will succeed (for all 20 files) or fail.

Of course you can commit 20 files one-by-one. No, that won't be atomic, what a surprise. But it won't be atomic in any other revision control software, either.

Same is true for branching. Yes, branching is (logically, not technically) a copy of a complete directory, so what? It has no bearing, there is no such thing as a half-copy. Branching "copies" all data to a new directory, but in reality it only creates a virtual directory referencing the files of the current revision. Concurrent commits to trunk (or to whatever) add new versions (with a higher revision number) to the original directory, which has absolutely no bearing for the copy.

Besides, this is the exact same way Git works internally. Torvalds only called things "tree object" and "blob object" rather than "file" and "directory", but they're still the exact same things working in the same way.
If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.
One of the toy projects that's never going to released and that I'm involved with had 40k downloads last week. It has slightly over 7400 files (including some non-source files) with 1.1 million lines of text/code. Doing a complete, pristine checkout takes 1m35s (tried just now). Too slow for you? OK, fair enough.

But that isn't the fault of Subversion, it's reality. This project's repo is served via WebDAV/SSL (which is pretty much Subversion's slowest possible mode of operation) on a MuchoCheapo-class server located on a different continent. Downloading lots of stuff over the internet takes time. So what, nothing surprising there. Git can't do the job any faster or better (and if someone says it does, he's either comparing apples and oranges, or just lying).

Checking out a slightly smaller (about 15%) toy project that I'm involved with, from the above mentioned server on the LAN takes 16-17 seconds. Again, not surprising, because that's close to the peak bandwidth that the NAS delivers. Downloading a .tar file of comparable size is maybe a second or two faster, not more.

Branching either of these toy projects takes about 1-2 seconds, plus the time to check out the new branch (though that time is close to zero, if you switch rather than checking out anew). So, what exactly are you trying to tell me? Your harddisk is faster than the internet? Wow, I'm shocked.

You really have to compare apples and apples, not apples and oranges. Is "branching" very fast with Git? Of course, but only because you are not branching when you're telling that you are. The act of branching involves making a copy and communicating changes to others. Half of that process is "forgotten" in the comparison.

Now of course, merging is another story. Merging usually takes days, literally. However, that's just what happens when people edit both branches without discipline. There are conflicts, and conflicts must be merged or resolved. When they cannot be merged automatically, a human has to do them by hand. That's just what it is, nothing surprising again, and Git can't do "magic" in that case either.

On the other hand, we have for example images tagged with svn:needs-lock, which is a form of "magic" that Subversion will trivially do for you, and that Git can't do at all.

To avoid a misunderstanding: Again, I'm not saying that Git is an inferior revision control system. I'm not opposing to Git as such. If you want to use it (either because of political reasons, or because you have a very special need and it really does just what you need), that's fine with me.

I'm only opposing to the Torvalds-style "Git is God's Gift to Humanity, everything else is shit" propaganda. Everything else is not shit.

Every system has its advantages and disadvantages, but they all have their legitimate place, and they all (well, almost all... my experience with RCS was truly traumatizing) work reasonably well for most people.

#1samoth

Posted 22 January 2013 - 11:33 AM

No, svn commits are not atomic. I can commit a set of changes to git/hg/bzr/darcs as one single atomic operation, and then uncommit/revert in one single atomic operation, or cherry-pick and apply in one single atomic operation. If I'm using svn and commit a changeset of say 20 files, then I get 20 single commit operations.

I don't get you. If you commit 20 files, Subversion first looks whether any of the 20 files was committed by anyone else in the mean time. If that's not the case, the commit will succeed, atomically, for all 20 files.


If any single file has been touched by anyone else in the mean time, the commit fails with "out of date, please update". A properly configured client will run the update automatically, too. Now changes are merged automatically to your working copy, if possible, or you are prompted to resolve conflicts. After resolving conflicts, you commit a second time. And, again, this will succeed (for all 20 files) or fail.

Of course you can commit 20 files one-by-one. No, that won't be atomic, what a surprise. But it won't be atomic in any other revision control software, either.

 

Same is true for branching. Yes, branching is (logically, not technically) a copy of a complete directory, so what? It has no bearing, there is no such thing as a half-copy. Branching "copies" all data to a new directory, but in reality it only creates a virtual directory referencing the files of the current revision. Concurrent commits to trunk (or to whatever) add new versions (with a higher revision number) to the original directory, which has absolutely no bearing for the copy.

 

Besides, this is the exact same way Git works internally. Torvalds only called things "tree object" and "blob object" rather than "file" and "directory", but they're still the exact same things working in the same way.
 

If you have a toy project or a small hobby project that's never going to get released, this may not be a consideration for you.

One of the toy projects that's never going to released and that I'm involved with had 40k downloads last week. It has slightly over 7400 files (including some non-source files) with 1.1 million lines of text/code. Doing a complete, pristine checkout takes 1m35s (tried just now). Too slow for you? OK, fair enough.


But that isn't the fault of Subversion, it's reality. This project's repo is served via WebDAV/SSL (which is pretty much Subversion's slowest possible mode of operation) on a MuchoCheapo-class server located on a different continent. Downloading lots of stuff over the internet takes time. So what, nothing surprising there. Git can't do the job any faster or better (and if someone says it does, he's either comparing apples and oranges, or just lying).

Checking out a slightly smaller (about 15%) toy project that I'm involved with, from the above mentioned server on the LAN takes 16-17 seconds. Again, not surprising, because that's close to the peak bandwidth that the NAS delivers. Downloading a .tar file of comparable size is maybe a second or two faster, not more.

Branching either of these toy projects takes about 1-2 seconds, plus the time to check out the new branch. So, what exactly are you trying to tell me? Your harddisk is faster than the internet? Wow, I'm shocked.

Now of course, merging is another story. Merging usually takes days, literally. However, that's just what happens when people edit both branches without discipline. There are conflicts, and conflicts must be merged or resolved. When they cannot be merged automatically, a human has to do them by hand. That's just what it is, nothing surprising again, and Git can't do "magic" in that case either.

 

On the other hand, we have for example images tagged with svn:needs-lock, which is a form of "magic" that Subversion will trivially do for you, and that Git can't do at all.


To avoid a misunderstanding: Again, I'm not saying that Git is an inferior revision control system. I'm not opposing to Git as such. If you want to use it (either because of political reasons, or because you have a very special need and it really does just what you need), that's fine with me.

 

I'm only opposing to the Torvalds-style "Git is God's Gift to Humanity, everything else is shit" propaganda. Everything else is not shit.

Every system has its advantages and disadvantages, but they all have their legitimate place, and they all (well, almost all... my experience with RCS was truly traumatizing) work reasonably well for most people.


PARTNERS