On Mon, Apr 13, 2015 at 9:31 AM, Julian Foad <julianf...@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
