On Fri, Apr 18, 2008 at 5:11 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Rui, Guo wrote:
>
> >
> > On Thu, Apr 17, 2008 at 02:18:34PM -0400, C. Michael Pilato wrote:
> >
> >
> > > Perhaps there's a middle ground to consider seeking: Adding NEWTREE at
> depth (FOO - (depth from TARGET to FOO). Yes, in the case of 'svn add
> --depth=FOO NEWTREE', that's depth=FOO. But what about 'svn add --force
> --depth=immediates parent=of-NEWTREE' ? Seems in that case you want NEWTREE
> added at depth empty, since that's what left of a depth-immediates additive
> crawl of its parent directory (the actual target of the operation).
> > >
> > Perhaps I didn't correctly get your idea in my previous reply. However, my
> > reply seems still apply. :-)
> >
> > Instead of your example:
> > svn add --force --depth=immediates parent=of-NEWTREE
> >
> > I tried this instead...
> > svn add --depth=immediates --parents NEWTREE
> > In this situation, the depth of intermediate parents is not explicitly
> > defined, while the depth of the target should be set to immediates.
> However,
> > the depth of the intermediate parents can be set to depth-empty according
> to
> > the current behavior.
> >
> > As of your example, I just agree with your expectation. That is
> reasonable.
> >
>
> If I'm understanding all this correctly, I think what you've said makes
> sense. Consistency demands that --depth continue to act (as it does with
> all other commands) as an operational filter applied to the operation
> target(s) -- not applied individually to operationally interesting children
> of those targets. The distinction there is meaningful.
>
> In my example, the target of the operation is one directory level above
> NEWTREE, which means NEWTREE is permitted one fewer depth level during the
> operation. In your example, NEWTREE is the target of the operation, so it
> is permitted the entirety of the specified depth level.
Well, let's also think one step forward.
So we do "svn add --depth=immediates" or something. And either it
leaves us with a shallow tree whose depth is immediates with empty
children, or infinite with infinite children (and no grandchildren).
Whatever.
Let's say that the case that the code chose was wrong for our
particular use case. I assert that this will be the case for some
people no matter what we choose.
How do they fix this?
Well, hmm. The only thing we have now that sets depth is "update".
But running update on schedule-add files seems kind of crazy. Hmm.
--dave
(PS: This kind of makes me think that integrating set-depth into the
update logic in the first place is somewhat flawed. If I was to go
back and redesign the integration of depth in the reporter now (ha,
not a real proposal), perhaps the right way to do it would be to have
a reporter run that describes the current depth of the working copy,
and then a second reporter run that describes the "requested depth" of
the whole working copy, rather than a single operative depth. Ah
well.)
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-04-18 21:23:26 CEST