I would like to float the possibility of a pull request based workflow. This if accepted would mean that developers should push commits only via pull-requests. The advantages would include
A stable "master" bookmark (I avoid the terminology "branch", since we use mercurial).
Code review is possible, when it is required, so potentially less bugs
Less noise in codes
Less merge conflicts
Most importantly, allows other developers to catch up with the changes
People who are familiar with Pythran's development might be familiar with this approach. This is possible in mercurial also through the use multiple heads and bookmarks, and I would like to see whether it is feasible.
One last thing - even if the proposal is rejected, all developers should definitely avoid a commit where you make a merge and apply the code-style tool black in the same commit.
Update ~3 week since
Advantages
Allows to facilitate better features and bug fixes through code review.
Easier to produce changelog towards during release(?) hg log --style changelog | grep "pull request" -A2
Disadvantages
Inability to update bookmarks - awaiting reply from bitbucket support.
(partial) Hard to initialize PR from terminal specifying bookmarks. bitbucket / bb command in fluiddevops allows initiating PR from the repository tip atleast from command line.
bitbucket pull_request --fork gfdyn --owner fluiddyn --title"title of PR"--desc"description of PR"# or in shortbb pull_request -f gfdyn -w fluiddyn -t"title of PR"-d"description of PR"
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
Just to be clear evolution extension and hg evolve allows for what git rebase -i can do to squash "draft changesets" - as noted by hg phase commands. Correct me if I am mistaken. It would be useful, indeed. I don't however understand how to use hg topic. Can you clarify?
Ok of course... The solution is to work with forked repositories... It should work fine then. Then we need to choose if we use "master" or "@" for the main bookmark.
Yes we should rely on forked repos. I think we should use both bookmarks: master for git mirror and @ for stable changeset in hg. The 2 bookmarks won't be deleted as an added safety measure.
I also enabled the branching model. So it would be nice if we do:
fix/something: for bugfix
enh/something for enhancement or features
rel/something for releases
This is inspired from numpy's workflow. This is optional and may not be enforced strictly.
I've just disabled write access for the default branch.
Just to be clear evolution extension and hg evolve allows for what git rebase -i can do to squash "draft changesets" - as noted by hg phase commands. Correct me if I am mistaken. It would be useful, indeed. I don't however understand how to use hg topic. Can you clarify?
For the CI on the PR, it's possible to activate Bitbucket Pipelines for the user repository such that we can be sure that we merge something that works.
Regarding the problem with the master and the @ bookmarks. For this workflow, there is no need for the bookmark @ and it should not be used for fluidsim repository.
The bookmark master should be used only for Github.
The right way to update the repository to the tip of the fluidsim repository is by using the command
Note that the second alias is really only for the core developers.
The first alias start_new_work is really useful for all fluidsim developers. For example, when I want to start a new development work on fluidsim, I run
hg start_new_workhg book fix/improve_tests# some changeshg commit -m "Improve some tests"hg push -B fix/improve_tests
Interesting alias. I didn't know there was a hg book --inactive command. This alias can be added to ~/.hgrc perhaps or inserted while using fluidmirror set-remote command.
Some random useful tips:
I have found hg log -G to be really useful in visualizing the heads.
Have the following in the ~/.hgrc. With this you would see relative paths while typing hg status etc.
[ui]tweakdefaults=True
Another thought on the use of evolution. As noted by @paugier, it is unfortunate that squashed/folded changesets using evolve appears in the user repository on Bitbucket. But a way around this is to mark the old bookmark as prune/something-something. Therefore if the bookmark prune/something-something reappears when you clone somewhere else, you intuitively remember you need to run hg prune -B prune/something-something to delete that head, ....or using some bash script magic.
From this message, it seems that Bitbucket team advice to use name branches for feature branches. However, I'm happy now with the workflow that we have with bookmarks so we can continue like that.
We could also try topics (from the evolve extension), but I don't really understand the advantage over bookmarks.
@paugier Could you write a few lines on how to use topic and absorb. You mentioned earlier that we would not need bookmarks anymore - it is not obvious to me how. Can we push topics to bitbucket?