On 01/27/2016 06:01 PM, Ben Coman wrote:
On Thu, Jan 28, 2016 at 9:41 AM, Ben Coman <[email protected]
<mailto:[email protected]>> wrote:
On Thu, Jan 28, 2016 at 5:03 AM, Dale Henrichs
<[email protected]
<mailto:[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?)
Yes I read the paper on "An Abstraction for Version Control Systems"[1]
and if I recall correctly SVN is lacking in a few of the features that
had to be "simulated" ... so an abstraction layer that did not have to
"fake features out" makes a lot of sense ... with that said, it also
makes a lot of sense to not exclude SVN, so an abstraction layer that
had provision for unsupported features would be useful ...
Dale
[1]
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjotZ6SmM3KAhVH2mMKHSItBSEQFggjMAA&url=https%3A%2F%2Fpublishup.uni-potsdam.de%2Ffiles%2F5708%2Ftbhpi54.pdf&usg=AFQjCNF6aORe6AHsTr0mrIMe1QueECxgKw
