On 28 Jul 2021, Nathan Hartman wrote:
Regarding #525, in addition to points discussed previously (i.e.,
that
SVN is strong at large repos and blobs than alternatives, and
#525
would make SVN even stronger in this area), it would improve the
experience for two additional types of users:
* those whose repositories are on the same machine; in this case
it's
definitely more sensible to grab a file directly from the
repository
than to keep an extra copy, which may never be used, in the wc.
* those (like me) who put their working copies on ramdisks, to
speed
up in-tree builds while reducing flash wear caused by useless
build
artifacts. Obviously in a typical system, RAM is more scarce than
non-volatile and freeing up a good chunk of it by not storing
pristines might improve the computer's overall performance enough
to
justify having to re-download files when needed (and if the
repository
is local, so much more so).
Both good points, yes.
(Several of the potential funders for #525, including my company, are
having a backchannel conversation about this right now. If it bears
fruit, we'll be posting here of course.)
More below...
2) Add a new '--depth=directories' depth type to make it easy
to
check out a sparse tree, that is, a skeleton directory tree
without the files. Then, within a given directory, you can do
'svn update --depth=files' or check out a particular file by
name
as needed. There's no ticket associated with this feature, as
far
as I know, but I can file one after this post if people think
this
idea is worthwhile.
Regarding point 2, '--depth=directories', this sounds like a
feature
that I would probably start using right away. I routinely work
with a
large project consisting of nearly 100k files in many
directories, so
I check it out with '--depth=immediates' and I have scripts that
expand several parts I need often; for other areas I expand
directories manually. Being able to checkout the entire skeleton
tree
as you described would save quite a few commands whenever I need
to
expand some deeply nested directory.
When writing the previous paragraph, I realized this would
encounter
the following issue:
Suppose you have a skeleton checked out with
'--depth=directories' and
it contains a path a/b/c/d/e/f/g; each of a, b, c, etc., may
contain
other subdirectories.
If you run 'svn up --set-depth=files' on a/b/c, as it works
currently
d/e/f/g will be deleted. (Unless they contain modifications.) So
there
has to be a way to make some depth elements sticky, or,
alternatively,
there has to be a way to do depth arithmetic, e.g.:
'svn up --set-depth+=files'
Ah, I didn't realize that --depth=files would prune directories
already checked out. Either we'd have to change that default
behavior, or add a new depth type... Or maybe the answer is just
that '--depth=directories' automatically makes those directories
sticky, so that other shallower depths don't prune them.
The following might be a separate feature request but it might be
cool
if 'svn update --set-depth=...' could support the '--parents'
argument, at least when setting depth=files. Rationale: a user
might
want to bring in all the files in g (in a/b/c/d/e/f/g) and all of
g's
ancestors, but not g's siblings nor those of its ancestors. (This
use
case comes up often in a project I work on; don't know whether
anyone
else has a need for this use case.)
Food for thought...
Yup. I'm inclined to start with the simple case (sparse tree of
all directories and only directories), and discuss other fancier
things as separate features later. This one would be a good one
to discuss, though. It might be that the '--parents' behavior
could be implied in most cases anyway, and thus wouldn't need an
explicit '--parents' flag.
Best regards,
-Karl
