repositories - pinning down discovery behaviour
Robert Collins
robertc at robertcollins.net
Wed Feb 8 21:10:49 GMT 2006
On Wed, 2006-02-08 at 10:49 +0100, Denys Duchier wrote:
> Robert Collins <robertc at robertcollins.net> writes:
>
> > On Mon, 2006-02-06 at 08:25 +0100, Denys Duchier wrote:
> >> I suggested assigning a uuid at shared-repo creation time to make (what I
> >> called) "inheritance" a bit more robust.
> >
> > I'm not sure why its more robust. Branches are not coupled to
> > repositories, only to the presence of the revision data. Having branches
> > not directly contained by their repository makes gc very hard; the only
> > things I can see a uuid allowing are violations of the rule about being
> > contained [i.e. by allowing repo contains repo contains branch using the
> > outer repo].
>
> Yes, that's exactly what Aaron was worried about in the presence of inheritance:
> that users would nest repos and that an existing branch might then start to
> inherit the wrong repo. The uuid idea makes inheritance more robust in the
> presence of nested repos.
Users shoots self in foot, news at 11. I mean by that that we trade off
safety features against flexability and useability. For instance, its
unsafe to probabilistically generate revision ids - really we should
ensure that revision ids are unique, perhaps by enforcing a unique
namespace for branches and generating revisions in sequence within that
namespace. Sound familiar? I dont think we can prevent a user creating a
repo, then a branch using it, then a repo in the middle. And to scale
well and provide clear behaviour, that branch *should* then reparent to
the new repository. What we can do is do the reparenting automatically:
when the repo is creating, scan for the existing containing repository,
and any child branches of the new repo that were using it, then lock the
parent repo and all the branches and add the new repo, and copy across
all the data referenced.
> the uuid idea is just your "bit" idea, but with a lot more entropy :-)
Well not really. The bit idea is a boolean 'shared' or 'not shared'. A
'not shared' repository containing a repositoryless branch is a semantic
error, and one the user would have to work to create. Its not something
that would happen accidentally. There is deliberately no discrimination
between repo A and B that are both shared - if they have the content,
they have the content. uuids add such discrimination, which I'm saying
we dont want.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060209/d2ded40e/attachment.pgp
More information about the bazaar
mailing list