This is a blog post about how I spent this week addressing the reviews of last week PRs and added a new storage method for the existing functionality.

What did I do this week?

I got more reviews on the two PRs that I had sent last week. I worked first three days solving those nit-picks in the reviews. Then, my mentor advised me to fold those two patches into one and update the description. I did that. Also, the very first PR that I sent on the very first day of coding period got merged but, broken two tests. I sent another patch to fix those broken tests and it got merged. Then, I worked on adding a storage method for the mergestate information in changeset extras. Until then, the usual mergestate information was just moved from `$HGRCPATH/merge` to `$HGRCPATH/merge-unresolved`. I had to write two functions in which one is an encoder and other is a decoder to store the list of merge records in extra mapping as it only parses strings. I haven't sent a new patch for this functionality. Instead, I amended it on top of the old patch as my mentor suggested. All work that I did was included here[1]. If you are interested in my work of this week only, then refer to this[2] changeset on my bitbucket hg clone. I also added an experimental config option to make sure that we have all tests running successfully for both storage methods at the same time successfully.

What is coming up next?

Now, I have also written storage in changeset level with the help of extra mapping. But, haven't received much reviews. The upcoming work will mostly based on reviews. However, this is a minimal implementation. I have used a storage format of mergestate which works for hg versions 3.7 and above. Also, I have omitted the storage of local version content of conflicted files. I'll try to explore more corner cases and work on that. I'll think upon transmitting these conflicted changesets across repositories.

Did you get stuck anywhere?

When storing mergestate records in changeset extras, I couldn't parse the information correctly. This was due to the absence of an encoder and a decoder. These mergestate records are a list of tuples. Since we can only read/write strings in extra, we needed to encode. I came to know this from my mentor and did code that functionality right away then. Also, two of my tests of my first merged patch were failing. I fixed that with the help of my mentor and another member.

This is a blog post about how I spent this week implementing the main feature offered by the project with a simple hack.

What did I do this week?

I worked on adding a new flag `--unresolved` to both `hg shelve` and `hg unshelve` commands and have sent two PRs[1][2] to the core with an initial prototype of the project implementation. This changes the behavior of `hg shelve` and `hg unshelve` commands to handle unresolved merge-states. I have also written test cases and error handling for all corner cases possible. At first, I worked on my bitbucket clone of `hg` and was consistently pushing new changesets and seeking reviews from my mentor. After getting a nice prototype, I sent those two patches to Phabricator. This will slightly change the behavior of these commands in both UI and internal workflow. The user has to update to one of the merge parents of the unresolved shelve to unshelve for later. I tried to fix this internally. But, couldn't find out a solution. Things can get worse when I have to write traversal mechanism and write enough parsing. This may slow down hg. So, a perfect balance between performance and intuitive nature can be maintained. Since, `hg log -G` command can perfectly help the user to get the old merge parents, it's no big deal to update to one of those just before doing unshelve.

What is coming up next?

Now that I have written the UI of the project and got that to work. But, to reach the end-goal of the project I would have to store data in a more convenient way. In the current implementation, I made use of the already stored data about merge-state. I will wait some more time for reviews from the community. Until now, all of the reviews I have got were from my mentor only. So, the next step will depend upon community's interest of getting things done in a usual manner. I will try sending patches about storing data in changeset level.

Did you get stuck anywhere?

I haven't had an idea that a simple hack can make the project work. I tried to store unnecessary data in my implementation. Then, my mentor told me we are already storing these things in a different way and I can make use of that. I interacted with my mentor very much and got enough confidence to push new changesets consistently and make things work. Surprisingly, I stuck at a point of sending patches and got an error that my hg version was not compatible. But, it got resolved automatically. I had already contributed much to the core. Still couldn't figure out why it has happened. Also, my initial implementation modified the code of more commands. At that time, my mentor told me that we can skip modifying things at such a low level if I write a neat abstraction at the top level. And at last, I successfully isolated my code from other parts of the codebase and wrote enough comments on that to make the community more understand my code.

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.

Hello everyone! I'm Navaneeth Suresh, a second-year undergraduate student at Indian Institute of Technology, Kharagpur. I'm working with Mercurial on adding a functionality to store an unresolved merge-state as my GSoC project.

What did I do this week?

There was a video conferencing session with my mentors of 45 min duration last week, we scheduled weekly meetings and discussed on how to have a kickstart with the project. I was advised by my mentors to send a mail in the mailing list so that I'll get to know the opinions of people on my proposal. They insisted on explaining the working of an open source community to me and told that only mentor-mentee interaction might not be enough during the GSoC period. As a result, I had sent a mail and got to know the opinions of various people on the project implementation. I had written a minimal RFC patch for the proposed implementation. However, changes were made in my proposed implementation method and I finalized the pipeline for the implementation with the help of the community by splitting the whole idea into even more subtasks. I realized the importance of starting small and seeking opinion of community during this period. Pros and cons for various methods to implement the project were discussed and people in the community voted for the approaches. I picked up the approach with most votes.

What is coming up next?

As soon as the coding period begins next week, I'll be writing code for initial feature of the project. I was told to bootstrap the implementation as an Extension so that it cannot interfere with the core package and turns out to be buggy. So, I'll be writing an extension to support storing unresolved merge-states as commits. This will involve giving attention to a couple of things and changing the default behavior of some parts of the codebase.

Did you get stuck anywhere?

When I was trying to visualize the changes caused by a command called `hg shelve` after studying its code and behavior, I was unable to proceed. I asked the community for a solution. One of the members suggested a solution which I had already tried and failed. But, then they make me realize that there is no need to visualize those changes now and told me that is not the correct starting point as I'll be facing some issues and told to start with a smaller subtask which less intervenes with most of the code. Then, I moved to thinking of a minimal solution to the smallest subtask possible.

That's all for this week. I'll be blogging about the things happen in the later phase of the GSoC period. Stay tuned!