Handling changes in the bzr-svn conversion logic

[David Allouche]

Sending this reply to the Bazaar mailing list because I think it is of
broad interest.

Jelmer Vernooij wrote:
> On Wed, 2006-08-16 at 16:26 +0200, David Allouche wrote:
>> * The handling of namespace bumps, when we need to knowingly bump the
>> version marker bzr-svn revision ids. We cannot just upgrade the
>> namespace for all imports at once, but if we don't, we need to provide
>> support for import using each namespace, which could be troublesome for
>> us and exceedingly complex for users.
>
> This is indeed a complex problem. Revision id aliases alone (no file id
> aliases required) could help smooth transitions when different versions
> of the mappings are compatible for a particular branch, but their
> propagation would be complicated.
> 
> Maybe at some point we'll be confident enough to say the mappings code
> will stay the same...

I do not think we can ever achieve that, because that would require
getting to a point where:

  * bzr-svn represent all svn branches perfectly
  * svn will certainly never add any new feature affecting the storage

The first might be attainable with a "reasonable" level of confidence.
The second appears impossible.

In other words, bzr-svn can achieve correctness for a subset of the
possible svn branches, but it cannot achieve correctness _and_
completeness in a permanent way.

However, data compatibility and integrity only requires correctness, and
not completeness. If it is possible to identify which revisions are not
converted correctly, we could just refuse to import them, until bzr-svn
is made more correct. In that case, there is no need for namespace
transitions because no incorrect import data ever gets committed.

One example to keep in mind would be how symlinks have been introduced
in Subversion in a forward-compatible way. Forward compatibility is our
enemy because it excludes correctness. If Subversion upstream has a
commitment to only introduce new features in ways that /allow/ clients
to be forward incompatible (e.g. using new properties in a reserved
namespace) then it is possible for us to identify revisions that might
not be supported correctly at this point and to refuse importing them.

In summary, the requirements to avoid transitions when the conversion
code evolves are:

 * correctness of the conversion for a subset of SVN tree states
 * positive identification of tree states that are not certainly correct
 * refusing persistent storage of tree states that are not certainly correct

It's a tall order, but it does not look impossible.
-- 
                                                            -- 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/faf08bd8/attachment.pgp