Igor, Otto's filetree stores monticello package meta data in the repository as well ... the basic model is to store the Monticello meta data ... having spent the last two days developing with filetree I have noticed an interesting side effect of storing meta data and source ... when you merge (using the git level merge) you end up having to resolve conflicts in the meta data and the source code ... I assume that this is a solvable problem (maybe even git has an answer?), but it is worth considering ... Another thing to consider with meta data is that with a file-based system folks will very likely do edits to the source files directly including potentially the meta data files .... like a said, maybe git has a way to hide meta data files from mere mortals, but if not one must be a bit careful... Dale ----- Original Message ----- | From: "Igor Stasenko" <siguctua@gmail.com> | To: Pharo-project@lists.gforge.inria.fr | Sent: Wednesday, February 1, 2012 7:20:12 AM | Subject: Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only? | | On 1 February 2012 16:12, Frank Shearar <frank.shearar@gmail.com> | wrote: | > On 1 February 2012 14:44, Damien Pollet <damien.pollet@gmail.com> | > wrote: | >> On 31 January 2012 15:59, Otto Behrens <otto@finworks.biz> wrote: | >>> I was wondering more if it is possible to do without having a | >>> file | >>> system checkout of the class definition. In other words, if the | >>> class | >>> definition in the image could serve as the working copy of the | >>> object | >>> in the git repository. I must read more on what the other guys | >>> did | >>> with the git interfaces (such as gitfs and gitosis) to understand | >>> what | >>> it comes down to. | >>> | >>> If this is possible, it would make merging, loading and | >>> committing | >>> essentially one step. | >> | >> Have you seen what Camillo did? | >> http://www.squeaksource.com/FSGit | >> https://github.com/dh83/fs-git-test | >> | >> Note the layout with class comment in a README file, etc :) | > | > That is _exactly_ the right thing to do! Bravo, Camillo! Also note | > how | > Nested-Package-Names end up looking like you might expect. | > | > Is there any necessity for storing a chunk? For instance in | > https://github.com/dh83/fs-git-test/blob/master/AAA/AAA.class/instance-side/... | > we have | > | > !AAA methodsFor: 'as yet unclassified' stamp: 'CamilloBruni | > 1/23/2012 19:15'! | > a | > Â Â Â Â | a | | > Â Â Â Â ^ a! ! | > | > with the ugly chunk !s. The only thing we can't directly regenerate | > is | > the timestamp: modulo that, we know the class name, the category | > (the | > name of the directory you're in), the author (from the author of | > the | > git commit). You'd have a disconnect between the git commit time | > and | > the time in the chunk which would, IIRC, be the time you hit Alt-S | > in | > your browser? Or would that be file-out time, which would likely | > then | > be the timestamp in the git commit? | > | | Good question, Frank. | But i want to go even further by saying: | why we cannot associate an arbitrary meta-information per method and | store it along with method? | | Today we storing the category, author and stamp. | Tomorrow we may want to add something more (link to documentation, | link to previous version etc etc) | And i think , at least in GitFS Camillo can do it pretty easy. | If you have 1 file per method, make 2 files per method, i.e.: | | methodname.st | methodname.meta | | and in meta, we can store everything we want in a form we want. while | .st is for storing purely smalltalk source code, and nothing else. | | -- | Best regards, | Igor Stasenko. | |