How can I implement this Mercurial+BitBucket workflow?

Question

I am new to DVCS's so please bear with me...

I am the author of a software library, currently hosted as a private repository on BitBucket. I would like to release the source code of my library to the public, but with the following setup:

• I would like to maintain two repositories on BitBucket, a private one and a public one.
• I would like the initial contents of the public repository to be the current contents of the private repository, without any history.
• I would like to continue making commmits to the private repository without touching the public repository. Then, once in a while, I would like to take a whole bunch of commits to the private repository, and push them to the public repository, as a single changeset, and with its own commit message.

How can I pull this off? If it helps, my private repo only has one branch (the main one).

Answer 1

Concatenating changesets

Well, concatenating changesets can be achieved with one of these technics or with rebase extension with --collapse.

Branch structure

To do what you want you must have a development branch with the detailed commits and a publish branch with the concatenated ones. As long as the publish branch doesn't have any node from the development branch as ancestor, you can push only the publish branch. That means you would have to use one of the options above, you can't merge development branch into publish branch because that would set development branch nodes as ancestors of public branch and you would have to push those nodes.

Controversy

Although this is possible, I agree with @Ringding, it shoudn't be the routine workflow. Here are two good reasons for not doing that:

1. You are adding unnecessary complexity to your workflow, things should be simpler.
2. Those development changesets are the evolutive steps that led to the final version, they are part of the history, hiding that is like lying. That's why history editing tools are extensions and not core commands, they shouldn't be part of a normal workflow.

Answer 2

This is easy to do. I would create a "publish" branch and merge into that whenever you want to push to the public repo. Then use the convert extension to extract only this one branch.

However, it is almost never a good idea to work like this. Potential contributors usually don't want to put up with development behind closed doors. For open source work, it's usually best to open up everything – bug tracker, source repo, wiki, mailing list, reviews, …