Re: [fossil-users] Locks (Was: Veracity)
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. Unlike source changes, you can't do a commit and then require a merge before pushing if there's a collision. There are also nasty restrictions on how you do things. In particular, you have to have autosync on (or ignore it if off) and be connected to all repositories you push/pull from to use it. Given those restrictions, if you're looking to change things to support fossil, wouldn't you be better off using a tool designed for managing binaries ( an artifact repository) instead of one designed for managing textual sources? I think fossil is a good tool for managing binaries too. And often binaries and textual sources better go together in a single repository. 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. 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/... 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com 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/... You found another use for propagating tags ;). As someone pointed out the original thread, fossil currently only allows tagging of commits, not files. Looking at the tagxref table, it's not clear to me whether that table supports (at least in principal) tagging individual files. If it does, tagging sounds like a good and simple solution to the advisory locking problem. -- - 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
Re: [fossil-users] Locks (Was: Veracity)
On Wed, Oct 19, 2011 at 07:27:56PM +0200, Stephan Beal wrote: 2011/10/19 Lluís Batlle i Rossell virik...@gmail.com 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/... You found another use for propagating tags ;). As someone pointed out the original thread, fossil currently only allows tagging of commits, not files. Looking at the tagxref table, it's not clear to me whether that table supports (at least in principal) tagging individual files. If it does, tagging sounds like a good and simple solution to the advisory locking problem. Well, the tags name or value could have the file name. Maybe, instead of tags, there could be a list like the versionable 'glob-ignore', of files that require locks. Those could be checked out with read-only permissions. That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. 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] Locks (Was: Veracity)
2011/10/19 Lluís Batlle i Rossell virik...@gmail.com Well, the tags name or value could have the file name. That's an idea. But we would also need the branch, wouldn't we? Or does the tag follow the branch? Maybe, instead of tags, there could be a list like the versionable 'glob-ignore', of files that require locks. Those could be checked out with read-only permissions. That sounds reasonably simple to implement and is probably flexible enough to handle most cases (where people have either a few binary files of different types or large collections which all match a wildcard or two). That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. Can we do read-only cross-platform (i.e. Windows)? But the needs-lock tag also has the sync problem - the tag would need to be in place before the checkout. And update would be more complicated because fossil would have to temporarily overwrite (and potentially revert) the permissions in order to perform an update. Hmmm. -- - 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
Re: [fossil-users] Locks (Was: Veracity)
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
Re: [fossil-users] Locks (Was: Veracity)
On Wed, Oct 19, 2011 at 07:41:56PM +0200, Stephan Beal wrote: That could even help even before fossil having a capability of centraliising locks; the read-only permissions could be enough for the people in a team to decide on the locks. Can we do read-only cross-platform (i.e. Windows)? Microsoft filesystems have support for a special file attribute which controls whether the file should be considered read-only. It is advisory. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
