On 2008.02.10 20:36:34 +0100, Michael Haggerty wrote:
> 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?
That's the first option I described (well, I skipped the "create a
branch" part). But you would get a history like this:
Before the tag change:
---A (tag XYZ)
\
B---C---D (trunk)
After the tag change:
---A---A' (tag XYZ)
\
B---C---D (trunk)
So not only does the tag move, but it's also no longer in the history of
trunk. And that makes it IMHO a bit confusing/useless to do that. With
the branches, you at least _know_ that things can change. Tags are not
supposed to do so.
That said, I'd not oppose any optional support to create such tags, I'd
just never use it.
Björn
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
