On 7/1/2014 8:39 AM, Stephan Beal wrote:
On Tue, Jul 1, 2014 at 3:53 AM, Ross Berteig <r...@cheshireeng.com
<mailto:r...@cheshireeng.com>> wrote:
....
Thank you very much for this. i will get the docs updated (@Shal: yours,
too) within the next couple days.
You're welcome. I figured that having put the effort into understanding
what was really going on, I should feed the results back upstream in
hopes that it's helpful to others.
Naturally, the descriptions of the /zip URL as well as the fossil
tarball and fossil zip commands should be aligned as well.
Will do.
On the subject of thankless documentation tasks, the original help text
for both the /tarball and /zip pages uses the term RID. From a search
through the /test-all-help page, that term is used only rarely. (I spot
it on /ci, /ci_edit, /tarball, /vinfo, /wdiff, and /zip, and notably not
in the help for any CLI command.)
None of the text actually defines the term. Other commands and pages use
UUID, ARTIFACT, VERSION, and other terms for similar use cases.
The thankless challenge for someone is to go through all the terms used
to describe a specific artifact, checkin, version, release, tag, etc.
and unify the language so that we can use the same term for the same
concept throughout the documentation.
Then, write the help text for the "fossil glossary" command which would
be a placeholder for a glossary of all of the terms of art that are
unique to fossil or to DVCS tasks in general.
Some trivia for you:
/tarball/foo ===> /tarball?name=foo
I figured that out, and struggled to find a way to say that concisely in
my proposed rewording of the help text. I don't think I succeeded.
that is a deep-seated internal convention/translation within the
library, originally used for wiki pages (/wiki/foo ==> /wiki?name=foo)
but it's done at a level far lower than the wiki API, so it happens to
all APIs _except_ when running in JSON mode (where i disabled it out
because it interferes with JSON-side argument collection).
Right, I knew I'd seen the motivation for it somewhere, but couldn't
recall where. This (and any other similar conventions) is also a
candidate for inclusion in documentation somewhere. The "glossary"
command I propose for describing things like RID, UUID, ARTIFACT,
VERSION, branch, tag, checkout, and so forth feels like not quite the
right spot, however.
....
If you parse the RSS feed or timeline, it would be possible to get the
sha1 in advance if you need it.
BitBake wants *both* MD5 and SHA256 of the tarball that it plans to
download. Since the tarball contains a folder name supplied by URL
parameters, fossil would have to construct the tarball with parameters
and compute both checksums. I don't see any reason to do that work until
that specific tarball is requested, and the path of least resistance is
to just let BitBake compute them the first time. Unfortunately it does
case BitBake to download the same tarball a second time, but on the
grand scale of things that is just an annoyance.
With Git, it can clone a repo and then checkout the requested version
for building from its own clone of the repo. If I had more time and
budget, I'd delve into that mechanism and figure out how to extend
BitBake to have the similar abilities for a fossil repo.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
