On Wed, Mar 25, 2009 at 4:56 PM, Kari Granö <kari.grano_at_gmail.com> wrote:
> On Wed, 25 Mar 2009 09:48:18 -0400, Paul Burba <ptburba_at_gmail.com> wrote:
>>> On Tue, Mar 24, 2009 at 4:26 PM, C. Michael Pilato
> <cmpilato_at_collab.net> wrote:
>>>> 2b. Â Subversion can record the merge on every present sibling of
> /trunk/testdata -- /trunk/src and /trunk/doc, in this case.
>>>
>>> As others have pointed out, this happens currently when you specify
> "--depth=infinity".
>>> Â Just having this as the default behavior would already be much better.
>
> Hi Paul,
>
>> Everyone on this thread seems to agree that is a better option. I'll
>> look into it a bit more to make sure there isn't some problem lurking
>> in the details and then propose this change in a separate thread.
>
> Thanks, much appreciated!
>
>>> However, this leads to another, unrelated problem: merges into sparse
>>> working copies invariably produce subtree mergeinfo,
>> Yes, this is intentional, we need some way to record that the merge
>> was never performed for the "missing" portions of the working copy,
>> i.e. the shallow subtrees. This is explained in painful detail in
>> http://www.collab.net/community/subversion/articles/merge-info.html in
>> the "Mergeinfo Inheritance and Non-Inheritable Ranges" section.
>
> Thanks for the pointer, this will be great stuff to read during my winter
> vacation next week :)
Oh no, don't ruin your vacation!
>>> which makes it hard to reason about the performed merges and can cause
> problems
>>> with "merge --reintegrate".
>> Problems? I can't see how it would *ever* work. Reintegrate was
>> never intended to support the use case where you had a shallow branch
>> working copy. Keep in mind that --reintegrate is simply a shortcut
>> for a 2-URL merge along with some safety checks
>
> Ok, good to hear this spelled out. In our scenario sparse (or switched)
> working copies are typical, as the repository contains huge subtrees that do
> not interest everyone.
>
>>> I find myself manually fixing svn:mergeinfo after such merges, which is
>>> a bit tedious.
>> By fix you mean delete? If so and it works for you great, but there
>> are very simple use cases where doing this will revert changes on your
>> trunk when reintegrating (hence the safety checks I mentioned before).
>
> 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).
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?
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1420387
Received on 2009-03-25 22:33:01 CET