Re: [ECOS] What's the process on switching version control system for eCos?

[Alex Schuilenburg <alexs at ecoscentric dot com>]

Bart Veer wrote on 2009-09-22 15:34:
> [...]
> 1) cvs is known to be broken in various ways, and sourceware.org has
> run with various revisions of cvs with different bugs over the years.
> Hence a full import of the current cvs repository into the proposed
> system is likely to be problematical. More precisely, it probably
> won't be too hard to get to a state where it is possible to check out
> something equivalent to the current cvs trunk; however, replicating
> the full history of the repository on all branches will be much more
> difficult. So:
>
>   a) how much effort will be contributed to minimize the loss of
>      history?
>   
As I now have a perl script that uses cvsps and cvs to reconstruct every
checkin, as well as fix checkouts of "tagged" releases and files
missing/added to branches/trunk because of CVS bugs, I don't anticipate
history will be lost.  In fact I expect history to be gained because of
the fixes ;-)

>   b) how much history can we expect to lose, irrespective of the
>      amount of effort put in?
>   
Only what cvsps misses, or rather, does not know what to do with (google
CVSPS_NO_BRANCH for details). Those files or changes are basically
orphaned.  However, I will send a list of the files along with their
revisions to the maintainers and you can decide what to do with them.

> 2) sorting out the repository itself is only part of the problem. The
> web pages will need updating. There will almost certainly be teething
> problems early on, e.g. the system may fail to work for some people
> because of firewall issues. Can we expect any assistance with issues
> like those?
>
> So, a suggestion that e.g. eCos should switch over to git because it
> is already in use on other projects is unlikely to get much attention
> from the maintainers. A serious offer to do the hard work will get
> much more attention, especially if it is backed up with experimental
> data and explanations of why some of the problems with cvs are just
> too hard to work around.
>   
My offer in my previous email is serious.  Little skin off my nose and
most CPU cycles are free.  I have already developed my script in-house
for an internal conversion and so we can evaluate the different DRCS
systems.  What the maintainers or community choose to do with the repo
is up to them, but moving an hg repo to sourceware will be has hard as
"hg clone http://hg.ecoscentric.com/ecos";, while converting it to git or
bzr a matter of exporting the patchsets (this time without error) from
hg after cloning it and importing them.

I guess I can summarise what problems were found within CVS during the
script's conversion, illustrating why "straight-forward" automated tools
like "hg convert" and other equivalents would not work.  It took all of
5 minutes to do a straight convertion with hg and a 30 second "diff -q
-r -x .hg -x .hgtags -x .cvsignore -x CVS <cvs-co> <hg-co>" to show that
a "straight-forward" conversion does not work.

-- Alex Schuilenburg

   >>>> Visit us at ESC-Boston  http://www.embedded.com/esc/boston <<<<
   >>>> Sep 22-23 on Stand 226  at Hynes Convention Center, Boston <<<<

       >>>> Visit us at ESC-UK  http://www.embedded.co.uk <<<<
       >>>> Oct 7-8 on Stand 433 at FIVE ISC, Farnborough <<<<


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss