Coding period: week #3

navaneethsuresh
Published: 06/15/2019

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.

DJDT

Versions

Time

Settings from gsoc.settings

Headers

Request

SQL queries from 1 connection

Static files (2312 found, 3 used)

Templates (11 rendered)

Cache calls from 1 backend

Signals

Log messages