On Jul 10, 2018, at 8:58 PM, Andy Goth <andrew.m.g...@gmail.com> wrote: > > "Got fossil ui working. Added, merged and committed website_design.md." I > thought it interesting that he spoke of merging as if it were a distinct task > in the workflow for adding a file.
Did he check the file in on a branch and then merge it down to trunk? > “...I'm reading the best practice for fossil is to leave the deprecated .md > in place?" I'm not sure where he got the idea that it's best to not delete > files It’s not Fossil-specific at all: once publicized, a URL should never die, else you get broken links, if only from web crawlers that saw that document once upon a time and then continue to return it in search results. There are several embedded documentation files in both the Fossil and SQLite project repositories that are deprecated, presumably for this reason. It’s arguable whether this rule applies to your codeveloper, because page lifetime also plays into it. It sounds like the file was only available for minutes, and then on a “young” site with very few outside people looking at it, if any at all. So, who could possibly have even known the URL was valid, much less cached it semi-permanently? > “People don't much like this behavior, but it's what we have, and it can be > changed.” Did you make it clear that “it can be changed” means your codeveloper can change it on his end, as opposed to waiting for someone to get around to changing Fossil for him? Two weeks ago, Fossil trunk was changed so that you no longer need to reconfigure Fossil’s checkout tree to enable this: http://fossil-scm.org/index.html/info/27e5e5ce65262f5a That is, the mv-rm-files option is now present in all Fossil builds. It is just not enabled by default. > Regarding fossil changes, he said, "If I get a carriage return/new line with > no prompt, does that mean there are no changes to apply?" So there seems to > be a bit of confusion, or at least hesitancy, about fossil changes (probably > also fossil extras) printing nothing. That’s not a Fossil issue, it’s a Unix vs Windows issue: traditionally-designed Unix programs often do their work silently if no problem occurs and there is nothing to tell the user. This design choice is part of Unix’s focus on the shell as a programming environment, rather than as a thing to type commands at interactively. DOS never developed this tradition of scripting commands and interpreting stdout and stderr, so Windows inherited that, and thus Windows programs tend to blabber. Compare the operation of Unix cp vs DOS COPY, for example. Fossil comes out of the Unix tradition, so Fossil only writes output when it has something important to tell you, or you asked it to tell you something. > fossil sync website_design.md That the sync command stores the given URL blindly here seems like a UX bug to me. Just as Fossil re-prompts for a password until it gets one that works, it should not store the URL until it successfully uses the given one to sync the local repo. > This was easily fixed with fossil remote-url. I’d have told your codeveloper to use “fossil sync URL” here instead, so he could compare and contrast the incorrect and correct forms of the command. By giving him a different command to back out, he may now be afraid to use “fossil sync” entirely. > the default of not deleting the file from disk is confusing to new users. Yes, well, the argument’s been had for years here. I take the recent change on Fossil trunk as a sign that *eventually* the default will change. We shall wee. _______________________________________________ fossil-users mailing list firstname.lastname@example.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users