This isn't really baked yet, but I'm off on holiday tomorrow and when I get back I start a (highly prestigious!) new job, so I won't be able to touch this for a while.
fhg is a bidirectional, incremental Mercural/fossil synchroniser. It'll push changes in both directions between a Mercurial repository and a fossil repository: https://cowlark.com/fhg Currently it *only* supports synchronising checkins --- no branches, tags, bookmarks, etc. (The Mercurial model for these is sufficiently different to the Fossil model that I hadn't figured out a way to do that yet.) Plus due to a Mercurial issue there are certain DAG shapes that Fossil supports that can't be represented in Mercurial. See the tests/twowaymergef.sh and tests/twowaymergeh.sh test cases. Also see this StackOverflow question where I've asked about it: http://stackoverflow.com/questions/20723929/nothing-to-merge-with-hg-merge (I think a possible workaround is to always create a new Mercurial branch whenever we want to do a checkin that forks, but that's grotesque and I'd prefer a cleaner solution.) The Fossil repo has at least one instance of this. The synchronisation data is stored in the Fossil repository as a valued tag called 'hg', which makes the timeline pretty spammy. I don't know whether a raw tag would be more appropriate here. It'd also be really nice if 'fossil commit --tag' could set a tag value, because then I could check in a change and annotate it in a single operation. The code itself works in the time-honoured brute force way of doing a checkout from (n-1) in one VCS, then doing a forced update from (n) in the other VCS, then checking in (n) to the first VCS. This works, but keeping the repository clean is rather problematic --- Mercurial has the 'purge' command, which removes all untracked files from the working directory, but Fossil doesn't. Plus, Fossil will unconditionally write out "*-baseline/-orig/-local" files when it sees a merge conflict, which I then have to explicitly handle and ignore or else they get checked in to Mercurial (which is bad). Mercurial's merge has an option not to do this, which is really useful. It would be so nice if both VCSes had a tool which did 'force the working directory to look like revision (n) even if you have to delete untracked files', but they don't, so. (It may well be worth chucking all this and starting again from scratch with a system based around incremental fast-import changesets.) Plus, because the generated Fossil repository contains forged timestamps (to match the Mercurial checkins) the timeline graph generator can get horribly confused. Sometimes it produces graphs which are just plain wrong. I hope this is useful to someone. Right now the code is pretty shonky and I'm sure there are bugs (I just took time out from writing this email to fix one^H^H^Htwo). OTOH I've thrown it at some pretty large repositories and it seems to work. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ "There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs." --- │ Flon's Axiom
signature.asc
Description: OpenPGP digital signature
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
