On Dec 21, 2009, at 10:15 AM, [email protected] wrote:
> > Sorry I am a newbie for fossil; until now I have used git and > mercurial. > > I have a doubt regarding the sentence: > > "A fossil repository is a 'unordered bag' of artifacts". This statement is correct - but you have to understand it in the right context. The repository synchronization mechanism of fossil considers the artifacts to be unordered. When you do [fossil sync] (or [fossil pull] or [fossil push] or [fossil clone]) the synchronization logic shares artifacts between the local repository and the remote repository and that synchronization logic knows nothing about graphs and relationships between artifacts. (Well, *almost* nothing. There is the issue of the "cluster" artifact, but if you are trying to understand how fossil works, you can ignore clusters to a first approximation - clusters are only there as a performance optimization.) After two repositories sync, each repository looks at its artifacts and builds "graphs" of relationships between artifacts. But a key feature of Fossil is that this graphs can be reconstructed at any time by reexamining the raw artifacts, in any order. When you do [fossil rebuild], it does exactly that: [fossil rebuild] throws out all its old graphs, then rereads all of the artifacts and reconstructs all of the graphs from scratch based on information in the artifacts. I'm not an expert on the internal operation of git and hg, but I believe the behavior described above is a fundamental difference between Fossil and the others. In git and hg, the graph is part of the primary state of the repository. But in Fossil, the graph is derived from the unordered bag of artifacts and can be completely reconstructed from the artifacts on demand. The graph is secondary information that is derived from the primary information which is contained in the artifacts. There are pluses and minuses to the Fossil approach. On the plus side, it makes the synchronization protocol simple and efficient and it allows us to synchronize tickets and wiki transparently together with versions. On the minus side, because the graph is not part of the primary data, Fossil does not have the ability to sync just one particular branch, since the sync logic has no knowledge of the graph. > > In mercurial and in git the emphasys is on the "graph" > concept... every object (for example in git a commit or a blob or a > tag) is related to others... > > In any case also in fossil an artifact is related to others... so for > me (sorry for the naive question) in any case also in fossil we have a > graph, only that it is "hidden" inside the artifact format and not > "external" in the repository "metadata". > > Could it be correct as a comment? > > Lino > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
