> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: Wednesday, March 12, 2008 2:55 PM
> To: Reedick, Andrew
> Cc: users_at_subversion.tigris.org
> Subject: Re: Unversioned files held by repo
>
>
> But consider a likely alternative, where you run the repository out of
> space because you can't delete just to maintain unwanted disposable
> and/or reproducible content. Or on the opposite site you have people
> who avoid committing things because of the side effects that can't be
> undone.
>
> > It breaks build repeatability.
>
> A likely scenario is that the items in question are build targets, not
> dependencies, but you'd like them stored temporarily or for others to
> be
> able to access them without having to build their own.
So you want something like ClearCase's wink-in capability? Do a build
in workspace/view1. Someone kicks off a similar build in
workspace/view2. Instead of rebuilding each and every derived object
(build object), ClearCase will grab the object from view1 and pull it
into view2. At which point the build object is stored on the ClearCase
server for easier sharing. IIRC.
ClearCase will also go through the extra effort of comparing version
numbers when 'winking in' derived objects, since make programs can be
mislead by how version control systems play with file timestamps.
Plan C would be to build revision 100. Tar up revision 100's build
output and put it on the network.
User Bravo checkouts 100. Bravo then untars the 100.tar into his
workspace. Bravo then probably needs to touch all the files (from the
tar) so that make isn't confused. Bravo then 'svn updates' to revision
110 and kicks off an incremental build.
Plan C.1 It might be a good idea to tweak the build scripts to put the
build output in an entirely separate directory. That would make the
file/dir slinging easier.
Plan D. Instead of a tar, just put the full build output on a file
server. Tweak the build scripts to look there before deciding whether
to rebuild a particular object file or not. At one company I worked
for, a local build would look at the main network dir, the secondary
network dir, and finally the local dir before deciding whether to build
a piece of code. No idea what those makefiles looked like.
Plan E Avoid the whole issue by getting a faster build machine, or setup
distributed/parallel builds. =)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-12 20:25:33 CET