Hi Luc We worried about some of this with DIALS but went ahead with it anyway and it seems to have worked out OK – there has been some confusion where people get it a bit of a knot from time to time, but we have moved OK and are also moving to a more native GIT way of working – this is where the real benefit lies I think. I would think for CCTBX the argument would be even stronger, as it’s needed all over the place (dials, ccp4, phenix, olex2…) and so having the flexibility offered by much easier and more reliable branching would be very useful. We’ve found that a handful of git commands will do what most ex-svn people need, with additional flexibility like partial commits. Clearly we *could* make a git cctbx anyway and sync it to the cctbx svn, but that would seem messy and not really the right way to do things… Does anyone else hold an opinion? In particular are there any known blockers to this? Thanks & best wishes Graeme From: [email protected] [mailto:[email protected]] On Behalf Of Luc Bourhis Sent: 11 January 2016 16:45 To: cctbx mailing list Subject: Re: [cctbxbb] Git Hi Graeme, Can we revisit the idea of moving to git for cctbx? This brings to mind a question I have been asking myself since the subject has been brought forth. The idea Paul wrote about on this list was a move to Github. I guess some, perhaps many, developers will keep interacting with the repository using subversion. I am worried this would clash with the workflow of those of us who would go the native git way. By that I mean creating many branches and merge points, which one would merge into the official repository when ready. I am worried the history would look very opaque for the subversion users. I would even probably create a fork on Github, making it even more opaque for a tool like subversion. Has anybody thought about such issues? My preferred solution would be for everybody to move to git but I don’t think that’s realistic. At the other end of the spectrum, there is putting in place a policy to keep the history linear. Best wishes, Luc -- 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

Dear Luc, We actually had a look at the quality of the Github svn interface when we prepared for the DIALS move. My verdict was that it is surprisingly useful. All the possible git operations are mapped rather well onto a linear SVN history. All the branches and tags are accessible either by checking out the root of the repository, ie. svn co https://github.com/dials/dials.git (not recommended, as, say, any new branch/tag will probably result in a huge update operation for you) or by checking them out directly, ie. svn co https://github.com/dials/dials.git/branches/fix_export or svn co https://github.com/dials/dials.git/tags/1.0 Forks by other people are, as is the case when using git, simply not visible. I agree that looking at the project history through SVN may not be as clear as the git history. I wonder how relevant this is though, as you can explore the history, without running any commands, on the Github website, eg. https://github.com/dials/dials/network, https://github.com/dials/dials/commits/master, etc. Creating new branches and tags and merging stuff via SVN would be a major operation. However, that has always been the case with SVN, and for that reason one generally just does not do these things in SVN. But for an SVN user group those operations would not be important – you every only need to merge stuff if you create branches – so I don’t really see the problem. If you want to tag releases you can do that on the Github website as well as with a git command. In summary, I do recognize that SVN users will have difficulties participating in branched development, and in particular will not be able to quickly switch between branches. But I don’t think that this will be a problem, or that there is a need for a policy to keep the history linear. Best wishes -Markus From: [email protected] [mailto:[email protected]] On Behalf Of Luc Bourhis Sent: 11 January 2016 16:45 To: cctbx mailing list Subject: Re: [cctbxbb] Gi, Hi Graeme, Can we revisit the idea of moving to git for cctbx? This brings to mind a question I have been asking myself since the subject has been brought forth. The idea Paul wrote about on this list was a move to Github. I guess some, perhaps many, developers will keep interacting with the repository using subversion. I am worried this would clash with the workflow of those of us who would go the native git way. By that I mean creating many branches and merge points, which one would merge into the official repository when ready. I am worried the history would look very opaque for the subversion users. I would even probably create a fork on Github, making it even more opaque for a tool like subversion. Has anybody thought about such issues? My preferred solution would be for everybody to move to git but I don’t think that’s realistic. At the other end of the spectrum, there is putting in place a policy to keep the history linear. Best wishes, Luc -- 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

From the DIALS-West perspective, the switch to git has been a stumbling block to participation. I would have to agree with Ralf that git seems to be a tool for very smart people but not for folks who just want a simple tool for managing code.

