On 9/6/07, Karl Fogel <kfogel@red-bean.com> wrote:
> 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
>
>
I am pretty confident that I (and my coworkers) would find this
functionality useful, and will miss it if it is not there. We have
converted over a fairly large repository from CVS, that contains many
loosely related projects. The repository organization is largely the
same as before the migration, so we often run into situations where
developers need a root directory, but only some of the subdirectories.
Developers mostly work on a subset of these, but sometimes will need
to do work on modules that they would not normally have checked out.
Having to delete a working copy
and then do the multi-step sparse checkout process to get rid of those
seldom used directories is pretty ugly.
(Aside on repository organization: We are very limited in how we can
change the repo layout, as the version graphing of TKSVN is a 'must
have' feature for some developers. TKSVN does this graphing in a very
hacky (and slow) way, and this breaks if you move the tags and/or
branches directories. This greatly limits what repository
reorganizations we can do. If there are any other tools that do a
good job of generating revision graphs for individual files in SVN I
would love to hear about them, since last time I looked I was unable
to find any.)
Thanks,
Roy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 7 00:40:53 2007