[MERGE] HTTP redirection

Vincent Ladeuil v.ladeuil+lp at free.fr
Wed Feb 14 07:56:15 GMT 2007


>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:

    aaron> Vincent Ladeuil wrote:
    >>>>>>> "aaron" == Aaron Bentley <aaron.bentley at utoronto.ca> writes:
    aaron> Comment ("our only concrete control format") seems to be contradicted by
    aaron> registering BzrDirFormat4, 5, 6.
    >> 
    >> 
    >> *control* format not BzrDir format, or am I misunderstanding
    >> something (the truth is the distinction is a bit blurry for me,
    >> but registries are distinct...) ?

    aaron> TBH, I misunderstood at first.

    aaron> But having reread carefully, I think this is incorrect.

    aaron> The way it looks to me, control formats are formats of control
    aaron> directories.  Examples would be 'CVS', '.svn', '{arch}', etc.  We
    aaron> currently have only one type of control directory-- a '.bzr' control
    aaron> directory.

    aaron> The format is extremely basic.  It contains a "branch-format" file, a
    aaron> README file, and a "branch-lock" directory.  BzrDirFormat is the class
    aaron> for this.

    aaron> Depending on the contents of the "branch-format" file, a BzrDir may
    aaron> determined to be one of several subtypes, including BzrDirFormat4 and
    aaron> BzrDirMetaFormat1.

    aaron> The inheritance makes it a bit confusing, but when viewed as a control
    aaron> dir, BzrDir is a concrete type, and the fact that it has subtypes is
    aaron> best ignored.

The original purpose was to allow *foreign* BzrDirFormat (see hg,
svn and git plugins) to have distinct behaviors than native ones,
and I felt that registering an abstract class was... surprising
at best (hence the comment).

And my previous implementation was changing the way
BzrDirMetaFormat1 behave (to avoid imposing the redirection
handling to foreign branches).

This is not *needed* anymore, so I can revert that if you
wish. But it will have to be re-introduced if we need to have a
specific behavior for native BzrDirFormats that we do not want to
impose on foreign BzrDirFormats.

TBH, I would not have thought about it if I didn't get bitten by
defining a probe_transport in BzrDirFormat1 and puzzled because
it was not called. probe_transport being a *class* method, it
could not be called if the class is not registered...

<snip/>

    >> 
    >> open_containing_from_transport have not changed. It tries all
    >> directories from the initial url to the root until it finds a
    >> branch or fail.

    aaron> I think it would be good to add that information to
    aaron> open_containing_from_transport's docstring.

I'll do that.

    >> Have I answered your concerns ?

    aaron> Mostly, but I think you should revert your control_dir
    aaron> change.

Can you confirm that ?

Anyway, I'd like to keep the register_control_format call close
to the register_format calls as I had a hard time analyzing the
code.

    aaron> And since I'm pretty sure you've introduced a new
    aaron> failure mode for bundles, I think you should test for
    aaron> that, and correct it.

I'll do that too.

    aaron> Pretty much every other user of get_transport is
    aaron> preparatory to creating a bzrdir, so since none of our
    aaron> writable transports support redirection, we don't need
    aaron> to worry about what do do if, for example, "bzr init
    aaron> http://foo/bar" hits a redirection.

Yes.

Thanks for your comments,

       Vincent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20070214/fc10eb41/attachment-0001.pgp 


More information about the bazaar mailing list