I just wanted to point out that Fossil has a Wiki and ticketing system built into it; these are two other methods that could be used to communicate with other team members that you would be working on something that they should not touch. I'm just sayin'....
Friends don't let friends use locks in their DVCSes.... On Thu, Oct 20, 2011 at 10:57 AM, Matt Welland <[email protected]> wrote: > 2011/10/20 Lluís Batlle i Rossell <[email protected]> > >> Thinking as if we had to implement locks some day... >> >> I just thought that we could have locks working not on >> file-paths-in-branch, but >> on artifacts. That would expand well to multiple branches. >> >> Then, if anyone gets the lock, and commits a new version, it could get >> locked >> automatically too, expanding the list of artifacts needing lock. >> > > Actually I think you might be right on locking across branches though I'm > not 100% sure. The described mechanism sounds like a really good approach. > > >> Those artifacts that 'require lock' for edition could be checked out >> read-only. >> >> The list of locked artifacts could expand similar to the shun list, that >> can be >> told to be updated on autosync. And the list of lock owners too. Keeping >> the >> default remote as the source of locks. > > > >> And apart, not requiring a locks implementation, there could be a fossil >> default-off option to simply check out binary files readonly (fossil seems >> to >> know what file is binary and what not). That would put a step before >> binary-file >> editions, inviting to team communication. >> > > This is a good idea I think. It does depend on good behavior of the tools > however. For example the schematic editor in use here will clearly indicate > that the file was opened read-only and it will not allow edits but I've seen > tools that allow you to start editing and then you can't save because the > file is read-only. Of course bad tools is no reason to hesitate implementing > a good idea. > > >> If anyone think locks could help in their use of fossil, that chould give >> an >> opinion on this. I work either in a small team or alone, so I'm not very >> representative on this. >> > > I'm 99.9% certain that if locking of some sort were available that I could > expand the use of fossil to certain binary files in our team. > > Interestingly I ran into a scenario where I wish I had locks for my lone > use of fossil. I have documentation in Lyx format and although Lyx files can > sometimes be merged it isn't easy to resolve conflicts if you make lots of > changes. I had forgotten that I made some substantial changes on a branch > and edited my Lyx doc on the trunk. It took me over an hour to resolve the > differences and get Lyx to read the merged doc. > > If locks were available I'd personally keep Lyx files, graphics (even svg) > and other not-easy-to-merge files "locked" so that I don't unknowingly edit > them in parallel on different computers or different branches. > > > >> _______________________________________________ >> fossil-users mailing list >> [email protected] >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> > > > _______________________________________________ > fossil-users mailing list > [email protected] > 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 [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
