Ross Berteig wrote: > > * stash-fixes > > IMHO, not quite ready yet. > > The schema change in the stash-related tables clearly fixes one problem > with mixing a stash with renamed files. I think this needs to hold off > until someone more expert in SQLite than I figures out how to safely do > the needed change (moving a primary key from one column to another) as a > run-time check. I also have a tortured mess of test cases for stashed > renames that don't shine as bright a light on the issues as they could, > that I intend to improve. >
Agreed. > > * [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. > > 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. > > * [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. > > * 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. > > * 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. > > * 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. > > * 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. > > * miniz-1.16br1 > > IMHO, if any library we fold in to our source tree has updates, we > should evaluate them. Miniz certainly fits that description, the > question may be where the official upstream source is located post > google-code's closure. > Yes, if we are going to retain support for it, it needs to be up-to-date (especially it appears to have some issues that zlib does not have). However, before updating it, we really need to find its official source. If it's no longer actively maintained, we should probably just remove it from the tree. > > 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. > > 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. > > * baseUrlRepoDir > > This seem to be a first take at the more recent altBaseUrlRepoDir > improvement. Probably based on a patch by David Given: > This one is dead. The "altBaseUrlRepoDir" fix is the correct one. > > * test-only > * do-not-merge > * mistake > * hierarchical-manifests > * jan-manifest-tags > * technoteattachcli > * technote-cli > I don't know anything about any of these branches. -- Joe Mistachkin _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
