[Openmcl-devel] How about Git?

[Gary Byers]

On 11/30/2015 08:29 AM, Stelian Ionescu wrote:
> If you want to keep the master copy in SNV and mirror to git, SubGit 
> can do that but mapping externals to submodules is not supported: 
> http://www.subgit.com/remote-book.html chapter 9.
> If you want to keep the master copy in git and access it through SVN, 
> Github supports that: 
> https://help.github.com/articles/support-for-subversion-clients/. 
> Again, mapping submodules to externals is not supported.
> That said, as far as I understand it, there are two reasons why 
> binaries are bundles with the sources:
> 1) for easy distribution of released binaries together with the code 
> so that those who only use releases can also M-. (or equivalent) 
> without hassles.
> 2) for easy bootstrap because of compiler and/or ABI(such as fasl 
> format) changes within a release.

Several years ago this was essentially how CCL was distributed - one 
checked out sources from CVS and a
a matching tarball via FTP or equivalent, and that was it.  At the time, 
there were two possible choice of
tarballs., one for 32-bit PPC Linux and another for 32-bit PPC Darwin.

Some of the smartest people that I've ever known were very confused by 
this, and I think that having
a single way for users to obtain a consistent set of sources and 
binaries is very important.  SVN offers
this via "external properties", which are otherwise a mess.  If Git does 
as well, I have not seen anyone
describe the mechanism.

I don't otherwise care whether one uses "svn co something" or "git clone 
something", but I would
not want to expect users to have to revert back to what didn't work well 
long ago.

> These two issues can be solved by bundling all release binaries into a 
> single tarball, and ensuring that during the development phase the 
> compiler can always be easily bootstrapped from the previous released 
> binaries. This second part, though, I'm unsure how difficult it is.
> All of it makes sense thinking about only if there's the feeling that 
> git is worth it. In my little world, I have so much tooling around 
> git, including the wonderful Magit client for Emacs, that unless I'm 
> really determined I don't contribute to non-Git projects any more, 
> except for maybe opening bugs.
> >
>> note that there are technical solutions that  allow bi-directional 
>> mirroring
>> between svn and git, and if I understand correctly at least one of 
>> them is
>> free (as in beer) for open-source projects.  see www.subgit.com 
>> <http://www.subgit.com>.
>> I am personally very skeptical that switching from svn to git would 
>> solve more problems
>> than it would introduce, but I may be mistaken about that.  Clozure's 
>> policy has generally
>> been to give svn commit access to anyone who asks for it, but I don't 
>> think that too many
>> people have asked.  I don't think that the current system is ideal by 
>> any means, and I don't
>> object to anything that would make CCL easier for more people to use 
>> and contribute to.  Why would I?
>> It's a slightly different issue, but the fact that Linux itself uses 
>> git does not mean that
>> everyone has to deal with constant chaos (aside from the usual chaos 
>> of Linux itself ...)
>> I don't know that we would be any more or less responsive to git pull 
>> requests than
>> we are to Trac tickets.
>> I agree that "switching to git" would likely only be successful for 
>> anyone
>> if Clozure was actively involved in some way.  my own scepticism is 
>> (I think)
>> based on technical concerns.  I don't -think- that anyone at Clozure 
>> objects
>> to the idea because we want to retain svn out of love for svn or out of
>> a desire to hoard code which is freely available.  If someone wants 
>> to import
>> the svn repository into git, nothing is stopping them and if they do 
>> so in a
>> way that deals with binaries and sources in a reasonable way that would
>> help to allay a lot of my scepticism.  That's not the last step, but 
>> it would
>> likely be a good first step.
>> On 11/29/2015 10:48 PM, Ron Garret wrote:
>>> On Nov 29, 2015, at 8:39 PM, Gary Byers <gb at clozure.com 
>>> <mailto:gb at clozure.com>> wrote:
>>>> If anyone wants to import the CCL svn repository into git and host 
>>>> it on github,
>>>> what exactly is stopping them ?
>>>> If there is some answer to that question - other than the fact that 
>>>> no one has
>>>> time or sees a clear benefit to doing so that would justify the 
>>>> disruption that
>>>> it would likely cause - I haven't heard it, and if there is some 
>>>> technical reason
>>>> I can't think of it.
>>>> see https://help.github.com/articles/importing-from-subversion/, 
>>>> and the url
>>>> that that the tool referenced on that page wants is likely 
>>>> <http://svn.clozure.com/publicsvn/openmcl/> 
>>>> <http://svn.clozure.com/publicsvn/openmcl/>
>>>> Thanks for volunteering.  Good luck, and please let us know how you 
>>>> dealt with the issues that some people were trying to
>>>> discuss.
>>> The problem is not importing the current SVN repo into Git.  The 
>>> problem is the on-going work of keeping the git repo up to date if 
>>> the “official” repo (i.e. the one that you’re checking changes into) 
>>> is still in SVN, and also the problem of pulling changes in the git 
>>> repo (if there are any, and there might be because github pull 
>>> requests are pretty handy) back into the “official” SVN repo. 
>>>  Otherwise CCL will fork, and that’s probably not a good thing.
>>> For this reason it would be very helpful to have Clozure Associates’ 
>>> official blessing for switching to git, assuming such a thing were 
>>> in fact desirable.  I’m a git fan, but since CA is still doing the 
>>> lion’s share of the work I think this ought to be entirely CA's call.
>>> rg
>> _________________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>> https://lists.clozure.com/mailman/listinfo/openmcl-devel
> --
> Stelian Ionescu a.k.a. fe[nl]ix
> Quidquid latine dictum sit, altum videtur.
> http://common-lisp.net/project/iolib

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20151130/95db1586/attachment.htm>