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

Re: Can client-side hooks run a script not in working copy?

From: Ben Fritz <fritzophrenic_at_gmail.com>
Date: Mon, 5 Aug 2013 14:44:49 -0500

On Mon, Aug 5, 2013 at 1:18 PM, Ron Wilson <ronw.mrmx_at_gmail.com> wrote:
>> > Another option would be to put commands in the makefile or build script
>> > of
>> > each project that will check for the hook scripts (or tools project)
>> > being
>> > in the working copy and fetching them if they weren't.
>> That works if the tools project is a subdirectory of everybody's WC
>> root. But I like checking out just a single "trunk" directory.
> Understandable.
> Maybe an extern reference in each project to the tools project would satisfy
> TSVN's restrictions. Otherwise, the alternative is to maintain multiple
> copies of the hook scripts in each project. Seems to me an extra project
> containing the common elements is a small price to pay.

We actually have a nice "Shared/Tools" location where I could put such
things. But how would I get this into my project's working copy?

I actually realized a little while ago when I started trying to test
some of these options, that the tsvn:XXXhook properties are not in
1.7.x so I probably need to try a different tack for now anyway.

But if I were using 1.8.x, an external reference would be a nice way
to do this. Will this work? Server-side scripts require an absolute
path to run, and
mentions the %REPOROOT% variable as a way to account for differing
working copy locations. But since an external doesn't actually reside
at the repository path where it appears in the working copy, I don't
think I can use REPOROOT in this case. I can't tell from the docs
whether relative paths work or not for the client-side scripts.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-05 21:45:16 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

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