git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Feature Request] Better Subversion integration

From
Björn Steinbrink <b.steinbrink@gmx.de>
Date
Feb 10, 2008, 17:53 UTC
Message-ID
<20080210175351.GA13411@atjola.homenet>
In-Reply-To
<47AF2BBF.1060403@alum.mit.edu>
On 2008.02.10 17:52:15 +0100, Michael Haggerty wrote:
Show 29 quoted lines
> 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
Previous: Michael HaggertyNext: Michael Haggerty
Message 4 of 10 in “[Feature Request] Better Subversion integration”
  1. Sam Granieri JrFeb 10, 2008
  2. Björn SteinbrinkFeb 10, 2008
  3. Michael HaggertyFeb 10, 2008
  4. Björn SteinbrinkFeb 10, 2008
  5. Michael HaggertyFeb 10, 2008
  6. Björn SteinbrinkFeb 10, 2008
  7. Sebastian HarlFeb 11, 2008
  8. Sam Granieri JrFeb 11, 2008
  9. Sebastian HarlFeb 11, 2008
  10. Jan HudecFeb 15, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.