[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: Ruslan Sivak <rsivak_at_istandfor.com>
Date: 2007-07-23 19:01:08 CEST

Toby Thain wrote:
> On 23-Jul-07, at 10:37 AM, patrick wrote:
>> Toby Thain wrote:
>>>> i prefer having airbags in cars.
>>>> telling the people to drive carefully so no accidents will happen or
>>>> otherwise not drive at all just does not seem to be an adequate
>>>> solution :-]
>>> That makes no sense.
>>> Two things we know:
>>> 1. Mistakes happen.
>>> 2. Mistakes happen less with education.
>>> I don't see any analogy between 'obliterate' and airbags.
>> your first point was exactly what i was trying to say: mistakes happen.
>> educating the users normally helps, but accidents will still occur
>> always
>> and forever.
>> adding airbags to cars or adding obliterate functions to VCSs will
>> minimize
>> the damage when such an accident occurs. that was the analogy i was
>> trying
>> to point out.
> But oddly I haven't needed to dump and filter on any production
> repository I use - of course people make imperfect commits (just now
> somebody broke the compile) but I've never had to remove anything for
> legal reasons or reasons of propriety. I have become very curious
> about the original poster's environment, since it seems his frequency
> of stupid mistakes is high and cannot be reduced. This is alien to me.
In our environment, I was cleaning up old folders (projects that were
removed from the repository either because they were no longer going to
be worked on, or because they grew and needed their own repository). I
was trying to use svndumpfilter to remove them, but because they've been
branched so many times, i had to also exclude them from all the
branches, which became a very painfull process. I, too, see the need of
something where you can tell it what objects you want to delete, and
have it delete all references to those objects made in future revisions.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jul 23 19:00:18 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.