Stefan wrote:
>>> If I merge r15744-15745 from
>>> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk to my (sparse)
working
>>> 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
with.
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.
http://svn.haxx.se/dev/archive-2009-03/0702.shtml
on the SVN dev list. For the CLI, the workaround is to use explicit
"--depth=infinity".
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.
BR,
Kari
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1404044
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-03-24 18:14:02 CET