CODEWITHSUNDEEP
version-controlmercurialopen-sourcedvcsbitbucket
HighCommander4
HighCommander4

Reputation: 52739

How can I implement this Mercurial+BitBucket workflow?

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:

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

Upvotes: 4

Views: 216

Answers (2)

Rafael Piccolo
Rafael Piccolo

Reputation: 2338

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.

Upvotes: 3

Ringding
Ringding

Reputation: 2856

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, …

Upvotes: 3

Related Questions