[Svnmerge] init leakage

James Sleeman james at gogo.co.nz
Sat Feb 16 18:33:18 PST 2008


On Sat, 2008-02-16 at 11:23 -0500, Raman Gupta wrote:
> James Sleeman wrote:
> > If I do svnmerge avail in site/narf I get both zort (correct) and foo
> > (incorrect) and trunk (also incorrect).
>
> The simple reason is that the branching operation ("svn cp") is
> copying the merge information implicitly.

Ah, of course. Didn't even think of that.  So to "correct" the issue in
my repo I could just svnmerge uninit on the bad ones and it should be
fine.

> 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 

Why not consider instead of adding another command or option to
svnmerge, the properties used by svnmerge could simply include and check
the "linked" branch(es).

For example after creating & initing client/zort and site/narf, the
properties on site/narf would include

  svnmerge-link: /branches/site/narf:/branches/client/zort 
                 /branches/client/zort:/trunk

Which was the result of something like
  $ svn cp /trunk /branches/client/zort
  zort$ svnmerge init /trunk

  $ svn cp /branches/client/zort /branches/site/narf
  narf$ svnmerge init /branches/client/zort 

After the zort$ init, /branches/client/zort has property
 svnmerge-link:  /branches/client/zort:/trunk

After the second svn cp /branches/site/narf has
 svnmerge-link:  /branches/client/zort:/trunk

After the narf$ init, /branches/site/narf has
 svnmerge-link: /branches/site/narf:/branches/client/zort 
                /branches/client/zort:/trunk
 
An svnmerge uninit just removes the appropriate source from the
appropriate target in the svnmerge-link property.

  narf$ svnmerge uninit /branches/client/zort
  svnmerge-link: /branches/site/narf:/branches/client/zort 

  narf$ svnmerge uninit /trunk
  ERROR: trunk not initialized against /branches/site/narf

When svnmerge needs to determine available sources it simply looks in
svnmerge-link to find them (rather than svnmerge-integrated).

That way svn cp will work in the way (I) expected, because the new
branch has a different value for the target which will not appear in
svnmerge-link until it's inited against something.

It also keeps intact the "history of the merge/block" of the branch
because svnmerge uninit only removes the link, not the
integration/blocking history (currently uninit deletes merge/block
information) even when it has been propogated by svn cp from ancestors.

And also implicitly allows that situation for which your --merge-carry
flag catered, because the user can simply svnmerge init against that
ancestor source again and because all merge/block information has been
preserved (implicitly) from the time the target copy was made then it
will behave in just the expected manner.  I suspect that the only time
this would come into play, is renaming a branch (svn mv) that's the only
time you'd WANT to preserve your link'd sources, and again, with this
proposal, simply re-running svnmerge init on the appropriate target(s)
in the now renamed branch will relink them without any issue whatsoever.

So to conclude:
  add new property svnmerge-link which is list of target:source
  svnmerge init adds to svnmerge-link
  svnmerge uninit removes from svnmerge-link
  svnmerge avail (etc.) uses svnmerge-link (instead of
svnmerge-integrated) to figure out what source's are available to
svnmerge
  no information is lost, in fact, more is stored and preserved
  people rejoice in the better expected behaviour of making many level'd
branched repositories and the preservation of merge/block information
even after uniniting so that reiniting is much more painless

Unfortunatly python isn't my area of expertise and any lame attempt by
me to implement this would never be accepted, but hopefully my idea is
useful.  I expect it took longer to write this email than it would for
somebody to write the patch :-)

-- 
James Sleeman, Gogo Internet Services
http://host.gogo.co.nz/ - Webhosting + Free Domain or 25% Discount for
Designers
http://code.gogo.co.nz/ - PHP Programming




More information about the Svnmerge mailing list