What constitutes the "identity" of a changeset?

[James Henstridge]

On 30/03/2008, Paul Moore <p.f.moore at gmail.com> wrote:
> On 29/03/2008, Stephen J. Turnbull <turnbull at sk.tsukuba.ac.jp> wrote:
>  > James Westby writes:
>  >
>  >   > However, you are neglecting the caveat I put in to try and make the
>  >   > discussion simpler, "assuming  certain rules along the way",
>  >
>  > Of course I neglected it, since I had no idea what rules you were
>  >  talking about.
>  >
>  >  This is a serious problem for people new to bzr.
>
>
> This was my point, as well. There are certain rules which make it
>  possible to reason about revisions, and they aren't clearly states
>  anywhere. Indeed, from the discussions it seems that the rules can
>  differ between repositories/plugins/??? (bzr-svn seems to try to
>  respect identity based on svn repository UUID, whereas there is no
>  equivalent for Bazaar native repositories)

The idea with bzr-svn is to treat the Subversion branch as just
another branch: if two people pull or merge from a standard Bazaar
branch, they'll see the same revision IDs, and the same should be true
for svn branches.

To do this, the Subversion revisions are given revision IDs based on
how Subversion identifies revisions: the repository UUID, the revision
number and the path inside the repository.

Outside of the bzr-svn plugin, there is no special meaning attached to
the structure of these revision IDs.  The only thing it requires is
that a particular revision ID always maps to the same revision.


>  Saying that revision identity is based on revision ID, and that is
>  arbitrary, avoids the issue. It just means that the rules by which
>  revision ID is calculated need specifying. Aaron did this earlier,
>  presumably only for Bazaar core and not for bzr-svn. In that case IDs
>  are random, and so *are* unique. So the only revision ID preserving
>  operation is a copy. Which then leaves the question of what operations
>  copy, and what don't. For example, diff/patch clearly isn't revision
>  ID preserving, and bzr clone must be (otherwise what's the point?).
>  But what about greyer areas like creating a merge directive and
>  merging it? Upgrading a repository? The things loom does with
>  up-thread etc? I can assume, but I don't *know*.

Some things that preserve revision IDs:
* cloning a branch.
* merging or pulling a branch.
* merging or pulling a merge directive (they are essentially a
serialised delta between two branches).
* bzr-loom operations (that plugin is effectively just managing a
stack of branches for you).
* upgrading the repository format.

Some things that do not preserve revision IDs:
* applying a diff with "patch" then committing.
* using the rebase plugin to apply revisions to a different parent revision.
* using "bzr uncommit" then committing a changed revision.


>  Arguably, this is simply a case of documentation not being written yet
>  - internals documentation is lower priority than user documentation,
>  certainly. And "use the source" is always available as an answer. But
>  these sort of things arise fairly often, and affect people's mental
>  model, so I believe that more effort needs to be made to clarify them.
>  The biggest issue with the newer crop of DVCS is that they all *look*
>  pretty similar, but there are large but subtle differences in the
>  concepts involved, and it's easy to get confused when moving from one
>  to another, and transferring incorrect concepts across.


James.