Issue #4560 resolved

Provide a method for setting the phase of a repository to non-publishing. (BB-5267)

Michael Forbes
created an issue

It would be useful if there was some way of making mercurial repositories non-publishing. This simply amounts to including the following lines in the .hg/hgrc file. Unfortunately, there seems to be no way to access this from the bitbucket web interface:

[phases]
publish = False

Use Case

One might like to maintain a private repository for an online backup. Pushing to this private repository should not alter the phase of draft change-sets so that later rebasing etc. can be performed. (Pushing to a public repository, or a shared private repository, however, should change the phase to public.)

As second use case is code review: it is useful to push ones code to a fork, so that a code review can be performed on a pull request. At the end of the code review, one often wants to clean up the changes (rebasing) before the code is pulled back into the main project. It would be very useful to be able to mark the review fork as non-publishing so that the phases are maintained, guiding this later rebasing.

Reference

This was briefly discussed on the mailing list, then ignored:

https://groups.google.com/d/topic/bitbucket-users/XCC5jmYo5FU/discussion

Comments (36)

  1. Sean Farley staff

    (Pushing to a public repository, or a shared private repository, however, should change the phase to public.)

    I really, really want phases to be built into bitbucket but I don't think a public repository should *automatically* set the phase. With the upcoming `evolve` extension, you can have a shared repository with mutable history. This is a really, really great feature.

  2. Kevin Stanton

    It makes it a massive headache to work on a team, because no pull-request is ever accepted on the first try. There are always changes that come out of a code-review, and rebasing becomes a PITA then because the user has pushed their code to bitbucket so others can review it. Then you have to manually mark changesets back to draft and strip changesets from Bitbucket before you can rebase again.

  3. Michael Forbes reporter

    The reason I marked this as minor priority is that, in principle, you can fix this locally with a push hook. However, I have not fully integrated this yet, and the method discussed relies on a reference public server to determine which phases should really be public (which may not always be appropriate). Also, all developers then need to be aware of this and make sure the hook is active.

    https://groups.google.com/d/topic/mercurial_general/_BejSPqs9hE/discussion

    Given how easy this would be for bitbucket to support (just a toggle somewhere in the UI that adds and removes a line in the .hgrc file), I tend to agree that the priority should be higher.

  4. akrauss

    Continuous integration is another use case for this. We have a repository where everybody may push arbitrary changesets for running integration tests. Most of these changes require further work before being published eventually.

  5. Matthew Turk

    This would be a very nice feature for our ( The yt Project & The Enzo Project ) use case. With changesets under review potentially being used to generate simulation and data results (where we embed the changeset in the output data) we would like to be able to have a non-publishing repository to contain these, with a publishing repository where we post reviewed, 'public' changesets. Having the UI, or even just an API, toggle would be an excellent way to do this.

  6. Martin Geisler

    Being able to easily incorporate review comments for a branch by re-pushing would we a great feature.

    Please remember to go and vote on the issue — voting is a new feature that Bitbucket added a few months ago. There are currently 11 votes for the issue.

  7. ruarc

    This seems like a gaping hole in functionality. Can anybody involved in Bitbucket give an answer as to when/if this will be implemented?

  8. Martin Geisler

    Maybe Brodie Rao can tell us if this is on the internal roadmap?

    ruarc I suggest you ask other developers to come vote on the issue. With 44 votes, this issue has now made it's way onto the first page when you sort by votes. From what I read on other issues, that is one factor the Bitbucket guys use when considering what to work on next.

  9. Brodie Rao staff

    I've just pushed out a change to make this configurable in the repo admin page. You should see a checkbox that says "This is a non-publishing repository" that you can use to configure this setting.

    You can also set it from the API:

    curl -X PUT -u username -d non_publishing=true https://bitbucket.org/api/1.0/repositories/username/reponame
    

    Querying on the value isn't yet exposed through the API.

  10. Josef Eisl

    Thanks for resolving this!

    May I suggest these follow-up enhancements:

    • issue #6710
    • Display phase information in the web UI
    • Synchronize phase information for forked repositories

    Are there already issues for the later two enhancements?

  11. Brodie Rao staff

    Josef Eisl

    Display phase information in the web UI

    I've just pushed out a change to mark draft commits in the commit history and individual commit pages.

    Synchronize phase information for forked repositories

    Can you clarify what you mean by this?

  12. Angel Ezquerra

    Nice! Thank you Brodie!

    Is it possible to push obsolete markets now? That is, can we use the mutable history extension to amend a commit that has been pushed to a non publishing repository?

  13. Josef Eisl

    Brodie Rao

    Synchronize phase information for forked repositories

    Assume that we have a repo upstream and a fork of it dev. upstream is publishing and dev is not. Further assume there is a cset 123 in both repositories but in dev it is marked as draft. Both repositories do not differ in csets but in the phase of 123. I would like to have an option to synchronize this information.

  14. Josef Eisl

    Brodie Rao

    I've just pushed out a change to mark draft commits in the commit history and individual commit pages.

    It seems that there is an issue with this change. Please have a look at: https://bitbucket.org/zapster/cacao-compiler2/commits/all

    This repository is publishing but still some commits are marked as drafts. Those commits where introduced by the following pull-request from a non-publishing repository:

    https://bitbucket.org/zapster/cacao-compiler2/pull-request/3/compiler2-development-update

    Maybe its not the UI that causes the problem but the pull-request merge?

  15. Log in to comment