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
