Re: [fossil-users] (no subject)
On Sat, Aug 30, 2014 at 6:46 AM, Stephan Beal sgb...@googlemail.com wrote:
You do now :). The first script-available feature was the DB layer. It
seems i didn't bind the pseudo-recursive transactions bits, but everything
else one needs for DB access seems to be there, and the require.s2 module
makes it really easy to write mini-apps/modules to import data:
Out of curiosity's sake, i went ahead and used the various existing pieces
to create a standalone mini-timeilne application (to see if any needed
parts are missing). It's entire implementation:
#!/usr/bin/env f-s2sh
assert Fossil.require;
Fossil.require(
['fsl/db/checkout', // opens the current checkout
'fsl/timeline/basic' // array of recent event table entries
],
proc(co,tl){
const j2h = Fossil.time.julianToHuman;
const fmt = %1$-8s %2$.10s @ %3$s by %4$s;
const typeMap = { // maps event.type labels to strings
g: 'tag', w: 'wiki',
ci: 'checkin', e: 'event',
t: 'ticket'
};
tl.eachIndex(proc(v){
print(fmt.applyFormat(typeMap[v.type]|||'???',
v.uuid,
j2h(v.mtime),
v.user));
print('\t',v.comment);
});
});
which outputs:
[stephan@host:~/cvs/fossil/libfossil/s2]$ ./timeline.s2
checkin b9d3c27a12 @ 2014-08-30 06:25:15 by stephan
latest s2/requires2.
checkin 7a4fa849d3 @ 2014-08-27 18:47:25 by stephan
latest s2, added missing require.s2 scripts.
tag 3c78d1c612 @ 2014-08-26 21:21:11 by stephan
Edit [0f48e69758f241506f43bb4c6370baef0ef09f5a|0f48e69758]: Edit check-in
comment.
checkin 0f48e69758 @ 2014-08-26 21:20:23 by stephan
latest s2, lots of little stuff, one notable corner-case bug (bogus OOM
error).
checkin acc01d60c7 @ 2014-08-26 17:26:53 by stephan
accommodated API changes.
--
- 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] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm working on a project where the first version given to me was far from the first version that existed. Having nothing else to go on, I used it as the initial check-in of my new Fossil repository. Now I have been given a few older versions. What's the best way to go about putting them into the repository? I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I could also make a whole new repository with everything committed in the right order, but this is error-prone and, frankly, too OCD for my liking. By the way, --date-override is documented for some commands (e.g. tag) but not for commit. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAiiWAAoJELtYwrrr47Y4jesIAOILfX6anlRgkbneiISmjKQx xuQgcmsqpof14dGsbCq8LAWaDsKVOMWw0pDefLoJBHVtYpfR5cR7cNkjLGA4WFNl HKO8FqYHYjdPto16BMMKFK7paeGtuAernVZvyfsZRtBxAIg+LwdPXwivxBzSkMO4 RIzGiK86AXtbSCo7fnRyAunPzyFDXxzOeujrgFJfPrxny8WemRh3rVSHjSC1fh33 FwraAX1wHbVGA026iauOb3YSvunPy6OdsDGZWtqK9S65ZyQQjLJIrL9tWNdufjvF XSt94qygfLSC02WkJ4vlWWKZLQtyXlP7To08m/XkQFg46yfDmYSEZm3G1b1H+FE= =7rTV -END PGP 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] Receiving old versions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2014 2:40 PM, Andy Goth wrote: Now I have been given a few older versions. What's the best way to go about putting them into the repository? I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I cloned my repository and did the above as a test just to see how bad it comes out. Well, it's pretty bad. Not only is the timeline bizarre, the default diffs are unhelpful too. Diffs are typically against the predecessor version, but in this situation, Fossil's concept of predecessor doesn't match the naïve user expectation. Surprise notwithstanding, this is correct behavior in face of the time paradox. I think my best course of action is to not try to put the old code into the repository unless I am given a more complete archive of historical versions, at which time it might be worthwhile to rebuild the repository with everything put in the right sequence. Of course this blows away all the artifact IDs, but that would be acceptable at this stage. Let's say I do this, using the oldest known version as the initial commit, and everything seems good for a while. But then someone finds an in-between version thought to have been lost. I would update to its predecessor version then check it in with the date override, either allowing the fork or putting it on an branch. The timeline would look mostly good, but only because the predecessor version already existed. Diffs surrounding the newfound would have to be done with explicitly selected from and to versions, but that's a small price to pay for not having to rebuild the repository and trash the artifact IDs. Then a version older than the previously oldest known version is found. Now we're in trouble again. Maybe I could have prevented that last problem by making the initial empty check-in be dated before the project was known to have started, so there would never be anything older than it. Thoughts? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAi4UAAoJELtYwrrr47Y4J8MIAMbIomO0T3d/lNiClwMi7Ph1 uoeWBPmmz1hd8cQlgT0uS/u6bhYQkOSqeDRM3kWPJCV9iDeRAdQ2wfJjT2/iv3ez OWQGDQcveIL36yBVzBAzGMmTrLKxtSxSZ5gjHzi6t7hn3bALz+6JySbDiHqUhNui 0QlvLz1+I0JyUepWw4OXzX6FzTUY4ldgZWz88N6DojX89zTdnwJo4sgFj8tV 1iL+xIwoQVDzoB+UMPc4uLGuMTSBDU5rzQS9ohvliniadoRPeI52BanLnm3zNP36 pp1BI3cKKynJH1DPP7ybTD0Y3XM6HqQUiO83JCsZSBAtn44zKJ86Qwpb/zzpIog= =g08t -END PGP 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] Receiving old versions
On Sat, Aug 30, 2014 at 3:40 PM, Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm working on a project where the first version given to me was far from the first version that existed. Having nothing else to go on, I used it as the initial check-in of my new Fossil repository. Now I have been given a few older versions. What's the best way to go about putting them into the repository? You can't. Or, at least, you can't link them into the tree of existing versions. The older version will become a new and independent graph. The reason is this: Each version has a parent, the name of which is included in the manifest. You cannot add this to the manifest after the fact, since that would change the manifest and manifests are immutable. One could enhance Fossil to accept a new kind of tag that changes the parent of a check-in. We already have takes like this for changing the check-in comment and the check-in time. If such a tag existed, you would be able to add the older check-ins to the repo, then reparent what used to be your root check-in so that it was a child of when of the older check-ins you just added. But, as of this writing, no reparent tag exists. I know I can check them in with --allow-older and the --date-override options, though this will produce a very funky timeline display. Is there a better way? I could also make a whole new repository with everything committed in the right order, but this is error-prone and, frankly, too OCD for my liking. By the way, --date-override is documented for some commands (e.g. tag) but not for commit. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUAiiWAAoJELtYwrrr47Y4jesIAOILfX6anlRgkbneiISmjKQx xuQgcmsqpof14dGsbCq8LAWaDsKVOMWw0pDefLoJBHVtYpfR5cR7cNkjLGA4WFNl HKO8FqYHYjdPto16BMMKFK7paeGtuAernVZvyfsZRtBxAIg+LwdPXwivxBzSkMO4 RIzGiK86AXtbSCo7fnRyAunPzyFDXxzOeujrgFJfPrxny8WemRh3rVSHjSC1fh33 FwraAX1wHbVGA026iauOb3YSvunPy6OdsDGZWtqK9S65ZyQQjLJIrL9tWNdufjvF XSt94qygfLSC02WkJ4vlWWKZLQtyXlP7To08m/XkQFg46yfDmYSEZm3G1b1H+FE= =7rTV -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- 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] (no subject)
At Sat, 30 Aug 2014 09:57:21 +0200, Stephan Beal wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] On Sat, Aug 30, 2014 at 8:41 AM, Stephan Beal sgb...@googlemail.com wrote: Out of curiosity's sake, i went ahead and used the various existing pieces to create a standalone mini-timeilne application (to see if any needed parts are missing). It's entire implementation: And here it is with file listing support (the query for that is more than half the script): http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/timeline.s2 I do want to reimplement the timeline view at some point, so this may prove useful. Good to know that s2 is capable of doing this task. Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Shunning and assertion failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm continuing to experiment with putting old versions into the repository. This necessarily meant numerous false starts and failures (it's a fool's errand, really), which in turn mean shunning and trying again (compounding the mistake). I was able to get my repository into a sorry state where this happens: $ f up version-4.31 fossil: ./src/bag.c:146: bag_find: Assertion `e0' failed. Aborted Seems like this happens when I try to update to any version identified by a tag, even trunk and tip. Updating to a timestamp also fails. Going to rebuild and keep trying, but I thought I should report the assert failure even if the path to it was long and naughty. By the way, $ f version This is fossil version 1.30 [e4bc6f12ea] 2014-08-30 09:03:26 UTC - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUApLTAAoJELtYwrrr47Y4+u4IAMmJv4dhe4dY++PoVKaZM5Nl Tz5gdmude2FdqYkasYsaD9qfi6mG4R3ztda7bHn2hy5zfpm0g2NE0pLfRr29lach WomeMTUAf1I5m/eaAcZmlvWGO1H1U4x1fMwGycpoojddJJTOv6HdY4vLCKolV0fA Aa+rUhsnx/9wLrpkj+hpwbGdPx4gXIKB+Xe3tA0/3f+FugyYTUSPKxnXXKAl0rQ0 eLTtGoPNMeFX5VNHM6xXdR5CSV1ksX1e7TaGNXikbhlRKbBwlbQdnM6mzUrxZFVU WMtHxuzwNQVCj49VtqabbKOuxoOpPYGPMjczO0x/FYIEFmfaF2dwfhfgFNZ5TxA= =RJYc -END PGP 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] Shunning and assertion failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/30/2014 10:13 PM, Andy Goth wrote: $ f up version-4.31 fossil: ./src/bag.c:146: bag_find: Assertion `e0' failed. Aborted Going to rebuild and keep trying Also I should mention that the assert failure goes away following rebuild. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUApNfAAoJELtYwrrr47Y46LkH/jzxZ8gBz5JXyW1GQU/XsvL3 +kyoFRJyYP/KH2LkNJNQFmf00thSj1RFzzsj9BKi9v7+BBAP1nIOW+jcDNNU9hSs Bykv4QrdTqHNhyyiQSUI7rz/HfJWjRp5r+SAae5xnC8uvtu6AjTDxezt637c/pQc +6hQ6YbP7+Hdu9yILCUa6TiVxzlMhUDvTu3dkVusD/02s9u5UDk+MecRDGvASrCw 5sKUnuv85rZrv+fqKL/W1VMkOQmXDZjctuUTJjTvTgjA2GG42OgUFOkrUw2WKmHU B8FWgF3R5UgCb9XgC2Oaxh7n+Ao4smLMqWSgPO+a/Dj5D3xCyOssC92J955yMfE= =aKe4 -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
