Tom Kielty wrote:
> 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.
Since every revision number is an explicit tag why not simply work based
on the revision numbers. If your build is successful you can make a tag
at the end. (In our systems we simply record the history of what
revision a build was built from.) There's no need to halt development
work while the build is going.
If your build really is 3.5 hours long I can't over-stress the benefit
of setting up continuous integration (e.g. CruiseControl) to give very
quick feedback to developers if they check in something broken. That
way the compile problems are fixed before your nightly build starts.
> 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”
Yes, you can do this:
svn ci Project1\res.rc Project2\res.rc -m"Build.043"
But I much prefer (and use) something architected like this:
Commmon\version.h // store per-build version info like revision #
Project1\res.rc // #include Common\include.h
Project2\res.rc // #include Common\include.h
If you ever need local-project overrides Common\version.h can
#include ".\local-version.h"
While you're making the transtion from VSS -> SVN, I strongly recommend
you take a good look at your existing processes and see if they can be
made better, don't just attempt to map all the old VSS stuff (which was
limited or made indiferent by poor technology) into SVN.
-Nathan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon May 28 23:32:04 2007