[Openmcl-devel] making a git mirror of ccl

[mikel evins]

> On Dec 17, 2015, at 8:42 PM, Robert P. Goldman <rpgoldman at sift.info> wrote:
> 
> On 12/17/15 Dec 17 -6:04 PM, mikel evins wrote:
>> 
>>> On Dec 17, 2015, at 5:58 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>>> 
>>> If we were ever to convert completely to git, I would suppose that we'd want to maintain some sort of similar setup.
>> 
>> A very common git workflow is sort of the opposite: the master branch contains tested, vetted, working code, and another branch contains code being tested before merging it with the master. Branches are extremely cheap and fast to create and merge in git, and so it’s also very common for each dev to work on a distinct branch or, in fat, a collection of branches. It’s fairly usual to have one branch per feature being worked on, and for such branches to live only long enough for the feature in question to be developed and merged with the release.
> 
> That's really a "release-free" model, actually, where "master" == "release".
> 
> The branches that Mikel refers to are short-lived, "topic" branches, not
> long-lived release/maintenance branches.
> 
> But in the case where you have a stable system that people rely on, like
> CCL, you typically wish to have at least a "release" branch that
> corresponds to the publicly released/shipped version.
> 
> And if people are depending on the released version, you may wish to add
> patches to the released version at the same time that you are preparing
> the next release.  In this case you will have two different tips of the
> git graph.  This would be like maintaining "stable" and "testing"
> simultaneously.
> 
> IIUC, SBCL does not have this behavior, and behaves as Mikel describes:
> there's only one head, and a last release tag.  AFAICT, releases are
> never patched as such (i.e., there's no "stable"), just tagged.  If
> there's a bug in the latest 1.n.x it seems like you can either grab a
> patch off head or wait for 1.n.x+1.  I don't believe they ever repair
> 1.n.x while preparing 1.n.x+1.
> 
> Put differently, the model Mikel's describing has release *tags* but not
> really release *branches*.
> 
> I believe that CCL has always had release *branches*, and I actually
> think that's a good thing, and there's no need to give it up when moving
> to git.


You’re right, of course. Thanks for expanding on the different models.

It may seem like I’m advocating a switch to git. I’m not. I’ve had mostly good experiences with it (and a couple of bad ones). It’s fast and flexible, and it enables me to continue using version control without interruption even if the net is down or inaccessible. But there are sensible reasons not to switch to Subversion, the most straightforward of which is that it works. If it ain’t broke, don’t fix it. Subversion also handles binaries better than git, especially large binaries that change often (which git handles very badly).

On the other hand, about the only downside I can see to providing a Github mirror of CCL is that somebody has to set it up and tend to it. Because of the way that CCL uses externals and binaries, that could be more work than it sounds like. If it works, though, in return CCL becomes much more accessible to more people. If a way can be found to easily migrate pull requests from Github to the master repo, exposing CCL on Github also makes it easier for more people to contribute to CCL.