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 :)
>> 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?
Kari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1420011
Received on 2009-03-25 22:16:48 CET