Blair Zajac wrote: > Daniel Rall wrote: >> On Thu, 09 Nov 2006, Blair Zajac wrote: >> ... >>> However, how is the svn merge tracking in 1.5 or greater going to >>> work? Is it always going to effectively have the -b flag set? >> >> Yes. >> >>> We had this discussion before, but I would much rather see the -b >>> flag always set to reduce the possibility of errors. If the svn 1.5 >>> merge tracking will always have bidirectional support on, then I >>> think svnmerge.py should too. >> >> I tend to think so, too. Why is bi-directional support in svnmerge.py >> off by default (other than it being added later on); does it result in >> a performance problem? > > Yes. IIRC, Giovanni had performance concerns about using bidirectional > support with svn repositories that aren't on the LAN. I was outvoted :)
One problem is that currently to enable bidirectional merging, one has to set svnmerge properties on both of the directories involved in the exchange. This is awkward to do via a working copy because typically one doesn't have a working copy that contains both directories. Would the following be a decent approach with good backwards portability? - "svnmerge.py init" can be invoked only on single directories, and allows merging *into* that directory. To enable bidirectional merging, one has to run "svnmerge.py init" in each of the directories (each time setting the other directory as the merge source). - All other merge commands check whether "svnmerge.py init" has been invoked in both directories involved in the merge. If so, it assumes the --bidirectional option. If not, then it reverts to the current default behavior. In the case of non-bidirectional merging, this approach of course requires an extra propget. Michael _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
