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
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
* it doesn't fix the permissions in real time (this point is less
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 and/or buffering), then
I think this could be a solution too (though I'd prefer client-side
 This one, for instance:
 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 <email@example.com> - 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