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

Re: svn.collab.net is now running 1.5.0-alpha2

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Sat, 01 Mar 2008 16:33:51 +0100

Karl Fogel wrote:
> Talden <talden_at_gmail.com> writes:
>> #71 suggests I have hand-waved away complex issues. It seems my point
>> has been missed. Obliterate is achieved today with dump/filter/load.
>> It's too slow and resource intensive and filtering isn't as expressive
>> as is desirable. That's where we are at now. Right now. After 7 years
>> of requests.
>> Provide a tool that edits revisions instead of dumping and reloading
>> everything that has at least the filtering expressiveness of
>> dumpfilter and all the same semantics (re: dealing with copies) as a
>> dump/filter/reload and you have a first iteration that substantially
>> reduce the pain for many admins in short-order.
> Ah, okay, I hadn't understood that point, thanks. So you meant: a
> tool that has the same effect as what we now recommend people do with
> dump/filter/reload, but without the "dump" and "reload" stages.
> It would be a start, at least.

[This is getting more and more off topic I'm afraid]

My personal goal for 1.6 (besides improving ra_serf) is to replace
svndumpfilter with something that actually works.

Basically the idea is to:
- read a repository, by loading it from local disc, syncing it or
loading a dump file.
- execute a set of filters on each revision (note not all filters will
work when the source is a dump file).
- write the repository again

While this is not obliterate, for me it would be sufficiently efficient
and handles the 'split repository in a repo per project' feature I need
regularly. I also think this can be stepping stone to continue
implementing obliterate, as the filters can be reused anyway.

In a month or so, I'll send a proposal to the list on how I plan to
write this. I don't think this impacts the obliterate design work at
all, on the contrary, I hope it'll define the necessary filters.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-01 16:33:36 CET

This is an archived mail posted to the Subversion Dev mailing list.