On Sun, Mar 11, 2012 at 9:19 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Sun, Mar 11, 2012 at 5:28 PM, Nico Kadel-Garcia <nkadel_at_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/ .
Received on 2012-03-12 06:02:54 CET