On Tue, Jul 1, 2014 at 8:39 PM, Ross Berteig <r...@cheshireeng.com> wrote:
> 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.) > Yeah, RID is kind of a leaky internal term we throw around a lot. It basically means "a given blob" (RID == blob.rid field in the db). > None of the text actually defines the term. Other commands and pages use > UUID, ARTIFACT, VERSION, and other terms for similar use cases. > FWIW, the libfossil docs go into the distinctions (including RID) in great detail, with an overview hereI: http://fossil.wanderinghorse.net/repos/libfossil/doxygen/page_terminology.html > 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. > That was one of the initial challenges in libfossil, believe it or not. i had to personally come to terms with unambiguous definitions of terms (like "manifest") which have very context-dependent meanings here in fossil. 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. see the above link ;) > 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. > Agreed. i'll see if i can find a place to mention it when i get around to updating the docs, but no place specific comes to mind at the moment. > >> 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. > We "could", except that we'd need to protect it against abuse, provide a URL like: myfossilsite.com/md5/A_UUID, for which it would calculate the MD5 of the underlying artifact, and return it as a single line of text/plain content. It would be trivial to add but has potential abuse problems and authentication via wget/curl is problematic b/c you'd have to store your credentials somewhere script-readable. We generally would not want it accessible by bots, which could DOS the server with it by selecting the proper UUIDs (the ones it knows are most expensive to extract from the db, undeltify, decompress, etc.). If we can solve those, i'll add it. -- ----- 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
