On Tue, Jun 3, 2014 at 6:42 PM, Nico Williams <n...@cryptonector.com> wrote:
> However, a git->Fossil->git doesn't produce the same commit hashes. > It seems like it ought to be possible to reproduce the exact same > commits, therefore the exact same commit hashes. > Looking at the very first commit in a test run of a git->Fossil->git > conversion, the only differences are: > > - the commit author information (Fossil loses the comment part of the > author's RFC5322 email address) > - the date (Fossil changes the timezone to +0000, that is, it loses > the timezone of the original). > The date conversion is very problematic for round-trip fidelity. When developing libfossil, one of the initial test challenges was to make sure libfossil has 100% fidelity with fossil in terms of manifest generation. It turns out that it's impossible to convert the timestamps to and from Julian Days with 100% fidelity all of the time. i spent a great deal of time finding conversion tweaks and "acceptable" difference rates for the general case, but my current tests (run across the 1645 current event table entries in libfossil) have 1ms precision differences in 4 records (0.24%) when converting those timestamps round-trip (from Julian to RFC8601, then back to Julian). My point being: at least some small percentage of round-trip timestamp conversions will fail because Julian Days to not have a 1-to-1 mapping for all millisecond-level ranges in use today. I'm guessing there will be other minor differences in, for example, > merge commits, but first things first... > ANY difference results in a different hash, so the email change is enough (regardless of all my blather about timestamp precision changes). > Two ideas occur for fixing this: either add metadata so that Fossil > can reproduce git commits exactly, or store the commit headers as-is > in Fossil along with Fossil's parsed metadata from the same. The > latter will work better, but seems like a hack. The former might > prove to be a lengthy iterative process and may be git version > sensitive. > FWIW: Fossil was never intended to be a round-trip safety hatch for other SCMs which aren't as data-robust. Maybe convince the git developers to move their metadata into sqlite instead? -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
