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. 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. 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
