On 11 Jun 2004, at 22:02, Jim Moore wrote:
Actually, the "all or nothing" part of the transaction isn't a big deal because, as you said, it's very rare that a commit in CVS would fail.
Problem being (though) is that I've seen Subversion (1.0.2 under Linux) fail right because of that... Somehow an "atomic" transaction was left open on the server, don't ask me why...
Basically, after that commit failed, the entire repository was so slow that most TCP/IP connections were failing after 3 minutes for timeouts...
Only solution was to run a "svn recover" followed by a "svn rmtxt" and again followed by another "svn recover"...
That is when I started feeling that having all my history in big berkeley DB files which I could not "cat" was kinda scary...
But on the other hand, we (VNU, at work) are still using subversion because of all its other features (moving, copying, tag^H^H^Hbranch^H^H^H^H^Hcopying) and its quite impressive speed over slow/remote networks...
Pier
What is VERY cool about the atomic part is that all of your files in the
commit are part of the same transaction. With CVS it's a very difficult to
determine what files were committed together. Take a look at what the
cvs-commit email program has to do in order to send out a single email for
all the files you've committed to see an example, where it has to make a
bunch of assumptions like "What other files have the same commit message?"
and "Were they committed at the same time (give or take a few seconds)?"
Reasonably intelligent changelog reports have the same problem, but they
have to do that for every file. Fortunately there are (nasty) perl scripts
for figuring that kind of thing out, but it's simply a non-issue with SVN.
If you want to know what other files changed as part of rev 1234 you simply
ask the server what other files were part of that transaction since it
handles them all as one unit instead of bunches of seperate ones. (Another
place it's nice is that if you have integration between your defect system
and CVS you have to associate each file and rev back to the defect, whereas
with SVN you only need to rev number as the files are implicit.)
When I'm in "user" mode, I love the "move/rename keeps history" that Brian
mentioned and don't really care about atomic/transactional commits.
However, when I'm doing tools & project administration, that's when the
transactions really rock.
-Jim Moore
----- Original Message ----- From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, June 11, 2004 8:21 AM Subject: Re: CVS and Subversion
Ceki G�lc� wrote:
Heu.., a couple of questions from the totally ignorant (me).
1) what is an atomic commit? Do I need to wear a irradiation-protective suit to use it?
"Atomic" as in "transaction" -- either all or nothing, should not crash
in-between. I've not seen such crashes with CVS, but apparently other
people encountered them.
2) How easy is it to migrate an existing CVS repo to subversion?
infra has nifty scripts to convert everything including branches and history.
Vadim
Thanks in advance for your response, even if it is RTFM.
At 01:04 PM 6/11/2004, Brian McCallister wrote:
I think the best way to sell Subversion is "atomic commits" and "move/rename keeps history" (big seller to the Java "we love cheap rename in [Eclipse | IDEA | JDEE]" crowd) ;-)
Now we just need to talk about adding dummy -dP flags to update so that I can stop getting errors...
Did I mention "atomic commits" ?
-Brian
ps: atomic commits
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
