Re: [fossil-users] Sixteen-digit event IDs
2014-06-30 17:12 GMT+02:00 Stephan Beal: i like it, but how about %U (big U, for UUID)? That one is still available. Or maybe %H (hash). Ah, now i see that %S could mean SHA1, so now %S makes more sense to me. %S stands for STRINGID already, I see no reason to change it. http://fossil-scm.org/index.html/artifact/49a234dc?ln=56 Regards, Jan Nijtmans ___ 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] Sixteen-digit event IDs
On Wed, Jul 2, 2014 at 9:59 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: %S stands for STRINGID already, I see no reason to change it. http://fossil-scm.org/index.html/artifact/49a234dc?ln=56 Indeed. i overlooked that. -- - 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] Using fossil with Bitbake and the Yocto project
On Wed, Jul 2, 2014 at 1:19 AM, Ron Wilson ronw.m...@gmail.com wrote: As for Fossil providing the needed bits to write a plug-in to any given tool, it is possible to write a plug-in that uses the command line Fossil. Or, for that matter, a hybrid that uses libfossil for information and fossil to perform commits, updates, etc. One of the benefits of libf is that it becomes really easy to write one-shot, single-purpose apps. See this page for a list of the current apps: http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki?name=f-tools If you wanted, for example, to create a tool which calculates the md5 of a given zip file, you could use f-zip as a basis and, instead of writing the zip to a file, use the libf md5 API to hash it. Or add a flag to f-zip which does that. With script bindings it becomes even simpler. The proof-of-concept th1ish bindings show us that it can be done: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/ (That's ALL implemented using the libfossil script bindings, by the way!) and i am at this very moment working on the next generation of that scripting engine to get around limitations in that engine i ran into while implementing an interactive fossil shell: https://docs.google.com/document/d/1hvMoHSIz94dob6fCU6SLxle_s7YL6CrA_4aU12OWwWY/view :) (That code is the reason libfossil is at a standstill at the moment ;) -- - 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] Using fossil with Bitbake and the Yocto project
On 6/30/2014 6:53 PM, Ross Berteig wrote:
After some effort, I believe I have a working BitBake recipe for
cross-compiling fossil in an embedded Linux distribution built by the
Yocto Project's BitBake tool.
I'll post my recipe for building fossil itself separately, after I've
verified that the fossil it builds actually does run in my target hardware.
I've attached the BitBake recipe that worked for me. Put the file in
~/yocto/poky/meta-myproject/recipes-myproject-extras/fossil and make
sure that some other recipe as a last resort ~/yocto/build/local.conf
mentions a need for fossil. You might want to tweak the options passed
to ./configure to suit.
I don't happen to care one way or the other about SSL, so I ignored it
both in the ./configure and in the documented dependencies. As luck
turned out, libssl was already built and present when this recipe was
built and ./configure noticed it, so the fossil as built got the related
features.
I've (lightly) tested the result in an image running in a very tiny
Gumstix Duovero OMAP4-based system by cloning my project's repository,
opening a working folder, and successfully building it in the target
with GCC.
To learn more about Yocto, see https://yoctoproject.org/ for plenty of
documentation.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
DESCRIPTION = Fossil SCM: A low-ceremony distributed version control system.
SECTION = dev-tools
LICENSE = BSD-2-Clause
LIC_FILES_CHKSUM =
file://COPYRIGHT-BSD2.txt;md5=f7c1e448c7cdaa143badd75d8e4cd90d
PR = r0
# Don't forget that PN, PV, and PR can be useful here
SRC_URI = http://fossil-scm.org/index.html/zip?name=${PN}-${PV}.zip\
uuid=3e5ebe2b9027cd\
;downloadfilename=${PN}-${PV}.zip
SRC_URI[md5sum] = 11bc7285a0eca23587fdb16ea6cda03c
SRC_URI[sha256sum] =
07ba770f24988bf6234b38eba8f5674c232ebe26ff03f506918a838c8a27de89
# fossil needs zlib since nearly everything it stores is compressed internally.
DEPENDS_${PN} = libz
# List the files installed in our main package
FILES_${PN} += \
${bindir}/fossil \
# Invoke fossil's configure command. There's probably an environment
# variable intended to supply the target prefix for cross compilation
# but it doesn't appear to be documented. The easy way is to look
# in the run.do_configure script and pluck it out of the definitions
# of CC and friends.
do_configure () {
./configure --json --host=arm-poky-linux-gnueabi --prefix=/usr/bin
}
# Install our actual executable from the build directory ${S} to the
# target file system tree in ${D}. By strong convention, ${D} will only
# hold files and folders actually generated by this recipe so that
# means that even standard folders such as /usr/bin must be created
# before installing files in them.
do_install () {
install -d ${D}${bindir}
install -m 0555 ${S}/fossil ${D}${bindir}
}
___
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] Sixteen-digit event IDs
On Jun 30, 2014 2:20 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-06-27 23:40 GMT+02:00 Andy Goth andrew.m.g...@gmail.com: How come events are always shown with (at least) sixteen digits on the timeline whereas other artifacts are given ten digits? http://www.fossil-scm.org/fossil/timeline?n=20y=e Just because it was implemented that way originally ;-) I would like to propose to use the same algorithm as in other places: Make sure that the displayed UUID contains at least one lowercase ASCII, with a minimum of length 10. This code isn't an area of expertise of mine, but isn't the one lower case ASCII requirement hopeful? The hyperlink uses the full UUID. The %S formatter could be used for the display part: http://fossil-scm.org/index.html/info/734d429940 To me the result looks good, but I would appreciate a second opinion before merging this to trunk. Any objections? Is there any place in the UI where changing the default length of %S causes a possible incompatibility. (If so, using the %.16s format would be more logical anyway.) Regards, Jan Nijtmans ___ 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
