On Thu, 01 Feb 2007 00:00:00 +0100, Matt Mackall wrote: > On Thu, Feb 01, 2007 at 12:58:42AM +0100, Jakub Narebski wrote: >> Matt Mackall wrote: >> On the other hand hg repository structure (namely log like append changelog >> / revlog to store commits) makes it I think hard to have multiple persistent >> branches. > > Not sure why you think that. There are some difficulties here, but > they're mostly owing to the fact that we've always emphasized the one > branch per repo approach as being the most user-friendly. Well, perhaps I should say that append-log changelog / revlog[*1*] structure to store commits makes it natural to have one branch per repository, as branch (in the lineage of given commit meaning, i.e. all commits which are ancestors of given commit) is roughly equivalent to changelog / revlog and branch tip (latest commit on a branch) is top commit (latest entry) in changelog / revlog. In git, with its DAG (direct acyclic graph) of commits and branch tip as a moving pointer (top of stack pointer like moving) to a commit in DAG makes it natural to have multiple branches in a repository (current branch is branch pointed by HEAD, another pointer - to branch this time[*2*]). Perhaps multiple branch repository makes learning curve a bit steeper, but also encourages using temporary branches and topic branches, which makes _development_ (as opposed to using version control tool) more (power)user-friendly; and makes SCM more powerfull. How Mercurial solves problem of multiple _persistent_ branches? Does it add pointers to commits somewhere deeper in changelog / revlog? BTW does Mercurial have tags? >>> In either case, both provide strong integrity checks with recursive >>> SHA1 hashing, zlib CRCs, and GPG signatures (as well as distributed >>> "back-up"!) so this is largely a non-issue relative to traditional >>> systems. >> >> Integrity checks can tell you that repository is corrupted, but it would >> be better if it didn't get corrupted in first place. > > Obviously. Hence our append-only design. Data that's written to a repo > is never rewritten, which minimizes exposure to software bugs and I/O > errors. By the way, RCS / CVS rewrote relevant data (to have diff from the top structure) on each commit. I wonder if git could generate pack on the fly fastimport like... >> Besides: zlib CRC for Mercurial? I thought that hg didn't compress the >> data, only delta chain store it? > > We use zlib compression of deltas and have since April 6, 2005. Nice to know. You compress only file deltas, or also file revision metadata? Do you compress manifests (trees) and commits (or at least commit messages) too? Footnotes: ---------- [*1*] I don't know what nomenclature Mercurial uses for blobs (file contents), trees (directory contents) and commits (revision contents) storage. [*2*] I disregard here latest work on "detached HEAD" in git. -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html