On Thu, Jan 28, 2016 at 9:41 AM, Ben Coman <btc@openinworld.com> wrote:


On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs <dale.henrichs@gemtalksystems.com> wrote:
The git repository is not tightly coupled to the image like the changes file (you can delete a git repository without impacting the functionality of an image), but if you are making changes in the image, then you _are_ coupled to a particular git commit identified by its SHA.

Metacello will record the SHA of the git repository at the time that packages are loaded from a git repository (to enable this feature in Pharo, some methods need to be implemented in the MetacelloPlatform for Pharo) and this information is stored along with the Metacello registration for the project.

Since the git repository can be independently manipulated from the shell or an image can be saved that references a SHA that is no longer "current" .... it is very important that the SHA be recorded and made visible to users via the tools.

By "current", do you mean the currently checked out directory as seen from the shell command line?

Slightly off topic...
I wonder if we could avoid needing a currently checked out directory as seen from the command line and have the Image work directly with the git repository (within the .git folder - is this what libgit integration may give us?) thus making the Image the equivalent of the current checked out directory?�� Then lets dump the .changes file by... rather than a method's source reference being a (fragile) hardcoded index into the .changes file, make each method an SHA key into the git (or mercurial) repository. ��
* Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it. You���ll learn more about what this means in a bit. [2]
* Git is a simple key-value data store. You can insert any kind of content into it, and it will give you back a key that you can use to retrieve the content again at any time. [3]
* [In Mercurial...] each revision of a file is identified by a 'NodeID', which is a SHA hash of its contents (combined with the position of that node in the history). [4]

*��The baseline data structures for Fossil and Git are the same (modulo formatting details). Both systems store check-ins as immutable objects referencing their immediate ancestors and named by their SHA1 hash. [5]

So to firm up this idea, while we might not want to tie ourselves too tightly to git, rather than try working with *all* types of source code management, would it be reasonable to concentrate on an abstraction layer focused on *content-addressable* source code? That is, would this provide flexibility for sufficient backend options, but a better experience with those than a totally generic source code management. (btw, Could EPICEA be made to work with SHAs?)

cheers -ben

��

In short, should our source code indexing be "content-addressable" with the possibility to use *any* key-value repository.�� Each method SHA would be calculated from its own source code and parent class SHA.�� Each class would calculate its SHA from its definition and superclass' SHA.�� A package/project SHA would be calculated from all its component class and method SHAs.


[5] http://fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki
��

cheer -ben

��
Soooo --- managing skew is an important function for the "project browser"... Here's what the tODE "Project Browser" looks like when version skew is detected:

In this I assume the red ones are skewed and the X ^ Y represent commits, but could you explain which ones.
��
��
Well I think that's enough for now...Here are some topics that I plan to cover in future posts:
�� - what has to be done to get the initial clone and hook it into an image?
�� - sharing git repos between separate "active images"
�� - cloning a github:// repos?
�� - ssh vs https clones
�� - working with remotes

Dale

[1] https://github.com/dalehenrich/tode
[2] https://github.com/GsDevKit/GsDevKit_home
[3] https://github.com/dalehenrich/metacello-work
[4] https://github.com/dalehenrich/filetree