Re: Automatically increment build number

[Matthew Riechers]

"Weber, Mathias-Henry 1254 PPW-P1" wrote:
> 
> > -----Original Message-----
> > From: Matthew Riechers [mailto:address@hidden
> > Sent: Tuesday, 8. May 2001 14:01
> > To: Weber, Mathias-Henry 1254 PPW-P1
> > Subject: Re: Automatically increment build number
> >
> >
> >
> > "Weber, Mathias-Henry 1254 PPW-P1" wrote:
> > >
> > > I want my project to output the actual build number. My
> > idea is to have a C
> > > file containing the build number and automatically
> > increment this build
> > > number each time anybody issues a "commit".
> > >
> > > In principle this would mean the following steps:
> > >
> > >         committing "Modified.cpp" starts
> > >                 checkout "BuildNo.cpp"
> > >                 increment build number within file "BuildNo.cpp"
> > >                 committing "BuildNo.cpp" starts
> > >                 committing "BuildNo.cpp" ends (hopefully)
> > >         committing "Modified.cpp" ends
> > >
> > > Now the problem is twofold:
> > >
> > > 1. The commit process is recursive which will probably
> > result in a deadlock
> > > situation
> > > 2. The checkout of "BuildNo.cpp" happens on the server.
> > What is the best way
> > > to accomplish/enforce an update on all clients?
> > >
> > > [ ... ]
> >
> > A build usually implies compiling, not editing. Why do you
> > want to track the number of commits? If you are actually
> > trying to count the number of builds, increment the value of
> > BuildNo.cpp when you do the *build*. If you are building
> > with some sort of Makefile or script system, it should be
> > trivial to add a 'increment_build.sh; cvs commit BuildNo.cpp'
> > to it.
> >
> 
> Of course you are right that I'd rather count the number of build runs. But
> since we actually do not have a central build server this is even more
> meaningless than updating the counter with every commit.
> 
> Another problem with coupling the incrementing of the counter to the build
> process would mean that this would have to be performed on every client
> host. The clients run Windows NT which is not my favourite choice for
> running script jobs. Furthermore the clients are rather differently equipped
> in terms of software the only common tool for script programming would be a
> DOS batch job. Do you understand that I am still interested in a different
> solution?
> 
> I do not realy want to count the number of build runs but rather have at
> least some meaningful indication about the included features of a certain
> executable. The build time of an executable could be quite recent but if the
> developer did not update recently it does not indicate that a feature is
> available or not.
> 
> Any further ideas?
> 
> Mathias


Using decentralized builds to track progress sounds a bit counter-productive. 
Why aren't periodic updates (auto-emails,
changelogs maybe) enough? The features would be enumerated in the log on 
commit, and you could have loginfo mail
everyone with a changelog style list if necessary. I think you are better off 
matching features to a tag in the
repository instead of a particular executable since you are using decentralized 
builds. If I'm missing something, please
explain.

- Matt