Re: Subversion on container

On จ., 2005-06-20 at 11:39 +0700, Ross Golder wrote:
> 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.

I found a bit more spare time to work on this today. More details can be
found on the following page:

To summarise:

- There is now read-only Subversion access to the modules (as they were
at the point at which they were most recently 'cvs2svn'ed). The
subversion http URL scheme is:[modulename]

If/when we switch to subversion, to provide SVN+SSH (write) access to
our 'gnomecvs' members, we would need to change the
"command='/usr/bin/cvs server'" command override (see sshd(8)) we apply
to their keys to a more subversion-appropriate command override (I
guess). I'm not yet sure what (I haven't RTFMed that bit yet).

- I bolted on a 'viewcvs' instance, so we can see things more clearly:

- I prepared some 'subversion commits update the website' scripts. The
viewcvs area is being kept up-to-date using roughly the same approach as
for the CVS-based sites. I wrote a single python '' script
to replace the 'cvs-update-*' perl-based scripts used for the CVS-based
sites. If/when we go live with subversion, getting our sites to stay
current with their subversion module shouldn't be a problem.

- Still not confident with the 'cvs2svn' runs. I've updated the
migration script I use to dump the stderr/stdout in a directory, which
I've made accessible here:

We need to examine this and work out whether any of these
warnings/errors are important, or whether we can ignore them. Some
modules are failing to convert (e.g. evolution), so those problems would
certainly need to be investigated and fixed.

I've now started a migration run for all the CVS modules so we can see
what else shakes loose. Comments and suggestions welcome for the next
rare opportunity that I have some spare time to work on it :)


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