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" <[email protected]> To: <[email protected]> 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 ideas, > 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 files. > 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 existing > 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 more, > 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 <[email protected]>: >> Hi! >> >> Germán Arduino wrote: >>> Hi Göran: >>> >>> Sorry by my intromision here, but want to say somethings :) >>> >>> 2010/2/23 Göran Krampe <[email protected] <mailto:[email protected]>> >> [SNIP] >>> What I have seen so far in Metacello is indeed nothing new - the >>> senarios and discussions about dependencies etc go loooong way back. >>> >>> >>> I'm on Squeak from old 3.2 times. And yes, a lot of discussions about >>> packages, >>> etc, but only discussions on most of cases. I think Metacello solves the >>> dependencies >>> questions very well and the other tools not (with exception of Universes >>> probably, but >>> abandoned now). Also Metacello provides all the features explained on >>> the excellent >>> mail of Torsten, assuring that the configurations will work with the >>> time not breaking >>> stuffs. >>> >>> The solution of using Metacello+Monticello is, imho, very simple, easy >>> 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. >> >> [SNIP] >>> 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 EXACTLY >>> this problem (fork interchange), and it was born in 2007: >>> >>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-August/119471.html >>> >>> 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 important >>> 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 wanted >> to mention it. But AFAIK there is no other tool/project aimed at that >> use case. Again, I may be wrong :) >> >> regards, Göran >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
