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

Re: [PROPOSAL] Dealing with large directories/difficult to organize trees.

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-07-11 08:18:31 CEST

I'm opposed to adding new commands for non-recursive checkouts. They're
a rarely-used feature--a valuble one when needed, but not one which
warrants expanding the command set.

You can already do the equivalent of "svn include" with "svn update".
(Incidentally, that's done as a special case in svn_client_update which
could also benefit other commands. For instance, "svn cat foo@375"
doesn't work if foo doesn't exist in the wc, but it could if we used the
parent directory's URL to identify what foo is supposed to be.)

I really don't think there's a compelling need for "svn exclude". If
people think there's really a need for it, I would favor creating a more
general "svn release". I've seen people ask for this as an alternative
to "rm -rf" for removing a working copy; it could check for locks and
local mods before removing the wc. You could then use "svn release" to
remove part of a working copy to yield a partial checkout.

(I also thought about adding an option to "svn revert" like --remove.
In some odd way that makes sense to me, but I doubt it would be
intuitive to most users.)

As a side note, I think you could have cut down the size of that design
proposal by 30-50%, making it more accessible to developers to review.
I'm probably guilty of some overly long design proposals myself, though.

> Backend wise we'll need to extend the reporter to handle saying what
> you don't want.

As I mentioned on IRC, I think there may be ways to abuse link_path to
accomplish this. It's not the best option in the steady state, but as a
compatibility hack it's probably better than receiving and ignoring a
huge swath of updates.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 11 08:20:10 2005

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

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