2011/10/19 Lluís Batlle i Rossell <virik...@gmail.com> > On Wed, Oct 19, 2011 at 09:38:44AM -0700, Mike Meyer wrote: > > This requires a lot of work on fossils part in order to be reliable. > If I had to implement that on fossil, I'd use some kind of table like the > shun > table, propagated on autosync, that would ban a commit modifying a file. > 'commit' could have a '--force', that would bypass the locks. I think they > should be informative, and not restrictive.
> But it's not only locks alone that help, because that would depend on how > often > you sync, and you would notice new locks only when syncing, and that would > be > already late, because you may have already modified the file in your > working > directory, requiring a complex merge. > That's what I meant by "a lot of work on fossils part to be reliable." Whether the lock command fails to create a lock or warns you if someone else has a lock is immaterial, they both take the same amount of work to figure out if someone else has a lock. If it isn't reliable, then it doesn't really solve the problem. And being reliable is a lot of work. No, I take that back. You could force locking to use a central server model. For each repository, you have to set a repository as the "lock server". Using "self" or some such would mean "You are the lock sever". The lock command could then either handle the lock locally, or request it from a remote server. Otherwise, you need a distributed lock manager, which is a hard enough problem to warrant it's own project. > Svn introduces the property of files of "needs_lock". Those files, once > checked > out, are checked out in read-only into disk, and get the writeable state > only if > properly got a lock. Of course read-only-ness can be bypassed by the user > owning > the file, and that also has only an informative role. Maybe something like > propagated tags could mark files as needs_lock, and act accordingly on > updates/checkouts/... > SVN has a central server, thus avoiding the hard problem. Once you've got that, "needs_lock" is a good idea for a SCM that uses a change/commit workflow instead of the checkout/change/commit workflow. <mike
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
