Re: Merge, undetected tree conflict when source tree moves directory
On Sat, Apr 30, 2011 at 8:56 PM, Stefan Sperling 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). Thanks Paolo
Re: Merge, undetected tree conflict when source tree moves directory
On Sun, May 01, 2011 at 01:13:14PM +0200, Paolo Compieta wrote: > On Sat, Apr 30, 2011 at 8:56 PM, Stefan Sperling 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.
Re: Merge, undetected tree conflict when source tree moves directory
Please find attached the repro-template(s) to reproduce the case in Ubuntu and Win7. Cheers, Paolo Compieta On Sat, Apr 30, 2011 at 6:29 PM, Paolo Compieta wrote: > Hi, > this is a first post, hope it's well written and clear. I've found this > (candidate-)bug while at work, and it's a big problem for my company. > I'm posting this to ask if it's a known bug (i haven't found anything > similar in the issue tracker, hope i did the right searches) or if it's > some stupid practice we're using that impairs us from handling "svn > move on dirs" properly. > > --- Details: > > OS: Ubuntu 10.04, Windows Vista > Subversion: 1.6.16 > > Bug: while merging, svn doesn't detect a tree conflict when: > source branch has "svn moved" (i.e. deleted) a folder > destination branch has modified a file inside the same folder > > Step to reproduce: > - trunk has folder A and file A/iota, branch is copied from this > - trunk moves (deletes) folder A, branch modifies A/iota > - branch merges from trunk > > Actual behavior: > svn doesn't rise any conflict or warning, discarding all > modifications in the branch > Expected behavior: > TREE CONFLICT: the directory being deleted in the branch > has changed from the merge's initial revision (see "Use > Case 5" and "Equality of directories" in > http://svn.apache.org/repos/asf/subversion/trunk/notes/tree-conflicts/detection.txt) > > > Cheers, > Paolo Compieta > svn_undetectedTreeConflict.sh Description: Bourne shell script repro-template Description: Binary data
Re: Merge, undetected tree conflict when source tree moves directory
Attaching also the complete script for Win7. (i already sent the template to the dev list) Paolo On Sat, Apr 30, 2011 at 6:36 PM, Paolo Compieta wrote: > Please find attached the repro-template(s) to reproduce the case in Ubuntu > and Win7. > > Cheers, > Paolo Compieta > > > On Sat, Apr 30, 2011 at 6:29 PM, Paolo Compieta > wrote: >> Hi, >> this is a first post, hope it's well written and clear. I've found this >> (candidate-)bug while at work, and it's a big problem for my company. >> I'm posting this to ask if it's a known bug (i haven't found anything >> similar in the issue tracker, hope i did the right searches) or if it's >> some stupid practice we're using that impairs us from handling "svn >> move on dirs" properly. >> >> --- Details: >> >> OS: Ubuntu 10.04, Windows Vista >> Subversion: 1.6.16 >> >> Bug: while merging, svn doesn't detect a tree conflict when: >> source branch has "svn moved" (i.e. deleted) a folder >> destination branch has modified a file inside the same folder >> >> Step to reproduce: >> - trunk has folder A and file A/iota, branch is copied from this >> - trunk moves (deletes) folder A, branch modifies A/iota >> - branch merges from trunk >> >> Actual behavior: >> svn doesn't rise any conflict or warning, discarding all >> modifications in the branch >> Expected behavior: >> TREE CONFLICT: the directory being deleted in the branch >> has changed from the merge's initial revision (see "Use >> Case 5" and "Equality of directories" in >> http://svn.apache.org/repos/asf/subversion/trunk/notes/tree-conflicts/detection.txt) >> >> >> Cheers, >> Paolo Compieta >> > > svn_undetectedTreeConflict_bat Description: Binary data
