git-svn tags and branches

> I've recently started using git and I like it so much that
> I've decided to start using it also for some svn-based
> projects (in particular, rbot http://linuxbrit.co.uk/rbot).
>
> The long term goal would be to move the project to git, but
> for the time being (among the other things we're waiting for
> Trac to have proper support for git, which is something that
> won't happen before Trac 0.12 at least) I've decided to
> experiment with a dual git/svn development process, using
> (of course) git-svn.
>
> My experience with toying around with it for a couple of
> hours has been extremely positive, but I've got some
> questions, especially about the tags and branch management.
>
> Currently, git-svn imports svn tags as lightweight git tags.

> I was susprised when I discovered this (from 'git describe'
> failing and some helpful assistance on the IRC channel), so
> I'm now wondering: is there a technical reason why they
> aren't converted to annotated tags? If not, would it be
> possible to implement this in git-svn, possibly with some
> way to 'fix' existing git-svn repository?

> I actually don't see how one can safely make them tags at all (rather
> than branches) since Subversion does not enforce the members of a
> "tags" subdirectory to remain unchanged after the initial copy.
> Basically, tags are not different from branches in Subversion from
> what you can do with them.

> On Mon, Aug 27, 2007 at 05:09:30PM +0200, David Kastrup  
> <dak@gnu.org> wrote:
>> I actually don't see how one can safely make them tags at all (rather
>> than branches) since Subversion does not enforce the members of a
>> "tags" subdirectory to remain unchanged after the initial copy.
>> Basically, tags are not different from branches in Subversion from
>> what you can do with them.
>
> Well, git-svn could make tags when the tag/branch is created in  
> subversion,
> and then create a branch on the first commit on top of that tag/ 
> branch in
> svn.
>

> On Aug 27, 2007, at 5:31 PM, Mike Hommey wrote:
> 
>> On Mon, Aug 27, 2007 at 05:09:30PM +0200, David Kastrup  
>> <dak@gnu.org> wrote:
>>> I actually don't see how one can safely make them tags at all (rather
>>> than branches) since Subversion does not enforce the members of a
>>> "tags" subdirectory to remain unchanged after the initial copy.
>>> Basically, tags are not different from branches in Subversion from
>>> what you can do with them.
>>
>> Well, git-svn could make tags when the tag/branch is created in  
>> subversion,
>> and then create a branch on the first commit on top of that tag/ 
>> branch in
>> svn.
> 
> Or update the tag ref in Git so that it points to the new "HEAD" of  
> the SVN tag.But all in all, it's more consistent to have it look  
> like a branch from the Git point of view, because that's really what  
> it is after all.

> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>>
>> Currently, git-svn imports svn tags as lightweight git tags.
> 
> It does?  I see them as branches.

>> I was susprised when I discovered this (from 'git describe'
>> failing and some helpful assistance on the IRC channel), so
>> I'm now wondering: is there a technical reason why they
>> aren't converted to annotated tags? If not, would it be
>> possible to implement this in git-svn, possibly with some
>> way to 'fix' existing git-svn repository?
> 
> I actually don't see how one can safely make them tags at all (rather
> than branches) since Subversion does not enforce the members of a
> "tags" subdirectory to remain unchanged after the initial copy.
> Basically, tags are not different from branches in Subversion from
> what you can do with them.

> Currently, git-svn imports svn tags as lightweight git tags.
> I was susprised when I discovered this (from 'git describe'
> failing and some helpful assistance on the IRC channel), so
> I'm now wondering: is there a technical reason why they
> aren't converted to annotated tags? If not, would it be
> possible to implement this in git-svn, possibly with some
> way to 'fix' existing git-svn repository?

