Comment 3 for bug 109730

On Tue, 2007-04-24 at 22:06 +0000, John A Meinel wrote:
> I think you are mistaken in how the workflow works with Bazaar.

Yes and no. Using Bazaar (or Mercurial. Git, etc.) in a distributed way
means the concept of locking per se is not an issue. I think it will
lead to problem dealing with binary file formats such as Word files and
FrameMaker files since as far as I am aware there is no sensible way of
merging independent changes on such files.

Using Bazaar as a central repository, I think there is an issue.

It all comes down to the issue of whether there is a sensible way of
merging some file types or whether only UTF-8 encoded (or other
encodings I suppose) text files can be merged. As I understand the Word
and FrameMaker formats, merging is not feasible so a sequential workflow
is required, which means some form of locking is required.

> We don't support modifying individual files separately. You modify the
> whole tree at a time. So it isn't possible to lock "just a couple
> files".

Is this any different from Subversion? Subversion updates a file but
this is a whole repository operation. Originally Subversion had no
individual file locking but it was introduced I suspect exactly for the
use case I am worrying about now.

> Further, when working in "centralized" mode with a checkout, you cannot
> commit without updating (as we do lock the remote repository while doing
> the local commit).

The issue is not the atomicity of the update, I assume that is the case
in all modern version control systems, the issue is the merging of
binary format files.

> So if someone modifies a file that you are working on, and manages to
> commit before you do, when you update you will get a conflicted file
> (though it will probably just dump 2 copies into the working tree if it
> realizes that they aren't text files).

This is fine for text files where difference algorithms can make some
sense of the situation. So MML files would be fine since they are just
text files with markup. However for the FrameMaker binary format, it is
not clear that any such algorithm can do the right thing. I will have
to check what it is that Subversion does but I don't think it just dumps
updated binary files in the repository,I think it has a differencing
system for them. With sequential updates this is no problem but because
the file format has non-local effects on update merging is not possible
in general -- unless of course my understanding if this is wrong, but in
that case why did Subversion introduce locks at all?

> We do have the functionality to lock a remote branch (and leave it in a
> locked state). And it wouldn't be too hard to update the code base so if
> it knows it already has the remote lock it re-uses it.

I am not thinking of code (that is just text :-), I am thinking
FrameMaker for books. Repository locking is important for atomicity of
update but not useful for the problem I think I have.

> But *I* would consider it bad form to allow users to leave remote
> branches locked.

Agreed. No argument there :-)

> I would actually recommend that "independent concurrent updates" will
> happen no matter what you do. (If someone has a checkout, they can
> always convert it to an independent branch and just do a local
> commit).

I understand that distributed use must allow this, and for use with
source code, I don't actually see an issue. My problem is providing a
shared versioned filestore for binary format document files. For this
use case, I think being able to lock either individual files or a
sub-directory of the hierarchy is necessary.

> I do see that having a way to say "I'm working on this, you probably
> want to wait until I'm done" could be useful. I'm not sure that it
> belongs in the VCS.

Subversion started with this view, and then the development team changed
their minds and added individual file locking. It turned out to be
exceedingly useful even if rarely used. It is possible to have a token
passing system outside the VCS -- indeed I had one prior to Subversion
adding locking -- and for really distributed working, this is essential.
However, for use in centralized mode, I think the situation is very
different. I argue therefore that being able to lock individual files
on a repository that has checkouts would be a very useful feature.

PS I hope that this thread is not inappropriate, I was talking this
through with someone I know and their comment was "File a bug." So I
did.
--
Russel.
====================================================
Dr Russel Winder +44 20 7585 2200
41 Buckmaster Road +44 7770 465 077
London SW11 1EN, UK <email address hidden>