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
Received on 2009-10-06 12:46:29 CEST