Handling changes in the bzr-svn conversion logic

[Jelmer Vernooij]

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.

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

> >>  * 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.
What sort of thing are you thinking of? The Subversion headers list all known properties, and I can't imagine what kind of features you are thinking of here.

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

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~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/d11b3cb9/attachment.pgp