[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merging into sparse working copy fails

From: Mark Eichin <eichin_at_gmail.com>
Date: Fri, 20 Mar 2009 13:25:33 -0400

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

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>
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-20 18:28:38 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.