On Mon, Jul 11, 2005 at 02:18:31AM -0400, Greg Hudson wrote:
> 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.)
Hmm I don't think really a special case. I think that works becuase
checkout is implemented as update too. Are people already using this if
so then I guess we should leave it that way.
I'm generally under the impression that people don't use non-recurssive
checkouts becuase they don't work right. Given that I think we probably
should feel free to change the interface without worrying too much about
breaking anyone. If they're using it, it's already broken anyway.
> 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.)
Don't like revert at all. Revert undoes local mods. Doesn't make much
sense to add it there. Really we don't have an operation at all that
corresponds.
I do think we need some way to remove a dir. People are going to ask
for it. What if you typo an "include" and end up with the wrong dir.
People will either have to throw away their working copy and recheckout
or start mucking with the entries file.
One of our strengths is the ability to morph a working copy into what
you want without starting over. I think not having such a command would
weaken that ability if we finally fix non-recurssive checkouts.
I do think release would be fine. The extra work to make it a more
general "throw away this wc" command would be minimal.
I know there was some other people opposed to include/exclude that
haven't piped up yet. Would update/release satisfy those people? If so
I'm okay with that UI design.
> 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.
Yeah but we don't really have a way to know what the server supports.
The server will not error out if we just add the fields and it doesn't
support it. It'll simply return all the extra data.
I think that the link_path trick might be a nice fall back but I don't
see the way to properly identify when to fall back until you're already
receiving extra data. In some cases you'd be better off to cancel and
start over and in others not, but then we run into the issue with neon
about not wanting to bail on a connection. *sigh*
That and I'm not really convinced that link_path will do what we want.
I kinda looked at it but didn't generate a bogus request to see if it
would actually work. Given the above I'm not sure it's worth it.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 11 21:58:49 2005