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

Re: the obliterate discussion - why dumpfiltering is no valid workaround

From: timotheus <timotheus_at_tstotts.net>
Date: 2007-07-23 22:07:01 CEST

Will Appleton wrote:
> We have the same situation here. We have lots of folks using SVN and TSVN
> that don't know anything at all about VCS's (same types you mentioned).
> We've already had a few instances of mistakes and things being added to the
> repo's that shouldn't be added, but nothing that required a D & L.
> The process of educating users is going well, and I expect that in a few
> weeks most of the goofy commits will begin to approach zero. :)
> On the other hand, I'd like to see the obliterate feature added to
> svnadmin. It would be nice insurance to have.
> -=W=-

Similar here, except the users are primarily a team of electrical
engineers. `obliterate' via `svnadmin' would be very useful insurance
indeed -- espcially for the rare case where someone commits a CD .ISO
image or huge ZIP file to the repository :-). Availability of this
command via `svn' sounds like a bad idea.

Toby Thain wrote:
> But seriously. The *first time* you see junk in the repo, you start
> educating your users. If they're not educable, perhaps they're not competent
> to be doing what they're apparently doing.

Also, when I used to admin Perforce for a world-wide engineering team
years back, I would need this functionality approximately once every few
months. Educating the multi-lingual, multi-cultural, in 3 countries,
team was an ongoing process that was easier said than done. And since
when is it the computer support guy that gets to descide to hire only
competent staff? That is *not* a real-world situtation, and just wishful
thinking, IMHO.

Just my 2c,

  • application/pgp-signature attachment: stored
Received on Mon Jul 23 22:06:40 2007

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.