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

recursive/nonrecursive

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-03 22:08:16 CEST

So I'm working on issue #493, started by pilchie long ago.

Here is a summary of how our client subcommands currently behave:

                Normal behavior: Option:

add nonrecursive --recursive
cleanup recursive
commit recursive --nonrecursive
copy recursive
delete recursive
diff recursive --nonrecursive
export recursive
import recursive --nonrecursive
log recursive
merge recursive --nonrecursive
mv recursive
propdel nonrecursive --recursive
propget nonrecursive --recursive
proplist nonrecursive --recursive
propset nonrecursive --recursive
revert nonrecursive --recursive
status recursive --nonrecursive
switch recursive --nonrecursive
update recursive --nonrecursive

And here is a list of TODO items that cmpilato and I think need to be
done, to close this issue:

info nonrecursive
resolve nonrecursive

    We should create --recursive options for these subcommands.

checkout recursive --nonrecursive

    Yes, you can check out a nonrecursive working copy... but does
    this feature acutally work as we want it to?

    - 'svn co -n URL' effectively creates a wc of the directory of
        depth 1... contains only immediate *file* children, and that's
        it...

    - Yes, you can commit changes to the file-children.

    - Updates don't work, assuming things changed below your wc.

    I'm worried about this feature, because it feels half-implemented
    to me. I mean, the entries file has *no* idea that its list of
    children is incomplete, or that it's in some 'nonrecursive' mode.
    Ideally, updates on areas below the top-level dir should be
    ignored by the update-editor, or something. Maybe a depth
    argument needs to be marshalled all the way over the network to
    dir_delta... not sure.

    Should we remove this feature? If not, how should we finish it?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 3 22:13:17 2002

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.