Agreed. On this ancient system such problems didn't exist (sign).
Weintraub, David wrote:
> 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 21:25:05 2005