Switching to git for the cctbx would be very liberating for developing and
testing code I believe. If bisecting git hash values seems cumbersome one
can always tag each commit with the number of previous commits made to the
branch used for the build. These numbers are sequential and obviously
straightforward to use for bisecting. We do this currently for the phaser
git repo:
https://git.csx.cam.ac.uk/x/cimr-phaser/phaser.git
Rob
Date: Mon, 13 Jun 2016 21:24:58 +0000
From:
To:
Subject: Re: [cctbxbb] Not wishing to raise this again but...
Message-ID: <1BB183A24316FD4DA62A5F8B952D4291CC715321@exchmbx03>
Content-Type: text/plain; charset="windows-1252"
At least according to Google Trends, svn has been on a downward trend since
about 2009/10, whereas git is still firmly on an upward trend (and overtook
svn in popularity long ago):
https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1
https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1
https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1
[cid:162fa876-cc25-6335-73af-714b0957d71e]
I think that avoiding a move to git is simply delaying the inevitable (and
if the cctbx didn't ever move with the times then we'd still be stuck with
CVS). In my opinion, the potential benefits to using git far outweigh the
(slightly) added complexity.
https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1https://www.google.co.uk/trends/explore#q=git%20commit%2C%20svn%20commit&cmpt=q&tz=Etc%2FGMT-1Cheers,
Richard
________________________________
From: [email protected] [[email protected]]
on behalf of Nicholas Sauter [[email protected]]
Sent: 13 June 2016 22:05
To: cctbx mailing list
Subject: Re: [cctbxbb] Not wishing to raise this again but...
I'd vote against the switch to git. Simple things, like svn update [remote
directory] seem too complicated. As for slightly involved tasks like code
bisection to locate the past commit that broke the test, well....I've never
been able to figure this one out so I am pretty lost trying to debug DIALS.
I do not wish to make things difficult for the maintenance of cctbx.xfel.
Nick
Nicholas K. Sauter, Ph. D.
Computer Staff Scientist, Molecular Biophysics and Integrated Bioimaging
Division
Lawrence Berkeley National Laboratory
1 Cyclotron Rd., Bldg. 33R0345
Berkeley, CA 94720
(510) 486-5713
On Mon, Jun 13, 2016 at 8:52 AM, Luc Bourhis
mailto:[email protected]> wrote:
On 13 Jun 2016, at 17:09,
[email protected]mailto:[email protected] wrote:
? is there any enthusiasm out there for moving cctbx to git? The more I work
with git the more I wish this existed properly for cctbx.
I?ve raised this a bunch of times and always it is ?not right now? however
?a good idea? ? this?ll be the last time I ask?
Could we move to git, please? I note the bootstrap script for Windows now
has a git dependency even!
+1
? and time to share some thoughts! It would be great if we could get the
cctbx up and running by just cloning, configuring and building without
needing to download anything else.
That could be done by adding SCons, Boost, and ccp4io as submodules in the
cctbx repository. And I reckon ccp4io_adaptbx should be added as a subtree
since it is developed by the same people as the cctbx.
Just an idea to think about as I haven?t not worked out the details at all.
Best wishes,
Luc
_______________________________________________
cctbxbb mailing list
[email protected]mailto:[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
