Issue #3 open

A way to easily open Bitbucket repsitories

Peter Hosey
created an issue

I propose an “Open Bitbucket Repository” menu item in the File menu, with fields for username and repo name.

Pasting a bb:, bb+ssh, http://bitbucket.org, https://bitbucket.org, or ssh://hg@bitbucket.org URL should automatically fill in the fields.

Comments (10)

  1. Jens Alfke repo owner
    • changed status to open

    How about adding it to the New Cloned Repository panel instead, since it's a special case of that? There could be a picker menu of some kind that lets you choose "Bitbucket" and just type in the repo name.

  2. Peter Hosey reporter

    Hm. I was envisioning a more read-only view. It depends on what hg will let you do with that -R switch, of course.

    Having it in the New Cloned Repository panel would be useful as well, but that's a separate idea.

    Bitbucket does require you to specify a username; the repo name alone won't do. The username field could allow / as a synonym for tab to switch to the repo-name field.

    I'm not sure about the UI. Perhaps make “Source” into a radio button group, with the plain URL/path field + Choose button on one radio button, and the Bitbucket username/repo name fields on the other radio button.

  3. Jens Alfke repo owner

    Oh, I see; I was just thinking you meant an easy way to download/clone a repository from BitBucket. But what I think you really mean is opening a Murky window directly on the remote repo without affecting the local filesystem, right?

    I haven't tried directly working with a remote repository. It's not clear whether all of the 'hg' subcommands Murky uses support it, although I think most of them should. (And if there are problems, someone could always fix the Mercurial source itself.)

  4. Jens Alfke repo owner

    It looks as though hg log doesn't work on remote repos:

    $ hg log -R ssh://hg@bitbucket.org/snej/murky/
    abort: repository 'ssh://hg@bitbucket.org/snej/murky/' is not local
    

    I was looking into this a while ago and I thought that I'd found a way to inspect a remote repository, but now I don't know what it was.

  5. Jens Alfke repo owner

    It looks as though it is intentionally impossible to browse a remote repo, according to the Mercurial FAQ:

    “4.20. How can I do a "hg log" of a remote repository? You can't. Mercurial accepts only local repositories for the -R option (see hg help -v log). ... The correct way to do this is cloning the remote repository to your computer and then doing a hg log locally. This is a very deliberate explicit design decision made by project leader Matt Mackall (mpm). See also http://www.selenic.com/mercurial/bts/issue1025 for the reasoning behind that.”

  6. Jesper Nøhr

    Yeah, I don't think this is possible. Even commands like "incoming" fetch a full bundle, unbundles it, and works its magic. It would really be too heavy to do this, I think.

  7. Daniel Myers

    Could load it into a temporary directory, that murky schedules to delete on close. Then it would feel like a remote browse that would take a moment to load and all the commands would be available on it while it was like that. Would also consider keeping the repo path in an extra file in the temporary folder so that if a user did decide to make a full clone of it then the directory path would still be correct (it would make a new clone off the original instead of the temporary copy at that point). I don't fully see the need to setup a remote repo browsing in that sense but if someone would find it useful that is the way i would approach it. Also the idea of cloning a bitbucket repo based on the name would be a nice feature I think. Where you would only have to type in the name of the user/repo and it grabs it for you.

  8. Peter Hosey reporter

    “Would also consider keeping the repo path in an extra file in the temporary folder so that if a user did decide to make a full clone of it then the directory path would still be correct (it would make a new clone off the original instead of the temporary copy at that point).”

    Did you mean to put that the other way around? If you decide to “clone” the remote repository you're viewing, it makes much more sense to simply move the formerly-temporary clone to where the user wants it than to do another full clone (possibly over the network) of the original.

    The real problem with your proposal of a temporary clone is how it would follow updates on the remote repository. The only way I can think of would be to pull every 10 minutes or so until the user closes or saves it.

  9. Log in to comment