Handling changes in the bzr-svn conversion logic

[David Allouche]

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?

>> 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.
>
> That's a neat idea. I think Jan Hudecs (?) proposal for custom file
> properties would be very helpful here. As long as we can store the data
> now and perhaps use it later, it's all fine by me. 

Maybe. But first we need to know what bzr will do with "copy" data.

>>  * 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.
>
> The problem is in the mapping between the Subversion and Bazaar
> concepts, not so much in the Subversion code itself, so I'm not sure
> this would help much. We're using the native Python-Subversion bindings
> which are a wrapper around the main Subversion libraries and I don't
> think we should be searching for bugs in those.

We need to trace a boundary in the set of svn trees and have two
essentially distinct features working with that: the conversion operates
on trees inside it, the forward-incompatibility ensures that we are not
processing any tree we cannot handle correctly.

I think the problem will be more in terms of feature coverage. You and
the bzr developers are able to audit the conversion logic for
correctness, but I am wary of missing some corner case or little known
SVN feature, and degrading gracefully by omission.

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

Doing massive tests like that is also a large task that can involve a
very significant load of community servers and take literally weeks.

>>  * 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).
> What sort of thing are you considering here? Just check sha-1s or
> something else?

Something like that. I posted a brain dump in my reply to Aaron. Let us
keep those discussions separate.

-- 
                                                            -- 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/6334ce18/attachment.pgp