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
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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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
Except of course that I chose to illustrate the 'go to a commit'-github-link with a version that has not been published yet. Try eg. https://github.com/xia2/xia2/commit/2a1e557 instead Sorry -Markus -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 05 April 2016 13:56 To: [email protected] Subject: Re: [cctbxbb] sequential revision number from git repo 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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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 [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
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, [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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 [email protected] 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
Hi Markus and Johan, Thanks for the info which is reassuring to know that we are on the right track. Personally I'm not keen on hooks used for tagging commits as we are only permitted to have remote hooks on our client machines triggered by the our git server machine. Over the past few years we have had many (extremely rare!) power outages in our building to make such a setup rather fragile. Rob On 05/04/2016 14:21, Hattne, Johan wrote:
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, [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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 [email protected] 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 [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb
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: [email protected] [mailto:[email protected]] 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, [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
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, [email protected] 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: [email protected] [mailto:[email protected]] 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, [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of R.D. Oeffner Sent: 05 April 2016 13:38 To: [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
participants (3)
-
Hattne, Johan -
markus.gerstel＠diamond.ac.uk -
R.D. Oeffner