On Wed, Oct 19, 2011 at 8:46 PM, Mike Meyer <m...@mired.org> wrote:
> On Wed, 19 Oct 2011 16:24:17 -0700
> Matt Welland <estifo...@gmail.com> wrote:
>
> > I sent out a description of how I think light weight "locks" could be
> > implemented on top of fossil in a past email. In fact I'm making some
> good
> > progress on implementing what I want in a wrapper around fossil
> (implement
> > locks in addition to some other things). I can look into making the
> wrapper
> > available if anyone is interested.
> >
> > As has been mentioned Locks are really helpful when managing data that
> can't
> > be automatically merged. However the need is not for draconian control
> but
> > more of a semaphore to prevent accidentally changing a binary file at the
> > same time someone else does.
> >
> > A more than adequate lock/semaphore methodology could be implemented on
> top
> > of fossil roughly like the following...
> >
> > files have two flags; lockcontrolled and lockstate
> >
> > User locks file(s): fossil lock file1 file2 ...
> > 1. Write permissions are removed
> > 2. Lockcontrolled flag is set
> > 3. Lockstate is set.
> > 4. Sync
>
> Suggestion: If autosync is not enabled, treat this as an
> error. Override with -force.
>
Good point. However using the wrapper I take over all calls to fossil and
can do what is needed. If building this into fossil itself then the problem
is a bit harder.
> What happens if you find out that someone else has locked the file
> during the sync? Do you then revert all the changes you made and fail?
>
Terminology is a bit clumsy here. The word lock seems to get us in trouble.
This is the model I'm implementing:
term lockcontrolled lockstate writeable
------ -------------- --------- ---------
normal false don't care yes
locked true true no
unlocked true false yes (only by locker)
Going from normal to locked is the dangerous (as in potentially confusing)
step. That step should be accompanied by an email for all to do a
sync/update before and after.
Going from locked to unlocked for edit is quite safe. The wrapper requests
the unlock from the central repo and either gets it or not. Only if it gets
the unlock does it open up permissions on the file and notify the user. This
is not a distributed action (at least for my wrapper).
> > On check out
> > 1. Files locked by others have write perms removed
>
> So the lock is on the file, at all revisions? Are the same file on
> different branches considered different files in this case?
>
The way I'm implementing it a path/file will be locked/unlocked for all
branches and revisions. Of course this is not a big brother system, users
are free to override and screw the other folks on the team. Such moves might
be career limiting of course since they have enough information to do the
right thing and a record is available as to what really happened.
> > On commit
> > 1. Changed locked files cause an error, override with -force
> >
> > On update
> > 1. Update write permissions per the flags.
> > 2. A locally changed locked file causes a merge failure
>
> If locks aren't specific to a revision, shouldn't this happen on a
> pull (or the pull part of a sync) and not an update?
>
Yes, you are right. Keep in mind that I'm cheating in all this by keeping
the lock data in a separate sqlite3 db and can manage the locks on every
call to fossil. Doing the right thing as part of fossil itself would be a
bit harder I think.
> > On unlock for edit
> > 1. If file not already locked....
> > 2. Update flags, sync
> > 3. Open permissions
> >
> > Or something like that. I think the closely coupled agressive sync model
> > fostered by fossil makes this very doable.
>
> So long as you've got either one central server, or a collection of
> very tightly synchronized servers, it should help a lot. Here, tightly
> synchronized means "synchronized much more frequently than pushes come
> in from developers."
>
Yes, very true.
> Personally, I still think this is a lot of work to go through to adopt
> one tool for a job that other tools are designed to do. Sort of like
> building a claw hammer fitting for a screwdriver.
>
Good point. In fact we are using two systems in parallel for this very
reason fossil and another system with rigorous locking. Using the wrapper
for locking is really an experiment I'm doing on my own time that may well
not pan out.
<mike
> --
> Mike Meyer <m...@mired.org> http://www.mired.org/
> Independent Software developer/SCM consultant, email for more information.
>
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.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
