All of lore.kernel.org
 help / color / mirror / Atom feed
* Importing a subversion repository where some branches come from trunk subtrees
@ 2012-03-31  9:28 frnchfrgg.jr
  2012-03-31 10:07 ` Andrew Sayers
  0 siblings, 1 reply; 3+ messages in thread
From: frnchfrgg.jr @ 2012-03-31  9:28 UTC (permalink / raw)
  To: git

Hello,

I noticed that a svn branch made out of a subtree of trunk confuses
git-svn which fetches the whole history a second time (restricted to
that subtree). Unfortunately this kind of strange branching has been
repeatedly made in the Blender svn repository and I can end up with 5
or 6 times the full history from rev1 to rev20000, which makes the
conversion even slower, the mirror bigger and loooong to clone and
bisects completely unuseful.

Is this expected ? Or when git-svn identified the svn revision number
of the parent and there already is a git commit imported from this
revision, should it use that commit as the parent ? This would make
the branch creation commit have a big "mangling paths" diff with its
parent but I think it is logical.

That also means that when importing a revision, git-svn should always
import the state of the whole tree (up to the branch, tag, or trunk
root) and not only a part of it.

I have made a 4-revision sample svn repo which exhibits the problem,
but it is quite simple to reproduce.

Is there a good reason for this behaviour (in other cases I can't think of) ?


Julien "_FrnchFrgg_" Rivaud

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Importing a subversion repository where some branches come from trunk subtrees
  2012-03-31  9:28 Importing a subversion repository where some branches come from trunk subtrees frnchfrgg.jr
@ 2012-03-31 10:07 ` Andrew Sayers
  2012-03-31 10:23   ` Julien "_FrnchFrgg_" Rivaud
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Sayers @ 2012-03-31 10:07 UTC (permalink / raw)
  To: frnchfrgg.jr; +Cc: git

I'm not an expert on git-svn internals, but I believe sub-project
branches are a limitation of its branching implementation.  svn-fe
doesn't have this problem at the downloading stage (and will do 20,000
revisions much quicker than git-svn), but requires you to split branches
out by hand.

I'm currently trying to document these strange edge cases as part of an
ongoing effort to add branch information on top of svn-fe's output.
Would you mind taking a look at [1] and letting me know if it's an
understandable description of your problem?  Improvements and other edge
cases are very much welcome, and I hope to have something in the coming
months that tackles these issues.

	- Andrew

[1]https://github.com/andrew-sayers/SVN-Branching-Language/blob/master/t/advanced/subproject_branch.sh

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Importing a subversion repository where some branches come from trunk subtrees
  2012-03-31 10:07 ` Andrew Sayers
@ 2012-03-31 10:23   ` Julien "_FrnchFrgg_" Rivaud
  0 siblings, 0 replies; 3+ messages in thread
From: Julien "_FrnchFrgg_" Rivaud @ 2012-03-31 10:23 UTC (permalink / raw)
  To: Andrew Sayers; +Cc: git

On Sat, Mar 31, 2012 at 12:07 PM, Andrew Sayers
<andrew-git@pileofstuff.org> wrote:

> Would you mind taking a look at [1] and letting me know if it's an
> understandable description of your problem?
> [1]https://github.com/andrew-sayers/SVN-Branching-Language/blob/master/t/advanced/subproject_branch.sh

Yes, it indeed is a good description of the action that causes git-svn
to duplicate history (on the other hand, the cases I saw from the
blender repo seem more like overlooks and/or straight mistakes)

_FrnchFrgg_

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2012-03-31 10:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-31  9:28 Importing a subversion repository where some branches come from trunk subtrees frnchfrgg.jr
2012-03-31 10:07 ` Andrew Sayers
2012-03-31 10:23   ` Julien "_FrnchFrgg_" Rivaud

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.