tech-repository archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pkgsrc-wip conversion
Hi Eric!
I'm the main pkgsrc-wip administrator, and would like to convert away
from CVS to git or hg (slight preference to hg because I prefer its
command line, and think I know how to set this up as a server and
givelots of people access to it -- wip currently has over 400
committers).
I have converted the pkgsrc-wip repository (available via rsync at
rsync://pkgsrc-wip.cvs.sourceforge.net/cvsroot/pkgsrc-wip/) to fossil
using Jörg's cvs2fossil, and then made a git repository from that, and
a hg repository from the git repository (using the hg-git extension;
'hg convert' is buggy when converting this repository from git).
I went this roundabout way because 'hg convert' doesn't like the wip
CVS repository, and the hg fastimport extension doesn't support all
fastimport stream commands generated by fossil for wip.
This conversion process gives me identical checkouts in all steps
(fossil, git, hg) (last tested with a repository from June 6 this
year).
When looking at the repositories with tortoisehg or gitk, the branches
don't look too nice to me. I'm not completely sure if they are correct
or not, but at least at some points they look weird (gitk: some files
are on branches on which I wouldn't expect them; tortoisehg: doesn't
look like I would expect it at all, but perhaps that's a result of the
convoluted conversion process).
I think the repository is basically "nice" (no hand-editing AFAIK
except complete removal of some *,v where files were imported into
wrong paths).
There is one particularity with it: In pkgsrc and thus in pkgsrc-wip
it was common to 'cvs import' new packages. The Vendor tag for wip was
the sourceforge username, the Release tag the sourceforge username
with the import date attached, for example THOMASKLAUSNER and
THOMASKLAUSNER__20140701 (for pkgsrc itself, the tags were usually
"TNF" and "pkgsrc-$DATE"). We've changed away from that and are using
'cvs add' for some years now.
I'm not sure it's worth keeping these branches, since they basically
were just artifacts of the process and do not contain information. I'm
fine with keeping them though, if that's easier, but I'd prefer that
they should be marked dead/obsolete/closed (hg supports that for
branches, not sure about git).
I'd be interested in your comments, and help in getting a better
conversion done, if possible.
Thanks,
Thomas
Home |
Main Index |
Thread Index |
Old Index