On Fri, Aug 15, 2014 at 10:25 AM, Charles Curtit <charles.cur...@pgs.com> wrote:
> Hello folks, > > I've been looking for a DVCS and ticket system for a while now, to make my > job easier at work and I find Fossil looks really enticing. I've read the > docs about fossil for 3-4 hours now, and I think it's time for some > questions I have that do not seem to have immediate obvious answers. I'm > sorry the answers I look for are already somewhere, feel free to send me > there to look if you have the right pointers. > The only bad questions are the ones not asked. > > Is it possible to have a setup with a central server and multiple > satellite servers with near realtime replication going on between them ? I > imagine a scenario where each site has a server and where users use the > server at their own site. > "out of the box", Fossil supports this kind of "hub and spoke" arrangement. > My mains goals are : > * speedy user interface for every one. (central or satellite > office) > For tickets and the internal wiki pages, even a single Fossil server can support at least a few dozen users accessing it via web browsers. For developers, besides updating source and other project files on their PCs, they could potentially view/update tickets and wiki pages directly on their PCs (with the updates being sync'd with the office's Fossil server). > * low use of bandwidth btw offices (meaning no user go and try to > talk to the central server from a satellite office). > By itself, Fossil is able to handle forwarding of local updates to, and pulling updates from, the central server. Preventing users in an office from directly accessing the central server is a network configuration issue outside of Fossil's scope. > * low latency in ticket replication (seconds desired, a few > minutes at the most) between offices. > While Fossil can be configured to auto-syn code commits, ticket entry/change is not considered a trigger for an auto-sync event. (see below for more detail) > Other desirable features : > * ease of creation or suppression of a satellite office > Creation of a satellite Fossil server is accomplished via "fossil close URL" on the machine hosting the new Fossil server. Then any site specific setting would need to be set. I believe that "soft" suppression can be accomplished by assigning each satellite server its own user credential, then adding or revoking permissions for each of the respective credentials. Completely suppressing an existing satellite Fossil server would require either deleting the satellite's repository (on the satellite server's machine) or blocking access at the network level. > * the possibility to segregate tickets by office (I think that can > be done with tags and maybe branches) > You could configure an additional field in tickets to contain an office ID. Each satellite server would need to be configured to insert that ID when a ticket is created. > > The first step in our use of it would be for the wiki and the ticket > system. Do ticket get replicated automatically to a central server when the > user clicks "send" ? or does this require other user action ? Same for > answers from a central office that would get posted to a central server, do > satellite users need to do something to receive new data, or is it > automatically pushed to satellite office servers ? > As I previously stated, Fossil does not consider ticket changes to be auto-sync events. However.... Many projects using Fossil simply use a cron job to periodically sync between sites. The down side of this is that a minimum of a few hundred bytes will be exchanged in each direction, every time. On-demand sync could be accomplished with the aid of a tool (external to Fossil) triggered by Fossil's RSS feed. (I've heard that Fossil now has some kind of ticket change hook for its built-in scripting language. It might be possible to trigger the (external to Fossil) tool.) The tool would then command Fossil to sync to the central server. > Do the tickets support the limitation in size of artifacts attached to > them ? > > It happens sometimes that satellite office use diverging code compared to > our main branch. Is it possible to segregate the tickets by branch ? and is > it possible perhaps to synchronise a satellite server only on one branch of > the main server ? > > Is there a way to see when a satellite server has replicated a ticket to > the central server ? > Maybe use Fossil's RSS feed from the central server. > > Also I can easily see the wiki interface being used as a distributed help > and documentation system by the technical minded people at each sites. But > there needs to be some measure of control in this area for us. Is it > possible currently to show only the latest "approved pages" and along that > modifications that have been proposed by users ? Is merging of wiki pages > possible ? > Fossil actually has 2 wikis. The original built-in wiki and "embedded documentation". Adding/updating "built-in wiki" pages is through the Fossil web interface. Adding/updating embedded documents is the same as adding/updating source code (and other project files). Viewing of either type of wiki page through a web browser works the same. So, I can think of 2 possibilities offhand: 1. Use the "built-in wiki" pages as the published pages while adds/updates are done on the "embedded documentation" wiki pages. When an update (or new page) is ready for publishing, someone with permission to update "built-in wiki" pages would then publish the approved version. I recommend this because all Fossil version control features are available to "embedded documentation" pages. The disadvantage is that editing the requires using an external tool (though Fossil has a command for previewing the pages (locally) before committing; the updated page would have to be committed before other users could see it, but that's no different from updating "built-in wiki" pages). 2. Use the "embedded documentation" pages as the published pages while adds/updates are done on the "built-in wiki" pages. While this allows using Fossil's web interface to edit wiki pages, currently only the most recent version of a given page is view-able or update-able. (The changes are still saved, just no easy way to access them.) > Does the wiki support images ? > Yes > > Anybody knows of something that allows tracking and answering tickets from > a mobile phone ? > Fossil's web interface is usable from a mobile phone or tablet that has a web browser.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
