Thanks for the reply, your decision not to block the release makes sense. Also, i was thinking of a temporary workaround for marking directories in destination branches to inhibit their deletion.. but it seems there isn't any.
May i help somehow to make this land in 1.7.x? Writing tests or analyzing code for the solution? Do you have already a clear list of shortcomings to be fixed before starting to implement this kind of detection? On Sun, May 1, 2011 at 3:22 PM, Stefan Sperling <s...@elego.de> wrote: > On Sun, May 01, 2011 at 01:13:14PM +0200, Paolo Compieta wrote: > > On Sat, Apr 30, 2011 at 8:56 PM, Stefan Sperling <s...@elego.de> wrote: > > > > > This is a remaining task tracked in this issue: > > > http://subversion.tigris.org/issues/show_bug.cgi?id=3150#desc4 > > > > > > I would expect this feature to appear in the 1.8 or a later release. > > > > > > > > > +1 to put this in 1.7, or one more 1.6.x > > > > In my company, we've been talking about this incident for a day and a > half, > > and we'll be working for a few other days trying to recall all recent > "svn > > move on dirs" and double-check all of them to see if we've lost things: > it's > > really scaring to know that svn could have removed modified things > without > > saying anything. I'd classify this as blocker, cause it seriously impairs > > merge operations for weeks, even after simple refactoring tasks (we have > > many different branches and sub-branches, thus modifications take time to > > spread and reach all branches). > > I know this seriously sucks and I would love to see it fixed, too. > But it's not a simple problem to fix, unfortunately. > > We did what we could for 1.6.x with tree conflict detection but several > problems remain that aren't feasible to fix quickly. We need to rewrite > some parts of the software to get this to work. 1.7 will already bring > us a step closer (all code managing working copies has been rewritten) > but it's not quite there yet. > > It should not be considered a blocker because it is not a regression from > a previous release. 1.7.x already has a vast amount of other improvements. > Keeping those on hold because of this problem would not be a wise decision. > > For now, if you do refactoring, you should merge them ASAP to branches that > you know will also need them. Subversion's current merge algorithm assumes > that tree structures in the merge sources and target match up. > It needs manual help if they don't. >
