On Sat, Aug 7, 2010 at 6:51 AM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Paul Burba wrote on Fri, Aug 06, 2010 at 10:30:50 -0400: >> As described in issue #2915, in 1.6 when a merge target is a missing >> subtree due to its removal by non-svn means, we try to record >> mergeinfo such that the missing subtree doesn't have (or inherit) >> mergeinfo describing the merge: >> >> (If you already have a vague idea of how this works you can skip to >> 'You might suggest that it makes more sense' below for the RFC) >> >> ### A file is missing in our merge target >> >> 1.6.13-dev>svn st >> ! A_COPY\D\H\psi >> >> ### No initial mergeinfo >> >> 1.6.13-dev>svn pg svn:mergeinfo -vR >> >> ### Merge tries to apply change to missing file, but can't >> ### and reports it as skipped >> >> 1.6.13-dev>svn merge ^^/A A_COPY -r2:4 >> --- Merging r3 through r4 into 'A_COPY': >> U A_COPY\D\G\rho >> Skipped missing target: 'A_COPY\D\H\psi' >> Summary of conflicts: >> Skipped paths: 1 >> >> ### Merge target gets mergeinfo describing the merge >> ### performed and the missing file gets empty "override" >> ### mergeinfo so it doesn't inherit the target's mergeinfo >> >> 1.6.13-dev>svn st >> M A_COPY >> M A_COPY\D\G\rho >> !M A_COPY\D\H\psi >> >> 1.6.13-dev>svn pg svn:mergeinfo -vR >> Properties on 'A_COPY\D\H\psi': >> svn:mergeinfo >> >> Properties on 'A_COPY': >> svn:mergeinfo >> /A:3-4 >> >> If the missing subtree was a directory we obviously can't set its >> properties, so we treat this as a tree conflict: >> > > When I read your "if you already know how it works", I expected that here > we'd set non-inheritable mergeinfo on the parent of the missing dir (and > then set normal mergeinfo on that dir's siblings). > > Perhaps there's a very good reason we don't do that --- I'm completely > unacquainted with these mergeinfo subtleties --- but I'm just repeating what > my intuition said...
Hi Daniel, Yours is a not unreasonable assumption given how we handle other types of 'missing' subtrees during a merge. Nothing was done to fix this in 1.5 simply because it was a low priority problem (http://subversion.tigris.org/issues/show_bug.cgi?id=2915#desc2). That 1.6 calls this a tree conflict due to the 'local delete' of of the directory is also bit odd since I suspect most of us would consider a 'local delete' as something due to 'svn delete' or perhaps a shallow working copy, rather than an OS-level removal of the directory. Regardless, with wcng's single DB we now have the opportunity to fix this in a very satisfactory way. Did you have any opinions on my two suggested solutions? Or perhaps a third option occurred to you? Paul >> 1.6.13-dev>svn st >> ! A_COPY\D\H >> >> 1.6.13-dev>svn merge ^^/A A_COPY -r2:4 >> --- Merging r3 through r4 into 'A_COPY': >> U A_COPY\D\G\rho >> C A_COPY\D\H >> Summary of conflicts: >> Tree conflicts: 1 >> >> 1.6.13-dev>svn st >> M A_COPY >> M A_COPY\D\G\rho >> ! C A_COPY\D\H >> > local delete, incoming edit upon merge >> >> ~~~~~ >
