What we did at UBZ

[Aaron Bentley]

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

Jan Hudec wrote:
> I am not sure I understand how it should work. Anyway, I'd like to make some
> points and it may be that I will talk about the same.
> 
>  - The key property of convergence is, that a revision keeps it's identity
>    despite being pushed around. This is very important, as it allows one to
>    have a complicated net of mirrors and not create a lot of mess.

What I mean by "pull convergence": currently, you can pull from another
branch if they have merged you since your last commit.  When you do
this, the new revisions in the other branch are appended to your
revision-history.  None of the revisions in your revision-history are
overwritten.

If we removed pull convergence, you would not have that option.  You
would either merge the other branch, or overwrite your branch with the
other branch.

In the implementation, we would remove the "revision-history" file.
Instead, we'd have a "last-revision" file that would record the
last-committed revision.  For uses like "log", we would use the
parent-ids in the revision, instead of the revision-history.  We'd
always use the first-listed parent in the revision as we went back in time.

>  - I prefer to view the revision parents as equal. Neither of them is
>    fundamentally more significant than the other.

There are attractions to thinking that way, but I don't think it's
entirely right.

The first revision parent is special, because it is what the committer
had prior to committing.  If you look at the logs from bzr itself,
you'll find a lot of comments like "Merged Martin" or "Applied changes
from John".  Hardly anyone says "Combined the Mainline with my branch",
implying that the two are equal.

>  - The revision should be pulled as much exactly as is as possible --
>    including the order of parents.

I'd say the revision must be installed exactly.

>  - The mainline is the history obtained by following first parent of each
>    revision.
> 
>  - And of course, the definition of pull remains that it can only apply
>    revisions, that are descenants of the current destination head.

No, the definition becomes that pull can only apply revisions that are
desdants of the current destination head, and that the destination head
must be the first parent.

> Follows from that that after pull, the destination branch shows history
> exactly the same as the source did. Actually it should be exactly equivalent
> to source.

Which is a change.

> Now I _think_ what I described matches the above "new behaviour". What
> confuses me is that "removing pull convergence" is announed in the begining,
> but this really strenghtens the convergence.

This makes it impossible for pull to converge.  All it can do is overwrite.

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

iD8DBQFDflhW0F+nu1YWqI0RApsQAJ9HXCehSdAzNJfGX/bhsF3Zt9gMhACfT8Y4
NHoPCFb7iGi5LHF6RS7HSso=
=l3tC
-----END PGP SIGNATURE-----