> The problem is very simple: The pre-commit hook runs on the
> server, but the code that needs munging sits in the working
> directory on the client side.
>
> In order to do this type of munging, the conversation between
> the server and client must be greatly enriched. Right now,
> it's basically the client sending information for the
> archive, and the server giving a resulting status. To have
> the pre-commit hook modify the code, it would need to send
> each mod back to the client. All of this for a feature of
> rather dubious value.
Where does the RCS keyword expansion take place?
> Now, you could create a post-commit hook that immediately
> checks out the files that were just committed, mucks them up,
> then recommits them back to the archive. All you need is a
> way for the post-commit hook to know that it shouldn't run a
> second time around. A lot of people do something similar
> with "svn export" to automatically update a directory on a server.
>
> Of course, your developer will now be sitting there with an
> out-of-date working copy, and will have to remember to do an
> "svn update" to put the changes into their working copy.
> Plus, they'll have to wait until they're sure whatever
> process you're running is finished and has completed its
> commit operation.
Right, not the solution I am looking for.
> The pre-commit hook running on the server side is a big
> disadvantage of using Subversion. But it is also a big
> advantage too...
>
> I had been doing ClearCase administration for well over a
> decade, and ClearCase has a similar feature to hooks called
> "triggers". Unlike Subversion hooks, triggers run on the
> client side which means you can do anything you want to the
> file in a trigger before it is actually checked in. However,
> because it runs on the client side, you now are responsible
> to make sure each and every client is setup correctly.
>
> Imagine over 100 people on a project with each and everyone
> on a differently configured client. You have to make sure
> that every trigger you write will work with all the hundreds
> of flavors of Unix and of course all of your PCs. Of course,
> IT is helping you out by upgrading OS's, installing software,
> or even giving people new computers, and forgetting to let
> you know. I spent a good chunk of my time just making sure
> PCs and workstations were configured correctly.
>
> With Subversion, I don't care if the developer uses a PC, a
> Linux box, Unix server, a Mac, or even an Etch-A-Sketch. As
> long as they can get a Subversion client for whatever they
> use, they can do their development work. My hooks merely make
> sure that the code is in the right format before it is
> committed, and that all of the needed properties are
> correctly set. If something is wrong, I reject the commit and
> give the user a nice explanation what went wrong. My hook
> only has to run on a single system and I no longer have to
> worry about the client's configuration.
How does it make sure the code is in the proper format?
Bernie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 22 23:25:34 2005