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.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
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:26:45 2006