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 <stsp_at_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 <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-04 01:32:28 CEST