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

RE: Unversioned files held by repo

From: Reedick, Andrew <jr9445_at_ATT.COM>
Date: Wed, 12 Mar 2008 14:24:38 -0500

> -----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

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.