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

Doing builds with subversion

From: Tom Kielty <tom.kielty_at_calabrio.com>
Date: 2007-05-28 16:19:29 CEST

I have a two part question regarding doing our product builds.


We are in the process of moving from Source Safe to Subversion.


The first one deals with the tagging process for a build/release. Our
product build takes around 3.5 hours to run. The challenge is when to
tag. If we tag first and then build off the tag it will keep the
build/tag pristine as no developers have access to modify the tags.
However the problem comes in if the build fails. It has been our build
practice, that if a build fails the developer responsible fixes the
problem, checks the updated files into source control and then the build
engineer updates the build environment with the new file and continues
the build. However if we are building off the tag then a switch will
have to be made. However will all the intermediate files that are
produced and the unique files that are updated but not checked back into
source control this present a problem for getting the latest files. Due
to the time to re-spin a build we want to avoid the challenge of
repining for every failure.


Another ideas we had was, when the build began to lock all users from
updating the trunk and build from the trunk. When the build is done a
tag would then take place. However this does prevent developers from
checking in code for 3.5 hours.


Thought on this?



The next issue deals with updating files during the build. Some of our
applications are MFC apps in which the build script will update the
resource files with the latest version and information per that build.
With Source Safe the build script would check the updated .rc file back
into Source Safe. This was done so that the dev. would have the latest
up to date data in the resource files in source control. With subversion
we were starting the same process but soon realized that every check-in
would create a new revision number. That means for every build we would
but our revisions up almost 100. Not ideal. So then I looked at doing a
global check-in when we were done building. However due to the number of
changed and new files I am unable to do that.


So my question is am I stuck not updating the files to prevent the 100
revisions, or is there a way to do a commit on only certain files and
ignore the rest?


i.e. svn ci *.rc -m"Updated per the build"


Thanks for your comments on this.


Tom Kielty
Received on Mon May 28 22:57:22 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.