On Wed, Dec 9, 2009 at 8:33 AM, Bob Archer <bob.archer_at_amsi.com> wrote:
> > > How about taking a slightly different approach.
> > >
> > > Rather than versioning your app based on the svn revision number,
> > > version it based on the build number. Have the build script
> > update the
> > > version.h file. Once the build is done commit the version.h file
> > and
> > > create a tag for that build. Now if someone updates from head and
> > does
> > > a manual build the version.h file is correct for that revision.
> > >
> > > BOb
> > >
> > >
> > Yes, I failed to mention that is similar to the first approach I
> > implemented - people use mix of linux and windows tortoise client
> > and they instinctively just commit specific files they changed (me
> > included) and the elegant self generating version .h file (that I
> > spent time getting just right with lots of echo's and >> and a note
> > about this being an automatically generated file, do not edit, etc
> > :-) sits as an orphan in their directory forever or until they
> > remember to check it in. Next person does update and the version
> > number is unchanged.
> >
> > Of course having the build script doing an auto-commit on file
> > changes isn't practical since people do tons of builds a day. Looks
> > like creating a special build process using auto tools or scripts
> > and svnversion seems only solution and if you don't have this with
> > full svn and gnu in your environment you are out of luck and have
> > to rely on manually versioning those files before distributing
> > them.
>
> If the build script is run by a dev it should not be committed as an
> official version. Only the build server can commit an official version. This
> is easy to do by having a property in your build script that flags whether
> this is a versioned build or just an interim build that a dev is testing.
>
> You could also have a "current" tag that is updated after each build so
> people that are building for production would checkout/export from that tag
> which would always have the correct version.h in it.
>
>
Here is my 2c. This is probably something that is individual's preference
though.
I think if you can make sure the version.h creation is correct and
repeatable, then you don't need to check in the version.h file at all. You
can have a template version.h (version.h.tmpl) checked into svn. Then the
build script generates version.h using the template + a few build specific
information generated at the time of the build. Then you only need to make
sure that any person who builds a branch (or trunk) at a particular
revision, always gets the exact same copy of the version.h. [I've had such
implementation in multiple companies].
-Hari
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2428921
Please start new threads on the <users_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <users-subscribe_at_subversion.apache.org>.
Received on 2009-12-09 18:14:33 CET