On Sun, May 01, 2011 at 01:13:14PM +0200, Paolo Compieta wrote:
> On Sat, Apr 30, 2011 at 8:56 PM, Stefan Sperling <stsp_at_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.
Received on 2011-05-01 15:23:18 CEST