git-svn tags and branches

git-svn tags and branches

[Giuseppe Bilotta]

Hello all,

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?

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?

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[David Kastrup]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:

> 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.

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.

> 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).

I'll leave that question to people who actually understand git-svn and
git branches.

-- 
David Kastrup

Re: git-svn tags and branches

[Mike Hommey]

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.

Mike

Re: git-svn tags and branches

[Benoit SIGOURE]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

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.

-- 
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: git-svn tags and branches

[Giuseppe Bilotta]

On Monday 27 August 2007 17:09, David Kastrup wrote:

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

Oh, I thought that them being in refs/remote/tags meant they
were remote tags. But yes, I had noticed them appearing with
git branch -r

>> 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.

Although this is technically true, I doubt there are many Subversion
projects which alter the members of a tags subdirectory. So the fact
that it's technically possible doesn't really mean it happens.

I mean, even in git you can do some pretty dirty tag stuff. It may
not be as straightforward as in svn, but still ...

So yes, I still think that an option to convert svn tags to annotated
tags would be appropriate. Wether or not it should be default, it's
a different matter, of course.

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Giuseppe Bilotta]

On Monday 27 August 2007 17:36, Benoit SIGOURE wrote:

> 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.

Yes and no. By making it just a branch you lose the tag POV on that
particular commit, and this is, in a way, a loss of information: yes, it
can behave like a branch but most projects use it as a tag.

I think the best approach is to have an annotated tag 'tagname'
corresponding to the tags/tagname copy on the svn side in addition
to the 'tags/tagname' branch that is currently used to track its head.

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Giuseppe Bilotta]

On 8/29/07, Sam Vilain <sam@vilain.net> wrote:
> Giuseppe Bilotta wrote:

> > 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.

Urgh. I think I like this idea even less. just use the tag 'tagname'
and move it around then :)

BTW can git have a tag and a branch with the same name? If not, I
would recomment the use of 'name' for the tag, 'name-branch' for the
branch, and 'tag-name-branch' for the branch under the tag.

> > 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.

The only two svn projects I cooperate with don't have this particular
situation. IIRC David mentioned the case?

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Andreas Ericsson]

Giuseppe Bilotta wrote:
> BTW can git have a tag and a branch with the same name?

Yes it can. I'm unsure as to what takes precedense.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: git-svn tags and branches

[Junio C Hamano]

"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.

- "git checkout foo" would switch you to foo branch

- Anything else that lets you use an abbreviated refname 'foo',
  e.g.

  . git branch newbranch foo
  . git log foo
  . git diff foo

  will scold you that 'foo' is ambiguous, while it does not
  outright fail, and takes the first match from the list defined
  in sha1_name.c (ref_fmt[]), so a tag wins over a branch.  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"

Re: git-svn tags and branches

[Giuseppe Bilotta]

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?


-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Junio C Hamano]

"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:

> 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?

That's the "Yes but" part.  You need to know what you are doing.

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.

Re: git-svn tags and branches

[Giuseppe Bilotta]

[did it again, sorry for the double-sent]

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.

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Giuseppe Bilotta]

On 8/29/07, Junio C Hamano <gitster@pobox.com> wrote:
> "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".
>


-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Eric Wong]

Giuseppe Bilotta <giuseppe.bilotta@gmail.com> wrote:
> 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?

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.

> 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?

The author of git-svn (myself) hasn't gotten around to supporting
(or even looking at) git branch --track.

Right now, dcommit only knows about HEAD and the remote it's committing
to, nothing else.  The config set by --track doesn't do anything
for git-svn.

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...

-- 
Eric Wong

Re: git-svn tags and branches

[Giuseppe Bilotta]

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.

> 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...

I enormously appreciate the efforts you've put into git-svn so far, it
has been quite a refreshing change from having to way eons every time
I had to commit something, while still giving me the ability to keep
my work nicely in sync with the upstream repo.

I've considered tackling these minor issues myself, but my
understanding of git's internals is most definitely not yet adequate,
so I haven't been able to do any hacking yet.

-- 
Giuseppe "Oblomov" Bilotta

Re: git-svn tags and branches

[Peter Baumann]

On Thu, Aug 30, 2007 at 01:44:35PM +0200, Giuseppe Bilotta wrote:
> 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.
> 

Did you have a look at the --prefix option mentioned in the manpage? I
think it does what you want.

-Peter

Re: git-svn tags and branches

[Giuseppe Bilotta]

On 8/30/07, Peter Baumann <waste.manager@gmx.de> wrote:
> 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.

Uh, it must have escaped me, thanks.

(Still, it would make sense to have a non-empty default.)

-- 
Giuseppe "Oblomov" Bilotta