[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Client side hook scripts [Was: Proposal for $Revision$ keyword amendment, "global" revnums, etc...]

From: David Weintraub <david_at_WeintraubWorld.net>
Date: 2005-10-14 05:42:44 CEST

On 10/11/05, Miha Vitorovic wrote:
> I must say that, after following this discussion in its many
> incarnations, I
> have been finally shown the light. :-) I think that it would be
> much more
> useful for people to start pushing for/requesting client side hook
> scripts.
> That would open a much larger set of possibilities and would also
> provide an
> easy and cheap way of getting this infamous "global" revision number.
>
> Don't you agree?

I've been a ClearCase administrator for over a dozen years. ClearCase
uses client side hooks (which they call "triggers"). There are two
things you can do with client side scripts you cannot do with server
side scripts:

1). Talk to the client and ask for things like defect ID number.
2). Modify the files during the transaction. For example, expanding
the $RCS$ strings.

The first isn't all that useful and the second is really bad practice.

In return, you get the headache of attempting to make sure that all
client systems are correctly configured. What if your trigger is in
Perl, and they don't have Perl on their system? What if you assume
they have the BSD version of awk or sort, but instead, they use the
System V version which take different parameters? What if they are on
a PC, and don't even have awk or sort? What if you require they have
Cygwin installed, but they put the SYSTEM32 directory in their path
before Cygwin's /bin directory?

Then, there are the people who figure out the way around the trigger
is to write their own "Perl" command that will always return an exit
code of "0" no matter what happens (Simply a one line shell script
with "exit 0"). They simply put this "Perl command" in their path
before everything else. Maybe you'll want to force set the path, but
for which system? Is Perl in /usr/bin/perl, /bin/perl, or /usr/local/
bin/perl. What if the Perl in /bin/perl is a very old version and the
user has the newer version in /usr/local/bin/perl. Then again, what
if that's the "exit 0" one? What if you depend upon a Perl module
that doesn't exist on the client's system?

I was taking care of a ClearCase site with about 100 users and at
least half of my time was spent with client configuration problems.
With server side triggers, you only have to worry about the
configuration of one machine, and that's a machine you control.
That's a great advantage of Subversion, I don't care whether the
developers use a Unix, Linux, Windows, Mac, or even an Etch-A-Sketch
to do their work. They can use any Subversion client they want on any
system they want (there aren't even any licensing issues since it is
OpenSource). With ClearCase, I was putting out fires due to bad
clients. With Subversion, I can concentrate on what a CM is suppose
to be doing.

=======================================
Well, I've wrestled with reality for 35 years, doctor,
and I'm happy to state I finally won out over it."
-- Elwood P. Dowd
=======================================

David Weintraub
david@weintraubworld.net
david@weintraub.name
Received on Fri Oct 14 05:43:29 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.