[fossil-users] [ANN] fhg: a Mercurial/fossil synchroniser
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
Re: [fossil-users] Incorrect branch content on import
On 22/12/2013 0:55, Roy Marples wrote: On 21/12/2013 21:11, Roy Marples wrote: I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. By adding a commit to the dhcpcd-5 branch in git, exporting and then importing into fossil it now seems to work. So basically the error happened because once the dhcpd-5 branch was made there were no commits in it. Hope this helps someone fixing it. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Question on repo size after repeated binary file commits?
I am curious what is stored in the repo for each new commit that includes a tiny change to a binary file. Whether a dll or an image file, is fossil storing each binary file compressed, uncompressed or some sort of delta? Over time(6mo's to 1yr), I would like to reduce my repo size by purging really old binary files. Thanks for fossil! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question on repo size after repeated binary file commits?
On Sun, Dec 22, 2013 at 7:37 PM, sky5w...@gmail.com wrote: I am curious what is stored in the repo for each new commit that includes a tiny change to a binary file. Whether a dll or an image file, is fossil storing each binary file compressed, uncompressed or some sort of delta? Over time(6mo's to 1yr), I would like to reduce my repo size by purging really old binary files. Thanks for fossil! Fossil does have delta encoding but I am not sure whether this is used for binary files. However part of the design philosophy of Fossil is that no history is ever lost. So reducing the repository size is generally not possible. Mark ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question on repo size after repeated binary file commits?
Ah, is there a way to quantify the binary delta? If I have a 1MB binary file and commit a 1 byte change, what is the size of the computed binary delta? You are correct of course, but I tend not to extend the spirit of fossil to binary files and images. It is their existence and not legacy that is critical in my application. An example would be icons used for toolbars and menus. If I tweak them or add layering, I sorta obsolete the originals. Here, I prefer the smaller repo. On Sun, Dec 22, 2013 at 1:46 PM, Mark Janssen mpc.jans...@gmail.com wrote: On Sun, Dec 22, 2013 at 7:37 PM, sky5w...@gmail.com wrote: I am curious what is stored in the repo for each new commit that includes a tiny change to a binary file. Whether a dll or an image file, is fossil storing each binary file compressed, uncompressed or some sort of delta? Over time(6mo's to 1yr), I would like to reduce my repo size by purging really old binary files. Thanks for fossil! Fossil does have delta encoding but I am not sure whether this is used for binary files. However part of the design philosophy of Fossil is that no history is ever lost. So reducing the repository size is generally not possible. Mark ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question on repo size after repeated binary file commits?
On Sun, Dec 22, 2013 at 8:44 PM, sky5w...@gmail.com wrote: Ah, is there a way to quantify the binary delta? If I have a 1MB binary file and commit a 1 byte change, what is the size of the computed binary delta? Very, very small: Create two binaries with a one-byte difference: [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag foo; echo -n x foo; cat f-wiki foo [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag bar; echo -n y bar; cat f-wiki bar [stephan@host:~/cvs/fossil/libfossil]$ l foo bar -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 bar -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 foo The delta: [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar 4tz2 2Qjj@0,1:yO@0,2UEw@2Qk7,3wep03; Confirm that the delta actually does what's expected: [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar baz [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta -a baz foo bar2 [stephan@host:~/cvs/fossil/libfossil]$ cmp bar bar2 [stephan@host:~/cvs/fossil/libfossil]$ echo $? 0 To answer your question: 37 bytes: [stephan@host:~/cvs/fossil/libfossil]$ l baz -rw-rw-r-- 1 stephan users 37 Dec 22 20:49 baz -- - 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
Re: [fossil-users] Question on repo size after repeated binary file commits?
Thanks. I didn't know how binary was handled given the Timeline diff response = cannot compute difference between binary files. I think it would be cool if instead fossil listed some of the metrics used or determined in the binary delta operation. Thanks for Fossil! On Sun, Dec 22, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Dec 22, 2013 at 8:44 PM, sky5w...@gmail.com wrote: Ah, is there a way to quantify the binary delta? If I have a 1MB binary file and commit a 1 byte change, what is the size of the computed binary delta? Very, very small: Create two binaries with a one-byte difference: [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag foo; echo -n x foo; cat f-wiki foo [stephan@host:~/cvs/fossil/libfossil]$ cat f-tag bar; echo -n y bar; cat f-wiki bar [stephan@host:~/cvs/fossil/libfossil]$ l foo bar -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 bar -rw-rw-r-- 1 stephan users 1281922 Dec 22 20:48 foo The delta: [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar 4tz2 2Qjj@0,1:yO@0,2UEw@2Qk7,3wep03; Confirm that the delta actually does what's expected: [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta foo bar baz [stephan@host:~/cvs/fossil/libfossil]$ ./f-delta -a baz foo bar2 [stephan@host:~/cvs/fossil/libfossil]$ cmp bar bar2 [stephan@host:~/cvs/fossil/libfossil]$ echo $? 0 To answer your question: 37 bytes: [stephan@host:~/cvs/fossil/libfossil]$ l baz -rw-rw-r-- 1 stephan users 37 Dec 22 20:49 baz -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil import timestamp mangling
On 20/12/13 17:07, David Given wrote: [...] http://www.fossil-scm.org/index.html/info/10f9673a25 Does that patch look good enough to merge to trunk? If I don't do it today I will forget about it completely... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ 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
Re: [fossil-users] fossil import timestamp mangling
On Sun, Dec 22, 2013 at 3:11 PM, David Given d...@cowlark.com wrote: On 20/12/13 17:07, David Given wrote: [...] http://www.fossil-scm.org/index.html/info/10f9673a25 Does that patch look good enough to merge to trunk? If I don't do it today I will forget about it completely... No. Look at the diff. The indentation is wrong. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil import timestamp mangling
On 22/12/13 20:18, Richard Hipp wrote: [...] No. Look at the diff. The indentation is wrong. Oops, sorry. This one should fix it: http://www.fossil-scm.org/index.html/info/70b82e8cc5 (Incidentally, at some future point when I have time, would a patch to add vim modelines to all the sourcefiles be likely to be accepted? This would configure vim to get the indentation right automatically. I don't know whether emacs would honour it too, though. This would involve a single-line comment at the end of each file.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ 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
Re: [fossil-users] fossil import timestamp mangling
On Sun, Dec 22, 2013 at 3:41 PM, David Given d...@cowlark.com wrote: (Incidentally, at some future point when I have time, would a patch to add vim modelines to all the sourcefiles be likely to be accepted? This would configure vim to get the indentation right automatically. I don't know whether emacs would honour it too, though. This would involve a single-line comment at the end of each file.) No. The sources should be editor-agnostic. We do not need editor-wars. A corollary to the above is there should be no tabs anywhere in the source code. (I have not checked yet to see if your changes contain tabs.) See http://www.fossil-scm.org/fossil/doc/tip/www/style.wiki for additional information on the coding style. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Question on repo size after repeated binary file commits?
Really, I am only implying some minimal file statistic like 'DeltaSize(%)' or somesuch to show the user it is in fact compared internally. The current message contradicts what is in fact happening. Maybe change that message to Cannot visually display binary diffs. DeltaSize(%) = -10. On Sun, Dec 22, 2013 at 3:15 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Dec 22, 2013 at 9:06 PM, sky5w...@gmail.com wrote: Thanks. I didn't know how binary was handled given the Timeline diff response = cannot compute difference between binary files. That message is a bit misleading. It really means a visual difference. There isn't a mechanism to show a textual diff for binaries, and fossil's internal deltas and its text diffs are two completely different beasts. I think it would be cool if instead fossil listed some of the metrics used or determined in the binary delta operation. The diff-related pages don't actually use the delta code (though diff/delta are logically similar, they are much different implementations). A delta blob does in fact know (without expensive processing) the size of the original blob and the size of the delta, so it might be feasible to do that. The unsightly part is that fossil doesn't really know what's a binary and what isn't (the delta algorithm is the same for all data). When performing a textual diff and it runs into any binary-looking data, it aborts the diff and assumes that it's binary. i.e. it would first need to run through the text diff and, as a fallback, generate statistics for a binary delta. Yeah, doable, but IMO horribly ugly because it would have to be done as a fallback for the diff generation, making it more expensive (computation/memory) than it really needs to be. -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil import timestamp mangling
On Sun, Dec 22, 2013 at 08:41:45PM +, David Given wrote: On 22/12/13 20:18, Richard Hipp wrote: [...] No. Look at the diff. The indentation is wrong. Oops, sorry. This one should fix it: http://www.fossil-scm.org/index.html/info/70b82e8cc5 (Incidentally, at some future point when I have time, would a patch to add vim modelines to all the sourcefiles be likely to be accepted? This would configure vim to get the indentation right automatically. I don't know whether emacs would honour it too, though. This would involve a single-line comment at the end of each file.) You can use this vim plugin: https://code.google.com/p/lh-vim/source/browse/misc/trunk/plugin/local_vimrc.vim Put it on your ~/.vim/plugin dir and add a file called: _vimrc_local.vim file inside the fossil-scm/src dir (on your local checkout). Then you can put vim setting that match the fossil syle guideline for all files in src/. My _vimrc_local.vim file contain the following: - set et set ts=2 set sts=2 set sw=2 Like this you have advantage of the modeline without imposing the modeline in the fossil source to everyones.. Regards, -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil import timestamp mangling
On 22/12/13 20:56, Martin Gagnon wrote: [...] You can use this vim plugin: https://code.google.com/p/lh-vim/source/browse/misc/trunk/plugin/local_vimrc.vim Ah! I didn't know such a thing existed. Thanks, very useful. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ 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
Re: [fossil-users] Question on repo size after repeated binary file commits?
On Sun, Dec 22, 2013 at 9:57 PM, sky5w...@gmail.com wrote: Really, I am only implying some minimal file statistic like 'DeltaSize(%)' or somesuch to show the user it is in fact compared internally. The current message contradicts what is in fact happening. Maybe change that message to Cannot visually display binary diffs. DeltaSize(%) = -10. It is in principal an minimal change, but it is more invasive than it sounds because the parts which deal with diffs are 100% different, and separate from, those which deal with deltas. The code which generates the diff, and outputs the cannot... message does not have enough info to know about the underlying delta (nor whether there is in fact any delta at all - there is not always one). -- - 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
[fossil-users] hidden tag bug (or missing feature).
Hello, When clicking on the genealogy links from the /info page for a hidden check-in (e.g. family, ancestors, descendants, branch), the timeline does not display the hidden content which makes the view for hidden artifacts less useful and there is no way to unhide it except by manually adding unhide to the URL: http://www.fossil-scm.org/index.html/timeline?f=9c9e77676b417505 vs. http://www.fossil-scm.org/index.html/timeline?f=9c9e77676b417505unhide Also the following: http://www.fossil-scm.org/index.html/timeline?p=9c9e77676b417505unhide http://www.fossil-scm.org/index.html/timeline?d=9c9e77676b417505unhide http://www.fossil-scm.org/index.html/timeline?dp=9c9e77676b417505unhide http://www.fossil-scm.org/index.html/timeline?r=mistakeunhide But I think the whole point of clicking on such a link would be to display the content for it and not hide the information. Should the query be changed for these particular timeline displays? Or should a button to unhide them be enabled? Or what? Seems onerous to require the user to manually add unhide to the URL. :-) Thoughts? Thanks, Andy -- TAI64 timestamp: 400052b7a305 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] hidden tag bug (or missing feature).
2013/12/23 Andy Bradford amb-fos...@bradfords.org: Hello, When clicking on the genealogy links from the /info page for a hidden check-in (e.g. family, ancestors, descendants, branch), the timeline does not display the hidden content which makes the view for hidden artifacts less useful and there is no way to unhide it except by manually adding unhide to the URL: Fixed here: http://fossil-scm.org/index.html/info/fd0507e949 Thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
