Deferring issue #2843 (subdir exclusion interface).

Issue #2843 is about fact that there's no way to get rid of stuff
after you've pulled it into a (maybe mixed-depth) working copy.

For example:

   $ svn co --depth=empty greek-tree
   $ cd greek-tree
   $ svn up A
   [...pulls in all of A/, recursively...]
   $ vi A/D/gamma
   $ vi A/D/G/tau
   $ vi A/D/H/omega
   $ svn commit -m "Okay, done with A/ now."
   $ svn how-do-I-get-rid-of-subdir-A-now-that-I'm-done-with-it?
   
It seems reasonable that one might want to get rid of a subdir, or at
least "fold it up" to be empty, after one were done working with it.
Either behavior would probably require a new subcommand, though. We
can't just make 'svn update --depth=empty SUBDIR' fold up SUBDIR, for
example, because 'svn update --depth=empty' already means "update the
things you can reach with depth=empty, and touch nothing else".

But I'm loathe to add a new subcommand for a feature we're not
positive people will really need, and for which we have no real-world
experience. So I think we should defer issue #2843 until 1.6. That
will give the sparse-directories feature some time in the wild, and
then we can see if a new subcommand is really needed -- or if nothing
is needed, or if clever workarounds are available, or if someone
thinks up another solution entirely.

Thoughts?

Below is an IRC conversation with Mark Phippard and Erik Hülsmann on
this topic (they pretty much agreed). By the way, if anyone's
wondering why I spend so much time formatting IRC transcripts to be
readable: I don't. Search for the function "kf-irc-prettify" in
http://svn.red-bean.com/repos/kfogel/trunk/.emacs, and feel free to
swipe it if you want.

-------------------------------------------------------------------------
<kfogel> call for opinions: I'm looking at issue #2843, which is
            about the fact that there's no way to get rid of stuff
            after you've pulled it into a mixed-depth working copy.
            For example: 'svn co --depth=empty greek-tree; cd
            greek-tree; svn up A; ## prev command gets you the whole
            A/ tree, but you still don't have iota ##; ## Now, what if
            you're done with A/ and you want to get rid of it? ##

<kfogel> I think that this would not be a good interface for
            getting rid of A/ :

<kfogel> svn up --depth=empty A

<kfogel> even as a way to just "fold up" the subtree and have an
            empty subdir, it's not right, because it should just
            update files reachable by depth=empty and not touch
            anything else.

<kfogel> So overloading 'update --depth=' is out, IMHO.

<markphip> kfogel: I assume you are thinking of a new subcommand?

<kfogel> Our other idea was an 'svn exclude' command or something.

<kfogel> But here's what I'm thinking:

<kfogel> never mind, scratch that thought.

<kfogel> I'm not thinking anything.

<kfogel> I'm asking.

<kfogel> Is this worth a new subcommand?

<markphip> svn rmlocal A

<kfogel> markphip: I don't see any other way to do it.

<markphip> exclude might be cleaner

<kfogel> We could overload 'rm', with a --keep-remote flag (hah!)

<kfogel> 'svn toss A'

<markphip> svn rm --local

<ehu> we currently don't have a logical place to store that
            functionality.

<kfogel> right

<ehu> if you don't make it a separate subcommand, won't that be
            another --relocate problem?

<kfogel> ehu: right

<ehu> it's a new concept.

<ehu> concepts have their own commands.

<kfogel> But I hate adding subcommands prematurely. I'm tempted to
            release 1.5 without any way to do this, and see what kind
            of requests we get. That might be bad for the 1.5->1.6
            stretch, but better for the 1.6->infinite-future stretch
            -- the long term.

* markphip agrees. I think it is just a matter of coming up with the
            sub-command to use

* markphip would be in favor of that idea

<ehu> which one? just wait and see?

<markphip> yes

<kfogel> markphip: I think I'll just post that off to dev@ and link
            to the thread from the issue, then.

<ehu> right. epg has already said 1.6 should be 'soonish' after
            1.5.

<ehu> I'd love that.

<ehu> and it gives us an opportunity to add this.

<kfogel> me too

<kfogel> okay, writing mail

<markphip> Some of these features, even though there is a lot of logic
           to them, it might make sense to let some real world usage
           unfold first

<markphip> meaning, it might make sense to just wait and see what the
           demand is

<kfogel> markphip: That's exactly my feeling. We're going farther
           out on a limb than we ever have before with 1.5, in terms
           of releasing features that don't have much real-world usage
           behind them. No need to extend that limb even farther.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 6 23:38:20 2007