see, i still think conceptually it is a conflict, within a file if the spot a given bit of diff would apply is missing we'd still consider it a conflict, why isn't this the same thing? because we don't record it or any of the information that it would've merged, mainly with conflicts, we record both when you perform a large merge and thousands of lines of merge output scroll by, it's easy to miss a "skipped" notification sure, now we don't flag it as a conflict, but now we don't record mergeinfo either, we're changing that ;-) with conflicts, 'svn st' tells you wazzzup no argument that right now we don't treat it as a conflict, but conceptually, i don't see why it's any different if we don't record any info about the skip, we can't possibly claim that we've performed the merge ok, forget about what we record and what we don't record we've effectively skipped the merge because we skip the merge, we shouldn't record that we have performed it via the merge info but skipping the merge is conceptually the same as failing to apply a hunk of a diff because that section of the file is missing the fact that we don't track that fact now doesn't change it IMO we still put the hunk into the file, surrounded by conflict markers that is a very important difference because of it, we *do* perform the merge yes, and i'm saying maybe we should be doing something similar for skipped files/dirs in a merge I certainly wouldn't argue against that. kmaples was complaining to me the other day about the fact that our skip notifications fail to report *why* a file was skipped which is really important on large branch merges lets say we do it your way, if i've deleted A/B/z, and then merged a change that touched A/B/z and A/C/q, do we really want that rev to show up as available for A/B? I don't particularly want to go off on that tangent ATM,tho. rooneg: How else can I apply the change to "z" after restoring it in my WC? If we mark it as merged, there's no way to get that change. ahh, but if you restore z, it comes in with new merge history, it doesn't inherit it from its parent (or at least it shouldn't, IMO, since it wasn't there for the merge) it should get whatever merge history existed in the rev you resurrected it from The way things work now, it would inherit the merge info. but should it? ...because it's not set directly on z, but on its parent. Should it? Hell no. Yet one more thing to track, though. sure, but eventually merge history becomes disjoint, so in that case we could give it different merge history than its parent, and i think in order to be correct we have to the "inherit from your parent" thing is an optimization we can use when it's appropriate, it's not always correct we currently have no facility to track that information isn't that what you're supposed to be coding? ;-) (to your previous comment) Per the design, the only way to override inheritance is to set different merge info for the child. exactly, and when you copy z from a previous rev that's what should happen If we do that for z after it's deleted, then run 'svn revert z' to restore z, you just clobbered the merge info, and z now inherits from its parent. because unless you happen to copy it from a rev that happens to match in mergeinfo with its parent dir, it will be different hang on there, explain that one more time paths which have the same merge info as their parent don't have any merge info set explicitly yes, but when the merge info becomes different we need to recognize it and give them explicit merge info, right? isn't that the whole point? so, z will revert to the merge info it had before your merge, which -- if nothing -- will indicate that it inherits from it's parent but merge info is recorded as a property if you 'svn revert', you just clobbered that property if that's the case we need to fix that, revert needs to get smarter about merges what exactly should it do? it doesn't have access to the previous merge info without hitting the repos ...'cuz the pristine merge info was recorded on some parent not on z revert will become a non-local op hmm. yeah, that's tough ok, so lets forget about the merge then revert case if you do that you get what you deserve How else do you restore the original z so that you can somehow merge in the changes from the rev you just tried to merge? i wasn't talking about that sort of thing. i was talking about a 'svn cp from a previous rev' type thing, in that case shouldn't z get a new custom mergeinfo because we KNOW it isn't supposed to be the same as its parent dir, since it wasn't even there for all of parent dir's merges so svn delete z && svn ci, merge, ci, merge, ci, svn cp -r OLDREV $URL_OF_Z z, at this point z has a custom mergeinfo yes How is that a problem case? in that case, recording mergeinfo for skips (potentially by marking them as conflicts and requiring users to say "yes, i know it skipped") seems fine, because if the file ever comes back from the dead (other than via revert) it'll get new mergeinfo anyway In that scenario, where are the skips? we don't have to annoy the user by having those revs show up as available for that subdir, since if it ever matters (i.e. a file/dir in there that the revs would have merged into shows up again) the mergeinfo will get reset durring the resurrection from one of the middle 'merge, ci' ops? yes, exactly so the difference between your way and my way becomes "does that subdir show available revs for merging before z is resurrected?" your case is easier, but it results in mergeable revs that will never actually apply because z is never there In my case, z is either versioned (and missing locally), or unversioned and present locally. what about the case where z has been deleted and the delete was committed? we still skip then, don't we? In the case you described, I don't see any reason to not record merge info. In my case, I do. yes they seem to be different flavors of skip, tho ok, then we need to diferentiate between "skipped because the thing really isn't there" and "skipped because it's been locally deleted or is missing or something else weird" rooneg: I think my case falls under into the "obstructed" and "missing but expected to be there" categories your case falls under the "expected to be missing" category yes unexpected vs. expected skips? yucky crap, you distract me with interesting technical discussions and the twins are up 6 to nothing. damn it. yeah, expected vs. unexpected seems like the right distinction to make.