On Thu, Apr 2, 2015 at 11:00 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Pete Harlan wrote:
...
>> If you have suggestions for how I could further help this issue along,
>> please let me know. And thanks again very much for your time.
>
> It would help to catalogue the various cases. Maybe start with an
> premise that a whole tree merge should not generate any subtree
> mergeinfo and start finding the exceptions that currently occur.
I wrote a list of cases I could think of to test, and tested them
against 1.8.13.
Of the cases I considered and tested, the subtree mergeinfo appeared
if and only if a *directory* node was part of a tree conflict
(regardless of what it conflicted with). "PASSED" here means no
subtree merge info was created, and "FAILED" means it was created.
In all cases, "svn resolve --accept=working <conflicted path>" was run
prior to looking for subtree mergeinfo.
PASSED: dir-add-delete.sh (One side adds a dir, the other added and
deleted a dir of the same name)
PASSED: dir-delete-delete.sh (Both sides deleted a common dir.)
PASSED: file-add-add.sh (Both sides added a file with the same name.)
PASSED: file-add-delete.sh (One side added a file, the other added
and deleted the file.)
PASSED: file-copy-add.sh (One side added a file via copy, the other
via creating a new file.)
PASSED: file-delete-delete.sh (Both sides deleted the same file.)
PASSED: file-edit-delete.sh (One side edited a file, the other deleted it.)
PASSED: file-edit-edit.sh (Both sides edited a file in conflicting ways.)
PASSED: no-conflict.sh (Clean merge.)
FAILED: dir-add-add.sh (Dir of same name added to both sides.)
FAILED: dir-copy-add.sh (Same, only one was added via copy the other as new.)
FAILED: dir-file-add-add.sh (File added to one side, dir of same name
added to other.)
Current trunk fails the same tests. All tests pass with 1.7.20 and 1.6.23.
My scripts are Bash scripts similar to the script I originally posted
to this thread. I can share them if you think that would be useful,
or I'm happy to rerun them against other versions upon request.
> Another way to help would be to think about how the client could
> present the "WC is in a merged state" notion, and how that would
> affect various operations. Just assume that we can implement it, and
> imagine how it should behave in order to be useful. Is there a hard
> dividing line between "is" and "is not" in a "merged" state for the
> whole WC -- what if we *want* to merge subtrees separately? Does this
> "state" need more degrees of subtlety in some other way too?
When the WC is in a merged state, doesn't it necessarily contain
modifications to the merge-root svn:mergeinfo property? It seems
reasonable to me to have Subversion error out from initiating a new
merge if it is currently in the middle of a merge (as identified by a
modified svn:mergeinfo property), with a message like "You are in the
middle of merging <url> to <WC path>; please complete that before
merging again or revert it with <...>".
Any modification to other nodes' mergeinfo would be done only by
"resolve", which by default would resolve as a "full merge" as
initiated by the user (and thus not add explicit mergeinfo), and if
you want to handle merges that omit interior nodes from the merge
(why?) then you would do so with a new option to resolve, something
like "svn resolve --accept=omit-from-merge <path>". If *that* command
created interior mergeinfo, that would probably coincide with user
expectation.
I am aware that my analysis is naive regarding both Subversion's
implementation and the universe of potential use-cases, but for the
way I use Subversion this seems reasonable to me.
I'm also wondering if something could be done more expediently: Is
Subversion doing anything useful with the subtree mergeinfo that
appeared in 1.8? If not, then perhaps it could disappear until the
feature it's part of is more fleshed out (i.e., until a solution that
includes ways for the user to pass their intent to "resolve" is
added). Again, I don't know Subversion internals so maybe Subversion
is doing something useful with that information that I'm unaware of.
Thank you for your time,
--Pete
Received on 2015-04-11 02:03:02 CEST