what does @NNN in git-svn branch names mean?

What does it mean when git-svn creates branches with an @ sign and a Subversion revision number in them? The documentation doesn't say (and, this being perl, grepping for "@" in git-svn.perl is of little use!). I'll be happy to write something up if you'll clue me in.

On Feb 6, 2008 11:29 AM, Karl Hasselström <kha@treskal.com> wrote:

It looks like this happens when a branch is deleted and recreated. The old branch "foo" is renamed to "foo@lastrev", and the new branch "foo" tracks the current state.

Peter Harris

Karl Hasselström <kha@treskal.com> wrote:

Hi Karl,

The follow parent feature uses it, with the foo@NNN version being the parent branch.

For example, if I'm tracking http://example.com/project/trunk, but it was created from http://example.com/old-project at revision 76 (before they used the trunk/branches/tags convention), then the contents of http://example.com/old-project would show up as the ref trunk@75, and the trunk ref would start as r76 with the ref trunk@75 as its parent.

On 2008-02-06 11:18:30 -0800, Eric Wong wrote:

I thought I understood (especially with Peter's answer), so I tried to make a script that would create one of those @ branches:

    svnrepo=file://$(pwd)/svnrepo
    rm -rf svnrepo wd gs
    svnadmin create svnrepo
    svn mkdir -m c1 $svnrepo/trunk
    svn mkdir -m c2 $svnrepo/branches
    svn mkdir -m c3 $svnrepo/tags

    svn co $svnrepo/trunk wd
    (
        cd wd
        echo foo > foo.txt
        svn add foo.txt
        svn ci -m c4
    )

    svn cp -m c5 $svnrepo/trunk $svnrepo/branches/br

    (
        cd wd
        svn switch $svnrepo/branches/br
        echo foo >> foo.txt
        svn ci -m c6
        svn switch $svnrepo/trunk
        echo foobar >> foo.txt
        svn ci -m c7
    )

    svn rm -m c8 $svnrepo/branches/br
    svn cp -m c9 $svnrepo/trunk $svnrepo/branches/br

    git svn clone --stdlayout --prefix=svn/ $svnrepo gs
    (
        cd gs
        gitk --all
    )

However, this does not result in a br@N branch; instead, the remove-and-copy is imported as a merge from trunk to br. I'm not saying this is not correct, but it does seem that I still don't understand under what circumstances the @N branches are created.