markus.gerstel at diamond.ac.uk
markus.gerstel at diamond.ac.uk
Tue Jan 12 01:55:36 PST 2016
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.
From: cctbxbb-bounces at phenix-online.org [mailto:cctbxbb-bounces at phenix-online.org] On Behalf Of Luc Bourhis
Sent: 11 January 2016 16:45
To: cctbx mailing list
Subject: Re: [cctbxbb] Gi,
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cctbxbb