[Pharo-project] Source code management - my vision. (Was: Re: Why apackage management system)
alexandre at bergel.eu
Tue Feb 23 16:11:40 EST 2010
Doru did some experiement with Mondrian I believe.
On 23 Feb 2010, at 13:25, Gary Chambers wrote:
> Some kind of graph-based GUI would certainly help in this scenario to
> visualise the dependencies/changes... just a thought.
> Regards, Gary
> ----- Original Message -----
> From: "Igor Stasenko" <siguctua at gmail.com>
> To: <Pharo-project at lists.gforge.inria.fr>
> Sent: Tuesday, February 23, 2010 4:02 PM
> Subject: [Pharo-project] Source code management - my vision. (Was:
> Re: Why
> apackage management system)
>> Since Goran mentioned DeltaStreams, i'd like to share one of my
>> which came into my mind, when i complete coding the method trailers.
>> I made a method trailers open for future extensions.
>> A first step would be to introduce an abstract 'source management'
>> layer, which will be responsible for delivering
>> a method's and classes sources from some abstract data source. The
>> next step is actually implement such data sources.
>> So, the idea is to abandon hardwiring with .sources and .changes
>> What new opportunities it gives to us?
>> Suppose that instead of storing sources into file, you putting them
>> directly to database , such as CouchDB (yes! :).
>> Now if you imagine that anyone could access to this database on some
>> public location, this means that we automagically made a source code
>> exchange hub, and could do a very cool things with it.
>> Suppose that ALL source code is put into a single database. Now
>> different users creating own accounts and makind own 'forks' from
>> original. What we getting is a number of update streams (methods,
>> doits etc etc), which lying in those databases,
>> and if one user wants to load/merge code from one of the sources he
>> simply points to it and it get loaded into his image.
>> We could organize things very closely to what github currently is:
>> everyone could create any number of new projects, or forks of
>> ones. Freely exchange the code, do a cherry picking etc etc.
>> And what is most important, that with such organization you can track
>> any methods, classes in the image and their evolutionary history back
>> to its origin. As well as, you can query database, how an when a
>> concrete method/class get deleted (everything is recorded, not just
>> current state).
>> Also, it would allow us to manipulate the code at the lowest level of
>> granularity (individual methods/classes/doits, same as DS does), not
>> at a package level.
>> There are a lot of synergy with DeltaStreams - it could serve as an
>> 'offline' format, in same way as git storing the files locally, but
>> can reconnect with remote storage (which can be a public database).
>> One of the things, which could be made is to allow stashing/popping
>> code from stash. Suppose two projects started from a single starting
>> point (Squeak 3.9). Now suppose that by clicking a single button you
>> could get either trunk image, or Pharo 1.0 image.
>> But that's not all! With DeltaStreams, you could then click once
>> and revert things back from , say Pharo 1.0 to trunk or vice versa :)
>> Of course it would be stupid to do things at such large scale, but if
>> we put some common 'root' stuff into database, then we could very
>> easily track all changes & compare them. This would make cherry
>> picking and code exchange much more easier.
>> This could get us on the next level of code management and system
>> organization and organization of community efforts.
>> 2010/2/23 Göran Krampe <goran at krampe.se>:
>>> Germán Arduino wrote:
>>>> Hi Göran:
>>>> Sorry by my intromision here, but want to say somethings :)
>>>> 2010/2/23 Göran Krampe <goran at krampe.se <mailto:goran at krampe.se>>
>>>> What I have seen so far in Metacello is indeed nothing new - the
>>>> senarios and discussions about dependencies etc go loooong way
>>>> I'm on Squeak from old 3.2 times. And yes, a lot of discussions
>>>> etc, but only discussions on most of cases. I think Metacello
>>>> solves the
>>>> questions very well and the other tools not (with exception of
>>>> probably, but
>>>> abandoned now). Also Metacello provides all the features
>>>> explained on
>>>> the excellent
>>>> mail of Torsten, assuring that the configurations will work with
>>>> time not breaking
>>>> The solution of using Metacello+Monticello is, imho, very simple,
>>>> and productive
>>>> and is here, available to us. :)
>>> I never claimed otherwise! I am just saying that there is nothing
>>> new -
>>> and frankly, though I admit not having read carefully, I didn't
>>> find the
>>> example so... impressive. Perhaps I need to read it again.
>>> Again though - I am not saying anything negative about Metacello.
>>>> Anyway, "common exchange mechanism" - I am working on
>>>> Deltastreams which
>>>> I even presented at Brest, though unfortunately colliding with the
>>>> Seaside tutorial. Deltas and Deltastreams are indeed focused on
>>>> this problem (fork interchange), and it was born in 2007:
>>>> I and Igor are the ones working on it - and after Brest we have
>>>> had very
>>>> little time to move it forward. I still think it is a very
>>>> piece of the puzzle though.
>>>> But Deltastreams are ready to use on production systems?
>>> Nope, not yet, although very close. But since the topic came up I
>>> to mention it. But AFAIK there is no other tool/project aimed at
>>> use case. Again, I may be wrong :)
>>> regards, Göran
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>> Best regards,
>> Igor Stasenko AKA sig.
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Alexandre Bergel http://www.bergel.eu
More information about the Pharo-dev