Hello, On 2010-03-29 05:10, Eric Raymond wrote: > Thomas Rast <trast@xxxxxxxxxxxxxxx>: >> Eric Raymond wrote: >>> 2. The git-svn migration logic does not handle unmodified SVN tag >>> trees well. >> >> The problem here is that git-svn is designed to handle incremental >> updates, where it can't know whether some insane SVN user decides to >> modify the tag later on. > > Yes. Ideally, I suppose, git-svn (or whatever replaces it) would have > behavior something like this: > > 1. Turn unmodified tag directories into git tags > 2. Turn odified tags into branches. > 3. Recognize when a formerly unmodified tag has been modified, remove > the git tag, and turn it into a branch. > The 3rd point seems a bit weird to me.. users don't expect tags to disappear magically. Especially if it's done during a fetch while working. Here's how I would change the scenario: 1. For each creation of a sub-directory in SVN's tag directory, create a git tag on the revision that was referenced by the directory copy in SVN. 2. If (and only if) there are later modifications in the tag directory, create a branch starting from that tag. This way, the tag would be there but a branch would hold modifications based on code at this point, if there is any. The problem with my scenario, though is that it doesn't take care of tag creation + modification in the same commit (yuukkkk, but it's possible that it exists somewhere). If it could be possible to verify if modifications were made during the tag creation, then we could make the case hit both points. The other big "thing" is that it expects a certain correct separation into different directories (e.g. trunk/ tags/ branches/ ), which SVN doesn't enforce. -- Gabriel Filion -- 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