Re: Subversion

Rafael Garcia-Suarez wrote:

> Arthur Bergman wrote:
> 
>>First of all, checking out parrot using subversion takes at least 4 
>>time slonger than CVS
> 
> 
> AFAIK the svn developers are aware of this, and they say that people
> don't checkout that often anyway (moreover I think one can enable
> mod_deflate over mod_dav_svn).

Actually, enabling mod_deflate at the moment is a bad idea.  You'll end 
up tripping a bug in mod_deflate where it buffers data up to the point 
that svn times out because it thinks it isn't getting anything back. 
It's been fixed in dev versions of apache, but a release hasn't occured yet.

>>Doing a vendor checkin brining up parrot to latest version is a major 
>>pain the arse. The process alone of running svn_load_dirs takes around 
>>an hour, and then I have to tag it (because if you tell svn_load_dirs 
>>to tag things automatically it breaks). It also seems not to have 
>>changed some stuff when other stuff has changed! 
>>(http://svn.perl.org/ponie/vendor/parrot/current/config/auto/gcc.pl is 
>>one file that should have been updated).
> 
> 
> Last time I looked at svn_load_dirs.pl I decided not to use it. That was
> some time ago, though. Now, I merge by hand (I have not to do this very
> often) by untarring the source package in a working copy.

That's also what I do, but if you're having problems with 
svn_load_dirs.pl, I'm sure the author is listening to 
[email protected], so feel free to report them there.  Also you 
might try just importing the versions independent of each other and 
using the "--ingore-ancestry" option to 'svn merge' (i believe this is 
the default in the next version of svn, but you need the flag for now). 
  This will keep svn from being pedantic about only merging changes when 
the new version is related to the old one.

If you have trouble getting this to work correctly, feel free to mail 
[email protected], and someone will be happy to explain the 
process in detail, or just wait till tonight when I get out of work and 
I'll do it myself.

>>Committing two files took 1 minute 22 second yesterday, a checkout is 
>>extremely painfully slow. I am very close to saying it is a failed 
>>experiment and either go to p4 or cvs for the time being.
> 
> 
> That's weird.
> The commit in svn is done in two phases :
> a - if you haven't specified any target, svn scans recursively all
>     subdirectories to find modified files -- this can take a lot of
>     time, esp. on a slow disk. In other words, C<svn ci foo.h bar.c>
>     is *a lot* faster than C<svn ci .> at the root dir of your large
>     project.

I've been talking to Arthur about this offline, and while he says he did 
do just an 'svn commit' in this case, most of the time was spent in the 
'already talking to the network' part of the commit, so it most likely 
isn't the scan of the subdirectories.

> b - svn transfers a diff to the svn http server. This is usually fast
>     (unless, of course, you're checking in large binary files etc.)
> 
> 
>>A very angry Arthur who has spent far too much time battling an 
>>substandard versioning system. (which might be theoretically very nice, 
>>but does not scale)
> 
> 
> Remember, I had scaling worries.

I mentioned this discussion over on the svn dev list, and the general 
feeling was "please report any issues you encounter, so we can fix 
them".  Finding out because some of us happen to follow these lists 
isn't the most reliable way to get bugs fixed.

-garrett