I like the fact that all hooks are executed on a the server and not the
client -- dispite the limitations. I've been a ClearCase admin where trigger
scripts (what ClearCase calls hooks) are executed on the local clients. You
have to design your scripts keeping in mind that you might be using various
verisons of Perl, and each verison might have different versions of Perl
modules loaded on them.
You also have different shells, different versions of the same shell, and a
wide variety of operating systems, and then you have the Window machines.
Triggers were a big headache because they ran on the client. True, it
allowed for the trigger to easily converse with the client and request such
things as defect numbers, or to automatically attach properties to files,
but all of the headaches you have with making sure that your triggers work
with a wide variety of clients over rode any advantage. Plus, you always had
some smarty attempting to get around your triggers by writing their own
trigger scripts.
-----Original Message-----
From: Tim Hill [mailto:tim@realmsys.com]
Sent: Friday, April 22, 2005 2:03 PM
To: Weintraub, David
Cc: 'Ben Collins-Sussman'; Michael L Brown; Subversion mailing list
Subject: Re: Auto-prop not working?
Many many years ago (I'm dating myself) I worked on an SCC system (can't
recall the name) that got around this quite well. Basically (to translate a
little) it had the ability to execute server hook scripts on the *client*.
This is, an admin could author a hook script, place it on the server, and
then all clients would automatically upload and run that hook script at the
specified event. Now, this model is obviously one that could be abused, and
has issues with cross-platform clients, but I liked the model because (a) it
scaled well (server overhead was lower) and (b) a lot of smarts could be
injected that were based around individual best practices for the particular
group.
Just a thought (wish?)...
--Tim
Weintraub, David wrote:
From: Ben Collins-Sussman
> On Apr 22, 2005, at 11:11 AM, Weintraub, David wrote:
>
>> Actually, even if you specify all possible text file patterns, you
>> still have a problem. What if a user does their work on a system where
>> you didn't setup the autoproperty for them?
>>
>> This points to several missing features with Subversion:
>>
>> 1). No server side configuration. You have to basically set up this
>> configuration on all client machines. What if the user overrides this
>> configuration? What if the user decides to do work from home on his
>> personal computer where you did not setup this client configuration?
>> What happens when a machine gets replaced?
>
> This is planned for 1.3. It's a hot item.
Yea!
>> 2). Limited power of the svnserve and svnlook commands. Hooks can be
>> used to enforce policy, so maybe you'll program a post-commit hook
>> that examines a file that gets committed, and automatically sets the
>> svn:keyword property if it isn't already set. Oops, the propset and
>> propget commands don't work without first creating a working directory
>> and checking out that file in that working directory. A hook doesn't
>> work.
>>
>
> You've got it backwards. You should be using a *pre*-commit hook to
> reject any commit which doesn't have properties set correctly. It can
> send a nice message back to the use explaining why the commit was
> rejected.
Yes, I can reject the commmit, but it makes me feel like I'm working for the
DMV. Instead of simply being able to reject, I'd like fix the problem.
After all, I'm so close... After rejecting the commit, I can send the
developer the actual command to use and tell them to cut and paste it into
their command line. I just can't run the command myself.
Received on Fri Apr 22 20:42:38 2005