update and checkout hook scripts

View: New views
2 Messages — Rating Filter:   Alert me  

update and checkout hook scripts

by Gunther Mayer-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi guys,

I've run into the following challenge: I manage kml (Google Earth) files through my repository and need to get absolute paths within them to work transparently across linux and windows platforms. Google Earth itself cannot treat "C:\repo\myimage.jpg" identical to "/repo/myimage.jpg" so I have to do some magic in my repository by choosing a server side scheme (the unix paths) and transparently converting the paths back to windows paths on windows clients.

Can anybody think of a creative, low-overhead solution to this problem?

I thought commit-hooks are the answer but I need it in two places:
  • post-commit on the server to translate windows to unix paths with sed (I know that leaves me with stale client issues but I'll just have to be careful in the step below) - this is fairly easy to achieve
  • pre- or post- update/checkout somewhere which translates the paths back to the windows scheme
The latter is the tricky part because if I run it on the server, not only do I need special svn support which isn't available (although I saw proposed patches for pre-checkout hooks on this list sometime ago they seemingly were never committed) but I also need some way of telling whether the connecting client is a Windows one (also not supported afaik). If I try do to do this on the client then I'm limited by the availability of client side hook scripts which afaik are only supported in TortoiseSVN, plus I'll have to ensure that I change the corresponding .svn/text-base/ file at the same time to avoid the above client consistency issues.

Is there an easier way to achieve what I'm trying to do?

Gunther

RE: update and checkout hook scripts

by Srilakshmanan, Lakshman :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Gunther,
 
Changing the contents of a transaction in a hook script is discouraged.
 
My suggestion would be to provide a vb/shell script in the project to be run by the developer after checkout.
 
Don't try to automate it. It could be more trouble than it's worth.
 
Thanks
Lakshman

From: Gunther Mayer [mailto:gunther.mayer@...]
Sent: Sunday, 1 November 2009 10:45 PM
To: users@...
Subject: update and checkout hook scripts

Hi guys,

I've run into the following challenge: I manage kml (Google Earth) files through my repository and need to get absolute paths within them to work transparently across linux and windows platforms. Google Earth itself cannot treat "C:\repo\myimage.jpg" identical to "/repo/myimage.jpg" so I have to do some magic in my repository by choosing a server side scheme (the unix paths) and transparently converting the paths back to windows paths on windows clients.

Can anybody think of a creative, low-overhead solution to this problem?

I thought commit-hooks are the answer but I need it in two places:
  • post-commit on the server to translate windows to unix paths with sed (I know that leaves me with stale client issues but I'll just have to be careful in the step below) - this is fairly easy to achieve
  • pre- or post- update/checkout somewhere which translates the paths back to the windows scheme
The latter is the tricky part because if I run it on the server, not only do I need special svn support which isn't available (although I saw proposed patches for pre-checkout hooks on this list sometime ago they seemingly were never committed) but I also need some way of telling whether the connecting client is a Windows one (also not supported afaik). If I try do to do this on the client then I'm limited by the availability of client side hook scripts which afaik are only supported in TortoiseSVN, plus I'll have to ensure that I change the corresponding .svn/text-base/ file at the same time to avoid the above client consistency issues.

Is there an easier way to achieve what I'm trying to do?

Gunther
================================================================================================
EMAIL DISCLAIMER

This email and any attachments are confidential. They may also be subject to copyright.

If you are not an intended recipient of this email please immediately contact us by replying
to this email and then delete this email. 

You must not read, use, copy, retain, forward or disclose this email or any attachment.

We do not accept any liability arising from or in connection with unauthorised use or disclosure 
of the information contained in this email or any attachment.

We make reasonable efforts to protect against computer viruses but we do not accept liability
for any liability, loss or damage caused by any computer virus contained in this email.
================================================================================================