[Svnmerge] [PATCH] preserving mods to renamed files/directories

[Daniel Rall]

On Thu, 21 Jun 2007, lsuvkne at onemodel.org wrote:

> >>> On Thu, Jun 21, 2007 dlr at collab.net 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/svnmerge/attachments/20070621/72555dd2/attachment-0002.pgp>