Thread (7 messages) flat view 7 messages, 3 authors, 2016-06-15

Re: Three issues from a Subversion-to-git migration

From: Gabriel Filion <hidden>
Date: 2016-06-15 22:48:31

Hello,

On 2010-03-29 05:10, Eric Raymond wrote:
Thomas Rast [off-list ref]:
quoted
Eric Raymond wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help