Re: git-svn and repository hierarchy?

[Michael J Gruber <git@drmicha.warpmail.net>]

Josef Wolf venit, vidit, dixit 27.02.2009 23:05:
> Thanks for your patience, Michael!
> 
> On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote:
>> Josef Wolf venit, vidit, dixit 27.02.2009 18:12:
>>> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote:
>>>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34:
> 
> [ ... ]
>>>   (cd git-svn-repos; git pull ../clone1)
>> Gives you 1-2-3-4
>>
>>>   (cd git-svn-repos; git svn rebase)
>> Does nothing here (but is good practice)
>>
>>>   (cd git-svn-repos; git svn dcommit)
>> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates
>> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id).
> 
> So the sha1 is not preserved when it goes through svn?

No. Once your commits come back from svn through git-svn they have an
additional line in the commit. Also, the commit time time will be
different, and the author name might be depending on your name remapping.

The patch-id (which only looks at the actual diff being introduced)
should be the same.

>>>   (cd git-svn-repos; git pull ../clone1)  # if this line is executed,
>> That's the problem. This creates a merge after which you 1-2-3-4 and
>> 1-2'-3'-4' plus the merge of 4 and 4'.
> 
> --verbosity=on please ;-)

No such option "--verbosity". ;)

Uhm, I'm just not good at diagramms in ascii. You had 1-2-3-4 in
git-svn-repo. 2, 3 and 4 were dcommit to svn and came back as 2', 3',
4', such that git-svn rebased your master branch in git-svn-repo and
master looked like 1-2'-3'-4'. The primed version are the one with an
additional git-svn-id line in the commit: different sha1 from the
unprimed version, same patch-id.

Now, if you say pull ../clone1, you fetch from there and merges
FETCH_HEAD, i.e. the tip of ../clone1, which is 4. So you get

1-2'-3'-4'-o
 \        /
  2 -3 -4

with o being the tip (HEAD) of master. And that is the problem, because
no history is not linear in master, and the next git-svn dcommit won't
know what to do.

>> Instead, use git pull --rebase here. You don't want merges in the branch
>> from which you dcommit.
> 
> Yeah, "pull --rebase" seems to help a lot.  So I've come up with the next
> version of my workflow-test-script:
> 
> (
>   set -ex
> 
>   # create test directory
>   #
>   TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX`
>   rm -rf $TESTDIR
>   mkdir -p $TESTDIR
>   cd $TESTDIR
> 
>   SUBVERSION_REPOS=file://`pwd`/subversion-repos
> 
>   # create subversion repos with some history
>   #
>   svnadmin create subversion-repos
>   svn -m "create standard layout" mkdir \
>       $SUBVERSION_REPOS/trunk \
>       $SUBVERSION_REPOS/branches \
>       $SUBVERSION_REPOS/tags
>   svn co $SUBVERSION_REPOS/trunk subversion-wc
>   echo change1 >>subversion-wc/test
>   svn add subversion-wc/test
>   svn ci -m "commit 0" subversion-wc
> 
>   # create git-svn-repos
>   #
>   git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos
>   (cd git-svn-repos; git svn fetch)
> 
>   # create clones
>   #
>   git clone git-svn-repos clone1
>   git clone git-svn-repos clone2
>   git clone git-svn-repos clone3
> 
>   # now go several times to every clone, do some work on it, and sync
>   # the results
>   #
>   for cycle in 1 2 3; do
>     for clone in 1 2 3; do
>       for commit in 1 2 3; do
>         (
>           cd clone$clone
>           git pull --rebase
>           echo change $clone $commit >>test
>           git commit -a -m "commit $clone $commit"
>         )
>       done
>       (cd git-svn-repos; git pull --rebase ../clone$clone)
>       (cd git-svn-repos; git svn rebase)
>       (cd git-svn-repos; git svn dcommit)
>     done
>   done
> )
> 
> At least, this seems to not creating collisions any more.  But I'm still
> not sure I fully understand what's going on here.  Guess, I'll have to
> get into the learning-by-doing mode :)

Yes, be sure to check the DAG (the graph of commits which you produced)
using something like gitk or git log --graph with the "--all" argument
so that you see all branches!

>> Borrowing from some other vcs:
>>
>> Repeat the soothing mantra: a merge is no merge is no merge - it it's in
>> svn ;)
> 
> Huh?

I meant "if it's", sorry for the typo.
If you don't get the plug don't worry (or look up hg) ;)

>>> Obviously, I'm doing something wrong.  But I can't figure what.  Any hints?
>> I guess when we said integrated we should have said rebase. Haven't we?
> 
> You like to talk in riddles? Aren't you?

No, I'm not ;)

Michael