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