This week, I have worked on testing annotate on directories, and refactoring code according to the suggestions of Benedikt and Ganesh.
Annotate on directories
If a directory name is given as input, annotate will output the last modifying patch for each file in the directory. However, the annotate in screened often fails and gives "unknown" as the corresponding patch for a file. A simple test case:
I have corrected this bug, and built patch index annotate on top of this. I have tested patch index annotate with the corrected version, and I found that they give the same output for all folders in darcs development repository.
However, when I tested corrected annotate with screened annotate, I found that they gave different output two files in /tests of darcs development repository.(They were no differences in the other folders)
The files are ./tests/issue1446.sh, and ./tests/issue1248.sh. However, even though they give different patches, they both give the correct answer as per the documentation. This is because the filenames correspond to different files in the repository history. The corrected version gives the last patch modifying the most recent file, but the screened version gives the last patch modifying a previous file.
Eric suggested that I patch the corrected version of annotate, and see if it gets accepted into the development branch. I have done so.
Code Refactors
Benedikt suggested some refactors, most of which are to help the code get closer to existing coding conventions. Ganesh suggested (a) refactor to help with the safety of the coerce used in patch index code.
Next week, I will work on:
Annotate on directories
If a directory name is given as input, annotate will output the last modifying patch for each file in the directory. However, the annotate in screened often fails and gives "unknown" as the corresponding patch for a file. A simple test case:
I have corrected this bug, and built patch index annotate on top of this. I have tested patch index annotate with the corrected version, and I found that they give the same output for all folders in darcs development repository.
However, when I tested corrected annotate with screened annotate, I found that they gave different output two files in /tests of darcs development repository.(They were no differences in the other folders)
The files are ./tests/issue1446.sh, and ./tests/issue1248.sh. However, even though they give different patches, they both give the correct answer as per the documentation. This is because the filenames correspond to different files in the repository history. The corrected version gives the last patch modifying the most recent file, but the screened version gives the last patch modifying a previous file.
Eric suggested that I patch the corrected version of annotate, and see if it gets accepted into the development branch. I have done so.
Code Refactors
Benedikt suggested some refactors, most of which are to help the code get closer to existing coding conventions. Ganesh suggested (a) refactor to help with the safety of the coerce used in patch index code.
Next week, I will work on:
- More flexibility in the default option: Patch index should be ideally invisible to the user. Currently, it is invisible only if the user uses patch index. If he wishes to not use patch index, he has to pass --no-patch-index to nearly every command. After a discussion with Eric, and Benedikt, the solution I have in mind is this:
- Change the patch index automatic update, so that it works only if the patch index is created. (and does not create it automatically) This means that by default, patch index will be used/updated only if it exists.
- Give an option to delete patch index, so that the user can go back to a state where the default is to not use/update patch index.
- Disabling patch index on lazy get: patch index gets created by default at get. However, it requires all patches to be present in the repository. --lazy is used, so that patches will not be downloaded until needed. Thus by using patch index, the purpose of lazy is defeated, as it will get all the patches.
- Integrate the timing tests into darcs-benchmark.
No comments:
Post a Comment