On Mon, Apr 30, 2012 at 2:01 PM, <sky5w...@gmail.com> 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 <d...@sqlite.org> wrote: > > > > > > On Mon, Apr 30, 2012 at 12:19 PM, <sky5w...@gmail.com> 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 <d...@sqlite.org> wrote: > >> > > >> > > >> > 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-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.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
