Handling changes in the bzr-svn conversion logic

[Jelmer Vernooij]

On Tue, 2006-08-29 at 16:24 +0200, David Allouche wrote:
> 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.
[...]

> 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.
They do. Properties starting with svn: are only to be used by the
Subversion folks and are the sole property prefix used by them. 

However, since they support file copies (and file copies are /very/
common) I don't think it would be wise to refuse converting branches
that contain file copies at the moment. We could choose to never ever
support them, but I'd rather avoid taking that decision now.

Note, btw, that bzr-svn supports symlinks. The only features it lacks
that the svn client supports are nested trees and renames.

> 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.
It is certainly an interesting idea, and probably more feasible then
using revision id aliases to handle changes in the mappings. Being able
to guarantee correctness might prove difficult though.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Bazaar branches: http://people.samba.org/bzr/jelmer
-------------- 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/20060831/10f5b81c/attachment.pgp