Hi Luc, As a lone developer this would make a lot of sense - however I'm working with others on these projects so it would be a pain to go this way. However, a corollary of this is that it would be neat to be using a distributed system - is there any scope for doing that? I suspect in the meantime a couple of well defined branches (with clearly defined merge points) would work OK… Thanks, Graeme On 20 Apr 2012, at 13:27, Luc Bourhis wrote:

Hi Graeme,

...

Quick question - does anyone ever use branches with the CCTBX repository? Just at the moment I'm up to a few things which I would like to be able to commit, but I don't want to break the existing code... however as a project it does not seem CCTBX uses branches much...

There are 2 reasons for branches not being used much: (a) subversion branches used to be very difficult to use correctly and even nowadays I would not rule out there are still dark corners when it comes to merging (b) cctbx developers, and especially our beloved overseer for life, is fairly tolerant with *temporary* breakages: as long as you announce coming commits as potentially dangerous, and you have tested at least on one of the Linux test machine, and you fix any problem within a few days, then we will be more than happy to cope. However, if you envision that your coding adventures are going to span several dozen commits, a good fraction of which you may eventually throw away, then, the trunk may not be the right place to work. If you are unsure, feel free to discuss the matter here or directly with our beloved overseer for life.

My personal solution to this problem is to keep a local git mirror of the subversion repository on my machine and to heavily use branches in there. In my humble opinion, this is a superior solution because git is so much better at branching and merging than subversion. Eventually I may end up pushing several dozen of commits to sourceforge in one go because I have tested on a handful of machines, using git to keep it all in sync. this is far superior a working pattern than using subversion. Note that you could substitute mercurial instead of git in that paragraph of mine without changing the conclusions.

Best wishes,

Luc

_______________________________________________ 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 Luc, OK, what you say makes sense. I wonder how hard it would be to set up a git hub mirror of this? It would make sense to do it once rather than O(n) times. I am biased to using git as there's a number of git experts sitting within a few metres of me here... However I would think this is not something to do later on on a Friday afternoon :o) Thanks, Graeme On 20 Apr 2012, at 15:49, Luc Bourhis wrote: As a lone developer this would make a lot of sense - however I'm working with others on these projects so it would be a pain to go this way. I beg to differ. You and your collaborators could work together on a distributed git repo mirroring sourceforge on the master branch. You would do your collaborative work on various development branches. Someone would finally be responsible to merge the relevant branch to the master branch and then to push the changes to sourceforge. Again feel free to substitute mercurial instead of git. However, a corollary of this is that it would be neat to be using a distributed system - is there any scope for doing that? Our beloved overseer for life is not interested to switch away from subversion but it is very all too easy to create a mirror, as I did. Since I am the only person who has seemed motivated by git so far, I haven't made my git repo public but if you are interested I could push it to GitHub (I could also give you access to my computer but since I work from home, it would not be so reliable network-wise as I have got a rather hopeless ADSL at the moment). I may even be possible to put a post-commit hook on sourceforge to automatically push any new commit onto that would-be GitHub repo. 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

Hi Ralf,

I'm using git a little bit, too, when I'm traveling. I really like the GitHub mirror idea but don't have the free cycles to establish and maintain it myself. But I'd be happy to support someone else taking the lead on this.

Sourceforge does still not provide post-commit hooks for subversion. But it would be easy to put a crontab on the CCI machine phenix-online, that would periodically update from sourceforge and then push to GitHub. I'd be more than happy to take charge here. In fact I have already considered establishing the cctbx on GitHub several times. Luc

...

it would be easy to put a crontab on the CCI machine phenix-online, that would periodically update from sourceforge and then push to GitHub.

Or maybe we could setup a mail account that receives the commit messages which then triggers the git sync? Ralf

We first need to clarify what we want the GitHub repo to be for. Two choices here as I see it: (a) a repo that would fit in the git culture: git afficionados would fork it, do their own development and then send pull notification to us, never using "git svn"; (b) a repo whose sole purpose would be to spare the long time necessary to run "git svn clone" in the first place: users of that repo would share their development with us solely through "git svn dcommit". I had obviously (b) in mind, hence my not being concerned with a slight lag between sourceforge and GitHub. If option (a) is our goal, then not only the lag shall be minimised but the "master" branch of the GitHub repository should be "dcommited" periodically to sourceforge. And of course, we need a clear policy to deal with those pull requests. That option (b) would be an alternative to give commit rights to sourceforge to "casual" cctbx developers. Thanks to git, it would be easy to checkout and then evaluate their proposed pull, then giving the green light at the press of a button. As usual with git, it's another world entirely… Luc