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