Subversion/CVS experiment summary

[Stijn Hoop]

On Mon, Feb 09, 2004 at 01:26:45PM -0600, Craig Boston wrote:
> On Monday 09 February 2004 11:53 am, Stijn Hoop wrote:
> > Did you have to modify the script, or pass unusual options? I'd like to
> > reproduce this, but I didn't get very far when I tried a few days ago with
> > the 0.37.0 version of the tool.
> 
> No, I used the script as-is.  The version I have is
> LastChangedRevision: 8527, with a date of Jan. 29.  It looks like that
> version is slightly newer than the one included with 0.37 (Rev 8512).

Well, that explains a lot -- for some reason I tested using
$LastChangedRevision: 7921 $. I'll try with an up-to-date one then.

> One thing that may have made a difference is that so far I've been importing 
> things in chunks rather than trying to do the whole repo at once.

Yes, I was afraid though that commits might have spanned subtrees. But then
again, even if they did they would just get committed as separate revisions
to the tree, and I suppose one could live with that.

> > but although it looks like it handles things much better (even vendor
> > branches etc), it loads EVERYTHING into memory -- which means that it
> > eventually grew to 1G of memory/swap at which point my memory was
> > exhausted, and this was at pass 2 of 7...
> 
> Does the Python version do the same thing?  I didn't think to look at memory 
> usage very closely while it was running :-/

As far as I understood it builds a disk cache instead of using malloc().
This might explain the slowness :)

> > My thoughts were now going to do something like Tom Lord proposed for an
> > Arch gateway -- just import a CVS working copy into SVN at a certain
> > cut-off date, and setup a bi-directional gateway between the two.
> 
> If I'm reading that right, it sounds similar to a thought I had about just 
> routinely checking out snapshots and committing them on a vendor branch.
> Of course you'd have to do that separately for each branch you're interested
> in.

Yes, that's the idea. You 'just' need a tool that can determine changesets
from a CVS repository to automate this. See

http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree

but substitute Subversion for arch :)

> IMO, I find it immensely useful to have the entire history of a file at hand.

But you do have all history of a file at hand; you just need to have a
separate version system for the older history. Which is admittedly a bit
unwieldy, but it certainly makes for a smooth transition in the distributed
repository case...

> > Actually, would a sort of access control wrapper that is now also used with
> > the FreeBSD CVS repository not work? I do agree that it would be nice to
> > have per-directory access control with the svnserve method.
> 
> Yes, I think the same sort of access hooks (pre-commit?) can be used.  The 
> Subversion manual even mentions that, I just forgot about it...
> 
> That method has always seemed a little... hackish to me.

It is, but it does work. Maybe I'll test and see if I can 'port' those
scripts to Subversion :)

--Stijn

-- 
My server has more fans than Britney.
		-- Steve Warwick, from a posting at questions at freebsd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20040209/00b79a00/attachment.bin