Handling changes in the bzr-svn conversion logic

[David Allouche]

Jelmer Vernooij wrote:
> They do. Properties starting with svn: are only to be used by the
> Subversion folks and are the sole property prefix used by them. 

It's a requirement, but it's not enough. Allowing
forward-incompatibility also requires that the use of existing reserved
properties never change in a forward-compatible way.

But that's not a huge requirement, and maybe it's already implicit.
Though, if we need to rely on that, it would be worth getting an
explicit commitment.

I cannot think of any additional requirement to allowing
forward-incompatibility.

> 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.

It is my impression that the core bzr developers (mpool, lifeless,
abentley, j-a-meinel) agree that implementing general
identity-preserving copy has too many difficult implications, in
particular for merging, to be worth the trouble.

[snip consideration on how we might support copy across branches,
eventually it turns out not to be a very interesting restriction. My gut
feeling is that we should only distinguish clean renames and copies.]

It seems to me that tracking copies is mainly useful for log and
annotate. It could be useful for merge in those cases where subsequent
deletion cause a copy to turn into a rename, but it seems to me that
would require Hg-style history tracking to detect.

It might be a good time to have a discussion on what bzr could use copy
information for and how it could be represented.

We have a joker here: we only need to have a broad design, and not a
complete implementation on the bzr side. Copy information could be
recorded by bzr-svn as as special properties, which would be interpreted
on format upgrade by bzr when copy support is implemented.

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

I think renames (copy+delete in the same revision) is a "simple matter
of code" thanks to your clever approach of translating whole bzr
inventories.

Nested tree, I do not know. Since it's not implemented yet in bzr, care
would have to be taken to ensure that bzr support is a strict superset
of svn support. If some of the svn features for nested trees are
considered harmful, they could be made "advanced" features. Sorry if
that has been discussed recently, but I am way behind the mailing list.

Once again, what is important is for bzr-svn to be correct and lossless.
If bzr does not do much useful yet with the data, it's okay, as long as
the data is there and is preserved on upgrade.

>> 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.

Right. We could tackle this problem from multiple fronts:

 * When we think we are closing in on the target, contract a SVN guru
with a QA profile. The sort of person that thrives on nasty corner cases
and eats obscures bugs for breakfast. This person could bring a fresh
pair of eyeballs to the code and validate the implementation.

 * Make the bzr fetcher better at detecting revision-id integrity
violations, so the inevitable bugs will not cause too much splash damage
(Aaron's reply gave me an idea).

 * Add to all data-integrity bugfixes a checker that identifies bzr-svn
branches that are certainly not affected by the problem. Use that
checker in importd and redo those imports that are potentially corrupt.

-- 
                                                            -- 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/20060831/7c2c5c94/attachment.pgp