Hi, Thanks for you answer Richard. As I’m using annoying outlook, I’ll answer on top rather than try and fudge indents, sorry about that.
On Fossil sync speeds and would I like to collaborate : Maybe ☺ but sql and c are not my strong points, I’m more of a python tinkerer… One question stick up in my mind. Can a server handle fsyncs from multiple peers at the same time ? Satellite offices have tens or hundreds of users, but very few contributors. Triggering fsync upon each repo modification might just be viable. On branches and tickets visibility: I grasp that everything gets replicated to every servers. But is it possible in the interface to sort tickets by branches/tags sort of easily ? Is it also possible to have branches on the wiki ? Something I’m curious of: How are user accounts managed ? per server I’d imagine ? Can you walk me thru what happens once a user has been created on a server, the next time fsync is run ? How do user rights tie into this ? On finding another custom solution: Yeah I’m actively trying to avoid writing my own. And fossil looks really nice, almost all the features are there… Any projects you know that are sort of equivalent but different ?... Funny that system you worked on reminds me of a story from a friend at boeing, but it could just as well be a news agency or an intelligence agency …. Cheers a bunch ! Charles. From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp Sent: 15 August 2014 21:48 To: Fossil SCM user's discussion Subject: Re: [fossil-users] available topologies for syncing and other misc questions On Fri, Aug 15, 2014 at 10:25 AM, Charles Curtit <charles.cur...@pgs.com<mailto: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<mailto:fossil-users@lists.fossil-scm.org> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org<mailto: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
