info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Automatically increment build number


From: Weber, Mathias-Henry 1254 PPW-P1
Subject: RE: Automatically increment build number
Date: Wed, 9 May 2001 09:49:59 +0200

> -----Original Message-----
> From: Matthew Riechers [mailto:address@hidden
> 
> "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.
> 

Again - you're absolutely correct. This is what I do for "real" releases
(linking features to a tag). I just wanted to have some kind of a compact
handle that help me to gauge the behaviour of the various intermediate test
releases that come up during the same day and sometimes reside
simultaneously on the same dedicated test machine with names like
        Appl.exe
        Appl.exe.old
        Appl.exe.bak
        Appl.exe.debug
        etc.

The process is that a developer builds an intermediate executable on his
personal machine including some fresh features that he wants to test. Then
he takes this executable to the dedicated test machine (there is special
hardware needed to test). Here he finds the above depicted situation and he
needs to copy the new executable to the test machine with the name
"Appl.exe".

So - he moves the existing "Appl.exe" to something like
"Appl.exe.dontknowhowtoname" and copies his file in place. After having
tested he leaves the test machine and checks in his modifications. 

We build "official" test releases about once a week, and there is a tag and
a release notes file coming with each of them. But we daily build several
"personal" releases and it does not pay off to document each of these
releases mainly bound to trash can. Here a build number that is incremented
automatically would be handy.

Since this topic is in no way crucial I consider this thread closed.
Nevertheless it helped me a lot to discuss it here to get a clearer view of
it.

Thanks 
Mathias



reply via email to

[Prev in Thread] Current Thread [Next in Thread]