rfc: remove "revision specs"

Robert Collins robertc at robertcollins.net
Wed Aug 31 23:32:00 BST 2005

On Wed, 2005-08-31 at 09:59 +0200, Matthieu Moy wrote:
> Robert Collins <robertc at robertcollins.net> writes:
> ...
> > bzr:///home/foo/bar <- if by that you mean a bzr branch on the local
> > file system, the relevant url scheme is 'file:' ->
> Yes, but then, the fact that you want to access it as a bzr branch
> doesn't appear in the URL. If I write file:///home/foo/bar then I'm
> thinking "the directory /home/foo/bar", and an automatic tool (my
> mailer/a gnome terminal/...) that would hyperlink it would only be
> able to open something like a file manager.

This is true. On the other hand, using a literal file:// or http:// or
sftp:// resource means that my existing tools, which will let me copy,
delete, commit (with nautilus plugins), rename the branch will be

> Another argument in favor of specific URL scheme for bzr is that if
> one wants to write a tool able to access several archive formats, he
> can't know how to access file:///path/to/archive (is it a git, bzr,
> baz archive ?).

  branch = Branch(url, find_root=False)
except NotABranch:
  branch = None
  branch = GitBranch(url)
except ...

I've written more such tools now than I can remember, and its really
quite easy : you end up with a factory that goes:

  tree = VCS.tree(url)
except NoSupportedVCS:

> > One could defined bzr+file: if we want to be able to define it but I
> > think that that isn't useful at this point.
> I like this one, though I'm not familiar enough with std66 to tell
> wether it's the right way to do.
> > Does the simpler way I'm writing them influence this feeling ?
> Using http:// or file:// does not answer my question. I like
> bzr+...:// but I'm not sure it's the correct way to use std66.

It is an appropriate use of std66, the real question is - are we
creating a sufficiently different protocol that its a win to go down
that path. At the moment I'm with Aaron - I think we should use file://,
http://, and sftp:// urls : we aren't changing the protocol for
accessing the resource enough to make the loss of interoperation a win.


GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- 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/20050901/e02e788e/attachment.pgp 

More information about the bazaar mailing list