[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature request - SVN command to clean a working copy of all unversioned and ignored files and directories

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sun, 11 Mar 2012 18:28:18 -0400

On Sun, Mar 11, 2012 at 2:41 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:

> On Sun, Mar 11, 2012 at 1:10 PM, Andreas Krey <a.krey_at_gmx.de> wrote:
> > ...
> >> That seems wrong or at least unnecessarily inconvenient for a CI
> >> setup.
> >
> > You're a bit hung up on the 'CI' token. That isn't the only situation
> > where a 'svn cleanup' can be useful.
>
> Subversion probably isn't the best VCS to use if you can't arrange
> reasonable connectivity to the repository to make clean checkouts
> feasible.
>

Been there, done that, got my wrist slapped for questioning the mandated
standard, no matter what it was. In this sort of case. The lack of a
"restore this working copy to the pristine state" feature does not seem
fundamental to any particular Subversion approach, does it? The "CVS done
right" approach, the "centralized source control with cheap branching", or
any of the other features?

> >> And if you are doing it by hand, why not just delete
> >> everything but your .svn directory and revert?
> >
> > Typical VCS operations should not only be possible but also easy.
> > (And even the 'everything but .svn' part is tricky.)
>
Easy to do, yeas, Easy to do *wrong*, even easier. The Subversion checkout
contains the information for a pristine restoration, and could even include
some options like recursive cleanups and "get the svn:externals, too!".

> With post-1.7 versions, it shouldn't be hard at all - at least on
> systems where filenames starting with '.' don't expand in wildcards.
>
Right: it can be written locally, and it can be written *wrong* in a lot of
ways locally.

> But, if I know I'm going to want to return to a particular
> working-copy state, I just copy the whole thing locally before making
> the changes I may want to discard.

This is a pretty expensive operation in a bulky source tree, when the
component checking and consistency matching is already built into tools
like "svn status".

> I'd be more likely to do that to
> preserve a set of local changes that I wasn't sure about committing or
> to hold a checkpoint offline like you might in a distributed VCS, but
> it should work as well to have an 'already reverted' copy sitting
> locally when bandwidth is a concern.

Which is workable, but expensive in developer time and effort.

> This isn't particularly optimal
> with subversion either since you end up with two full copies of
> everything in each instance of the working copies, but at least it
> gives you a choice of disk or network resources.
>

4 copies. Never forget the pristine copies in .svn/.
Received on 2012-03-11 23:28:53 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.