{"thread":{"id":"15161","subject":"complex cvs import","startedAt":"2008-08-22T13:13:22Z","lastAt":"2008-08-23T09:12:16Z","messageCount":3,"participants":["Luis Gutierrez","Michael J Gruber","Robert Schiele"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88127","messageId":"48AEBB72.6060209@xmos.com","threadId":"15161","inReplyTo":null,"subject":"complex cvs import","fromName":"Luis Gutierrez","fromEmail":"luis.gutierrez@xmos.com","sentAt":"2008-08-22T13:13:22Z","receivedAt":"2008-08-22T13:13:22Z","isPatch":false,"sender":{"key":"luis.gutierrez@xmos.com","avatar":null},"body":"Hi All,\n\nDuring the past year or so we have been using a bastardized version of \nCVS in which branches were not 'true' cvs branches, but just a copy of \nthe original data in a different folder. For instance, we would have \nsomething like this:\n\nProjectX\n   \\---- dev01\n   |       \\... normal cvs data\n   \\---- dev02\n   |       \\... normal cvs data\n   \\---- release01\n   |       \\... normal cvs data\n   \\---- release02\n           \\... normal cvs data\n\nWhile a timeline of the branches looks like this:\n\n                /---release01\n----dev01------+                /---release02\n                \\---dev02------+--\n\nNow that we are trying to move to git, and I'm having problems importing \nthe projects with their full history.\n\nWhat I have done is use git-cvsimport on each of those branches to \ncreate separate git repositories: dev01, dev02, release01, and release02.\n\nWhat I was planing on doing next was:\n(all from the dev01 branch)\n1) git branch dev01\n2) git checkout -b release01\n3) git pull ssh:/..../release01\n4) git checkout -b dev02\n5) git pull ssh:/..../dev02\n6) git checkout -b release02\n7) git pull ssh:/..../release02\n\nNow, the problem I'm seeing is that I get hundreds of conflicts when \npulling.\n\nShort from doing a git-mergetool 100's of times, is there a better way \nof doing this? One that guarantees I keep the latests version (ie, the \none I'm pulling from).\nPut in another way, is there a way to let git know that it will not \nmerge the last version of the files, just the history?\n\nCheers.\n\nLuis Gutierrez\n"},{"id":"88142","messageId":"g8ml4s$2cd$1@ger.gmane.org","threadId":"15161","inReplyTo":"48AEBB72.6060209@xmos.com","subject":"Re: complex cvs import","fromName":"Michael J Gruber","fromEmail":"michaeljgruber+gmane@fastmail.fm","sentAt":"2008-08-22T15:14:35Z","receivedAt":"2008-08-22T15:14:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Luis Gutierrez venit, vidit, dixit 22.08.2008 15:13:\n> Hi All,\n> \n> During the past year or so we have been using a bastardized version of \n> CVS in which branches were not 'true' cvs branches, but just a copy of \n> the original data in a different folder. For instance, we would have \n> something like this:\n> \n> ProjectX\n>    \\---- dev01\n>    |       \\... normal cvs data\n>    \\---- dev02\n>    |       \\... normal cvs data\n>    \\---- release01\n>    |       \\... normal cvs data\n>    \\---- release02\n>            \\... normal cvs data\n> \n> While a timeline of the branches looks like this:\n> \n>                 /---release01\n> ----dev01------+                /---release02\n>                 \\---dev02------+--\n> \n> Now that we are trying to move to git, and I'm having problems importing \n> the projects with their full history.\n> \n> What I have done is use git-cvsimport on each of those branches to \n> create separate git repositories: dev01, dev02, release01, and release02.\n> \n> What I was planing on doing next was:\n> (all from the dev01 branch)\n> 1) git branch dev01\n> 2) git checkout -b release01\n> 3) git pull ssh:/..../release01\n> 4) git checkout -b dev02\n> 5) git pull ssh:/..../dev02\n> 6) git checkout -b release02\n> 7) git pull ssh:/..../release02\n> \n> Now, the problem I'm seeing is that I get hundreds of conflicts when \n> pulling.\n> \n> Short from doing a git-mergetool 100's of times, is there a better way \n> of doing this? One that guarantees I keep the latests version (ie, the \n> one I'm pulling from).\n> Put in another way, is there a way to let git know that it will not \n> merge the last version of the files, just the history?\n> \n> Cheers.\n> \n> Luis Gutierrez\n\nHow about:\n\n- fetch instead of pull\n- After each fetch, put the fetched thing in a local branch:\ngit checkout -b release01 FETCH_HEAD\n\nNow you've got local \"branches\" without a common root.\n\nFinally, stitch it together using grafts and filter-branch.\n\nMichael\n"},{"id":"88280","messageId":"20080823091215.GJ11842@schiele.dyndns.org","threadId":"15161","inReplyTo":"48AEBB72.6060209@xmos.com","subject":"Re: complex cvs import","fromName":"Robert Schiele","fromEmail":"rschiele@gmail.com","sentAt":"2008-08-23T09:12:16Z","receivedAt":"2008-08-23T09:12:16Z","isPatch":false,"sender":{"key":"rschiele@gmail.com","avatar":"https://gravatar.com/avatar/409473567eb2287d5f0157b51f5b703994b347f24f92172e3a0588741c27a492?d=mp&s=160"},"body":"On Fri, Aug 22, 2008 at 02:13:22PM +0100, Luis Gutierrez wrote:\n> Hi All,\n>\n> During the past year or so we have been using a bastardized version of CVS \n> in which branches were not 'true' cvs branches, but just a copy of the \n> original data in a different folder. For instance, we would have something \n> like this:\n>\n> ProjectX\n>   \\---- dev01\n>   |       \\... normal cvs data\n>   \\---- dev02\n>   |       \\... normal cvs data\n>   \\---- release01\n>   |       \\... normal cvs data\n>   \\---- release02\n>           \\... normal cvs data\n>\n> While a timeline of the branches looks like this:\n>\n>                /---release01\n> ----dev01------+                /---release02\n>                \\---dev02------+--\n>\n> Now that we are trying to move to git, and I'm having problems importing \n> the projects with their full history.\n\nI solved a similar situation about one year ago with the following script:\n\n------\n#!/bin/bash\n\nset -eux\n\nCVSREPOS=/path/to/cvs\nREPOSDIR=~/gitmigration\nexport TMPDIR=$(TMPDIR=/dev/shm mktemp -d)\n\ncvsimport()\n{\n    if [ \"$2\" ]; then\n    GBR=$1_tmp\n    cd $TMPDIR/checkout\n    git branch $1_tmp $2\n    else\n    GBR=master\n    fi\n    git cvsimport -a -k -d $CVSREPOS -C $TMPDIR/checkout -i -A <(\n    cat <<EOF\nuser1=One User <user.one@example.com>\nuser2=Two User <user.two@example.com>\nEOF\n    ) -o $GBR $1\n    cd $TMPDIR/checkout\n    git tag -d $3\n    git branch -D $4\n    git branch -m $GBR $1\n}\n\nrm -rf ~/.cvsps\ncvs -d $CVSREPOS rtag -D '2002-06-07 20:41:34 +0000' rel1fork mainbranch\ncvs -d $CVSREPOS rtag -D '2004-09-22 18:11:45 +0000' rel2fork rel1branch\ncvs -d $CVSREPOS rtag -D '2003-10-22 20:44:21 +0000' rel3fork rel1branch\ncvs -d $CVSREPOS rtag -D '2006-03-27 21:07:23 +0000' rel4fork rel3branch\ncvs -d $CVSREPOS rtag -D '2005-10-28 22:00:18 +0000' rel5fork rel3branch\ncvsimport mainbranch ''       fooxtag fooxbranch\ncvsimport rel1branch rel1fork fooytag fooybranch\ncvsimport rel2branch rel2fork fooztag foozbranch\ncvsimport rel3branch rel3fork sometag somebranch\ncvsimport rel4branch rel4fork inittag initbranch\ncvsimport rel5branch rel5fork bartag  barbranch\ncd $TMPDIR/checkout\ngit branch -m rel3branch master\nrm -rf $REPOSDIR\ngit clone --bare $TMPDIR/checkout $REPOSDIR\ntouch $REPOSDIR/git-daemon-export-ok\necho 'My description' > $REPOSDIR/description\ncat <<EOF >> $REPOSDIR/config\n        sharedrepository = 2\n[receive]\n        denyNonFastforwards = true\nEOF\nfind $REPOSDIR -type f -print0 | xargs -0 chmod g+u\nfind $REPOSDIR -type d -print0 | xargs -0 chmod g+u,g+s\ncd /\nrm -rf $TMPDIR\n------\n\nSome explanations:\n\n1. If people start a new repository in cvs they often do so with cvs import\n   (since this is the way it is documented) but don't use the created branch\n   and tag at all.  Because of that cvsimport (the one from the script)\n   removes them after importing.\n\n2. The script requires the points in the tree to be tagged where you branched\n   of one of your \"special\" cvs branches.  If you already have tags for that\n   you are fine, otherwise you need to \"reverse engineer\" that place and tag\n   this in cvs with something like\n\n   cvs -d $CVSREPOS rtag -D '2004-09-22 18:11:45 +0000' rel2fork rel1branch\n\n   which means rel2branch was forked off from rel1branch at point rel2fork\n\n3. Now you import all the \"special\" branches with commands like\n\n   cvsimport mainbranch ''       fooxtag fooxbranch\n   cvsimport rel1branch rel1fork fooytag fooybranch\n\n   The imports need to be in topological order of the branch dependencies.\n   Thus you start with the oldest branch that exists in your cvs (mainbranch).\n\n   Parameters are:\n\n   - Branch to import.\n\n   - Tag where this branch was forked off (or empty for main branch).\n\n   - Tag that was created by cvs import and will be deleted after import.\n\n   - Branch that was created by cvs import and will be deleted after import.\n\n4. There is a line\n\n   git branch -m rel3branch master\n\n   in the script that is supposed to rename your \"main\" branch to master\n   (since this a convention in git).  This is technically not required and\n   might make no sense depending on your workflow.\n\nI hope this is useful for you.\n\nRobert\n\n-- \nRobert Schiele\nDipl.-Wirtsch.informatiker\tmailto:rschiele@gmail.com\n\n\"Quidquid latine dictum sit, altum sonatur.\"\n"}]}