On 6/23/06, Michael Sinz <Michael.Sinz@sinz.org> wrote:
> On 6/23/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 6/23/06, Eric Gillespie <epg@pretzelnet.org> wrote:
> > > "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> > >
> > > > One thing I don't see here is a way to remove existing files or
> > > > directories. If I have a depth 0 checkout (i.e. an empty directory) I
> > > > can pull in extra subdirectories via 'svn up', but how can I get rid
> > > > of them if they're already there?
> > >
> > > I covered this with the 'svn up --depth 0 Awc/D' example. But,
> > > now that i think about it, this might not be enough.
> > >
> > > If you have a depth 0 working copy foo containing a file bar you
> > > want to get rid of, then 'svn up --depth 0 bar' works naturally.
> > > But what if foo is depth 1? It would just bring bar back on the
> > > next update. I guess setting a file's depth to 0 means setting
> > > its parent's depth to 0, but this may be unexpected.
> >
> > Yeah, it really seems like what we want is a way to mark a particular
> > entry as unwanted, so that it'll never get updated, even if the
> > parent's depth is not 0.
>
>
> Do we? Is it a good thing for a depth-1 (or depth-inf) directory
> in the WC to be able to have some parts of it not come back
> on an update? To me this sounds like major trouble.
>
> For example, what happens if I as that file "foo.c" be gone.
> Then, at some point that file is actually deleted from the
> repository. After some time (maybe months later) a new and
> important file is created as "foo.c" Does that new file show up
> or is it still blocked? A new file called "bar.c" would show up
> since I never marked it "gone"
>
> To me it seems that it would be much clearer in the general
> case that if a file (directory) wishes to be gone, its container
> must now be depth-0 otherwise the behavior is inconsistent
> and somewhat surprising.
I'm not sure... This will require some thought...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 23 20:36:49 2006