I can't agree with Markus that a linear history is dispensable. In fact, this is one feature in svn that I've found very helpful over the years. If a feature is broken today, but I know for a fact that it worked sometime in the past, I simply do a svn update -r "[datestamp]" to narrow down the exact date when the feature became broken, then I isolate the exact commit and look at the code. Can this be done with git or does it even make sense if there is no concept of linear change? The git environment seems a bit chaotic, and not conducive to close cooperation, from what I can see now. More experience with it may convince me otherwise. 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 Tue, Jan 12, 2016 at 2:22 AM, wrote:

Hi fellows,

I believe it is not a bad idea to move to https://github.com (the servers) and later on decide if move to use *git* (the CLI tool). This can an incremental way to do transition. And will allow really old fashion developers (those who refuse to learn *git*) or conservative policies to survive and still move to a new more reliable code repository.

Just my thoughts,

Greetings,

Luiso

*From:* [email protected] [mailto: [email protected]] *On Behalf Of * [email protected] *Sent:* 12 January 2016 09:56 *To:* [email protected] *Subject:* Re: [cctbxbb] Git

Dear Luc,

We actually had a look at the quality of the Github svn interface when we prepared for the DIALS move. My verdict was that it is surprisingly useful.

All the possible git operations are mapped rather well onto a linear SVN history. All the branches and tags are accessible either by checking out the root of the repository, ie.

svn co https://github.com/dials/dials.git (not recommended, as, say, any new branch/tag will probably result in a huge update operation for you)

or by checking them out directly, ie.

svn co https://github.com/dials/dials.git/branches/fix_export

or svn co https://github.com/dials/dials.git/tags/1.0

Forks by other people are, as is the case when using git, simply not visible. I agree that looking at the project history through SVN may not be as clear as the git history. I wonder how relevant this is though, as you can explore the history, without running any commands, on the Github website, eg. https://github.com/dials/dials/network, https://github.com/dials/dials/commits/master, etc.

Creating new branches and tags and merging stuff via SVN would be a major operation. However, that has always been the case with SVN, and for that reason one generally just does not do these things in SVN.

But for an SVN user group those operations would not be important – you every only need to merge stuff if you create branches – so I don’t really see the problem. If you want to tag releases you can do that on the Github website as well as with a git command.

In summary, I do recognize that SVN users will have difficulties participating in branched development, and in particular will not be able to quickly switch between branches.

But I don’t think that this will be a problem, or that there is a need for a policy to keep the history linear.

Best wishes

-Markus

*From:* [email protected] [ mailto:[email protected] ] *On Behalf Of *Luc Bourhis *Sent:* 11 January 2016 16:45 *To:* cctbx mailing list *Subject:* Re: [cctbxbb] Gi,

Hi Graeme,

Can we revisit the idea of moving to git for cctbx?

This brings to mind a question I have been asking myself since the subject has been brought forth. The idea Paul wrote about on this list was a move to Github. I guess some, perhaps many, developers will keep interacting with the repository using subversion. I am worried this would clash with the workflow of those of us who would go the native git way. By that I mean creating many branches and merge points, which one would merge into the official repository when ready. I am worried the history would look very opaque for the subversion users. I would even probably create a fork on Github, making it even more opaque for a tool like subversion. Has anybody thought about such issues? My preferred solution would be for everybody to move to git but I don’t think that’s realistic. At the other end of the spectrum, there is putting in place a policy to keep the history linear.

Best wishes,

Luc

--

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

--

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

Nick I offer an opinion here - git is like C++ - in the same way as Fortran 77 is like SVN. You can code fortran in any language syntax you like just fine. If you write it using C++ syntax you need to use g++ to compile it but that’s it. You can do that without using any C++ idioms. Or you can go the full monty and code with STL metaprogramming & such - much more complex and more powerful but not mandatory. You can use git like svn which works a bit better, that’s OK. It does not stop other people from using branches and such - you just run off the trunk like you do with SVN and let them get on with it. Every so often you will see a massive commit come in, from someone who did use git more powerfully, but that is no different to someone running over svn. What it does mean though is if you have a bunch of changes and one is a bug fix, you can easily cherry pick just the bug fix to push back for example, leaving the rest of the work in progress … in progress. I was that old fashioned developer Luis alluded to, I did not like it much when I started and now I find it *awesome* - you can commit as you go and only push when you are ready, which makes it really easy to keep your head clearer on big things Cheers Graeme On 12 Jan 2016, at 17:52, Nicholas Sauter mailto:[email protected]> wrote:

