Pulling multiple branches in the same repository

[Martin Pool]

On 08/05/2006, at 5:57 PM, Erik Bågfors wrote:

> Hi.  I pulled bzr.dev and bzr.0.8 at the same time, into the same
> repository, and I got the following error message.
>
> : [bagfors at zyrgelkwyt]$ ; bzr pull
> Using saved location: http://bazaar-vcs.org/bzr/bzr.0.8/
> bzr: ERROR: Could not acquire lock
> LockDir(/home/bagfors/src/bzr/.bzr/repository/lock)
> /home/bagfors/src/bzr/bzr.dev/bzrlib/lockable_files.py:107:
> UserWarning: file group
> LockableFiles(<bzrlib.transport.local.LocalTransport
> url=/home/bagfors/src/bzr/bzr.0.8/.bzr/branch/>) was not explicitly
> unlocked
>  warn("file group %r was not explicitly unlocked" % self)
> [Exit 3 ]
>
> pulling again works...
>
> I understand that there is a locking issue here, but I see two
> problems with this
> 1) The error message is really bad.  Will confuse a user

How about something like this:

   Could not acquire repository lock on /home/bagfors/src/bzr/
   Currently held by bagfors at zyrgelkwyt process 123, "bzr pull"

Also we should show something while waiting for the lock.

Secondly we should fix the problem causing the UserWarning.  It's  
useful for developers to know about these and fix them up but I'm not  
sure they should be visible to users.

> 2) When adding multiple developers on multiple branches, I think not
> allowing two of them to work on different branches (at least) at the
> same time, will give problems.  This might mean that bzr has problems
> scaling up to a large number of users on the same repository (and
> branch for that matter)

Yes, this will need more work.  There's no conceptual reason why we  
need to hold a lock on the repository during insertion of new  
revisions: we're not changing existing information and there is no  
reason why parallel inserts should conflict.  (By contrast we do need  
to lock branches during commits/pulls, because only one attempt  
should win.)

On local storage we should be OK to have multiple writers going into  
the same knit but on pessimistic assumptions about sftp this will not  
be safe.  That may be something to consider for a future format change.

-- 
Martin