On 01/21/2011 01:28 PM, Miguel Cobá wrote:
El vie, 21-01-2011 a las 13:10 -0800, Dale Henrichs escribió:
Miguel,
A timestamp isn't sufficient in the presence of branching. How do other
SCMs identify branches?
I am not an expert, for sure :), but the way Git works AFAICT is by
storing in files the SHA1 hash of all the branches heads reachable.
That is, if you don't have a pointer to the head of a branch you can't
reach the branch, even if the commit is there.
Git also stores a history of the last n branches you have visited in
case you by accident delete the file containing the pointer to a branch
head.
So the metadata of git (.git/ folder) has all this information.
when rebuilding branches histories (and for merging) git traverses the
list of parents of two branches until find two commits with the same id
(SHA1) and from there it can do the merge. But as I said, this is
metadata and the commit has no way of knowing to which branch it
belongs. The commit only know the blog of changes, the author, timestamp
and parent(s) commits (if was a merge).
This is different that monticello where, appears to me, the commit (.mcz
file) encodes the author, branch, version number and package name.
In git, there are only blobs that have a defined structure and are named
just with the SHA1 hash of the bytes changed in that commit.
For more info (very readable) check:
http://progit.org/book/ch3-1.html
http://progit.org/book/ch9-0.html
Thanks Miguel,
Thats interesting.
Actually, the mcz file itself has all of the meta data embedded in
it...full history, including UUIDs for each of the versions...the meta
information has been encoded into the mcz file name to make it easy for
humans and tools to guess what the meta data is (and 99% of the time the
mcz file name and meta data match:)
Without info encoded in the mcz file name, the tools have to crack open
every one of the mcz files in a repository in order to build the real
version structure...
Presumably a new version of SqueakSource could maintain separate
metadata files and then in-image tools could use that metadata to
present the mcz files in a coherent manner ... then there would be no
need to care what the mcz file was named, the UUID would probably be
sufficient...
Dale