From the DIALS-West perspective, the switch to git has been a stumbling block to participation. I would have to agree with Ralf that git seems to be a tool for very smart people but not for folks who just want a simple tool for managing code.

I can't agree with Markus that a linear history is dispensable. In fact, this is one feature in svn that I've found very helpful over the years. If a feature is broken today, but I know for a fact that it worked sometime in the past, I simply do a svn update -r "[datestamp]" to narrow down the exact date when the feature became broken, then I isolate the exact commit and look at the code. Can this be done with git or does it even make sense if there is no concept of linear change? The git environment seems a bit chaotic, and not conducive to close cooperation, from what I can see now. More experience with it may convince me otherwise. 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 Tue, Jan 12, 2016 at 2:22 AM, mailto:[email protected]> wrote: Hi fellows, I believe it is not a bad idea to move to https://github.comhttps://github.com/ (the servers) and later on decide if move to use git (the CLI tool). This can an incremental way to do transition. And will allow really old fashion developers (those who refuse to learn git) or conservative policies to survive and still move to a new more reliable code repository. Just my thoughts, Greetings, Luiso From: [email protected]mailto:[email protected] [mailto:[email protected]mailto:[email protected]] On Behalf Of [email protected]mailto:[email protected] Sent: 12 January 2016 09:56 To: [email protected]mailto:[email protected] Subject: Re: [cctbxbb] Git Dear Luc, We actually had a look at the quality of the Github svn interface when we prepared for the DIALS move. My verdict was that it is surprisingly useful. All the possible git operations are mapped rather well onto a linear SVN history. All the branches and tags are accessible either by checking out the root of the repository, ie. svn co https://github.com/dials/dials.git (not recommended, as, say, any new branch/tag will probably result in a huge update operation for you) or by checking them out directly, ie. svn co https://github.com/dials/dials.git/branches/fix_export or svn co https://github.com/dials/dials.git/tags/1.0 Forks by other people are, as is the case when using git, simply not visible. I agree that looking at the project history through SVN may not be as clear as the git history. I wonder how relevant this is though, as you can explore the history, without running any commands, on the Github website, eg. https://github.com/dials/dials/network, https://github.com/dials/dials/commits/master, etc. Creating new branches and tags and merging stuff via SVN would be a major operation. However, that has always been the case with SVN, and for that reason one generally just does not do these things in SVN. But for an SVN user group those operations would not be important – you every only need to merge stuff if you create branches – so I don’t really see the problem. If you want to tag releases you can do that on the Github website as well as with a git command. In summary, I do recognize that SVN users will have difficulties participating in branched development, and in particular will not be able to quickly switch between branches. But I don’t think that this will be a problem, or that there is a need for a policy to keep the history linear. Best wishes -Markus From: [email protected]mailto:[email protected] [mailto:[email protected]] On Behalf Of Luc Bourhis Sent: 11 January 2016 16:45 To: cctbx mailing list Subject: Re: [cctbxbb] Gi, Hi Graeme, Can we revisit the idea of moving to git for cctbx? This brings to mind a question I have been asking myself since the subject has been brought forth. The idea Paul wrote about on this list was a move to Github. I guess some, perhaps many, developers will keep interacting with the repository using subversion. I am worried this would clash with the workflow of those of us who would go the native git way. By that I mean creating many branches and merge points, which one would merge into the official repository when ready. I am worried the history would look very opaque for the subversion users. I would even probably create a fork on Github, making it even more opaque for a tool like subversion. Has anybody thought about such issues? My preferred solution would be for everybody to move to git but I don’t think that’s realistic. At the other end of the spectrum, there is putting in place a policy to keep the history linear. Best wishes, Luc -- 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 -- 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]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb _______________________________________________ cctbxbb mailing list [email protected]mailto:[email protected] http://phenix-online.org/mailman/listinfo/cctbxbb

