Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: [hwloc-devel] git / nightly builds
From: Jeff Squyres (jsquyres) (jsquyres_at_[hidden])
Date: 2013-09-27 09:36:25


I'd say that git and the new Trac are now fully open for business. I might still do some shifting around of tags (see below), but otherwise, I think everything is just about ready.

I'm revamping make_dist_script and the nightly build script; I should finally be able to commit those today, if all goes well. However, I had to make some changes to VERSION and some other surrounding infrastructure to make it all work. Specifically: git just does some things *differently* than SVN, so it required some changes in the way that hwloc does things, infrastructure-wise.

Two things:

1. I'm not excited about back-porting these changes all the way back to hwloc-1.0 just so that we can make nightly tarballs for these branches which aren't used any more. I'm thinking that I should definitely make these changes for master and the v1.7 branch. Should I also do the v1.6 branch?

I'm thinking that back-porting further is useless; we should just stop making nightlies for all the older branches.

To clarify: with SVN, we still checked all the older branches every night and would make a new tarball if there was ever a change. We never made changes in those older branches, so we never made new nightlies. But we *would have*, if a change had every been committed on those branches.

2. With SVN, adding the r number in the tarball version was sufficient to observe ordering of the tarballs. For example:

   hwloc-1.8r1234.tar.bz2
   hwloc-1.8r1240.tar.bz2
   hwloc-1.8r1255.tar.bz2
   ...etc.

With git, we only have a hash number. So there's no obvious ordering of the tarballs. For example:

   hwloc-1.8git11223344.tar.bz2
   hwloc-1.8git00aa3344.tar.bz2
   hwloc-1.8git99aa2277.tar.bz2
   ...etc.

However, there is "git describe" functionality which, in our case, can show you how many commits you are beyond a given tag. For example, I added a "dev" tag on the master branch for the first pure-git commit (i.e., 1 beyond the last SVN commit). For example:

    $ git clone git_at_[hidden]:open-mpi/hwloc.git
    ...clone completes successfully...
    $ cd hwloc
    $ git checkout master
    $ git describe --always
    dev-3-g51efdd1

Where the "3" represents that we're 3 commits beyond the "dev" tag. The "g" just means "git", and the "51efdd1" is the hash of that commit.

Hence, if we use that as our version string, we get tarballs named something like this:

    hwloc-dev-3-g51efdd1.tar.bz2
    hwloc-dev-10-gf50a385.tar.bz2
    ...etc.

For the master branch, I think that's fine. However, note that ***THIS IS DIFFERENT THAN WHAT WE HAVE PREVIOUSLY DONE ON RELEASE BRANCHES!***

For example, if you checkout the v1.7 branch:

    $ git checkout v1.7
    $ git describe --always
    hwloc-1.7.2-4-g3a6f84c

*** NOTE THE DIFFERENCE HERE:

a) The last SVN nightly snapshot on the v1.7 branch was named
   hwloc-1.7.3rc1r5779.tar.bz2.
b) The first git nightly snapshot on the v1.7 branch will be named
   hwloc-1.7.2-4-g3a6f84c.tar.bz2.

Note "1.7.3rc1..." vs. "1.7.2...". I.e., the git name will say "we're X commits beyond the 1.7.2 tag", but the old SVN name was "we're at this *upcoming* version".

I think that this is ok (other projects use this "git describe" kind of behavior for their nightly snapshots), but this is a change from what we used to do, so I wanted to call it out specifically.

Are you guys ok with this?

(note: I'm still mucking with the final tag names, so some of the above may change slightly)

-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/