Re: [fossil-users] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell : > On Thu, Oct 20, 2011 at 11:31:01AM -0700, Mike Meyer wrote: >> Hmm - maybe the "readonly-glob" setting is enough? If it's not set, you get >> the current behavior. Otherwise, you check it when you pull files out of the >> repository (to set them read-only) or commit (unless -force is on). That >> also fixes the question of retroactively setting the flag. But it might be >> to expensive. > > I think it's becoming more and more a "quick hack". :) Richard has already said "No" to locks in Fossil, so a Read Only mechanism of some kind would be the only option. I think that a "readonly-glob" setting should be sufficient. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
On Thu, Oct 20, 2011 at 11:31:01AM -0700, Mike Meyer wrote: > 2011/10/20 Lluís Batlle i Rossell > > > On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: > > > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment > > wrote: > > > How about an having a way to flag files - when created - as "read-only" > > or > > > some such. (I think someone else may have suggested this). Such files > > would > > > be checked out read only, and would require a "-force" to commit. A new > > > "readonly-glob" setting would help - causing files that matched it to be > > > flagged as such along the way. > > > > > > The goal is not to have locks as such, but to alert people to the fact > > that > > > a file requires out-of-band communications before it gets changed and/or > > > committed. > > > > It looks very nice, but that should be able to be set on past checkins too, > > the > > same way you edit checkins to change tags. Otherwise, "when created" sounds > > very > > limiting. > > > > Two issues. One is that it really belongs on files, not checkins. The other > is that you have to figure out what to do about files derived from that one > when you set the flag retroactively. I'm still not sure on what would I prefer. I still have 'artifacts' in mind. > Hmm - maybe the "readonly-glob" setting is enough? If it's not set, you get > the current behavior. Otherwise, you check it when you pull files out of the > repository (to set them read-only) or commit (unless -force is on). That > also fixes the question of retroactively setting the flag. But it might be > to expensive. I think it's becoming more and more a "quick hack". :) Listing some features that people may expect for "needs-lock" files: 1. Avoid editing what someone already edited in another checkin, and can be merged with the branch where you plan the edit. 2. Avoid editing what another is already editing in the working dir, and can be merged with the branch where you plan the edit. For the case 2, team communication can be ideal. But for case 1, also memory plays a role, so team communication may not be the perfect solution. :) I'd expect an optional locking system to provide an alert for both cases. But maybe it is expect too much. But in five minutes I may think different. :) 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
Re: [fossil-users] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell > On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: > > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment > wrote: > > How about an having a way to flag files - when created - as "read-only" > or > > some such. (I think someone else may have suggested this). Such files > would > > be checked out read only, and would require a "-force" to commit. A new > > "readonly-glob" setting would help - causing files that matched it to be > > flagged as such along the way. > > > > The goal is not to have locks as such, but to alert people to the fact > that > > a file requires out-of-band communications before it gets changed and/or > > committed. > > It looks very nice, but that should be able to be set on past checkins too, > the > same way you edit checkins to change tags. Otherwise, "when created" sounds > very > limiting. > Two issues. One is that it really belongs on files, not checkins. The other is that you have to figure out what to do about files derived from that one when you set the flag retroactively. > We don't have anything like file tags, other than the executable bit. And > changing this detail may involve a change in the manifests some new > artifact > types. > > I think that something that worked as propagated-tags, but could set files > readonly, would be great. That would help accross branches, and also allow > avoid locking files in subgraphs. Would fossil stand some dozens of > propagated > tags with long names? of the kind "readonly:PATH". > To bad "easy to describe" doesn't imply "easy to implement". Having a real file properties solution would make this easy. Hmm - maybe the "readonly-glob" setting is enough? If it's not set, you get the current behavior. Otherwise, you check it when you pull files out of the repository (to set them read-only) or commit (unless -force is on). That also fixes the question of retroactively setting the flag. But it might be to expensive. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote: > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment wrote: > The problem is that locking in a distributed environment is hard to do > reliably. "Mostly" reliable could well be worse than no locking at all: you > start to depend on it, and it will then naturally fail at the worst possible > moment. I think there is some better-than-nothing approach here. I saw that veracity has locks only in-branch, that for me means quite useless locks. Can't we do something better? :) > How about an having a way to flag files - when created - as "read-only" or > some such. (I think someone else may have suggested this). Such files would > be checked out read only, and would require a "-force" to commit. A new > "readonly-glob" setting would help - causing files that matched it to be > flagged as such along the way. > > The goal is not to have locks as such, but to alert people to the fact that > a file requires out-of-band communications before it gets changed and/or > committed. It looks very nice, but that should be able to be set on past checkins too, the same way you edit checkins to change tags. Otherwise, "when created" sounds very limiting. We don't have anything like file tags, other than the executable bit. And changing this detail may involve a change in the manifests some new artifact types. I think that something that worked as propagated-tags, but could set files readonly, would be great. That would help accross branches, and also allow avoid locking files in subgraphs. Would fossil stand some dozens of propagated tags with long names? of the kind "readonly:PATH". 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
Re: [fossil-users] More thoughts on locks
This is my favorite approach so far- simple, straightforward, and no complications related to offline commits or someone forgetting to remove a lock. On Thu, Oct 20, 2011 at 2:07 PM, Mike Meyer wrote: > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment wrote: > >> I'm a novice Fossil user working in a small group with need >> to track both text and binary files. >> >> It seems to me that locks are nice to have for text files >> since 3 way diffs can be merged at relatively little cost. >> But inability to merge binary files might mean painful hand >> merging based on side by side comparisons for word processing >> documents or presentation slides, or based on repeating the >> edits for image files. >> >> So a lock would provide immediate warning when attempting >> checkout that someone else is probably touching the file. >> Out of band communication would be needed to gain access >> - not a bad thing and better than proceeding blindly. >> > > The problem is that locking in a distributed environment is hard to do > reliably. "Mostly" reliable could well be worse than no locking at all: you > start to depend on it, and it will then naturally fail at the worst possible > moment. > > How about an having a way to flag files - when created - as "read-only" or > some such. (I think someone else may have suggested this). Such files would > be checked out read only, and would require a "-force" to commit. A new > "readonly-glob" setting would help - causing files that matched it to be > flagged as such along the way. > > The goal is not to have locks as such, but to alert people to the fact that > a file requires out-of-band communications before it gets changed and/or > committed. > > > > ___ > 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
Re: [fossil-users] More thoughts on locks
On Thu, Oct 20, 2011 at 11:05:33AM -0700, Michael Barrow wrote: > 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' That's a fallback that some teams may agree. If we have users that would better use locks instead of common edit of a wiki page... maybe we can provide a nicer solution to them. > Friends don't let friends use locks in their DVCSes I've always meant informative locks, always bypassable... I think you may be thinking of enforced locks, forbidding commits or something simliar. I would not like that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment wrote: > I'm a novice Fossil user working in a small group with need > to track both text and binary files. > > It seems to me that locks are nice to have for text files > since 3 way diffs can be merged at relatively little cost. > But inability to merge binary files might mean painful hand > merging based on side by side comparisons for word processing > documents or presentation slides, or based on repeating the > edits for image files. > > So a lock would provide immediate warning when attempting > checkout that someone else is probably touching the file. > Out of band communication would be needed to gain access > - not a bad thing and better than proceeding blindly. > The problem is that locking in a distributed environment is hard to do reliably. "Mostly" reliable could well be worse than no locking at all: you start to depend on it, and it will then naturally fail at the worst possible moment. How about an having a way to flag files - when created - as "read-only" or some such. (I think someone else may have suggested this). Such files would be checked out read only, and would require a "-force" to commit. A new "readonly-glob" setting would help - causing files that matched it to be flagged as such along the way. The goal is not to have locks as such, but to alert people to the fact that a file requires out-of-band communications before it gets changed and/or committed. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
On Thu, Oct 20, 2011 at 01:54:19PM -0400, Chris Peachment wrote: > So a lock would provide immediate warning when attempting > checkout that someone else is probably touching the file. > Out of band communication would be needed to gain access > - not a bad thing and better than proceeding blindly. > Yes, I really mean a *warning*, and not a blocker for any operation. A "--force" (or chmod +w) should bypass locks easily. But at least the user would have done extra work to edit the file. > Locking should be optional to retain current behaviour for > those users wanting it. Well, locking nothing should be an easy equivalent. > How would the person doing the checkout that created the > lock know this fact, as encouragement to avoid long lockout > periods? long lockout periods could be fixed by the admin of the central repository, similar to the same way an artifact can be unshunned. If that does not work for the team, they better stop using locks. Any user should use the features only if they help them. > How would their repository know they owned the lock? If a file needs-lock, it would be readonly. The user should issue a fossil operation (fossil edit myfile.txt); that would do the proper network communication with the default remote, asking for the lock, and if succeeded, setting write permission to the file. On commit or an unlock operation (fossil unedit myfile.txt), the readonly permission would be set again. > Since a commit generates a new artefact, how does the old, > locked one, get unlocked? Well, I did not think much on old artifacts. I think the lock could be kept always, unless an admin says the opposite. It would be nice to know that the artifact is not only locked, but it already derived into another locked artifact. That could be reported by "fossil edit myfile.txt". Regards, Lluís. > On Thu, 2011-10-20 at 19:22 +0200, Lluís Batlle i Rossell wrote: > > 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. > > > > 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. > > > > 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. > > ___ > > 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] More thoughts on locks
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 wrote: > 2011/10/20 Lluís Batlle i Rossell > >> 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 >> 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
Re: [fossil-users] More thoughts on locks
2011/10/20 Lluís Batlle i Rossell > 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 > 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
Re: [fossil-users] More thoughts on locks
I'm a novice Fossil user working in a small group with need to track both text and binary files. It seems to me that locks are nice to have for text files since 3 way diffs can be merged at relatively little cost. But inability to merge binary files might mean painful hand merging based on side by side comparisons for word processing documents or presentation slides, or based on repeating the edits for image files. So a lock would provide immediate warning when attempting checkout that someone else is probably touching the file. Out of band communication would be needed to gain access - not a bad thing and better than proceeding blindly. Locking artefacts provides a good way to split the chain of past and current versions. Locking should be optional to retain current behaviour for those users wanting it. How would the person doing the checkout that created the lock know this fact, as encouragement to avoid long lockout periods? How would their repository know they owned the lock? Since a commit generates a new artefact, how does the old, locked one, get unlocked? On Thu, 2011-10-20 at 19:22 +0200, Lluís Batlle i Rossell wrote: > 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. > > 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. > > 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. > ___ > 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
[fossil-users] More thoughts on locks
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. 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. 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
