www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: CVS and Subversion
Date Fri, 11 Jun 2004 15:45:31 GMT
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 

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...


> 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" <vadim@reverycodes.com>
> To: <community@apache.org>
> 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: community-unsubscribe@apache.org
> For additional commands, e-mail: community-help@apache.org

View raw message