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