Re: [Feature Request] Better Subversion integration

[Michael Haggerty <mhagger@alum.mit.edu>]

Björn Steinbrink wrote:
> 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.

You're right; when importing incrementally there is no way to know what
people will do with a tag after the initial conversion.  I was thinking
more of a one-time conversion.

If a new tag is created cleanly in subversion (that is, a single copy
from a single location, then you can read the SVN source (trunk or
branch name + SVN revision number) directly out of SVN.  A persistent
look-up table could keep track of the git hashes corresponding to such
sources.

If a clean tag is later modified, would it be reasonable to
"retroactively" create a git branch based on the contents of the old
tag, and modify that?

The general case is certainly not easy, but some standard, easy cases
could probably be covered.

Michael