[fossil-users] Idea: Close coupled usage model for fossil
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
Re: [fossil-users] Idea: Close coupled usage model for fossil
On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland 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
Re: [fossil-users] Idea: Close coupled usage model for fossil
Hi, How can I unset the default user? I cannot see an option under fossil unset ...? Users that forget to: fossil commit -U myusername_notdefault have their changes assigned to the default and wrong user. On Mon, Apr 30, 2012 at 11:29 AM, Richard Hipp wrote: > > > On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Idea: Close coupled usage model for fossil
On Mon, Apr 30, 2012 at 12:19 PM, wrote: > Hi, > How can I unset the default user? > I cannot see an option under fossil unset ...? > Looks like you have to manually change the database. Run "fossil sql" then type: "DELETE FROM config WHERE name='default-user';" > > Users that forget to: > fossil commit -U myusername_notdefault > have their changes assigned to the default and wrong user. > > On Mon, Apr 30, 2012 at 11:29 AM, Richard Hipp wrote: > > > > > > On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland > 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 > > > ___ > 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
Re: [fossil-users] Idea: Close coupled usage model for fossil
Before trying your sql, I opened my repo with SQLiteExpert and found no entry in table config:name = 'default-user'? Is there a hidden location or is the default-user actually NOT set? Really confused since I want #3 below to happen BEFORE #2 :( User Name is determined from the following rules, in order: 1. The value of the --user or -U command-line option. 2. A username set using the "fossil user default" command 3. The value of the USER environment variable 4. An arbitrary user from the "user" table in the repository database. 5. "anonymous" On Mon, Apr 30, 2012 at 12:35 PM, Richard Hipp wrote: > > > On Mon, Apr 30, 2012 at 12:19 PM, wrote: >> >> Hi, >> How can I unset the default user? >> I cannot see an option under fossil unset ...? > > > Looks like you have to manually change the database. Run "fossil sql" then > type: "DELETE FROM config WHERE name='default-user';" > >> >> >> Users that forget to: >> fossil commit -U myusername_notdefault >> have their changes assigned to the default and wrong user. >> >> On Mon, Apr 30, 2012 at 11:29 AM, Richard Hipp wrote: >> > >> > >> > On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland >> > 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 >> > >> ___ >> 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 > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Idea: Close coupled usage model for fossil
On Mon, Apr 30, 2012 at 2:01 PM, wrote: > Before trying your sql, I opened my repo with SQLiteExpert and found > no entry in table config:name = 'default-user'? > Is there a hidden location or is the default-user actually NOT set? > Check the VVAR table in _FOSSIL_. It is probably set there. > > Really confused since I want #3 below to happen BEFORE #2 :( > User Name is determined from the following rules, in order: > 1. The value of the --user or -U command-line option. > 2. A username set using the "fossil user default" command > 3. The value of the USER environment variable > 4. An arbitrary user from the "user" table in the repository database. > 5. "anonymous" > > > On Mon, Apr 30, 2012 at 12:35 PM, Richard Hipp wrote: > > > > > > On Mon, Apr 30, 2012 at 12:19 PM, wrote: > >> > >> Hi, > >> How can I unset the default user? > >> I cannot see an option under fossil unset ...? > > > > > > Looks like you have to manually change the database. Run "fossil sql" > then > > type: "DELETE FROM config WHERE name='default-user';" > > > >> > >> > >> Users that forget to: > >> fossil commit -U myusername_notdefault > >> have their changes assigned to the default and wrong user. > >> > >> On Mon, Apr 30, 2012 at 11:29 AM, Richard Hipp wrote: > >> > > >> > > >> > On Mon, Apr 30, 2012 at 11:13 AM, Matt Welland > >> > 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-312source > >> > 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 > >> > > >> ___ > >> 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 > > > ___ > fossil-users mailing list > fossil-users@lists.
Re: [fossil-users] Idea: Close coupled usage model for fossil
On Mon, Apr 30, 2012 at 8:01 PM, wrote: > Really confused since I want #3 below to happen BEFORE #2 :( > User Name is determined from the following rules, in order: > 1. The value of the --user or -U command-line option. > 2. A username set using the "fossil user default" command > 3. The value of the USER environment variable > The list from the source docs says something slightly different: 301 ** (1) Use the --user and -U command-line options. 302 ** 303 ** (2) If the local database is open, check in VVAR. 304 ** 305 ** (3) Check the default user in the repository 306 ** 307 ** (4) Try the USER environment variable. 308 ** 309 ** (5) Use the first user in the USER table. i didn't compare these with the code, but i'll use these numbers below... If we follow the often-seen conventions that config file entries can be overridden with CLI arg, and that $ENV vars often have a precedence between config file and CLI args (in my experience, anyway), i would argue that swapping 3 (config file) and 4 ($USER) would be the right (well, more conventional) thing to do. e.g. in PHP GET supersedes POST (by default), and POST supersedes (by default) COOKIES. The order of precedence generally (conventionally) corresponds to the ease with which a user can change these options (passing a URL param (GET) is easy for the user, POST is a bit more work, and working with cookies is generally even more work (or impossible, depending on the programming environment), thus PHP's default precedence ordering). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
