[cctbxbb] sequential revision number from git repo

Hattne, Johan hattnej at janelia.hhmi.org
Tue Apr 5 08:33:32 PDT 2016


Would this not mean that .gitversion is updated on every commit, at least if as in our case, it not only records the release version but also the current commit?

@Rob: Apologies for my liberal use of “hook”.  What our build system does is that it generates what essentially amounts to Markus’s .gitversion whenever we run “make dist” (using “git describe” or some such, it need not involve the network).  There is little need for this file when compiling from a sources under git control, because it can be done on the fly.

// Cheers; Johan


> On Apr 5, 2016, at 09:47, markus.gerstel at diamond.ac.uk wrote:
> 
> Hi Johan,
> 
> We generate a file named '.gitversion' that lives in the main directory. That way the version number survives being packed up in an installer.
> If you download the code via the "Download ZIP" button on Github there is no way (as far as I know) to recover any version information, so we fall back to a default of "DIALS 1.dev" ("DIALS 1.1" for the release branch)
> 
> -Markus
> 
> -----Original Message-----
> From: cctbxbb-bounces at phenix-online.org [mailto:cctbxbb-bounces at phenix-online.org] On Behalf Of Hattne, Johan
> Sent: 05 April 2016 14:21
> To: cctbx mailing list
> Subject: Re: [cctbxbb] sequential revision number from git repo
> 
> Hi Markus;
> 
> I didn’t actually read the code, but it looks like we’re doing something similar over here, and I find the the tricky bit is how to deal with any kind of releases that don’t have all the little git bits.  We sort that out by having hooks in the “make dist” equivalent, which basically generate a version file that is included in the release tarball.
> 
> However, it was recently pointed out to us that that all falls apart if someone uses the "Download ZIP” button from the code tab, because then the hooks are not run.  I haven’t even attempted to RTFM around this, and if you or anybody else here has a solution I won’t have to.
> 
> Do you by any chance?
> 
> // Cheers; Johan
> 
> 
>> On Apr 5, 2016, at 08:55, markus.gerstel at diamond.ac.uk wrote:
>> 
>> Hi Rob,
>> 
>> This is close to what we do with DIALS.
>> If you run dials.version you may get e.g.
>> DIALS 1.dev.132-g7042805
>> So this is the 132nd commit after the commit we tagged "1.dev", which 
>> happened when we branched for the 1.1 stable release so we could keep 
>> the version numbers sufficiently different
>> 
>> If you run DIALS 1.1, for example the version from CCP4, you might get 
>> DIALS 1.1.3-gb5528a5-release The 3rd commit on the 1.1 release branch.
>> 
>> Same with xia2:
>> XIA2 0.4.0.301-g7f16ab6
>> 
>> In xia2 we also add the branch name if it is not 'master', so the version distributed with DIALS 1.1 is:
>> XIA2 0.4.0.289-g2a1e557-dials-1.1
>> 
>> We kept the commit ID in - and I would recommend to keep it with cctbx, too.
>> The reason for this is: 
>> - The number on its own does not uniquely identify a commit, as you 
>> might be on a different branch (although we do put in the branch 
>> names, too)
>> - Because then I can go to 
>> https://github.com/dials/dials/commit/b5528a5 and see everything about 
>> that commit
>> - Because then I can do  git checkout b55528a5  and instantly have that particular code version on my machine to fiddle with things.
>> 
>> To see the magic happen, check 
>> https://github.com/dials/dials/blob/master/util/version.py or 
>> https://github.com/xia2/xia2/blob/master/XIA2Version.py
>> 
>> -Markus
>> 
>> 
>> -----Original Message-----
>> From: cctbxbb-bounces at phenix-online.org 
>> [mailto:cctbxbb-bounces at phenix-online.org] On Behalf Of R.D. Oeffner
>> Sent: 05 April 2016 13:38
>> To: cctbxbb at phenix-online.org
>> Subject: [cctbxbb] sequential revision number from git repo
>> 
>> Hi,
>> 
>> We are slowly moving phaser svn to git. One issue that we would like to address is if there is a practical way of conveying a linear commit history from the git repo.
>> 
>> One approach is to just count the number of revisions that was made to the master branch in the git repo with "git rev-list --count HEAD"
>> and then pretend that number is a revision number. This enables us to tell users "This bug was fixed after revision 6456 of phaser" rather than "This bug was fixed after commit 29b0a1c... of phaser". Is there any pitfalls with this approach?
>> 
>> What workarounds do other people using git come up with?
>> 
>> 
>> 
>> Rob
>> 
>> 
>> --
>> Robert Oeffner, Ph.D.
>> Research Associate, The Read Group
>> Department of Haematology,
>> Cambridge Institute for Medical Research University of Cambridge 
>> Cambridge Biomedical Campus Wellcome Trust/MRC Building Hills Road 
>> Cambridge CB2 0XY
>> 
>> www.cimr.cam.ac.uk/investigators/read/index.html
>> tel: +44(0)1223 763234
>> mobile: +44(0)7712 887162
>> _______________________________________________
>> cctbxbb mailing list
>> cctbxbb at phenix-online.org
>> http://phenix-online.org/mailman/listinfo/cctbxbb
>> 
>> --
>> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
>> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
>> Diamond Light Source Limited (company no. 4375679). Registered in 
>> England and Wales with its registered office at Diamond House, Harwell 
>> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United 
>> Kingdom
>> 
>> 
>> _______________________________________________
>> cctbxbb mailing list
>> cctbxbb at phenix-online.org
>> http://phenix-online.org/mailman/listinfo/cctbxbb
> 
>          Research Specialist @ Gonen Lab ____________________________________________________
>    Janelia Research Campus * 19700 Helix Drive Ashburn, VA 20147 * +1 (571) 209-4000 extension 3376
> 
> 
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
> 
> -- 
> This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
> 
> _______________________________________________
> cctbxbb mailing list
> cctbxbb at phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb

          Research Specialist @ Gonen Lab
____________________________________________________
    Janelia Research Campus * 19700 Helix Drive
Ashburn, VA 20147 * +1 (571) 209-4000 extension 3376




More information about the cctbxbb mailing list