John Niven wrote:
>> -----Original Message-----
>> From: Ethan Schlenker [mailto:ethans_at_gamespot.com]
>> Sent: Wednesday, 13 February 2008 13:17
>> To: users_at_subversion.tigris.org
>> Subject: Re: Adding a file to repos with a post commit hook?
>>
>> Hrm - Perhaps I didn't explain myself well enough :-)
>>
>
> I think it's more likely that it's too hot for my poor little brain to
> work ;-)
>
>
>> Both the normal js file and the compressed file will be in svn. The
>> compressed version will be also stored in svn so that our dev
>> environment can use the compressed or the normal (to test if there are
>> ever bugs with the compressed version). Devs don't have to touch the
>> compressed version as the post-commit hook would take care of updating
>> the compressed file when they commit changes to a normal file.
>>
>
> Ah, OK. No reason why you can't do this - I'd still prefer to keep only
> source (uncompressed) in SVN, and treat compressed as equivalent to a
> binary, i.e. a product of the build process, but that's personal
> preference.
>
>
>>> and worry about compression nearer
>>> deployment. How do you deploy the javascript files? Could you use
>>> something like Ant (ant.apache.org) and trigger the compression
>>>
> then?
>
>> Doing it as part of the deployment process, is an option, but I'd like
>> the compressed file to be in svn as well so that the dev environments
>> can easily use it for testing. The more similar the live and dev
>> enviroments are the better.
>>
>> I guess my question boils down to: can a post-commit hook add/commit
>> a file in a repository?
>>
>
> I don't see why not (though I've limited experience with post-commit
> hooks). I can think of two possible approaches (disclaimer: I'm out of
> my SVN comfort-zone now, my experience with hook scripts is really
> limited to ensuring there's a log message, but it is something I've been
> looking into recently):
>
> 1. If all your developers are using TortoiseSVN you could create a
> client-side hook that regenerated the compressed js file(s), then
> committed the new file(s). This relies on all your team using
> TortoiseSVN (and, by extension, Windows);
> 2. Have a working copy on the SVN server, and a server-side hook to
> regenerate the compressed file using new uncompressed file. This is
> almost certainly the preferred option.
>
> Hope this helps, and sorry I can't be more helpful
> Cheers
> John
>
>
To me this method seems problematic. Developers are going to commit
there changes and then forget to update there working copy. Then they'll
waste time trying to figure out why the new code they added doesn't fix
the problem only to find out it did but they are testing the old version
of the compressed files.
I don't work with js but it would seem to me that you'd want something
in place that make sure that the compressed version really matches the
version the developer is looking at.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-13 02:40:45 CET