complex cvs import

complex cvs import

[Luis Gutierrez]

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.

What I have done is use git-cvsimport on each of those branches to 
create separate git repositories: dev01, dev02, release01, and release02.

What I was planing on doing next was:
(all from the dev01 branch)
1) git branch dev01
2) git checkout -b release01
3) git pull ssh:/..../release01
4) git checkout -b dev02
5) git pull ssh:/..../dev02
6) git checkout -b release02
7) git pull ssh:/..../release02

Now, the problem I'm seeing is that I get hundreds of conflicts when 
pulling.

Short from doing a git-mergetool 100's of times, is there a better way 
of doing this? One that guarantees I keep the latests version (ie, the 
one I'm pulling from).
Put in another way, is there a way to let git know that it will not 
merge the last version of the files, just the history?

Cheers.

Luis Gutierrez

Re: complex cvs import

[Michael J Gruber]

Luis Gutierrez venit, vidit, dixit 22.08.2008 15:13:
> 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.
> 
> What I have done is use git-cvsimport on each of those branches to 
> create separate git repositories: dev01, dev02, release01, and release02.
> 
> What I was planing on doing next was:
> (all from the dev01 branch)
> 1) git branch dev01
> 2) git checkout -b release01
> 3) git pull ssh:/..../release01
> 4) git checkout -b dev02
> 5) git pull ssh:/..../dev02
> 6) git checkout -b release02
> 7) git pull ssh:/..../release02
> 
> Now, the problem I'm seeing is that I get hundreds of conflicts when 
> pulling.
> 
> Short from doing a git-mergetool 100's of times, is there a better way 
> of doing this? One that guarantees I keep the latests version (ie, the 
> one I'm pulling from).
> Put in another way, is there a way to let git know that it will not 
> merge the last version of the files, just the history?
> 
> Cheers.
> 
> Luis Gutierrez

How about:

- fetch instead of pull
- After each fetch, put the fetched thing in a local branch:
git checkout -b release01 FETCH_HEAD

Now you've got local "branches" without a common root.

Finally, stitch it together using grafts and filter-branch.

Michael

Re: complex cvs import

[Robert Schiele]

[-- 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 --]