"atomic commits" is accurate -- the transactional part is a consequence of it. It's just that, in this case, the side-effect is cooler than the "primary" feature.
But you're right in that it is different than most databases where you can't usually get to the transaction information once it's committed; in SVN the revision number is (effectively) the transaction id. In fact, what SVN stores is more a "transaction log" than anything. ----- Original Message ----- From: "Vadim Gritsenko" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, June 11, 2004 9:17 AM Subject: Re: CVS and Subversion > 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. > > > >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. > > > > > > So, original mail ("atomic commits!") was misleading. It is really more > about "SVN stores transaction log", but not about "atomic commit". > Compare with databases, were transactions are atomic - but once > committed, there is no way (usually) to find out which records were > modified as part of transaction. > > Thanks for clarification. > > Vadim > > > >-Jim Moore --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
