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:


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 

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

Reply via email to