This is going to be a blog post about how I spent this week coding up and thinking about implementing the initial feature of the project in a minimal manner.

What did I do this week?

I pushed two commits to my clone[1] of `hg` in Bitbucket. Since my project is about adding functionality to store an unresolved merge-state, there can be two approaches viz; storage in changeset level and storage as external textfiles. However, this project also adds a functionality to exchange unresolved commits between repositories. So, my end goal would be storing in changeset level. @marmoute had suggested some ideas on changeset level storage and realized me the things to consider when I go on implemented that (especially, performance issues). My mentor @pulkit25 insisted me on taking baby steps to the proposed implementation. He asked me to code up a minimal implementation of external textfile storage and push the code somewhere public. The final version of the code lies here[2]. After getting this done, I worked on adding another command to help the user get back to the old state and pushed the code here[3]. I bootstrapped both of the functionalities as extensions as my mentor told me to because, it can decrease the chances of main core codebase getting buggy and can isolate it from other functionalities. I had also written required tests for the code for every functionality. This will account for bugs on adding new functionalities and keep a good eye on breaking existing functionalities upon adding new ones.

What is coming up next?

I did commit a functionality to get the user back to the old state just before the merge. So, the next step would be to help them work with the old merge-state and continue their merge resolution. I will make the changes to the commit that I've made and wait for reviews from my mentor. If this goes well on time, I'll start planning about storing data in the changeset level with the help of my mentor and the hg community.

Did you get stuck anywhere?

There was an inflexion point in the very beginning in the start of the coding period. I wasn't confident about the implementation part as my proposed plan got changed by the suggestions of the community. But, with the help of my mentor I started making progress. With minimal patches as baby steps, I improved on my implementation and am getting closer to the expected results.

There was a point when I was confused in the development workflow. I was amending the changesets and the DAG was visible as expected when I viewed it locally. But, when I pushed to the remote repo in Bitbucket, it showed the old changesets which were outdated and created new heads. I asked my mentor about this. He explained me the mechanism that happens internally when I amend changesets. I basically needed obsmarkers. When I locally amend, hg strips the old changeset but, doesn't share that info with the server. So, when I pull again, I'll get the changeset back. What obsmarkers does is tell that the changeset is obsolete and prevent it from travelling. He pointed me to evolve extension[4] which made my life easier to edit history. However, evolve support is broken in Bitbucket right now. So, the obsolete changesets will keep on showing up. He told me to ignore this at the time being and focus more on the project implementation. My mentor @pulkit25 is really active and replies to me in the speed of light whenever I ping him. He realized me that this project is going to be tough but, having patience will make amazing end results.