[CC-ing two Subversion developers that might have more input on this... I'm not a merge expert :-)]
> -----Original Message----- > From: Pete Harlan [mailto:pchpubli...@gmail.com] > Sent: zaterdag 14 maart 2015 02:45 > To: Bert Huijben > Cc: subversion > Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in > subdirs > > Thank you for your response! This may demonstrate my question more > clearly: > > The script I posted creates an empty trunk and a branch from it, and > then creates dir/file.txt in both trunk and branch separately, and > then merges trunk to branch, resulting in this tree conflict: > > % svn st > M . > C dir > > local dir obstruction, incoming dir add upon merge > M dir/file.txt > Summary of conflicts: > Tree conflicts: 1 > > The path dir/file.txt gains an (empty) svn:mergeinfo property that > remains after resolving and committing the merge: > > % svn propget svn:mergeinfo -R > . - /trunk:2-4 > dir/file.txt - This mergeinformation on 'dir/file' is actually a copy of what was on trunk before this merge started, containing everything except the merge that was skipped. > % svn resolve --accept=working dir dir/file.txt > Resolved conflicted state of 'dir' Ack. This removes the conflict state to allow the conflict. If you would now (or after the conflict) run the same merge with --record-only the mergeinfo on parent and ancestor would be the same again. % svn merge -c 2-4 ^/trunk --record-only This tells Subversion that you performed all things to make the merge match the original revisions. This has the effect of 'eliding' the mergeinfo on the file. (Something which you and probably every other user would probably call 'removing the svn:mergeinfo property' from the file... Which is what happens if the mergeinfo matches that of the ancestor) I think it would be useful if the conflict resolver had an option to do this automatically for you, but I don't think we currently implement any resolving of tree conflicts at merge. (It is on our feature wish list, but it is very hard to determine what a user should/could do in each of the conflict situation) > % svn commit -m 'Merge from trunk' > Sending . > Sending dir/file.txt > > Committed revision 5. > > % svn propget svn:mergeinfo -R > . - /trunk:2-4 > dir/file.txt - > Question #1: Once the user has resolved the conflict, why treat > dir/file.txt differently than any other file involved in the merge > from trunk? I have resolved the merge to my satsifaction, and > do not wish to treat subpaths specially. You performed a multi revision merge and some of the changes were not applied to the target. R2 might have added the file, while r3 and r4 might have other interesting changes for this file. (Your script knows... but Subversion doesn't... While merging It just sees the merge as a range with a start and end-state) Why would you request that we just ignore those other changes by recording that everything was merged into your working copy? (The fact that we did this in 1.7 is what we call a bug). Losing valuable information during merges is one of the reasons we introduced tree conflicts in 1.6, and improved their detection in later versions. > > Question #2: If Subversion were to set dir/file.txt's svn:mergeinfo > property to "/trunk:2-4" after the resolution and prior to the commit, > would this reflect what the user intends, and then cause it to be > elided and disappear? Yes. See the record only merge I recommended above. (Just setting the property yourself doesn't trigger the elide code. Setting it using record only does this) > Interestingly (perhaps?), if I modify dir/file.txt on trunk and merge > that back into branch, the message from Subversion doesn't agree with > what it writes into file.txt's svn:mergeinfo property: > > % svn merge ^/trunk > --- Merging r5 through r6 into '.': > U dir/file.txt > --- Recording mergeinfo for merge of r2 through r6 into '.': > U . > --- Recording mergeinfo for merge of r2 through r6 into 'dir/file.txt': > U dir/file.txt > > % svn propget -v svn:mergeinfo -R > Properties on '.': > svn:mergeinfo > /trunk:2-6 > Properties on 'dir/file.txt': > svn:mergeinfo > /trunk/dir/file.txt:3-6 > > The merge says it's recording r2 through r6 into dir/file.txt, but > instead it records 3-6. (Trunk didn't change in revision 2, so the > two ranges represent the same set of changes.) These values surprise me. Especially 3-6. (I would have expected 2-6 (= the elide), or 5-6 (whatever was not merged first)) > Question #3: If I remove the svn:mergeinfo property on dir/file.txt > prior to committing the first merge, future merges appear to happen > normally and all is happy. Is removing that property going to create > a problem down the road? It is in our current implementation identical to that record only merge. Future merge improvements might work better if you created one 'file.txt' and merged that directly, but I don't see any problems in any versions of Subversion that exist today. (Including the upcoming 1.9) > If the answer to #3 is "removing the property does not create a > problem, since the user completely resolved all conflicts", then I > would argue that it would be nice if this happened automatically (as > in #2), restoring the pre-1.8 behavior. I agree that it would be nice to do this automatically as one of the options during conflict resolving. But the 'choose working' option you used here, is in almost every case keep the working copy as it is now and only remove the marker. Perhaps it would be the logical thing to do on 'mine-conflict' or 'theirs-conflict' for this particular type of conflict (Not sure which. I leave that to the merge experts). Note that the tree conflict has exactly this information stored to do this operation for you (See 'svn info' on your conflicted file)... We just haven't any resolver strategies on merge implemented yet. > Or am I misunderstanding something about the svn:mergeinfo property or > conflict resolution that would explain the need to track dir/file.txt > specially on an ongoing basis? I hope I explained a few more things here. Bert > > Thank you for your time. > > Pete > > On Fri, Mar 13, 2015 at 5:10 PM, Bert Huijben <b...@qqmail.nl> wrote: > > > > > >> -----Original Message----- > >> From: Pete Harlan [mailto:pchpubli...@gmail.com] > >> Sent: vrijdag 13 maart 2015 23:18 > >> To: Bert Huijben > >> Cc: subversion > >> Subject: Re: 1.8 bug(?): svn:mergeinfo set for tree-conflicted files in > >> subdirs > >> > >> Hi, > >> > >> I narrowed down the change to this commit, in version 1.8.0-dev: > >> > >> ------------------------------------------------------------------------ > >> r1441043 | rhuijben | 2013-01-31 08:20:25 -0800 (Thu, 31 Jan 2013) | > >> 30 lines > >> > >> Following up on r1440966, also handle file obstruction handling in the > merge > >> from the file_openened function. > >> > >> * subversion/libsvn_client/merge.c > >> (merge_file_baton_t): Add fields to store conflicts and skips. > >> (mark_dir_edited): Add comment. > >> (mark_file_edited): Handle skips and tree conflicts on files. > >> > >> (merge_file_opened): Handle obstruction handling for changes, adds, > deletes > >> and persist the result in the baton. Or notify if we know the result > >> for > >> delete/add. > >> > >> (merge_file_changed, > >> merge_file_added, > >> merge_file_deleted): Replace obstruction check with simple baton > readout. > >> > >> (merge_dir_opened): Tweak comment. > >> > >> * subversion/tests/cmdline/merge_authz_tests.py > >> (mergeinfo_and_skipped_paths): Expect detailed skip. > >> > >> * subversion/tests/cmdline/merge_tests.py > >> (merge_to_sparse_directories): Expect detailed skip. > >> > >> * subversion/tests/cmdline/merge_tree_conflict_tests.py > >> (tree_conflicts_merge_edit_onto_missing): Expect detailed skip. > >> > >> * subversion/tests/cmdline/tree_conflict_tests.py > >> (at_directory_external): Remove Wimp marker (added in r1440966) > >> > >> I don't know Subversion internals so I haven't dug in further than > >> this. Is there a way that I should be resolving the tree conflict > >> that would tell Subversion that I don't want the subdirectory to have > >> a detached svn:mergeinfo? I'm using "svn resolve --accept=working > >> <path>" but that leaves the property in place on the file within path. > > > > That just removes the marker that there was a conflict... It doesn't > > resolve the > actual conflict. > > > > And in your mails I haven't found a clear description either... > > > > The change you quote here is that something is skipped, because it was > obstructed. (Unversioned obstruction? Other merge? Something else?) > > > > Subversion doesn't know if that skip was intentional or needs further > > handling > from you as the user. That is why it marks the tree conflict. > > > > In some cases you might want to perform a followup merge to complete the > merge where it stopped at the obstruction. That might just be the same > operation as before, because it will continue where it had to stop the last > time. > That is why it records this mergeinfo... It hasn't merged this part of the > tree. > > > > In other cases you might want to perform a record only merge, to record that > something wass merged... if the thing to be merged is nothing at all. > > > > > > Subversion found an obstruction... Something in the way of what it expected > to be changing. > > * Why? > > * How should the merge continue? > > * What should the user do manually to resolve the obstruction > > * What could Subversion have done automatically to resolve the obstruction > > * How should this be recorded in Subversion. > > > > That is what the tree conflict asks you... > > > > And to help you further I need at least more information than I have now. > > > > > > Just creating an issue in our issue tracker is not going to help here... > > It will just delay your question until eventually another developer will be > asking these same questions. Probably only in a few years when you forgot the > answers. > > > > That is why we ask to only create issues after creating a full bug report > > and in > a way that eventually it can be resolved. The issue tracker is just for > remembering issues/todos, not a way to escalate a problem. Recording it there > is not a step towards resolving a problem. > > > > > > I currently have absolutely no idea where to look at to fix 'your issue', > > and I'm > pretty sure none of the other Subversion developers has a clue either. > > > > This all starts by 'what kind of obstruction' is there... Is there an > > obstruction or > is the fact that Subversion detects the obstruction a bug? > > > > An existing tree conflict that hasn't been resolved is certainly an > > obstruction... > That is why merges are interrupted to resolve the conflicts before continuing. > (And the intermediate state of the merge is recorded in the mergeinfo > properties) > > > > Bert > >
