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. > > To give you some background : We have a central office with satellite > offices. The satellite offices are on ships, so they very often are > disconnected, and they suffer from low bandwidth and high latency > connections (satellite connections in the very space and stars sense of the > term). We have many (10-100) users in each ship/office. Some users are > teams, some users are individuals. Basically the satellite users mostly get > support from the central office. Sometimes this support needs to happen in > near realtime and is so done by email (which prevents any easy history > tracking and knowledge spreading). > > 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. > My mains goals are : > * speedy user interface for every one. (central or satellite > office) > Fossil is very good at that. > * low use of bandwidth btw offices (meaning no user go and try to > talk to the central server from a satellite office). > Fossil is very good at this too. > * low latency in ticket replication (seconds desired, a few > minutes at the most) between offices. > Tickets go immediately to the local server on ship. But they are only sent to the central server at the next synchronization event. You can set up to do synchronization (via a cron job) as often as you like, but the more frequently you do so, the more bandwidth you'll use. For a long time now, we've been wanting to add on-demand-synchronization between servers. In other words, servers sync with each other immediately when they have something to share. This turns out to be difficult to do with a CGI-based server, or we would have probably done so already. It is much, much easier to do when Fossil is running as a stand-alone server or as an SCGI server. But if we add the capability, we'd like it to work for all server configurations, not just all-but-CGI. > Other desirable features : > * ease of creation or suppression of a satellite office > Fossil treats all systems as peers. All servers hold all content. There is no way to segregate. > * the possibility to segregate tickets by office (I think that can > be done with tags and maybe branches) > See the previous. > > 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 ? > Do the tickets support the limitation in size of artifacts attached to > them ? > Right now, you'd need to run "fossil sync" on the satellites whenever a change occurs, in order for that change to propagate. On the SQLite project (for which Fossil was designed and written) we use a cron job to run "fossil sync" every few hours - which gives us all the synchronicity that we require. It sounds as if you have much tighter real-time demands. Fossil is going to have a difficult time doing what you want, I think, without some enhancements. Would you like to contribute? FWIW, many of the ideas in Fossil are informed by a system I developed on 15 years ago that involved real-time collaboration between a central office and multiple satellites, many of which were on aircraft and had slow and intermittent network connectivity. This was *real-time* collaboration, such that when a dude at headquarters made a change, that change was immediately and automatically visible on the screens of (connected) satellite coworkers. When networking was restored after an outage, everything automatically synced up. So I have some familiarity with what you are trying to do and of the difficulties in getting it to work well. Fossil *might* be helpful your scenario. But you might also want to look into a custom real-time solution. Fossil was originally designed for a slower pace of collaboration. Such as checking in a change or commenting on a ticket from poolside, or while waiting to board a flight, or while sitting on the balcony of a hotel room overlooking the Black Sea. In other words, a more relaxed pace. I'm not saying that Fossil can't be made to do what you want, but what you describe seems outside its original design scope. > > 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 ? > > No. All servers see all content. If satellites what to start their own branch, that's fine. But that branch will be replicated to the central server and to all other satellites. (Call that "distributed backup" if you like. It's a feature, not a bug.) > Is there a way to see when a satellite server has replicated a ticket to > the central server ? > Not really. I mean, you could look on the central server to see what info it had. But I don't think that is what you have in mind. > > 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 ? > Does the wiki support images ? > Wiki does support images. No problems there. The Fossil infrastructure is set up to support merge for divergent wiki edits, but that is not something that has ever been implemented because the need has never before arisen. > > Anybody knows of something that allows tracking and answering tickets from > a mobile phone ? > I use the web-browser on my android phone to check the status of my projects when I am away from the office. It works. Not the most sexy approach, but it works fine. > > Thanks in advance for your input. > > Brgds, > Charles. > > This e-mail, including any attachments and response string, may contain > proprietary information which is confidential and may be legally > privileged. It is for the intended recipient only. If you are not the > intended recipient or transmission error has misdirected this e-mail, > please notify the author by return e-mail and delete this message and any > attachment immediately. If you are not the intended recipient you must not > use, disclose, distribute, forward, copy, print or rely on this e-mail in > any way except as permitted by the author. > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
