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

Re: Merging with sparse checkouts

From: Kari Granö <kari.grano_at_gmail.com>
Date: Tue, 24 Mar 2009 19:12:53 +0200

Stefan wrote:

>>> If I merge r15744-15745 from
>>> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk to my (sparse)
>>> copy of of
>>> http://tortoisesvn.tigris.org/svn/tortoisesvn/branches/1.6.x@15743 using

>>> depth="working copy", I get
>>> (1) No text changes at all
>>> (2) Mergeinfo of /trunk gets added to all sparse subtrees of my WC
>> What "--depth" flag does the TSVN GUI value "working copy" correspond to?

> The "working copy" depth is actually a real svn depth - it just doesn't
> have a CLI 'name' but is used as the default depth in the CLI if no
> depth is specified manually.
> It should be 'expanded' to the depth the working copy was checked out

Right. It seems that when merging into sparse working copy, the default
depth for svn.exe is not that of working copy, but rather that of the
immediate target (that is, "immediate children"). Presumably this is the
same on the API level as well, seeing the TSVN behavior.

Other people are bumping into this as well, see e.g.


on the SVN dev list. For the CLI, the workaround is to use explicit

For a GUI client such as TSVN the issue is worse, as the GUI incorrectly
states that the merge depth is "working copy".

I'm not sure where this should be fixed. Probably the Subversion guys have
good reasons for the default, and therefore the GUI client should detect
whether the merge target is sparse and in that case remove the "working
copy" option from the merge dialog. Because that's how it is: for sparse
working copies, Subversion does not support it.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-24 18:14:02 CET

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

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