I personally do most of my cherry-picking merges with a tool that uses
a sparse copy, because I'm on 32-bit machines and a non-sparse merge
in the directory I care about (1455 files in 47 directories, 850 of
which are at top level) needs more than 3G of RAM. But I'm not sure
anyone else has that problem :-)
As for reasoning about subtree mergeinfo - I generally don't care
about a revision that didn't actually touch a file, so it doesn't make
a difference to me (or to the helper tools I write to do larger
merges.)
On Thu, Mar 19, 2009 at 4:27 PM, Kari Granö <kari.grano_at_gmail.com> wrote:
> Mark Eichin wrote:
>> You want to pass --depth=infinite to the merge itself, if it's like the
> case
>> I've seen before. Couldn't say if that's actually reasonable, but it
>> works...
>
> Thanks for the reply. You appear to be right, adding "--depth=infinity"
> makes the merge work. However, this looks like a surprising default to me.
> Contrast this with e.g. "svn update" behavior: there the working copy depth
> is respected in a deep manner. Not so with "svn merge": there the working
> copy depth appears to be shallow, taken from the target directory.
>
> Is there any reason for this asymmetry?
>
>>> (2) It seems that merging into a sparse working copy always creates
> subtree
>>> mergeinfo, which is not a good thing for reintegrate merges, and makes
>>> reasoning about performed merges hard. What is the recommended practice
>>> with merging and sparse checkouts? Should the merging only be done on
> fully
>>> infinite working copies?
>
> Do you have an opinion on this? If one wants to avoid subtree mergeinfo,
> the use of sparse checkouts seems impossible to me.
>
> Best regards,
> Kari.
>
>
--
_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1366037
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 18:28:38 CET