On 3/11/2016 3:40 PM, Joe Mistachkin wrote:
Ross Berteig wrote:
* [ff4a] pending-review
IMHO, merge this.
Changes how the fusefs command appears when fossil is compiled without
fusefs included. Seems reasonable. In fact, I wonder if the json command
shouldn't get a similar treatment when json is not enabled.
It would be nice if we could be consistent in this area. If a feature is
not included in the build, it should ideally be totally gone.
I don't feel strongly about gone or not, but consistent would be good.
IIRC there was some resistance to the original version of this change
where it was totally gone, and the current state where fusefs became a
secondary command that fails was the result of that.
Foolish consistency question: should the text produced by fossil_fatal()
be a complete sentence? A quick grep over src/*.c shows the answer is
currently mostly not, but a few message due begin with an uppercase
letter, but even fewer end with a period.
FWIW, I've tried to make the error text I've added as complete and
gramatically correct as possible.
For maximum irony, I note that I wrote "due" not "do".
I've always believed in grammatically correct (or as close as practical)
text errors. Errors are usually seen by people least familiar with how
things should work, so avoiding too much jargon and idiom seems better.
There are a *lot* of calls to fossil_fatal(). Perhaps if I'm bored
sometime I'll sweep across them wearing my editor's cap to spell check,
capitalize, punctuate, and such.
* [4bd2] pending-review
Builds on Windows. The /brlist page now has a combo box for display
style, picking "Show branch colors" works for me. The result is possibly
more eye-bending than useful. I wonder if the color wouldn't be better
applied to only one column rather than across the entire row, possibly
even a (narrow) dedicated left-most column, in which case it wouldn't
need the option.
I kinda like it. Not sure how many other people would find it useful.
It is fun when you sort by each of the columns...
I do think that trading a small block of color in one column for the
combo box would be a fair trade.
IMHO that desire shouldn't block a merge.
* baruch_timeline_fixes
Builds on Windows. A quick scan of the source changes doesn't look like
trouble. /timeline and its buttons seem to work, but I haven't located a
test case to evaluate this change.
There is a test case somewhere. I think it may have been posted to the
mailing list(s) at some point. I don't quite know enough about that code
to be 100% confident in the changes.
I thought I remembered some discussion, but my google-fu is failing me
today. The obvious test of just loading /timeline in fossil ui and
clicking older and newer worked. I didn't poke at it much more than that.
* altBaseUrlRepoDir
Builds on Windows. A quick scan of the source changes doesn't look like
trouble. Same research as reported below for the baseUrlRepoDir tag
applies. I don't have a test case to evaluate this change.
This fixes an issue with how zBaseURL and zTop are determined. I ran into
the issue while configuring Fossil in a very particular way on Linux. I'm
not 100% confident in the fix; however, it does work. I do not think it
will break anything else, but it needs more eyes.
I found a lot of discussion going back quite a ways of the --baseurl
feature and how it interacts with things. I haven't tried to understand
the issue or review the code changes, beyond a quick glance.
* mvHardDirFix
Doesn't build for me on Windows with MINGW, link fails with undefined
references to fossil_utf8_to_filename and fossil_filename_free. I don't
see either function in the source tree...
Closest match replaces "filename" with "path".
Thanks, should be fixed now.
Builds now on Windows, but the mv-rm tests are not a complete pass:
$ tclsh ../fossil4/test/tester.tcl ./fossil mv-rm -quiet -verbose -prot
test mv-file-new-directory-4 FAILED!
RESULT: DELETE d2/f13
REVERT f12
"fossil undo" is available to undo changes to the working checkout.
test mv-file-new-directory-12 FAILED!
RESULT: REVERT subdirC/f10
REVERT subdirC/f11
"fossil undo" is available to undo changes to the working checkout.
***** Final results: 2 errors out of 56 tests
***** Considered failures: mv-file-new-directory-4 mv-file-new-directory-12
Both of those are tests added with this feature. Not sure what they
imply yet.
* ross-doc-env
This branch is mostly a new public facing document describing the
environment variables and global command line options, how they
interact, and including some digressions into things like how does
fossil figure out what user name to use that didn't fit well into the
documentation of any single option or variable.
Along the way I noticed a discrepancy in the way two parts of fossil
tested the same list of variables (to guess user name) and regularized
that by changing db_create_default_users().
I think this is ready to merge, and would be valuable for the
documentation. But since it is my code and docs, I'm eager for some
proofreading...
It's really great, please feel free to merge it when you are ready. We
can always make corrections to it on trunk.
Merged to trunk.
* miniz-1.16br1
....
This raises another question, is there a reason to prefer miniz over
zlib or vice-versa?
Please prefer zlib, it's far more well tested.
OK.
I've been building on Windows with miniz due to installation friction
with zlib (probably some trivial issue, but using miniz has been the
path of least resistance).
I thought I made the zlib compilation stuff work seamlessly on Windows
(using both MinGW and MSVC). I'm eager to hear how its broken so that I
can fix it.
If I use win/Makefile.mingw, then the zlib from compat/zlib is built and
links just fine with no friction other than remembering to build in-tree
from MSYS bash. (Out of tree may work now, I didn't re-check.)
But lately I've been preferring to use your improvements to ./configure
which now works great on Windows, at least from the MSYS port of bash.
It is much better at specifying features.
However, it fails to find zlib.h and wants --with-zlib=tree to use the
in-tree version. I'm not sure how new that option is, I noticed
--with-miniz first, it worked, and I've not looked back. I'll switch
recipes to zlib for now.
Shouldn't ./configure fail to the in-tree versions of things that are
provided in tree?
Or is the consensus that the user needs to make that decision and affirm
it with --with-zlib=tree?
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
