Discussion:
autosync from GUI
(too old to reply)
Eric Rubin-Smith
2014-06-07 13:44:25 UTC
Permalink
Is it reasonable to ask that the 'autosync' setting cause artifacts created
from the GUI to also be autosynced?

I know this would likely increase the latency of the GUI, and would
possibly create a series of error cases and/or user interactions that do
not need to be handled in the GUI today. But I believe that today's
behavior nevertheless violates the principle of least astonishment.
Stephan Beal
2014-06-07 15:55:37 UTC
Permalink
Post by Eric Rubin-Smith
I know this would likely increase the latency of the GUI, and would
possibly create a series of error cases and/or user interactions that do
not need to be handled in the GUI today. But I believe that today's
behavior nevertheless violates the principle of least astonishment.
OTOH, since you've obviously thought through the "long tail" of problems
which come with having such a feature, you are probably not surprised that
Fossil does not currently have that feature ;).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Eric Rubin-Smith
2014-06-07 17:26:47 UTC
Permalink
Post by Stephan Beal
Post by Eric Rubin-Smith
I know this would likely increase the latency of the GUI, and would
possibly create a series of error cases and/or user interactions that do
not need to be handled in the GUI today. But I believe that today's
behavior nevertheless violates the principle of least astonishment.
OTOH, since you've obviously thought through the "long tail" of problems
which come with having such a feature, you are probably not surprised that
Fossil does not currently have that feature ;).
Okay :) but I don't think the tail should be *that* long.

Two of Fossil's self-proclaimed major benefits are: (a) its GUI and
(b) its autosync feature. That the GUI does not attempt to implement
autosync at all *is* surprising.

Note that in non-tiny teams, there is often a "project manager"
type whose job includes defining ticket reports, categorizing and
prioritizing tickets, editing the wiki, and so on. This type of person
might exclusively use the GUI. Forcing them to go use the CLI (even
after they use the GUI Admin page to choose the 'autosync' setting)
feels stranger still, since they would have no reason to use the CLI
otherwise.

We poor geeks who would like to pitch Fossil to our project teams will
encounter less resistance as the number of such surprises shrinks.

Perhaps a middle ground, instead of autosync, would be to have an
indicator on all (or some) of the GUI pages that a push is necessary.
I believe you can detect this using just the local repo clone in most
of the key circumstances. (You could take it a step further and poll
the remote clone to see if it has artifacts that the local clone does
not have, so that you could also report to the user that a pull is
necessary. But the devs will likely find that idea distasteful?)

Eric
Stephan Beal
2014-06-07 18:23:35 UTC
Permalink
Post by Eric Rubin-Smith
Two of Fossil's self-proclaimed major benefits are: (a) its GUI and
(b) its autosync feature. That the GUI does not attempt to implement
autosync at all *is* surprising.
i can see how it might seem surprising, but once one considers the problems
related to opening up an http connection from the server side, many
complications quickly become clear. The feature would break in too many
cases which we couldn't get around - it would not be reliable.

Here's a common problem we'd run into:

The WWW server accepts traffic from anyone but is unable to establish an
outbound HTTP connection to anyone but a small list of whitelisted hosts,
or an internal subnet, or similar. This is a very common setup, and it
would completely break an over-the-web-performed autosync of a
remote-hosted repo.

For the local UI case, sure, i can see it being useful, but people would
also expect it to work remotely, and it often wouldn't.


Note that in non-tiny teams, there is often a "project manager"
Post by Eric Rubin-Smith
type whose job includes defining ticket reports, categorizing and
prioritizing tickets, editing the wiki, and so on. This type of person
might exclusively use the GUI. Forcing them to go use the CLI (even
after they use the GUI Admin page to choose the 'autosync' setting)
feels stranger still, since they would have no reason to use the CLI
otherwise.
Some people use cron for that type of thing. Admittedly hacky, though.
Post by Eric Rubin-Smith
Perhaps a middle ground, instead of autosync, would be to have an
indicator on all (or some) of the GUI pages that a push is necessary.
I believe you can detect this using just the local repo clone in most
Post by Eric Rubin-Smith
of the key circumstances.
An indicator flag (which could be used from TH1 to inject a warning in the
header) should not be difficult to do. i'll have a look. i _think_ we only
have to look if the 'unsent' table is empty or not, but i'm not sure of
that.


