On 2008-06-04 11:00:14 +0200, Marc Haisenko wrote:
> The client hook would of course allow to implement something like
> that, but that issue has also been discussed already, as far as I
> remember, and I think the developers thought it might not be a good
> idea (but please search the archive yourself, I'm not entirely
> sure). You care about just yourself, and seem to assume that you
> will be the only user of that specific repository.
But this would be one of the goal of client-side hooks: each user
does whatever he wants with them. The user could also check that
updated XML files are well-formed/valid if he wants to, update
other files (not managed by Subversion) if some file is modified
(e.g. to update an index), and so on.
Also, as I've said, such a feature would be useful mainly for users
who manage their own files with Subversion; so yes, in these cases,
the user cares about himself and is the only user of the repository.
Not all repositories have to use client-side hooks after all!
Note that concerning user-side (client-side) configuration, this
is already the case of umask: Subversion doesn't enforce an umask
value specified at the repository level, so that different users
can already end up with different permissions. I don't see such a
feature very different to what client-side hooks could provide.
> The SubVersion developers have to think a bit bigger and then issues
> that are none to you become huge. One issue would be: Where would
> those hooks be stored ?
In the ~/.subversion directory, for instance.
> If every user has to install the hook himself
Yes, every user *must* install the hook himself.
> then inconsistencies can occur (e.g. not every user has that hook,
> maybe they have different versions, etc. pp.).
Client-side hooks should be optional. So, fatal inconsistencies
would be an error from the users.
> If the hooks are stored in the repository you have a huge security
> desaster
Of course. That's why the user must install hooks himself. The hook
can also contain code to update itself (e.g. if a copy is stored in
the repository); of course, in such a case, there would be security
implications if the repository is shared by several users (i.e. it
is not a repository for the user's own files), but there are also
security implications by typing "make" in a development project
managed by Subversion (or any other VCS).
BTW, about the security, a client-side hook could also do some
checks on the files that have been updated, e.g. the presence of
a virus or suspicious code. Such a feature isn't that bad, is it?
> So if all you need that feature for is archiving some stuff (like
> you /etc directory) you are better off using an external script like
> the "asvn" script already present,
You didn't take into account the problems I mentioned about asvn:
* it is inefficient because it doesn't know which files have been
updated;
* it doesn't fix the permissions in real time (this point is less
important).
IMHO, these two problems can only be solved cleanly with client-side
hooks or something similar, i.e. with some feedback given by svn.
Well, if someone knows how to parse its output without any drawback
(there are often problems with signals[1] and/or buffering[2]), then
I think this could be a solution too (though I'd prefer client-side
hooks).
[1] This one, for instance:
http://subversion.tigris.org/issues/show_bug.cgi?id=3014
[2] Well, it seems that buffering should not be a problem since 1.4.0
as I can see
* flush stdout after each status/notification line (r19476 -656)
in the CHANGES file. But it is listed under "Developer-visible changes".
So, I wonder...
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-04 15:24:05 CEST