Handling changes in the bzr-svn conversion logic

[David Allouche]

Jelmer Vernooij wrote:
> On Thu, 2006-08-31 at 18:26 +0200, David Allouche wrote:
>> Jelmer Vernooij wrote:
>>> On Thu, 2006-08-31 at 13:48 +0200, David Allouche wrote: I agree.
>>> It'd hurt interoperability between different versions of SVN 
>>> clients as well, so I don't think this should be a problem. Let's
>>> ask them just to be sure though.
>> Can you take care of that, please?
> Ben Collins-Sussman just confirmed that this is the case so we should
> be fine here.

That's good news. Great!

>> Maybe. But first we need to know what bzr will do with "copy" data.
>> 
> Do we have to know that yet? As long as we decide to not lose that
> data, we can postpone the decision as to what to do with it.

Without knowing how copy information will be used eventually, we may
represent the SVN data in a way that is not expressive enough to allow
lossless upgrade in the general case.

For example, a naive representation of copies (as simple file or
revision properties) might now allow shallow branches to be upgraded
reliably if we decide to represent copies as an inventory-complete DAG
in the revision inventory.

>>> I think testing against a huge number of Subversion branches
>>> would give us a better chance of catching these corner case bugs.
>>> 
>> Take my word on that, it's not enough. Because you found nothing
>> that breaks you today, does not mean that tomorrow somebody won't
>> do something clever that breaks you.
> All, truly all, corner cases I've seen so far had to do with the 
> mappings not handling the corner cases correctly. Something that
> isn't a corner case (copying a file from /trunk/bar to
> /branches/foo/bar) in Subversion can be a corner case in the mappings
> and that's where most of the trouble I've seen is.

Thank you for the example. Copying across branch boundaries could be one
of those cases (it's not true, because since we are aware of the problem
we can design for it).

As long as we cover a case, like copying inside a branch, I am confident
that we can audit that code for correctness (lifeless eats test cases
for breakfast, and I'm not too bad at finding logic holes). But failing
to cover another case entirely (like copying across branches) can go
unnoticed, precisely because there is nothing to audit.

If we summon a SVN guru to help us validate bzr-svn, that would involve
a lot of communication (good fit for a small focused sprint), because no
one person would have the required expertise of both ends. This sort of
"I'll explain what we do, see if you can find a fault" exercise between
two parties with complementary skills is also very good as a validation
methodology on its own.

-- 
                                                            -- 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/20060905/33fcec9d/attachment.pgp