Obliterate - client-side authorization [was: Obliterate - call graph, esp. repos and FS layers]

[Julian Foad <ju...@btopenworld.com>]

Re. client-side obliterate.

Mark Phippard wrote:
> Was there a specific use-case or reason that has caused this to be
> pushed down to the client layers?  I thought we were planning for
> obliterate to be an svnadmin function that required physical access to
> the repository.

Certainly there is real-world reason to want it available client side.
Imagine our source code being hosted in the big Apache repository, and
us asking their admins once a year or so to obliterate some huge mistake
that we've accidentally committed. We rarely make really huge commit
mistakes so the admins would probably tolerate us. Now imagine a similar
shared repository with lots of projects with diverse and non-VC-aware
users, and imagine there are frequent mistakes in which a user commits a
copy of their hard drive root or something. In such a repository it is
not really scaleable for the central admins to attend to such requests,
and it should be delegated to per-project admins.

But note that I'm approaching it this way in order to develop a good and
extensible design, and am not necessarily going to release it initially
with a client-side interface (even at the network API level). That's
still under consideration. I realized that if I designed it initially
without consideration for on-line operation and without using the normal
API layers, the work would not be re-usable when we want to extend it to
client-side operation in the future.
 
>  If we are planning to allow any client to obliterate
> revisions, what sort of access control are we planning?  Just
> something with hook scripts, similar to how we treat revision property
> changes?

and Ivan Zhakov wrote:
> It's slightly off-topic, but I'd like to see obliterate functionality
> as administrative task only. I.e. "svnadmin obliterate". Currently
> even authorization is disabled administrators are sure that nobody can
> remove anything from repository. But if you'll add "svn obliterate"
> many administrators will be forced to enable authorization and check
> they permissions. Another note that you will end with special
> permission for obliterating files, which is add unnecessary
> complexity.

If we do make a client-side "svn obliterate" command, we will have a
server-side configuration option to enable it, that will be OFF by
default. If the administrator does not enable it, it will not be
possible for any client (even a specially modified client) to do
obliteration. So we won't force administrators to enable authorization
if they don't want this.

If we do make a client-side "svn obliterate" command, we will need an
appropriate form of authentication for it. This could be as simple as
assigning the permission to certain user names, or much more complex. It
could be built-in or done by a pre-obliterate hook. I have not started
to design this, and ideas are welcome.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404012

Re: Re: Obliterate - client-side authorization [was: Obliterate - call graph, esp. repos and FS layers]

[Stefan Sperling <st...@elego.de>]

On Mon, Oct 12, 2009 at 07:51:36AM -0700, Andy Bolstridge wrote:
> I can give you another reason to make the obliterate functionality part of the client system (even if its turned off or the command itself is not exposed), and that's implementing shelving functionality.
> 
> Once obliterate is with us, and it frees up disc space, SVN can get 'temporary commits' that are deleted once the temps are fully committed. The entire system could be implemented as switching to a special hidden path in the repo and committing. When a full commit occurs, the hidden commits can be obliterated in the background.
> 
> I don't know how the client commands would look, but it could be implemented entirely on the client if obliterate was a client-callable option.

Developer talk on IRC indicates that shelving a.k.a. offline commits
(as well as local working copy cloning) is planned to be added to WC-NG
as a pure client-side feature at some point in the future (i.e. not 1.7).

Stefan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2406703

RE: Re: Obliterate - client-side authorization [was: Obliterate - call graph, esp. repos and FS layers]

[Andy Bolstridge <an...@bolstridge.plus.com>]

I can give you another reason to make the obliterate functionality part of the client system (even if its turned off or the command itself is not exposed), and that's implementing shelving functionality.

Once obliterate is with us, and it frees up disc space, SVN can get 'temporary commits' that are deleted once the temps are fully committed. The entire system could be implemented as switching to a special hidden path in the repo and committing. When a full commit occurs, the hidden commits can be obliterated in the background.

I don't know how the client commands would look, but it could be implemented entirely on the client if obliterate was a client-callable option.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2406696

Re: Obliterate - client-side authorization [was: Obliterate - call graph, esp. repos and FS layers]

[Branko Cibej <br...@xbc.nu>]

Julian Foad wrote:
> If we do make a client-side "svn obliterate" command, we will need an
> appropriate form of authentication for it. This could be as simple as
> assigning the permission to certain user names, ...

You mean, "authorization." :)

But yes, I agree with what you say about client-side obliteration.

I'd also mention the not so far-fetched use case where a project is
using a public Subversion hosting service. I bet if we had server-side
obliterate only, such services would quickly build a Web interface to it.

-- Brane

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404029