[MERGE REQUEST] Couple of small fixes

[Jelmer Vernooij]

On Thu, Dec 15, 2005 at 09:39:10AM -0600, John Arbash Meinel wrote about 'Re: [MERGE REQUEST] Couple of small fixes':
> Jelmer Vernooij wrote:
> > On Thu, Dec 15, 2005 at 08:57:57AM -0600, John Arbash Meinel wrote about 'Re: [MERGE REQUEST] Couple of small fixes':
> >>Jelmer Vernooij wrote:
> >>>I don't really see how this makes opening containing branches slower.
> >>>There are two approaches that can used for 'open_containing': 
> >>>depth-first and breadth-first search for a Branch. I've implemented
> >>>depth-first search because it does not make opening bzr branches
> >>>slower even if you have a several foreign branch classes loaded (since
> >>>it will try Bzr first).

> Except for the fact that you probably need to do breadth-first search.
> Because it is possible for me to have this arrangement:

> base/
>   .bzr/
>   subproject/
>     .svn/
>     subsubproject/
>       CVS
>   otherproject/
>     .git/

> We may decide that we don't support the above configuration. But it is
> certainly possible that I will have a master project which I am working
> on in bzr, which is using a library from someone else who only wants to
> use svn, and someone else who only uses CVS.
While breadth-first search might work, it would slow down bzr-native
branches, especially if we would eventually gain support for remote
SVN, git and darcs branches. 

> >>'svn://' notation would require to be parsed directly by the branch
> >>class, since we wouldn't register a tranport type for svn. The latter
> >>would work just fine with a simple Transport object.
> > The SvnBranch class does indeed accept 'svn://' URLs, and http URLs 
> > (if they contain a .svn subdirectory). Note that the SvnBranch does
> > not use the Transport object at all but uses the SVN standard
> > libraries to access these URLs.
> There are a few ways to handle the multi-connect issues.

> I personally would rather see us change how we name branches, and go
> with specific prefixes rather than try the same type multiple times.

> To clarify: we would introduce bzr+file:// bzr+http:// bzr+sftp://, as
> well as svn+http://, etc.
> For compatibility (and the common use case), an plain path, http:// and
> sftp:// are all treated with their bzr+ prefixes.
Is the + standardised somewhere in a RFC or something? This does look
like the sanest idea to me.

> Then we would have a Transport list, but we would also have a Branch
> registry.
I guess that would rather be a Branch type as not all Branch types
would use the Transport class (e.g., SvnBranch uses the svn client
libraries to access remote repositories).

> So that rather than being able to say:

> bzr log http://anonsvn.ethereal.com/foo
> we would require
> bzr log svn+http://anonsvn.ethereal.com/foo

[...]

> if not branch_types.has_key(branch_type):
>   raise UnsupportedBranchType()
That'd make sense.

> Then we still can support alternative branches just by giving a prefix,
> and we don't have to do a complete searching through all possible branch
> types everytime we use a relative path.
I think you've managed to finally convince me that 'probing' is not
going to work in the end. It's nice to be able to check out a URL
without knowing what VCS is involved, but it causes too many issues.

Cheers,

Jelmer

-- 
Jelmer Vernooij <jelmer at samba.org> - http://jelmer.vernstok.nl/
Currently playing: Stone Temple Pilots - Big Empty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051215/f4279b88/attachment.pgp