On Sun, Mar 11, 2012 at 9:19 PM, Les Mikesell <lesmikes...@gmail.com> wrote:
> On Sun, Mar 11, 2012 at 5:28 PM, Nico Kadel-Garcia <nka...@gmail.com> > wrote: > > > >> 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. > > Mandating the use of a tool should go hand in hand with providing the > necessary resources. And with subversion, one of those resources is > reasonable network connectivity to the one-and-only repository (or the > harder task of replicated repositories)... > You'd think so, but there's a far, far distance between "necessary resources" and "optimal performance". In terms of available bandwidth. There are several thousands of projects under Subversoin at Sourceforge that will *never* have that kind of bandwidth available from that central repository, no matter what your internal network looks like. > > 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? > > Not deleting random unrelated files could be considered a feature. > Nothing random about them, They're in the Subversion working copy, and someone specifically asked to restore that copy to a pristine state. I wouldn't suggest going down symlinks to other parts fo the operating system! > > Right: it can be written locally, and it can be written *wrong* in a lot > of > > ways locally. > > Yes, but imagine the ways a command that removes files not under > version control could go wrong. > Well, yes. But so can the "rm" command. I'm suggesting that having a *clean* implementation in Subversion itself is much safer than having the script kiddies write their own. Heck, it would eliminate a lot of my pain in writing "make clean" functions for any Subversion projects. I ran into just this situation with Nagios and BIND configurations: clearing away the debris had to be hand written.. > An option to 'status' that only shows the unversioned filenames so you > don't have to parse them out of the larger list if you want to remove > them might be nice. Doing it blindly seems a little heavy-handed. > I'm afraid of the extra processing. I've seen too many "one-off" scripts that ignored basic sanitation of the targeted file names. The obligatory XKCD quote for this problem is http://xkcd.com/327/ .