(You could take it a step further and poll
Post by Eric Rubin-Smith
the remote clone to see if it has artifacts that the local clone does
not have, so that you could also report to the user that a pull is
necessary. But the devs will likely find that idea distasteful?)
We can't poll from fossil's server mode because it's intended to serve one
request and quit immediately. If CGI processes start hanging around to
poll, some sysadmins might get upset. Another (relatively minor) problem is
that many fossil operations hold the global config db open, and a
long-running (e.g. polling) session can cause locking errors for other apps.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Ron Wilson
2014-06-07 19:27:37 UTC
Permalink
Post by Stephan Beal
For the local UI case, sure, i can see it being useful, but people would
also expect it to work remotely, and it often wouldn't.
When running the local UI, that is seen as part of the local client, but
when accessing a remote server the perception is different. I think it
reasonable that the "server Fossil" not try to autosync to another server
Fossil.

Granted, in a large enough project to have a hierarchy of core developers,
lack of server-to-server autosync might be inconvenient, but as far as I
know, large projects using git worry about this.

So, I think it would be worth it to have autosync for "fossil ui" without
also having it for the various "real" server modes.
Scott Robison
2014-06-07 20:37:07 UTC
Permalink
Post by Ron Wilson
Post by Stephan Beal
For the local UI case, sure, i can see it being useful, but people would
also expect it to work remotely, and it often wouldn't.
Post by Ron Wilson
When running the local UI, that is seen as part of the local client, but
when accessing a remote server the perception is different. I think it
reasonable that the "server Fossil" not try to autosync to another server
Fossil.

Please forgive what may be a stupid observation, but if there are users
that need ticket or wiki access (workflows that are typically ui only),
might not the best approach be to give them appropriate access to the
master via http (as someone already says they do indirectly by making that
the master copy)?

SDR
Ron Wilson
2014-06-08 21:16:43 UTC
Permalink
Post by Ron Wilson
Post by Stephan Beal
For the local UI case, sure, i can see it being useful, but people
would also expect it to work remotely, and it often wouldn't.
Post by Ron Wilson
When running the local UI, that is seen as part of the local client, but
when accessing a remote server the perception is different. I think it
reasonable that the "server Fossil" not try to autosync to another server
Fossil.
Please forgive what may be a stupid observation, but if there are users
that need ticket or wiki access (workflows that are typically ui only),
might not the best approach be to give them appropriate access to the
master via http (as someone already says they do indirectly by making that
the master copy)?
Not stupid. I suspect many Fossil installations do that. The Fossil and
SQLite main sites do that.

Sometimes, thought, that isn't practical. When those people aren't in the
office, its not too hard for them to understand that the syncs don't
happen. In the office, however, it is natural for them to expect the syncs
are done automatically.

Ron Wilson
2014-06-07 19:15:43 UTC
Permalink
Post by Eric Rubin-Smith
Two of Fossil's self-proclaimed major benefits are: (a) its GUI and
(b) its autosync feature. That the GUI does not attempt to implement
autosync at all *is* surprising.
Note that in non-tiny teams, there is often a "project manager"
type whose job includes defining ticket reports, categorizing and
prioritizing tickets, editing the wiki, and so on. This type of person
might exclusively use the GUI. Forcing them to go use the CLI (even
after they use the GUI Admin page to choose the 'autosync' setting)
feels stranger still, since they would have no reason to use the CLI
otherwise.
Because my team is using Fossil without support from IT, we made the
Project Manager's PC (which is under his desk) our main server.

But if not for this, we would have to setup his PC to run a scheduled sync
many times per day.
Continue reading on narkive:
Loading...