Handling changes in the bzr-svn conversion logic

[Jelmer Vernooij]

On Thu, 2006-08-31 at 13:48 +0200, David Allouche wrote:
> 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 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.

> [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.]
One way of looking at copies across branches is as partial merges. This
isn't always the case though, so it might not be worth the effort.

Only considering clean renames and copies makes sense though. 

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

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

> > 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.
Yeah, renames should be good to do now.

> 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.
I think svn:externals maps "nested-tree-by-reference" very very closely,
so I don't think we should hold back on supporting them.

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

I think testing against a huge number of Subversion branches would give
us a better chance of catching these corner case bugs.

>  * 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?

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