On Thu, Jan 28, 2016 at 9:41 AM, Ben Coman <[email protected]> wrote:
> > > On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs < > [email protected]> 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. > > [1] https://git-scm.com/book/en/v1/Git-Internals-Plumbing-and-Porcelain > [2] https://git-scm.com/book/en/v1/Git-Internals > [3] https://git-scm.com/book/en/v1/Git-Internals-Git-Objects > [4] http://ericsink.com/vcbe/html/repository_structure.html > [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 >> > >
