On Wed, Oct 19, 2011 at 06:42:21PM -0400, Richard Hipp wrote: > On Wed, Oct 19, 2011 at 6:17 PM, Michael Barrow <mich...@barrow.me> wrote: > > > No -- please no locks! > > > > > Concur. Locks are out-of-band for Fossil. If anybody thinks they really, > really need locks, I'll be happy to offer them a referral to Veracity.
I think something similar could be said about other fossil features; any feature is a plus for fossil. You also mentioned some implementation of a checklist. In a good situation, every developer in a repository will know what will be easy to merge and what not, and they should know that they have to speak with the rest of the team to edit that. And then those in the team have to remember that someone is editing that. But in a worse case, this system may fail, and some little infrastructure provided by fossil could be helpful. But, of course, first we should have a great idea to implement. :) I don't know how veracity deals with locks, but I think that they should not only be able to protect against in-branch editions, but also between branches, when there are future merges planned. With a VCS where people do a lot of feature-branches (we use fossil this way here), in-branch locks may be of little help. Regards, Lluís. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
