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.
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:
With git, we only have a hash number. So there's no obvious ordering of the tarballs. For example:
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
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:
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
*** NOTE THE DIFFERENCE HERE:
a) The last SVN nightly snapshot on the v1.7 branch was named
b) The first git nightly snapshot on the v1.7 branch will be named
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)
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/