Re: [Feature Request] Better Subversion integration

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2008.02.10 17:52:15 +0100, Michael Haggerty wrote:
> Björn Steinbrink wrote:
> > On 2008.02.09 20:44:59 -0600, Sam Granieri Jr wrote:
> >> Right now, git-svn import (or clone) will convert tags and branches as  
> >> remote branches.
> >> I would like it if git could pick up subversion tags and translate them 
> >> as git tags upon importing
> > 
> > SVN tags aren't like git tags. A "tag" in SVN is just another directory,
> > which you can modify at will. Yeah, I know, you _should_ not commit any
> > changes to SVN "tags", but shit happens. And once you modify the "tag"
> > in SVN, you would have to invalidate the git tag, and finding a commit
> > that matches the SVN state of things is probably way too expensive to be
> > practical. Maybe some --we-never-mess-up-svn-tag-alike-branches could
> > be added to allow git-svn to create teal git tags though? Dunno, I don't
> > care much. Shouldn't be too hard to find some shell magic to create
> > tags, if one wants them.
> 
> Because of the way an SVN repository is stored, it should be cheap to
> ask SVN whether the contents of a tag in the HEAD revision are identical
> to the contents at the time the tag was created.  If there was any
> change anywhere under the tag directory, then the node of the tag
> directory will be different in the two revisions.
> 
> For that matter, you could ask SVN for information about the revisions
> in which the tags/ directory was changed (this is also very cheap), and
> make sure that none of those changes modified an existing tag.  This
> scan could be done at the beginning of a conversion to determine which
> tags were handled as pure tags (and therefore convertible as git tags)
> and which were not (and therefore require more complicated handling).

Yeah, but what if a "tag" in SVN is modified after that? Then the git
tag becomes kinda invalid, and I see no cheap way to figure out if there
is a commit somewhere that has the same content of the new "tag". That's
what I'm talking about.

The only way I see to handle that is to create a new commit in git and
tag that. But IMHO that's totally nuts, because the tag doesn't even
point to a commit of the "real" branch anymore. And you'd either need to
replace/remove the old tag or use a naming scheme that includes some
@rev marker, both of which are just confusing when talking about tags.

Björn