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