On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland <estifo...@gmail.com> wrote:
> The discussion on keeping the location of checkouts in the repo deb > brought up an interesting thought. > > Observing the usage in our teams it is apparent that the distributed > nature of fossil is more of a burden than a benefit 90% of the time but > that remaining 10% of the time we very much appreciate the flexibility of > distributed scm. One model of usage that fossil seems very close to being > able to support is a centralized single db with optional distributed > cloning where needed. > > You store the master repo on NFS group writeable with group sticky bit on > the directory. All users open directly from that repo db. There is no sync > and no local copies of the db. This makes fossil blazingly fast (try doing > some fossil operations with sync turned off to see what I mean) and for a > closely knit fast moving team seeing what others are doing in near real > time is highly desirable. > > So far as I know there are only two things needed to make this usage model > a reality. > > 1. Long timeout, multiple retries or a graceful exit with "please try > again in one minute" on db access collisions. > 2. User name handling on local access should respect the environment $USER > and not the first entry in the users table. > The first entry in the user table is only selected if the USER environment variable is not set. The username is determined as shown at http://www.fossil-scm.org/fossil/artifact/128e900b12e?ln=298-312 source code. Assuming you have not set a default user for the repository (and probably you have not) then the USER environment variable will usually be the option that wins. > > Note: NFS file locking seems very reliable and I use sqlite3 successfully > with over a hundred processes spread over many machines by using long > timeouts and few joins. > That has never been my experience with NFS. I'm glad it works better for you than it does for me. > > Making this model work for teams of up to 10 or so people seems viable. > So, is this feasible? Are there other gotcha's lurking in the design and > implementation of fossil that make this a bad idea? > > _______________________________________________ > 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
