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

[Talden <ta...@gmail.com>]

On Sat, Mar 1, 2008 at 12:17 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "Mark Phippard" <ma...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Gavin 'Beau' Baumanis <ga...@thespidernet.com>]

Talden wrote:
> On Sat, Mar 1, 2008 at 12:17 PM, Karl Fogel <kf...@red-bean.com> wrote:
>   
>> "Mark Phippard" <ma...@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).
>>     
>
> I'm interesting in what Gavin comes up with as long as it doesn't
> become another monster feature with big delays.
>
> --
> Talden
>
>   

You and me both!

I would certainly like to see some path whereby development might occur 
incrementally.
And I am currently going through some of the outstanding issues/ /bugs, 
in the hope that I might be able to offer something along the lines of;
By completing work for issue #xxxx - we enable "this" which would be 
useful / a requirement for obliterate.

It is some pretty "dry" reading - especially to someone with no SVN 
development know-how or history, though I am progressing...


Beau.

-- 
Gavin 'Beau 'Baumanis
Principal
The Spidernet Web Design

W: http://www.thespidernet.com
E: gavinb@thespidernet.com
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)

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

[Lieven Govaerts <sv...@mobsol.be>]

Karl Fogel wrote:
> Talden <ta...@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.

Lieven

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Karl Fogel <kf...@red-bean.com>]

Talden <ta...@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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org