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
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
