On Thu, 21 Jun 2007, [EMAIL PROTECTED] wrote: > >>> On Thu, Jun 21, 2007 [EMAIL PROTECTED] wrote: > > http://www.orcaware.com/pipermail/svnmerge/2007-January/000821.html > > Thanks for the info. > > > Fixing these broken tests would be a great starting point for making > > yourself at home in the Subversion development community. > > Sounds great. I'm looking forward to the further info on that.
Pertaining to the test breakage itself, this is all the info I have off-hand. Further info can be discovered through investigation of the change itself, and its impact on the test cases (as it looked like you intended). For general information about working with Subversion's core development community, I recommend reading: http://subversion.tigris.org/hacking.html > >> It's not necessarily pretty but seems to reduce the risk for our most > >> common > >> scenarios. There are some scenarios that I know it doesn't support, best > >> practices, tips from our internal wiki that I can share later if there's > >> interest. > > I understand. Have you read > > <http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts.txt> ? > > > > While I do see a compelling need for this behavioral change, this does > > strike me as a lot of complexity to add to svnmerge.py. Perhaps after > > the change sets in your patch have been teased apart, it will seem > > more manageable. > > OK. Thanks for that link. I think of these changes to svnmerge.py as a > workaround until something like the tree conflicts problem is solved, whether > via issue #2282 (http://subversion.tigris.org/issues/show_bug.cgi?id=2282), > #2685 (http://subversion.tigris.org/issues/show_bug.cgi?id=2685), or real > 'atomic renames'. I am trying to learn more about the scope of #2685 to see > if it's something I can do myself in the time I can commit, but either way it > seems like our organization needs something in an earlier timeframe, than what > seems likely for fixing tree collisions, hence this workaround. I thought > others might be able to use it too. But if not, that's OK especially if one > of the other solutions could be done relatively soon. I urge you to review tree-conflicts.txt, and post your thoughts to the dev{AT}subversion.tigris.org mailing list. There are folks on that list actively thinking about this problem today who would be very happy to hear your thoughts, and work with you on this problem. > But I'll try to break up the patches too. That's a good idea. Some of that refactoring could be committed immediately, without much discussion. > I'll also work on trying to understand issue #2685 > (http://subversion.tigris.org/issues/show_bug.cgi?id=2685) better. > > Am I correct in speculating that any fix for tree collisions is likely to come > sometime after 1.5.0? We're trying to get some initial, weak-but-likely-helpful support for handling tree conflicts (without atomic rename support) into 1.5.0. The bulk of the work will follow. Personally, I could see it justifying a quick 1.6.0, as this is one of the top deficiencies in Subversion 1.x. IMHO, Subversion 2.x will be a whole 'nother ballgame.
pgp1ITlGoZokB.pgp
Description: PGP signature
_______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
