Skip to contentSkip to conversation

complex cvs import

DISCUSSION Luis Gutierrez 3 participants 3 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

Luis Gutierrez venit, vidit, dixit 22.08.2008 15:13:

Quoted 48 lines

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?

Quoted 3 lines

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

#2 lore raw
In reply to Luis Gutierrez
Quoted 17 lines · 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

Quoted 8 lines

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 <[email protected]>
user2=Two User <[email protected]>
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

Signature · 4 lines
Robert Schiele
Dipl.-Wirtsch.informatiker	mailto:[email protected]

"Quidquid latine dictum sit, altum sonatur."