On Wed, 25 Mar 2009 17:31:34 -0400 ptburba_at_gmail.com> wrote:
> > Hm, I guess I *have to* read that paper now :). Yes, I've been
> > subtree mergeinfo produced by sparse merges for those subtrees that
> > figured are not affected by the merge. That is, if merging rX into
> > sparse working copy only affects paths below /trunk/src, I've felt it
> > to revert the mergeinfo generated for the sparse /trunk/testdata
> folder. Is
> > this an unsafe practice?
> Assuming that there would only be changes under trunk/src *even* if
> the other shallow subtrees were present, then what you are doing
> should be safe (in fact I'm presently looking into making what you are
> doing the default behavior for merge).
That sounds cool! Making the merge produce only as little mergeinfo as needed will make it much more understandable as to why it's there.
> But when you said "sparse working copies invariably produce subtree
> mergeinfo, which makes it hard to reason about the performed merges
> and can cause problems with merge --reintegrate" I was imagining
> something like this:
> 1) You have a repos structured like this:
> 2) Copy trunk_at_99 to branches/branch-1 in r100
> 3) Checkout branches/branch-1 such that the docs subtree is missing
> due to a shallow checkout:
> branches (depth infinity)
> branches/src (depth infinity)
> branches/docs (depth empty)
> 4) Make some changes under both trunk/src and trunk/docs in r101-123.
> 5) In r124-r125 we make some changes to branches/branch-1
> 6) Merge all available revisions (i.e. now -r or -c option is
> specified) from trunk to branches/branch-1.
> Mergeinfo is set as follows:
> branches/branch-1 '/trunk:101-125'
> branches/branch-1/docs '/trunk:101-125*'
> Before committing this merge as r126 we delete the mergeinfo set on
> 6) Now we reintegrate branches/branch-1 back to trunk. Under the
> covers reintegrate is doing the following 2-URL merge:
> svn merge trunk_URL_at_125 branch-1_URL_at_126 trunk_working_copy
> But wait! The merge we did in #6 never brought the changes to the
> docs subtree that we made in #4 (because the subtree wasn't present to
> receive them). So branch-1_URL/docs_at_126 is the same as
> trunk_URL/docs@*99*. The 2-URL merge will actually revert those
> changes to trunk/docs that we made in #4, which is almost certainly
> not what we intended. Does that make sense?
Yes, if the trunk changes get silently reverted, then this is really dangerous.
But could the merge be smarter here? I mean, the last change on branch-1/docs is at r99 (it was never changed in branch-1 since it is sparse in the working copy). This should be the case even when merging from branch-1_at_126. Couldn't the merge therefore notice that branch-1/docs_at_126 is really branch-1/docs_at_99 which is *older* than trunk/docs_at_123 and skip the harmful merge?
Is this distinction technically impossible to make, or am I missing something obvious?
Received on 2009-03-25 23:42:22 CET