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

Re: Exporting with externals doesn't work

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-11-22 09:03:16 CET

On Nov 22, 2007, at 01:55, Joachim Durchholz wrote:

> Ryan Schmidt schrieb:
>>> So how about *client-side* hook scripts? Have a parameter --hook-
>>> dir for the SVN client. With a hook for checking whether a given
>>> file should be exported at all, and a hook for munging the
>>> contents of a file (possibly even before the file is written to
>>> disk: piping the file contents to stdin of the hook script would
>>> suffice).
>> Client-side hooks are not available, and probably never will be.
>> There are about a zillion threads in the mailing list archives if
>> you'd like to review them. Basically, it's a security issue to
>> allow code that someone committed to the repository to be run on
>> the client. Not to mention that it's very difficult to write a
>> script that works properly on all possible client environments,
>> given the poor scripting support built into Windows for example.
>> And what you're asking for -- the ability to tell the repository
>> what to send and not to send -- goes even further.
>
> The scripts would live on the client side, of course. IOW selecting
> the right set of hooks would have to be a command-line option of
> the client.
>
> I think the real work would be adding a hook in the protocol. I.e.
> when exporting, the SVN server would have to ask the client whether
> a specific file is actually needed before sending it.

I have a feeling you wouldn't get any support for such a feature from
the developers. This is a case where the svn client is insufficient
for your needs, so you would be told to go write your own client
program using the language bindings, which exist for most any language.

>> Hey, actually, if that's all you want, couldn't you just ask the
>> repository for a list of files first, and then only request the
>> ones you actually want? You may have to dig into the APIs, like
>> the Perl API for example, to do this optimally.
>
> Hm... well, yes, that would be an option.
> This is a PHP shop (urk), so I'd probably do an svn --xml list and
> parse the output (PHP does come with an XML parser, so I'm lucky
> here).
> ... speaking of svn list, it doesn't work either. So for the
> moment, I'm stuck with post-hoc file filtering. Not optimal, but I
> can live with that.

I'm primarily a PHP programmer too. You may want to look into this:

http://pecl.php.net/package/svn

Language bindings should be faster than running command line programs
and parsing output. But I haven't tried to use these PHP SVN bindings
yet. I ran into problems with the first version, but maybe this one's
better, or maybe I was doing something wrong before.

What do you mean "svn list [...] doesn't work"?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 22 09:04:19 2007

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

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