Thanks, this url was the reason why I posted my "thoughts".
Definitely, the specification is the absolutely "must-to-be-done"
development requirement.
I just try to help on the "pre-specification" stage where, IMHO,
use-cases are important step.
Trying to conclude this long thread, here is my vision of the problem:
On the user side:
- The feature *is* required by many users, mainly because of the two reasons
- 1/ disk space usage (that includes the "raw" disk cots, size of
the repository, etc)
- 2/ security
- In both cases, it is talken about user-mistake and not a regular workflow
- In both cases user interested to eliminate the content of the commited files
and do not care about directory structure.
On the dev. side:
- The feature requires review of the one of the base-concepts - no
changes in the past
- The feature requires changes on the low level of the core (immunable nodes?)
Implementation decisions to take:
- implement as the admin priviledge
-- pro: physically destruction of any data that belongs to another users *is*
administrator priviledge.
-- anti: user cannot fix the mistake immediately
- implement as the user priviledge
-- pro: (see "anti" above)
-- anti: (see "pro" above)
Hope, it could serve as a base for the speicification process.
Thanks,
Best Regards,
Moisei
> Please read over
> http://subversion.tigris.org/issues/show_bug.cgi?id=516
> to see the complexities of 'obliterate', and why we haven't gotten
> around to it yet. It's not impossible to implement, but some
> specification work is needed first.
> -Karl
>> Is not it much easier to implement "obliterate" in a way it
removes the content
>> of the file from the repository (for all the revisions) but does not remove
>> the record of this file?
>> Best Regards,
>> Moisei.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 15 09:45:17 2005