[Svnmerge] Bi-directional merging becoming more painful

[Blair Zajac]

Raman Gupta wrote:
> Blair Zajac wrote:
> 
>>So, given all that, where do we stand on resolving this issue in
>>svnmerge.py?
>>
>>There was some discussion a while back, but I don't know where people
>>stand now.
> 
> 
> Personally, this is the only thing keeping me from moving to the .py
> version.  I still have and use my patched shell version that allows me
> to track bi-directional merges using hidden dot-files. There was some
> discussion after my contributed patch about implementing it without
> using dot-files, but AFAIK there has not been any action on that front
> yet. See this message from Archie:
> 
> http://www.orcaware.com/pipermail/svnmerge/2005-August/000024.html
> 
> and the following one or two messages.

Thanks.  The bidirectional merging problem has been getting more painful for me, 
so I'm thinking about implementing something soon.

Here's my thoughts on reading the archived discussions.

1) In one of my projects, I have in my repository a checked in copy of a project 
from a separate Subversion repository that I don't have commit writes to, i.e. a 
vendor project.  I don't want to use svn:externals, since sometimes I send 
patches upstream and when they get commited, I would like to use svnmerge.py to 
merge in that one revision that I care about into my vendor branch.  When the 
next official release is announced, I then merge in all revisions.  The solution 
of modifying the source path won't work in this case, as I can't do commits into 
the source URL.

Another point Raman pointed out with the property on the source URL is that it 
requires a second commit by the user, which would then need to be handled by an 
'svnmerge commit' instead of an 'svn commit'.  This is potentailly lossy and I 
could easily see loosing information to have svnmerge working properly.

So if I had to trade adding dot files to my working copies or modifying the 
source URL, I would choose adding dot files.

2) On a larger scope, the different methods of handling the problem boil down to 
solutions that cache data somewhere (dot files or properties in the source URL) 
to speed up the merges versus a solution that doesn't cache anything but may be 
much slower.

I think Giovanni's in a good position to let us know about speed issues, as I 
understand, svnmerge.py is being used in the gcc repository, which is huge :) 
Any slowness pain there, we'll definitely hear about it.

So I think as a community, we should decide on the dot files or the slow 
approach.  Maybe we implement both?  Having the dot files there won't prevent 
the slower solution from working.

Regards,
Blair