On Wed, Oct 19, 2011 at 4:28 PM, Michael Barrow <mich...@barrow.me> wrote:
> I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a > plane (without wifi, of course) and I want to edit a binary file, I'd be > hosed because I wouldn't be able to push the lock to the "central" server. > Sure it would help a little. If the files were previously locked then you *know* you are taking a risk making changes that may have to be discarded or tediously manually merged. If you knew you were likely to edit the files on the plane then mark them for edit while you still have Wifi at the airport. Then when your coworker goes to open them she will see that you have taken the edit lock and will know it is best to wait. Simple, clean and workable with fossil thanks to the (brilliant) autosync methodology. As described in another thread they are similar to a tag but at a file granularity and with the side effect of changing the write permission on the file. Again, lock is too strong a word. Think semaphore. You are just trying to make it easier for people to know who is working on what without a mass of tiresome one line emails such as "don't edit the schematics today!" > What if, like the Fossil main repo for example, there are two central > servers? > Tags are synced between the two servers just fine right? > I do like your approach of a wrapper so that crazy lock stuff doesn't > destroy the pristine awesomeness of Fossil itself. :-) > Agreed :) > > On Wed, Oct 19, 2011 at 4:24 PM, 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 >> >> On check out >> 1. Files locked by others have write perms removed >> >> 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 >> >> 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. >> >> Matt >> -=- >> >> On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal <sgb...@googlemail.com>wrote: >> >>> On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal <sgb...@googlemail.com>wrote: >>> >>>> On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski < >>>> l...@maxnet.org.pl> wrote: >>>> >>>>> >>>>> I seem to be still in the 80's... So how do you cope with edit >>>>> conflicts on binary files today? >>>>> >>>> >>>> i wasn't aware that people use them for binary files. i don't ever keep >>>> binary files in SCM, so i've never had that use case. >>>> >>> >>> Could a new "special" tag be used to implement lock-like behaviour? By >>> "special" i mean a reserved name (or name pattern, e.g. locked-by-USERNAME). >>> >>> -- >>> ----- stephan beal >>> http://wanderinghorse.net/home/stephan/ >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Michael Barrow > michael at barrow dot me > +1 (408) 782-4249 > > > _______________________________________________ > 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
