Stephan Beal wrote: > > 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 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
