[Mulgara-dev] Re: [Mulgara-svn] r206 - trunk

Life is hard, and then you die ronald at innovation.ch
Sat Mar 3 22:04:18 UTC 2007


On Sat, Mar 03, 2007 at 11:49:10AM -0600, Paul Gearon wrote:
> 
> On Mar 3, 2007, at 4:04 AM, Life is hard, and then you die wrote:
> 
> >On Fri, Mar 02, 2007 at 09:29:37AM -0600, Paul Gearon wrote:
> >>Yes it would be much better.  I had forgotten to set this up, until
> >>the other day when someone told me the build number they were
> >>running, and I realized that the number was meaningless.  I thought a
> >>good interim step would be to update it manually.
> >>
> >>The *best* way to update this number would be via a script at checkin
> >>time.  That way the build machine doesn't have to be connected to the
> >>network.  But if that's infeasible, then calling across the network
> >>would be OK, I guess.
> >
> >I'n not sure we're talking quite the same thing. I'm suggestion not
> >storing the build number anywhere, but generating it on demand. I.e.
> >the 'version' file contains just the bsae version (e.g. "v1.0.0"), and
> >the build script tacks on the current version of the working copy that
> >is being used to do the build. This means the build number accurately
> >reflects what was used to build, no network access is needed, and the
> >version file only needs bumping on true version bumps. Or in shell
> >script terms the tag becomes "`cat version`.`svnversion`".
> >
> >Note that if the current working copy contains more than one version,
> >or contains modifications, the string returned by svnversion will
> >reflect that (e.g. "190:206M" shows that my working copy has multiple
> >version and local modifications) - so you can immediately tell if the
> >build was from a mixed or modified working copy.
> 
> We were discussing the same thing.  I was just under the impressions  
> the svnversion was doing some network access (not by following its  
> operation, but simply based on how long it took to respond).  If it  
> performs all of it's operations locally, then it's perfect.  :-)

It's all local. The reason it takes a moment or two is that it has to
walk the complete working-copy tree to find out all the versions in
use and if any modifications have been done (similar to 'svn stat').

Btw., dunno what version of subversion you're running locally, but if
you upgrade to 1.4 you'll find improved working-copy speed (you don't
have to change the server for this - any 1.x version will talk to any
other 1.x version - but if the server is running 1.4 too then you'll
get some additional speedups when network access is involved).

> I have no objection to the build looking like: v1.0.0.190:206M.   
> However, it would be nice if we can have a mechanism that allows us  
> to manually override this to v1.1.0.0 when we do the next release.

Well, the point was that releases should be done from clean
working-copies, so the version then would be v1.0.0.206 - if it isn't
you know something wasn't right went it got built.

> This brings up something about versioning.  I'm anticipating the  
> following convention, but we'd better agree on it:
> Given the version string:  "vA.B.C.D"  then we increment each value  
> according to:
> D - The most frequently changing value, based on the current  
> checkin.  Proposed to be of the form "190:106M"

As mentioned above, upon a clean build the form would really be just
'206' and anything else should be considered a bad build (because
it'll be hard to impossible to reproduce).

[snip - makes sense to me]
> You'll notice that the version number is set in the file "version".   
> Ant inserts this into the source code via a substitution of the  
> string @@build.label@@.  The value is read from the version file in  
> the -prepare-build target of common.xml, and the substitution takes  
> place in the -server-token-build-label target of src/jar/server/ 
> build.xml.  It also appears in a couple of other places (itql/ 
> build.xml and rdql/build.xml) but you'll find that these are  
> inconsequential (maybe this should be cleaned up).

It seems like there's a duplication of the version: it's stored in
both the 'version' file and in the common.properties (as
'mulgara-version'). Shouldn't the two be merged?

> So the modification to update the version string should take place in  
> the -prepare-build target.  Maybe we can create a new property that  
> instructs the target to not update the string, so we can manually set  
> it during a release.

If the property were set using normal ant methods, then this would be
automatic since ant properties are write-once-only - so you could
override it by specifying it on the command line via -Dversion=... .


  Cheers,

  Ronald




More information about the Mulgara-dev mailing list