[PATCH] Singleton Branches

[Martin Pool]

On 26 May 2005, John Arbash Meinel <john at arbash-meinel.com> wrote:

> It is very easy in code to have multiple requests for the same branch
> object without realizing it. Because the filesystem is sometimes the
> point of coordination, not the python code. Two portions of code saying
> give me information about this file will probably have to allocate a
> branch object to get it.

Right, so allowing for them to be matched up seems like a good idea, but
it shouldn't be mandatory.  I can imagine code that wants to have two
Branch objects on different threads pointing to the same branch and 
mutual exclusion between them.  (That would require using an OS lock
that works properly across threads, which is a whole other kettle of
fish to do portably.)

> I only really need a singleton Lock object, though it seemed reasonable
> to put that in the Branch object. I don't really know what ideas you
> have about how Branch is supposed to evolve, what methods/members etc it
> will contain. I can see that if you are starting to add data to a
> branch, you might have an in-memory representation that needs to evolve,
> but not be exposed to anyone else until it is done.

I haven't done that yet but it might be a reasonable thing to do.

> I'm still concerned about revfile appending. The last comment you made
> was "two processes can concurrently append to the same file, they just
> don't know where their data is". While probably completely true, the
> last portion is what makes it worthless. The whole point is that I can
> put my new revision information into the file, and then reference it
> later. I think the one big lock approach (.bzr/branch-lock) works fine.
> But you could also be more fine-grained and take out an explicit lock on
> each file as you are appending to it. One potentially useful advantage
> of the per-file locks is if you end up with shared multi-branch files
> (for instance, through hard-linking). You have mentioned that there is
> no problem with having extra information in a rev-file, as long as you
> don't reference it in the branch. Which means that the branch-lock no
> longer locks the file from all possible modifications. So you should
> lock the file itself. You probably won't lock it for long, and if you
> only lock it exclusive, and only do one file at a time, you should avoid
> deadlocks.

Yes, for that reason I thought I'd probably lock the revfile itself.

-- 
Martin