want an advisory exclusive lock on files/dirs

 Hi, Russel,
I have a link with program named valgrind.

http://freshmeat.net/projects/valgrind/

are you able to install an run the program it will try to get up on the
hardware or memory leak. It has been filed many time the ubiquity

 regards

bubba

On 4/24/07, Russel Winder <email address hidden> wrote:
>
> Public bug reported:
>
> If Bazaar is to be used in centralized mode as a replacement for
> Subversion then it needs a lock command so that files on the central
> repository can be locked. For binary files such as Word format or
> FrameMaker format files, independent concurrent updates cannot be
> sensibly merged, updating must be sequential.
>
> ** Affects: bzr (upstream)
> Importance: Undecided
> Status: Unconfirmed
>
> --
> Bazaar has no lock command
> https://bugs.launchpad.net/bugs/109730
> You received this bug notification because you are a member of Bazaar
> Developers, which is the registrant for Bazaar.
>

--
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFkcN7yXWcajQQndYRAgbqAKCMyXN9Jx4g0X7jocg+aUSFz0x4LwCgrURW
eGtqLjpzQVYa9+gzpCRtB84=
=zrpM
-----END PGP SIGNATURE-----

I think you are mistaken in how the workflow works with Bazaar.

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".

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).

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).

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.

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

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 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.

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, ...

On Wed, 2007-04-25 at 07:00 +0000, Russel Winder wrote:
>
> 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.

Bugs are good because they prevent the issue being lost.

I think for this though we should have a discussion on the mailing list
to get a broader set of input.

You are right that there is a real issue here. The problem then is not
acknowledging the issue but coming up with a solution that is:
 - scalable (large trees are more likely to have files needing this)
 - tasteful (must be understandable to users)
 - robust (e.g. in the face of the lock holder's machine dying)

Would you like to start the thread on the bazaar list?

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Wed, 2007-04-25 at 07:00 +0000, Russel Winder wrote:
>> 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.
>
> Bugs are good because they prevent the issue being lost.

This is true, but bugs are bad when they refer to issues that aren't
bugs, and don't demonstrate unambiguously-incorrect behavior. Making a
bug from a feature request is an assertion that "bzr is broken because
it doesn't meet my needs" and "this feature is the only acceptable way
for bzr to meet my needs".

This could be fixed by making Malone an *issue tracker* rather than a
bug tracker. Then this could be a feature request, or better yet, a
*user need*: "provide a sane workflow for people who use SVN to work
with binary files".

> I think for this though we should have a discussion on the mailing list
> to get a broader set of input.

That is another problem with just using a bugtracker. Feature requests
are often improved by list discussion,

I can imagine setting up Bundle Buggy to track "Feature requests" as
well as merge requests. They would be displayed in separate views. We
can make sure that non-subscribers can submit feature requests. That
would prevent requests from getting lost, and will keep feature requests
on the mailing list. What do you think of that idea?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGMLNl0F+nu1YWqI0RAl2CAJ4jj7iQ39YPDMlEC/iFSYkFGa8KJwCdHj6T
LYYKnUr+7Udz47l63DaLkoQ=
=xYzN
-----END PGP SIGNATURE-----

This is something that we should think about from time to time, and see if there is a way to handle. Probably the bug should be changed to "find a sane way to handle unmergable (binary) files" or something like that.

[Expired for Bazaar because there has been no activity for 60 days.]

Putting this back to 'confirmed'; we're not sure we want to do it but it may be useful as a plugin.

Locking files tends to lead to problems in my expierience as people dont't unlock files in a timely manner (or at all) hindering workflow. Obviously there is a problem with unmergable files, but I don't see an easy solution.

I am not up to date with the progress of metadata in bzr, but presumably a plugin could be written to set/check a "lock flag" in metadata. Of course, locks would only be enforced if the plugin was loaded, but it would provide something to try out.

In the mean time:

bzr mv document russel_is_editing_document
bzr ci

:-) or maybe not.

Unmergeable files (binary blobs) are really what this about, and use of locking is more or less mandatory -- though I fully appreciate the problems of allowing locking. Subversion's choice of unlock on commit is a good one and alleviates a great majority of the problems.

I had started on a plugin to support lock status metadata, but as the saying goes s$$$ happens, and I haven't really got beyond getting to the starting gate -- i.e I have a null plugin that loads.

If there were others with some cycles to help work on this, we could form a cabal (open to anyone of course) and use branches on Launchpad to progress things.

A number of people chipped in a lot of good ideas about this on the mailing list some time back. If there was more than just me on this, then it would force me to find a wiki page somewhere to create a summary of all the ideas.

I have tried using directories and mv of binary blobs as a way of creating what is effectively locking by renaming, and this can work in some circumstances, however where the binary blobs are part of a larger system, it gets more or less impossible and locking on the central server is the only choice.

I just want to point out that this is a show stopper for my organization. We are consolidating a number of existing CM/version control systems, and the first step is to find alternatives that satisfy a set of 22 "absolutely must have" requirements. This is the only one bazaar fails to satisfy.

I don't think the locking is particularly important -- what would be super duper useful is a way to indicate who is currently working on what file - this is especially useful for when working with binary files that won't merge smoothly.
This would mean that a user would have a means of indicating that they are currently making changes to the file and other users can check to see who is currently working on the file and contact them if they both want to be doing the same thing to the same file at the same time. IDE integration tools etc could probably do this automatically

Git, Bazaar, and Mercurial all have real problems working the way corporations need them to. I recently tried Veracity at my workplace, specifically because the big three open-source VCS systems don't support work flows that my users require. Veracity was even harder to use than git, so my users switched back to their favorite system - clio. I can't even begin to tell you how terrible clio is, but there's simply no alternative that works for them. These guys aren't software developers, and allowing multiple people to edit the same file at the same time confuses and scares them. Mostly they edit binary files like Word docs and PDFs. They expect a file to be read-only until "checked out", at which point it's locked on the central server and made writable locally. When they "check in", it's unlocked on the server, and the local file is made read-only again. Clio has a really awful GUI, but it's very simple and that works for them. They can see what files are locked and by who trivially. They do not use command lines, so everything has to go through the GUI. They also don't want the GUI integrated into Windows Explorer - they want a traditional application window, and the main window pane needs to be the file tree, with some icons to show file lock state, who has the lock, and whether a new version is available.

I understand why the free software community is against file locking. That's fine, and so far as software development goes, I agree. However, please stop saying that file locking is not useful in a VCS. It may not be useful to you, but the majority of people out there using VCS aren't even programmers, and they'd rather chew their arm off than resolve a merge conflict. They simply don't understand branching and merging. They're not stupid. They're smart people who just happen to work in other jobs, like writers and analog chip designers. File locking is useful to them. Git, Bazaar, and Mercurial will likely continue to ignore these users, but the VCS that does cater to their needs will be the one that finally displaces Subversion in the workplace.