On Nov 21, 2007, at 04:37, Joachim Durchholz wrote:
> Ryan Schmidt schrieb:
>
>> I believe the bug occurs any time you try to export from a working
>> copy (regardless of what protocol you used to check the working copy
>> out with), and I believe the bug does not occur if you try to export
>> from a repository URL (again, regardless of the protocol). But I have
>> not tested every protocol.
>
> OK, I'll have to try it out.
>
> Thinking about alternatives:
>
> Since the script is doing a rollout, which means walking the
> directory and munging files anyway: is an exported tree equivalent
> to a checked-out repository with the .svn directories removed?
Yes, that's exactly what export does: it removes the .svn directories.
> In that case, I could simply copy the repository tree and skip the
> unwanted files (i.e. .svns and some other stuff that I'm currently
> stripping after the export). This would also speed up the process
> because the repository contains some large binary files that aren't
> going into production anyway (test data and such).
>
> Another alternative: wait for 1.5.
> Should I hold my breath?
No; there's no ETA yet on when 1.5 will be done. "It'll be done when
it's done" is the common response I've seen.
> P.S.: Re CCing and reply-to headers: Thunderbird isn't smart enough
> to properly react to mailing-list headers. I've been considering
> dropping TB for a while now, it's just that I haven't come across a
> satisfactory alternative yet...)
>
> P.P.S.: I think that "export from the respository and have some
> file munging" scenario is quite common. That's not really
> attractive though: e.g. when rolling out for the customer, you
> don't want to first export several megabytes of versioned test data
> just to delete them afterwards; you'd want to filter them even
> before they get transmitted from the repository to the rollout
> directory.
I approach it differently: I structure my projects such that
everything that should be deployed is in one directory in the
repository. Other data which is needed during development but not
during deployment is in a separate directory. For deployment, just
export the deployment directory.
> My knee-jerk reaction was "use a hook script then"; however, since
> every hook script must serve all needs, this means that you have to
> coordinate closely that the export will do something differently
> depending on whether the checkout/export is for programming, for
> testing, or for rollout. (In a larger organisation with separate
> teams for SVN administration, programming, QS, and rollout, this is
> bound to become even more painful.)
This cannot be done with hooks. There is no pre-export hook.
> 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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 22 06:08:38 2007