Max Bowsher wrote:
> ...
> Depends how you structure your repository.
> All you have to do is put the platform specific tree *not* nested
> within the common tree in the repository. Then you use switch to
> switch in *just* the 1 platform you actually care about:
>
> /common/trunk/foo/jvm <---empty dir
> /platform/linux/jvm
> /platform/win32/jvm
>
> In a WC of /common/trunk/foo:
> svn switch url://to/repository/platform/<my-plat>/jvm jvm
>
>
> Max.
This is certainly a clever idea, and it's easy. Another alternative is
to simply not check out a working copy, since presumably this changes
very rarely and not in the course of regular development. Instead, just
use svn cat to fetch the appropriate file. This works if the number of
files is small, but breaks down if there are many such files, since you
can't do a cat of a directory.
Yet another idea, given how cheap storage is, is to keep the various
JVMs in a fixed, structured place on all machines (e.g.
/usr/local/jvm/jvm-version/...). You'd still keep a copy in the
repository, but by treating the JVM as part of the environment, you
speed up the builds. When I take this approach, I keep a configuration
file in the main tree that identifies the particular version of the
environment items that are being used. This is what I'll do if there
are many different tools that need to be tracked.
In other words, there are lots of possibilities. Factors include
available space, speed of machines and the network, how often you do
builds, how often you switch JVMs, and whether anyone updates the JVM or
just the project lead or SCM person..
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 1 04:53:30 2004