Re: Subversion on container

On จ., 2005-06-20 at 03:46 +1000, Jeff Waugh wrote:
> Hi,
> Could the sysadmin team please investigate the creation of a Subversion repo
> on container with ssh access (as per current CVS configuration), and perhaps
> try one of the CVS conversion scripts to see whether a module of reasonable
> age, branchiness and complexity (maybe gnome-panel would be a good choice)
> migrates sanely.

One repo? I was considering having one Subversion repo per CVS module.

I installed Subversion etc on container already, and started playing
with cvs2svn on a small cross-section of modules. I chose the 'test'
module (<1Mb of raw CVS), 'gtranslator' (IIRC, about ~20Mb) and
'evolution' (huge!). I ran cvs2svn on each module and obtained the
'.dump' files you see in /svn/gnome, which were used to create the
repositories there.

There were several warnings/errors on importing the larger two modules,
mostly due to tags and branches with conflicting names etc. The output
of 'cvs2svn' for each can also be found in /svn/gnome. I've copied them
here for people to see: (~1K) (~128K) (~930K)

There's nothing really ready for public SVN+SSH consumption just yet.
I'll try to find some time next weekend to take it further. In
particular, the evolution conversion failed to produce a SVN dump file,
so I'll need to look into why that was. It was late when I did this, and
I haven't had much spare time since. Next time, I'll add 'gnome-panel'
to my cross-section of test conversions.

> None of the existing scripts seem to be particularly good for migration of
> long-running projects like ours, but I've heard reports that the cut-and-run
> approach [1] has annoyed projects after migration (such as Samba). We'll
> have to figure out which path suits us better, and the only way we're ever
> going to get traction on this is to test it out.

I think it would be a great shame to lose the history. There's no real
urgency to switch to Subversion, so let's spend a little time ironing
out any problems involved in importing the complete history, so we can
still do a 'svn log' with some degree of certainty, and any new
SVN-based viewcvs will give the full picture etc.



> Thanks,
> - Jeff
> [1] Checking in the latest code, not migrating historical data.
> [2], you should also check James Henstridge's recent blog
>     entries about using baz -> it's easy, don't be scared by the ravings of
>     version control geeks.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]