Mutating history in Subversion and Bazaar

[David Allouche]

Sending this reply to the bazaar mailing list because it's probably of
broad interest.

Jelmer Vernooij wrote:
> Editing files in .bzr/ will get you into trouble too, and I can't think
> of a reason why that is different from editing files in Subversion
> repositories.
> 
> Note that doing an uncommit in Subversion requires taking the repository
> offline, dumping it into a text file, editing that text file and
> regenerating the repository. 

Changing history in Subversion in different from changing history in bzr
because the trade-off is different.

It boils down to Subversion being a centralized database system, while
bzr is a distributed database system. In Subversion the database /is/
the repository, in a very concrete way. In bzr the database is an
abstract mathematical object that is altered globally every time a
revision is created anywhere; each repository exhibits a fraction of
this database, and each repository is equally authoritative.

That might sound like I'm trying to confuse the issue, but the
distinction is really a deep and subtle one.

One the one hand, changing the history of a SVN repository may break
existing checkouts, but the downfall is quite limited in time and space.
This trade-off may be worthwhile in some circumstances, and even
advanced users who are aware of the implications will sometimes make
that choice.

On the other hand, changing the history of a bzr repository compromises
the integrity of the data in all existing repositories, in a /latent/
way. That is much more serious since repositories are more persistent
and precious than checkouts.

I am not familiar with the storage layer of bzr, so I will make some
(informed) assumptions in the following story.

  A SVN repository: A->B0->C
  A bzr-svn branch FOO: A->B0->D
  The SVN repository is altered: A->B1->C
  This SVN repository is imported into a new bzr-svn branch BAR.
  FOO is merged into BAR: A->B1->C->E B1->D->E

That's where bad things start happening. D is defined in FOO storage as
a delta from B0, but since BAR already has B1, it will define D by
applying the B0->D delta on B1. At this point BAR is corrupt although it
was created initially from a fresh import.

This specific story is likely to show obvious breakage quickly, but I
wanted to keep it simple for the sake of the example. I could come up
with equally plausible but more complicated stories that would produce
nasty time bombs.

You only need to have pulled /at some point/ into your repository a
branch that contains B0 to contaminate all the branches that use that
repository, in ways that may not be immediately obvious. This problem is
non-existent in Subversion because checkouts do not duplicate the
repository.

-- 
                                                            -- ddaa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060829/6afaa3f8/attachment.pgp