Luc, We discussed your "git add -p" suggestion in our group meeting just now, and nobody here could explain why the command would be "git add" rather than "git commit". So if you want to commit all of your changes at once you would use "git commit", but not "git add"? Or is "git add" mandatory anytime you want to commit any change and it is only the "-p" flag that is optional? The fact that we don't understand the paradigm and that we still have long discussions about syntax indicates to me that we are not ready for the switchover here at CCI. More discussion may serve to remedy this. 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 Tue, Jan 12, 2016 at 12:18 PM, Luc Bourhis wrote:

Another way to slice what Graeme has just written is that there are two orthogonal aspects to git: the delocalised, collaborative, multi-branching thingy on one hand and a better version control purely locally on the other hand. One can ignore completely the former and still ripe the benefits of the latter.

For example, let’s say you start to fix a bug and in the process you end up having to introduce new features and/or fix other things to make it work. After getting it all to work, you would really like to be able to split your changes in several commits, each concern with one feature/fix, even if some of these separate changes happened at different lines of the same file. With SVN, it’s so painful to do that most people will just commit it all in one commit. With ‘git add -p’, you can add chunk by chunk the changes related to each other to a first commit. Then proceed the same with a second commit. Etc. This is one of the feature which sold me on git.

Best wishes,

Luc

_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb

Great! Thanks, 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 Tue, Jan 12, 2016 at 12:45 PM, Luc Bourhis wrote:

...

We discussed your "git add -p" suggestion in our group meeting just now, and nobody here could explain why the command would be "git add" rather than "git commit". So if you want to commit all of your changes at once you would use "git commit", but not "git add"? Or is "git add" mandatory anytime you want to commit any change and it is only the "-p" flag that is optional?

git has the concept of the staging area which svn does not have:

- git add some_file.py will add the whole file to the staging area - git add -p will let you select which chunks go into the staging area

and you can mix and match those with different files at your heart content. When the staging area contains what you want in your commit, then you just do

git commit -m ‘your commit message’

and everything in the staging area will end up in that new commit.

But sometimes, you just want to commit a single file and then you can do the shortcut:

git commit -m ‘message’ your_file.py

which is equivalent to

git add your_file.py

followed by

git commit -m ‘message’

I hope this answers your question.

Luc

_______________________________________________ cctbxbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/cctbxbb

Hello everyone, Following up the earlier discussion, do have we reached a consensus? Also, I think timeframe has not been discussed, but I assume this will boil down to ‘after phenix release’ anyway. In the meantime I have contacted (nearly) all cctbx developers and obtained their github user-IDs - alongside some enthusiastic* feedback. I will mass-invite you all soonishly to a cctbx organisation with a preliminary git copy of the svn history to play with. Best wishes -Markus Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698 Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE * The best comment I received was ‘What’s CCTBX?’ – and that was talking to the correct person :) (name withheld) -- 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

Hi Paul, Thank you for the comments below Since much of the push for this is coming from the DIALS-East team, we will be happy to put together the solid plan you describe below - we can put together an initial sketch of the plan say as a google doc then circulate this for discussion. We'll try to get this done this week Thanks & best wishes Graeme -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Adams Sent: 02 July 2016 18:37 To: cctbx mailing list Subject: Re: [cctbxbb] Git Hi Everyone, I think there is general support for a move to git. It isn’t without some challenges, but I think we should do it, for future proofing if nothing else. Here is what I propose: - We need to articulate a plan for the transition. What steps will be undertaken, who will do what, what is the time line. I don’t want to make this complicated, but I’d be very nervous about undertaking this without a solid plan. Given the strong sentiments expressed on this list I’m sure there is no shortage of people interested in helping out. Can people can work together to formulate a plan? - Once we have a plan that is agreed upon, after the Phenix release we can start the process. I hope this puts the move to git about 1-2 months away. Cheers, Paul