> My second question concerns the uses of branche in git-svn,
> but it might come from a not perfect understanding of the
> branching mechanism in git (and yes, I've read the
> documentation and Wiki pages).
> 
> If I understand correctly, svn branches are imported in
> git-svn as remote branches (refs/remote/*) and are
> automatically updated on git-svn fetch or git-svn fetch-all.
> 
> In my experiments, however, I've noticed the following
> behaviour.
> 
> git branch --track trunk remote/trunk
> <do some changes and git commit them, while still on branch master>
> git svn dcommit
> 
> Now, master and remote/trunk point to the new roundtripped
> changes, but the branch 'trunk' (in git) remains pointing to
> the old remote/trunk head. I would have expected the --track
> option to keep trunk in sync with remote/trunk ...
> 
> Or am I missing something obvious?

> As noted by other repliers, SVN tags can be moving targets just like
> branches, and are treated as such by git-svn.
>
> I should note that tags in git can actually be updated like a branch
> just the same way, too, it's just not as easy to "accidentally" do.
>
> So I'll add the ability to modify refs under the refs/tags/ namespace to
> my git-svn TODO list (which is getting rather large).  I also plan to
> support branches outside of the refs/remotes/ namespace so it's easier
> to use (clone, browse from gitweb) from bare repositories.

> I really have a lot of catching up to do with all the new(er) things
> happening in git.  I learned git (what seems like) aeons ago have been
> more or less content with what the plumbing offered back then.  The past
> six months of my life hasn't exactly left me with a lot of time or
> energy for git, either; hopefully I'll have more time soon...

> On 8/30/07, Eric Wong <normalperson@yhbt.net> wrote:
> > As noted by other repliers, SVN tags can be moving targets just like
> > branches, and are treated as such by git-svn.
> >
> > I should note that tags in git can actually be updated like a branch
> > just the same way, too, it's just not as easy to "accidentally" do.
> >
> > So I'll add the ability to modify refs under the refs/tags/ namespace to
> > my git-svn TODO list (which is getting rather large).  I also plan to
> > support branches outside of the refs/remotes/ namespace so it's easier
> > to use (clone, browse from gitweb) from bare repositories.
> 
> Thank you very much, that would be very appreciated.
> 
> While we're at it: could you consider putting the svn-imported refs
> not directly under remote? something like refs/remote/svn would be
> rather cleaner.
> 

> On Thu, Aug 30, 2007 at 01:44:35PM +0200, Giuseppe Bilotta wrote:
> > While we're at it: could you consider putting the svn-imported refs
> > not directly under remote? something like refs/remote/svn would be
> > rather cleaner.
>
> Did you have a look at the --prefix option mentioned in the manpage? I
> think it does what you want.

> > I gather from the man page that doing this is highly frowned upon, and
> > requires manual intervention from all the poor souls that pulled in
> > the mean time.
>
> Right, but I think the bad practice should be propagated anyway.  It
> will affect virtually no-one, and serves to make it the case that even
> if such a thing happened, then just fetching the tag gives the expected
> behaviour.
>
> However I'd be prepared to accept that perhaps new tags should be made,
> eg "tags/svntagname.r1234", to reflect the fact there are there multiple
> tags with the same name but different contents.

> > I've been looking through the git-svn code to see if I could try an
> > implementation myself, but I must confess that the task seems way over
> > me ... I can't really wrap my mind around the git-svn code enough to
> > implement it.
>
> Coming up with agreed test cases is half (indeed sometimes most of) the
> work.

> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
> > BTW can git have a tag and a branch with the same name? If
> > not,...
>
> This is "Yes but".
>
> You can have a tag foo and branch foo.

> On 8/29/07, Junio C Hamano <gitster@pobox.com> wrote:
>> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>>
>> > BTW can git have a tag and a branch with the same name? If
>> > not,...
>>
>> This is "Yes but".
>>
>> You can have a tag foo and branch foo.
>
> [snip]
>
>>  You can clarify yourself to avoid ambiguity like so:
>>
>>   . git branch newbranch heads/foo ;# I mean "branch from foo branch"
>>   . git log tags/foo ;# "show history starting at that tag"
>
> Ok. So assuming we import a svn repo which has a tag and a branch
> called 'name', and that there are post-tag commits in tags/name, how
> do we call the stuff?
>
> We could call 'name' both the (annotated) tag and the branch, but what
> name would we use for the branch created by post-tag commits?

> As I said in the part you quoted, if you have branch foo and tag
> foo, and if you are interested in talking about the tag 'foo',
> you say "tag/foo".  When you want to talk about the branch, you
> say "heads/foo".  Replace "foo" with "name" and I think you get
> your answer.

> "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>
> > On 8/29/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> As I said in the part you quoted, if you have branch foo and tag
> >> foo, and if you are interested in talking about the tag 'foo',
> >> you say "tag/foo".  When you want to talk about the branch, you
> >> say "heads/foo".  Replace "foo" with "name" and I think you get
> >> your answer.
> >
> > The problem here is that you can have THREE things: the tag foo, the
> > branch foo, and the 'branch' under the tag foo, which is not the
> > branch foo.
>
> What do you mean?  "refs/tags/foo", "refs/heads/foo" and ...?
>
> You cannot have "refs/tags/foo/bar" if you have "refs/tags/foo".
>