On Sat, Mar 1, 2008 at 12:17 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "Mark Phippard" <markphip_at_gmail.com> writes:
> >> > He is making changes to properties as part of the merge process
> >> > (changing history). We do not have a mechanism for conveying this to
> >> > the working copy (one of the problems svn obliterate would also have
> >> > to solve).
>
> This isn't really related to this thread, and I don't expect (or need)
> a reply, but please note that we've pretty much agreed to punt on
> working-copy handling of obliterate. That is, it's okay to implement
> just the repository-side part, and let people re-check-out working
> copies or whatever.
>
> The reason I say this is that there has been so much FUD and
> misunderstanding about 'obliterate' on users@ and in the issue tracker
> that I want to prevent any further perpetuation of the myth that
> client-side issues are what's holding it up (for example, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=516#desc71 and the
> comments preceding it).
#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.
By all means talk about the future of the feature. Planning ahead
will undoubtedly influence the implementation and possibly avoid some
rework - but I do hope that, when Gavin 'Beau' Baumanis looks into
this feature, there is some emphasis on delivering this incrementally.
I can imagine that interesting enhancements might be:
- Adding regex filtering (a usability improvement)
- Adding '--follow-copies' (possibly useful for the 'security'
use-cases whereas the 'size' use-case is dealt with generally without
the copy following I expect)
- supporting a 'list-file' of patterns to filter with each optionally
following copies (usability and possibly atomicity of operation).
- Communicating these operations as new revisions to cause the same
operation on downstream clients (certainly the toughest part).
I'm interesting in what Gavin comes up with as long as it doesn't
become another monster feature with big delays.
--
Talden
---------------------------------------------------------------------
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 12:35:45 CET