On Jul 1, 2016, at 7:34 AM, [email protected] wrote:

Hello everyone,

Following up the earlier discussion, do have we reached a consensus?

Also, I think timeframe has not been discussed, but I assume this will boil down to ‘after phenix release’ anyway.

In the meantime I have contacted (nearly) all cctbx developers and obtained their github user-IDs - alongside some enthusiastic* feedback. I will mass-invite you all soonishly to a cctbx organisation with a preliminary git copy of the svn history to play with.

Best wishes -Markus

Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698

Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE

* The best comment I received was ‘What’s CCTBX?’ – and that was talking to the correct person :) (name withheld)

--

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

-- Paul Adams Division Director, Molecular Biophysics & Integrated Bioimaging, Lawrence Berkeley Lab Division Deputy for Biosciences, Advanced Light Source, Lawrence Berkeley Lab Adjunct Professor, Department of Bioengineering, U.C. Berkeley Vice President for Technology, the Joint BioEnergy Institute Laboratory Research Manager, ENIGMA Science Focus Area Building 33, Room 347 Building 80, Room 247 Building 978, Room 4126 Tel: 1-510-486-4225, Fax: 1-510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road BLDG 33R0345 Berkeley, CA 94720, USA. Executive Assistant: Louise Benvenue [ [email protected] ][ 1-510-495-2506 ] -- _______________________________________________ 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

Hi everyone, We have written up a plan at https://docs.google.com/document/d/1bTiGbnvw8lNUrBLbRmhEdnd22McDqBbiKxcpygaZ... feel free to comment on the document or here Best wishes -Markus ________________________________________ From: [email protected] [[email protected]] on behalf of [email protected] [[email protected]] Sent: Monday, July 04, 2016 08:00 To: [email protected] Subject: Re: [cctbxbb] Git Hi Paul, Thank you for the comments below Since much of the push for this is coming from the DIALS-East team, we will be happy to put together the solid plan you describe below - we can put together an initial sketch of the plan say as a google doc then circulate this for discussion. We'll try to get this done this week Thanks & best wishes Graeme -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Adams Sent: 02 July 2016 18:37 To: cctbx mailing list Subject: Re: [cctbxbb] Git Hi Everyone, I think there is general support for a move to git. It isn’t without some challenges, but I think we should do it, for future proofing if nothing else. Here is what I propose: - We need to articulate a plan for the transition. What steps will be undertaken, who will do what, what is the time line. I don’t want to make this complicated, but I’d be very nervous about undertaking this without a solid plan. Given the strong sentiments expressed on this list I’m sure there is no shortage of people interested in helping out. Can people can work together to formulate a plan? - Once we have a plan that is agreed upon, after the Phenix release we can start the process. I hope this puts the move to git about 1-2 months away. Cheers, Paul

On Jul 1, 2016, at 7:34 AM, [email protected] wrote:

Hello everyone,

Following up the earlier discussion, do have we reached a consensus?

Also, I think timeframe has not been discussed, but I assume this will boil down to ‘after phenix release’ anyway.

In the meantime I have contacted (nearly) all cctbx developers and obtained their github user-IDs - alongside some enthusiastic* feedback. I will mass-invite you all soonishly to a cctbx organisation with a preliminary git copy of the svn history to play with.

Best wishes -Markus

Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698

Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE

* The best comment I received was ‘What’s CCTBX?’ – and that was talking to the correct person :) (name withheld)

--

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

-- Paul Adams Division Director, Molecular Biophysics & Integrated Bioimaging, Lawrence Berkeley Lab Division Deputy for Biosciences, Advanced Light Source, Lawrence Berkeley Lab Adjunct Professor, Department of Bioengineering, U.C. Berkeley Vice President for Technology, the Joint BioEnergy Institute Laboratory Research Manager, ENIGMA Science Focus Area Building 33, Room 347 Building 80, Room 247 Building 978, Room 4126 Tel: 1-510-486-4225, Fax: 1-510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road BLDG 33R0345 Berkeley, CA 94720, USA. Executive Assistant: Louise Benvenue [ [email protected] ][ 1-510-495-2506 ] -- _______________________________________________ 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