git-svn: Trouble after project has moved in svn

git-svn: Trouble after project has moved in svn

[Jukka Zitting]

Hi,

Somewhat related to the recent thread about Apache Synapse, I'm having
trouble making a git-svn clone of a project that has been moved around
in a Subversion repository.

See the script at the end of this message for a simple test case that
does the following svn commits:

    PREPARE: creates projectA with the standard trunk,branches,tags structure
    VERSION1: first version of README.txt in projectA/trunk
    TAG1: tags projectA/trunk to projectA/tags/v1
    MOVE: moves projectA to projectB
    VERSION2: second version of README.txt in projectB/trunk
    TAG2: tags projectB/trunk to projectB/tags/v2

The resulting repository structure is:

    /projectB/
        trunk/
            README.txt # version 2
        branches/
        tags/
            v1/
                README.txt # version 1
            v2/
                README.txt # version 2

Here's the git commit graph created by the test case:

    * TAG2 <- refs/remotes/tags/v2
    | * VERSION2 <- refs/remotes/trunk
    |/
    * MOVE
    * VERSION1 <- refs/remotes/trunk@3
    | * MOVE <- refs/remotes/tags/v1
    | * TAG1 <- refs/remotes/tags/v1@3
    |/
    * PREPARE <- refs/remotes/tags/v1@1

The most pressing issue is that the refs/remotes/tags/v1 branch starts
directly from the first PREPARE commit instead of VERSION1. Also, the
branch point of refs/remotes/tags/v2 seems to be incorrect, it should
be based on the VERSION2 commit instead of MOVE.

A more accurate commit graph would be:

    * TAG2 <- refs/remotes/tags/v2
    * VERSION2 <- refs/remotes/trunk
    * MOVE
    | * MOVE <- refs/remotes/tags/v1
    | * TAG1
    |/
    * VERSION1
    * PREPARE

Or even (but I guess git-svn needs to map each svn commit to at least
one git commit, so this probably wouldn't work):

    * VERSION2 <- refs/remotes/trunk, refs/remotes/tags/v2
    * VERSION1 <- refs/remotes/tags/v1
    * PREPARE

I tried working my way through git-svn.perl to figure out how to
improve the way git-svn tracks svn moves, but so far I couldn't figure
out how to do that. Any ideas or hints?

BR,

Jukka Zitting

=====
#!/bin/sh

REPO=`pwd`/repo
svnadmin create $REPO

svn checkout file://$REPO checkout
cd checkout

svn mkdir projectA
svn mkdir projectA/trunk
svn mkdir projectA/branches
svn mkdir projectA/tags
svn commit -m PREPARE

echo VERSION1 > projectA/trunk/README.txt
svn add projectA/trunk/README.txt
svn commit -m VERSION1

svn copy projectA/trunk projectA/tags/v1
svn commit -m TAG1
svn update

svn move projectA projectB
svn commit -m MOVE

echo VERSION2 > projectB/trunk/README.txt
svn commit -m VERSION2

svn copy projectB/trunk projectB/tags/v2
svn commit -m TAG2
svn update

mkdir ../git
cd ../git

git svn init -s file://$REPO/projectB
git svn fetch

Re: git-svn: Trouble after project has moved in svn

[Michael J Gruber]

Jukka Zitting venit, vidit, dixit 17.07.2008 00:12:
> Hi,
> 
> Somewhat related to the recent thread about Apache Synapse, I'm having
> trouble making a git-svn clone of a project that has been moved around
> in a Subversion repository.
> 
> See the script at the end of this message for a simple test case that
> does the following svn commits:
> 
>     PREPARE: creates projectA with the standard trunk,branches,tags structure
>     VERSION1: first version of README.txt in projectA/trunk
>     TAG1: tags projectA/trunk to projectA/tags/v1
>     MOVE: moves projectA to projectB
>     VERSION2: second version of README.txt in projectB/trunk
>     TAG2: tags projectB/trunk to projectB/tags/v2
> 
> The resulting repository structure is:
> 
>     /projectB/
>         trunk/
>             README.txt # version 2
>         branches/
>         tags/
>             v1/
>                 README.txt # version 1
>             v2/
>                 README.txt # version 2
> 
> Here's the git commit graph created by the test case:
> 
>     * TAG2 <- refs/remotes/tags/v2
>     | * VERSION2 <- refs/remotes/trunk
>     |/
>     * MOVE
>     * VERSION1 <- refs/remotes/trunk@3
>     | * MOVE <- refs/remotes/tags/v1
>     | * TAG1 <- refs/remotes/tags/v1@3
>     |/
>     * PREPARE <- refs/remotes/tags/v1@1
> 
> The most pressing issue is that the refs/remotes/tags/v1 branch starts
> directly from the first PREPARE commit instead of VERSION1. Also, the
> branch point of refs/remotes/tags/v2 seems to be incorrect, it should
> be based on the VERSION2 commit instead of MOVE.

In the script below, you use copies inside your svn working copy for 
tagging, which is generally a bad idea: it stores the exact state of 
your wc as a "tag". Use this for creating "mixed states", but not for 
ordinary tagging (or make sure you svn up). See the detailed comments below.

If you want to create an svn tag (as far as svn has tags at all) use 
repo urls, or make sure your wc is up to date.

> =====
> #!/bin/sh
> 
> REPO=`pwd`/repo
> svnadmin create $REPO
> 
> svn checkout file://$REPO checkout
> cd checkout
> 
> svn mkdir projectA
> svn mkdir projectA/trunk
> svn mkdir projectA/branches
> svn mkdir projectA/tags
> svn commit -m PREPARE
> 
> echo VERSION1 > projectA/trunk/README.txt
> svn add projectA/trunk/README.txt
> svn commit -m VERSION1

Now, README.txt is at r2, but trunk is still at r1.
Use "svn update" here to get trunk to r2!

> svn copy projectA/trunk projectA/tags/v1

This copies r1 of trunk to the tags dir (unless you've inserted svn up 
above)!

> svn commit -m TAG1
> svn update
> 
> svn move projectA projectB
> svn commit -m MOVE
> 
> echo VERSION2 > projectB/trunk/README.txt
> svn commit -m VERSION2

Now, README.txt is at r5, but trunk is at r4.
"svn update"!

> svn copy projectB/trunk projectB/tags/v2

This tags (copies to tags/) r4 of trunk

> svn commit -m TAG2
> svn update

This produces r6: the tagging.

> 
> mkdir ../git
> cd ../git
> 
> git svn init -s file://$REPO/projectB
> git svn fetch

The results perfectly as expected. Compare "svn log -v" with git-svn's 
results, and you'll see that git (tag) branches fork off exactly at the 
revisions which you tagged in svn. Because the last commit occurs on 
tags/v2, git-svn checks out that branch as master, the supposedly 
"active" branch.

If you insert the two missing "svn update" commands which bring your wc 
up to date before tagging your git-svn results will be what you expected.

Cheers,
Michael

Re: git-svn: Trouble after project has moved in svn

[Jukka Zitting]

Hi,

On Thu, Jul 17, 2008 at 1:12 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Somewhat related to the recent thread about Apache Synapse, I'm having
> trouble making a git-svn clone of a project that has been moved around
> in a Subversion repository.

Ah, silly me, my test script was broken. Thanks to Michael J. Gruber
for pointing out that I should have used created the tags using svn
URLs instead of working copy path or at least done an "svn update"
before tagging. After fixing my test script the git-svn result was
exactly as I was hoping to see.

I think that covers my last barrier for creating experimental git
mirrors of various Apache codebases. Check out
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/ for
more on git experiments at Apache.

BR,

Jukka Zitting