On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> 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
But in this example, ./subtree is the merge root, and it's subtree's
mergeinfo that is modified (in 1.8.13), so this agrees with what I
suggested.
(I may be using "merge root" in a nonstandard way: I mean the points
in the WC and the source URL that are being merged.)
>> 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.
That is a case I hadn't considered, but it sounds reasonable and I
think a bypass would make sense here.
>> 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?
Yes, that makes a lot of sense. It's a way to collaborate on a merge,
with the downside being that commits are made that represent an
inconsistent state of the code (but that may be the best solution in
some cases).
--Pete
>> 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 20:12:53 CEST