[Svnmerge] init leakage

[Raman Gupta]

James Sleeman wrote:
> My repository looks like (in order of creation and svnmerge init'ing):
>  /trunk
> 
>  /client/foo
>  /site/bar
> 
>  /client/zort
>  /site/narf
> 
> client/foo is a (bi-directional) branch of trunk, and has been
> init'd against it. site/bar is a (bi-directional) branch of
> client/foo, and has been init'd against it. client/zort is a
> (bi-directional) branch of trunk, and has been init'd against it. 
> site/narf is a (bi-directional) branch of client/zort, and has been
>  init'd against it.
> 
> If I do svnmerge avail in site/narf I get both zort (correct) and foo
> (incorrect) and trunk (also incorrect).
> 
> It only seems to propogate forwards, not backwards.  That is, if I do
> svnmerge avail in site/bar I do not get client/zort which was init'd
> after site/bar was.

The simple reason is that the branching operation ("svn cp") is
copying the merge information implicitly.

I think svnmerge.py should grow a feature on init to create branches:

  svn init --cp ...

This command would do the svn cp, uninit merging to any existing
sources to avoid that information being implicitly carried over (the
uninit could be turned off with --mergecarry if someone has a good
reason to keep the carry-over merge info but I suspect that would be
rare), and finally init merging with the source branch. For a
discussion about this implicit vs. explicit stuff, see [1].

Thoughts?

Cheers,
Raman Gupta

[1] I believe, as James seem to, that the initialization of merging
between branches should be explicit and svnmerge.py should not
therefore, in James' example, consider narf to have any (direct)
merging relationship with foo and trunk. The tool should not assume
that it knows this information without any input from the user.

In svnmerge.py, this argument is doubled because svnmerge.py doesn't
even deterministically support merges from foo and trunk to narf
anyway -- at least not if one wants to continue merging between trunk
and foo (what we on the list have been calling graph-based merging as
opposed to a straight transitive merging which is what James is doing,
of which only the latter is currently supported).

Even if svnmerge.py did support graph merging, I still don't think the
tool should carry over that merge information unless the user requests
it explicitly. One reason is that merging relationships serve as
important project documentation, and having the tool create these
relationships implicitly is usually confusing because, while sometimes
the information makes sense to the user ("oh, I can merge stuff from
there, cool!"), usually it does not ("what! why would I want to merge
stuff from there? who did that?!").