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

AW: Don't understand why checkout depth defaults to "working copy only"

From: Niemann, Hartmut <hartmut.niemann_at_siemens.com>
Date: Mon, 9 Jul 2012 15:56:15 +0200

> Right click on the root of your working copy, Update to Revision and
> set the depth there to Fully Recursive and Make Depth Sticky.
> The default in most commands may come up as Working Copy. That just
> means it will respect the depth that is already set, so once you have
> set Fully Recursive, then any updates you do will be exactly that.
> The reason the default is Working Copy and not Fully Recursive is so
> that people who have sparse working copies do not have to keep
> changing that value to avoid getting a fully recursive checkout. It
> keeps the last (sticky) setting you used, so it should work well for
> all use cases.

Is there a reason why there is no "sticky" checkbox for the
checkout command and the default behaviour is "not sticky"?

I did an initial checkout "immediate children" of a project
and then a "sticky" update of two (of several) subfolders "fully recursive".
When I updateted the root of this WC, it started pulling in all other
It looks like I have to do three steps:
* checkout "immediate children"
* update to revision (HEAD), "immediate children, sticky" (which does nothing but store the depth)
* update the interesting children to revision (HEAD) "fully recursive, sticky"
and the second of these steps is not really intuitive.

"Omit externals" is not sticky either. Why? I have a use case where
it makes sense to decide for every working copy whether the externals
are needed. (And the externals are huge ...)

Am I doing anything wrong here?

With best regards


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-07-09 15:56:26 CEST

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.