Darcs repository migration to GitLab: proposed approach

Erik Huelsmann ehuels at gmail.com
Fri May 15 20:39:53 UTC 2015


Hi all,


As proposed earlier this year [1], common-lisp.net will stop running
darcsweb repository browsing and in fact will stop "supporting" Darcs
completely. As a result, it makes sense to the common-lisp.net admins to
convert projects with Darcs repositories to Git+GitLab, as that's the only
remaining DVC option on the system.

This is my current thinking with respect to the migration. The migration is
inspired on the approach with the CVS migration with the notable exception
that I do not envision offering projects to migrate to Subversion (offering
only to migrate to Git+GitLab where we supported both Subversion and Git
for CVS migration). Offering to migrate to Subversion doesn't seem to make
sense as it would mean migrating to a centralized VC from a decentralized
one.


These are the steps that I forsee in the preparation of the migration:

 1) Determine if there are any Darcs source repositories that map to
existing target repositories,
   e.g. because equally named Git repository which was already migrated to
GitLab
 2) Run a few test conversions on a test-installation
   *** looking for volunteers to help out validate the conversion-runs ***
 3) Post a full listing of all paths which will be affected by the
conversion on the common-lisp.net
   site for review by anyone interested

These are the steps that I forsee for the migration itself:

 1) One week before migration: notify the affected project/user of the
intended migration date
    [requesting projects/users to remove any repositories that should not
be migrated]
 2) Migrate the repositories as announced
   * Repositories in /home will be migrated to individual user accounts
   * Repositories in /project will be migrated to GitLab groups
 3) Send migration confirmation to the respective affected users/projects


As some users and projects seem to use Darcs repositories to manage their
public_html directories, my current thinking is to convert those
repositories, but leave these in-place so projects can replace them with
git check-outs at a later date


Same as with the CVS migration, it's likely that the migration/conversion
of repositories will be executed in batches.


[1]
https://mailman.common-lisp.net/pipermail/clo-devel/2015-February/000934.html


Could you provide me with your questions and opinions?


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20150515/b7b7d172/attachment.html>


More information about the clo-devel mailing list