On Sun, Mar 11, 2012 at 2:41 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On Sun, Mar 11, 2012 at 1:10 PM, Andreas Krey <a.k...@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/.