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
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-tsvn-props
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.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3062091
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-05 21:45:16 CEST