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

svn_depth_exclude (Re: svn commit: r27958 - in trunk/subversion: include libsvn_subr)

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-21 18:37:23 CET

On Nov 20, 2007 9:03 PM, David Glasser <glasser@davidglasser.net> wrote:
> On Nov 20, 2007 8:48 PM, <glasser@tigris.org> wrote:
> > Author: glasser
> > Date: Tue Nov 20 17:48:42 2007
> > New Revision: 27958
> >
> > Log:
> > Remove svn_depth_exclude from the API. It was an implementation
> > detail of some of the modules which processed depth, not a
> > semantically meaningful depth itself.
> >
> > Arguably, it *would* be useful to have a concept of svn_depth_exclude,
> > so that you could do things like "check all of A except for A/D".
> > However, we did not implement that (at least, we didn't document it if
> > we did, though it may have worked by accident). Perhaps we'll add
> > this back later, completely supported.
> To expand on this:
> I think it *would* be useful, eventually, to have an
> "svn_depth_exclude" level. This would let you do the sort of thing
> Perforce client specs support where you check out an entire directory
> except for a few subdirectories; we only support the opposite right
> now.
> However, even though we had an svn_depth_exclude value, we weren't
> *really* supporting it. It was mostly just being used as an in-memory
> filter in various WC functions (like the booleans I added in the last
> couple of revisions now do); though the code existed to write
> "excluded" values to wc entries files, parse it from --depth flags,
> etc, nothing actually expected that to happen. And svn_depth_exclude
> was never recognized on the repository side (ie,
> svn_repos_dir_deltas).
> Given time constraints, full support of svn_depth_exclude should
> probably wait until 1.6.

I've thought a little more about that. There are two main places
where an "svn_depth_exclude" value needs to be dealt with: in the
working copy, and in the repository reporter. The former opens up a
huge can of design worms, including the fact that we have no UI for
depth downgrade yet. (However, given the ability to do any
downgrading at all, supporting it for svn_depth_exclude should be
straightforward.) The latter ought to be a whole lot simpler.

My current thought is to bring back svn_depth_exclude but support it
*only* for calls to set_path (and friends) in the ra/repos reporters;
I'll test that it works in a C unit test in repos-tests.c. The
expectation would be that the 1.5 client wouldn't ever use this
(because we don't have the right UI to get svn_depth_exclude values
into wc depth fields), but that no heroic client/server compatibility
work would be needed when it is supported in the wc.

(The implicit assumption here is that we do understand now what a wc
with some depth=exclude values would *look* like on disk; the tough
part is just designing the right UI and implementing the
transformations to get it to the right place. And I think we do.)


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 18:37:39 2007

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.