Various people, ending in Eric Gillespie, wrote:
> > > 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 think i agree with Michael; depth 1 directories should always
> > have all their entries.
I also agree. While there is a use case there, it's fraught with
unclean edges and hard-to-explain consequences. Better for us to keep
it simple: if people want to pick and choose among entries, that's
what a depth-0 parent directory is for.
So, it looks like I'm going to have some time to work on this. I'll
start by checking the design doc into notes/. I'm talking about the
writeup posted by Eric Gillespie, here:
From: Eric Gillespie <firstname.lastname@example.org>
Subject: [PROPOSAL] Incomplete working copies (issue #695)
Date: Thu, 22 Jun 2006 22:35:06 -0700
...and will make a note in issue #695, of course.
I think the work can happen in trunk, but I'll create a branch if it
looks like it's going to be destabilizing.
Note that this proposal is similar to what Ben Reser came up with long
before (http://svn.haxx.se/dev/archive-2005-07/0398.shtml, and thanks
to Eric for digging up that URL). The main difference is that the new
proposal doesn't involve adding any new subcommands, and that the
depth flag gives us, I think, somewhat greater flexibility in where we
take this feature in the future. Nevertheless, Ben has done some of
the hard thinking already, especially about how to tweak the update
reporter, and that's going to help a lot.
Anyway, just a heads up that this will actually be happening. Looking
forward to the reviews!
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Jul 13 20:00:31 2006