CODEWITHSUNDEEP
version-controlmercurialrepositorybranchbranching-and-merging
Anestis Kivranoglou
Anestis Kivranoglou

Reputation: 8164

Mercurial. Abandoned - Alternative implementation Branch practice?

We use Mercurial as source control, mainly using named branches for major features that we close and merge into the development branch once finished.

Recently I had two divergent solutions to a particular problem. I couldn't decide which to chose as both had their pros and cons, so I implemented them both but had to chose one to be merged into the main branch.

The second implementation is not intended to be merged into the main branch ever. But I still want to keep it just in case it might be useful some day.

One obvious solution is to just open a named branch for each. Close both and just merge 1 into the main.

But this leaves some sort of "clutter" into the source tree.

Are there any other alternatives or best practices?

Upvotes: 1

Views: 129

Answers (1)

marcinkuzminski
marcinkuzminski

Reputation: 1771

We at RhodeCode use completely bookmark based solution, and pull request functionality.

We use rebase as merge strategy, this leaves the commit graph nice and clean. If we need to track changes you can always get back to original pull request and see what was the development process including CI tests/code comments.

Bookmarks are in our view much better option since it's a lightweight pointer, this allows you to do easy rebases/commit squash and simply then push new bookmark pointer and update the pull request with this info. This combined with Mercurial's phases support give a really nice way of working with new code submissions. (Public in main repo, drafts in forks where the commits are coming from)

We so far did few thousands of pull requests internally developing RhodeCode itself, and we all agreed with the team it's the most flexible and also simplest process.

Upvotes: 1

Related Questions