Pete Harlan wrote:
> Julian Foad wrote:
[...]
>> 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?
Not necessarily. Not if I ran a subtree merge, such as
svn merge ^/branches/source-branch/subtree ./subtree
> 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 <...>".
Sometimes, particularly if I know there's a big change or an intrusive
change among all the changes I want to merge from a given source
branch, it is nice to be able to merge a portion of all the source
changes I really want (a restricted revision range and/or a restricted
subtree), and resolve conflicts and check it's looking ok, and then
merge another portion or all the rest of the changes. That can help me
to deal with complex conflicts better.
But in general, I expect most people do most merges in one go, and
what you suggest might indeed be helpful. We just might want a bypass
for the intentional cases. That's no problem, we can have a bypass.
> 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?)
I might want to omit part of the tree from the merge if, for example,
the tree consists of one subtree 'src' containing lots of source code,
and another 'doc' containing lots of documentation, and the merge
turns out to have lots of changes and lots of conflicts in both areas,
and I decide that instead of completing all the conflict resolution in
both subtrees I'd rather concentrate on getting everything under 'src'
properly merged and leave the 'doc' for later. I might want to commit
this result, a result that says everything except the content of 'doc'
is merged, so that I or someone else can then merge the 'doc' subtree
later. Does that make sense, at least hypothetically?
> 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.
Yes, that sort of thing sounds reasonable.
> 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.
Hmm, I'm not sure about that.
- Julian
Received on 2015-04-13 18:35:16 CEST