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
> reverting
> > subtree mergeinfo produced by sparse merges for those subtrees that
> I've
> > figured are not affected by the merge. That is, if merging rX into
> my
> > sparse working copy only affects paths below /trunk/src, I've felt it
> safe
> > 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).
Hi Paul,
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:
>
> trunk
> trunk/src
> trunk/docs
>
> 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
> 'docs'.
>
> 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?
Kari.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1421079
Received on 2009-03-25 23:42:22 CET