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 g...@github.com: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
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
