[fossil-users] More thoughts on locks
Lluís Batlle i Rossell
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...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Chris Peachment
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?
Matt Welland
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.
Michael Barrow
Lluís Batlle i Rossell
> 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.
Mike Meyer
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.
Lluís Batlle i Rossell
> 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.
Brian Cottingham
Lluís Batlle i Rossell
> On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment <ch...@ononbb.com> 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.
Mike Meyer
On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote:
> On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment <ch...@ononbb.com> 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.
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".
Lluís Batlle i Rossell
> 2011/10/20 Lluís Batlle i Rossell <viri...@gmail.com>
>
> > On Thu, Oct 20, 2011 at 11:07:23AM -0700, Mike Meyer wrote:
> > > On Thu, Oct 20, 2011 at 10:54 AM, Chris Peachment <ch...@ononbb.com>
> > 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
Ron Wilson
> 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.