Re: complex cvs import

[Robert Schiele <rschiele@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]

On Fri, Aug 22, 2008 at 02:13:22PM +0100, Luis Gutierrez wrote:
> Hi All,
>
> During the past year or so we have been using a bastardized version of CVS 
> in which branches were not 'true' cvs branches, but just a copy of the 
> original data in a different folder. For instance, we would have something 
> like this:
>
> ProjectX
>   \---- dev01
>   |       \... normal cvs data
>   \---- dev02
>   |       \... normal cvs data
>   \---- release01
>   |       \... normal cvs data
>   \---- release02
>           \... normal cvs data
>
> While a timeline of the branches looks like this:
>
>                /---release01
> ----dev01------+                /---release02
>                \---dev02------+--
>
> Now that we are trying to move to git, and I'm having problems importing 
> the projects with their full history.

I solved a similar situation about one year ago with the following script:

------
#!/bin/bash

set -eux

CVSREPOS=/path/to/cvs
REPOSDIR=~/gitmigration
export TMPDIR=$(TMPDIR=/dev/shm mktemp -d)

cvsimport()
{
    if [ "$2" ]; then
    GBR=$1_tmp
    cd $TMPDIR/checkout
    git branch $1_tmp $2
    else
    GBR=master
    fi
    git cvsimport -a -k -d $CVSREPOS -C $TMPDIR/checkout -i -A <(
    cat <<EOF
user1=One User <user.one@example.com>
user2=Two User <user.two@example.com>
EOF
    ) -o $GBR $1
    cd $TMPDIR/checkout
    git tag -d $3
    git branch -D $4
    git branch -m $GBR $1
}

rm -rf ~/.cvsps
cvs -d $CVSREPOS rtag -D '2002-06-07 20:41:34 +0000' rel1fork mainbranch
cvs -d $CVSREPOS rtag -D '2004-09-22 18:11:45 +0000' rel2fork rel1branch
cvs -d $CVSREPOS rtag -D '2003-10-22 20:44:21 +0000' rel3fork rel1branch
cvs -d $CVSREPOS rtag -D '2006-03-27 21:07:23 +0000' rel4fork rel3branch
cvs -d $CVSREPOS rtag -D '2005-10-28 22:00:18 +0000' rel5fork rel3branch
cvsimport mainbranch ''       fooxtag fooxbranch
cvsimport rel1branch rel1fork fooytag fooybranch
cvsimport rel2branch rel2fork fooztag foozbranch
cvsimport rel3branch rel3fork sometag somebranch
cvsimport rel4branch rel4fork inittag initbranch
cvsimport rel5branch rel5fork bartag  barbranch
cd $TMPDIR/checkout
git branch -m rel3branch master
rm -rf $REPOSDIR
git clone --bare $TMPDIR/checkout $REPOSDIR
touch $REPOSDIR/git-daemon-export-ok
echo 'My description' > $REPOSDIR/description
cat <<EOF >> $REPOSDIR/config
        sharedrepository = 2
[receive]
        denyNonFastforwards = true
EOF
find $REPOSDIR -type f -print0 | xargs -0 chmod g+u
find $REPOSDIR -type d -print0 | xargs -0 chmod g+u,g+s
cd /
rm -rf $TMPDIR
------

Some explanations:

1. If people start a new repository in cvs they often do so with cvs import
   (since this is the way it is documented) but don't use the created branch
   and tag at all.  Because of that cvsimport (the one from the script)
   removes them after importing.

2. The script requires the points in the tree to be tagged where you branched
   of one of your "special" cvs branches.  If you already have tags for that
   you are fine, otherwise you need to "reverse engineer" that place and tag
   this in cvs with something like

   cvs -d $CVSREPOS rtag -D '2004-09-22 18:11:45 +0000' rel2fork rel1branch

   which means rel2branch was forked off from rel1branch at point rel2fork

3. Now you import all the "special" branches with commands like

   cvsimport mainbranch ''       fooxtag fooxbranch
   cvsimport rel1branch rel1fork fooytag fooybranch

   The imports need to be in topological order of the branch dependencies.
   Thus you start with the oldest branch that exists in your cvs (mainbranch).

   Parameters are:

   - Branch to import.

   - Tag where this branch was forked off (or empty for main branch).

   - Tag that was created by cvs import and will be deleted after import.

   - Branch that was created by cvs import and will be deleted after import.

4. There is a line

   git branch -m rel3branch master

   in the script that is supposed to rename your "main" branch to master
   (since this a convention in git).  This is technically not required and
   might make no sense depending on your workflow.

I hope this is useful for you.

Robert

-- 
Robert Schiele
Dipl.-Wirtsch.informatiker	mailto:rschiele@gmail.com

"Quidquid latine dictum sit, altum sonatur."

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]