|
Size: 330
Comment:
|
Size: 919
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| * we currently read the manifest of each head in order to figure out which versions of the hgtags file to use. on a moderately large repo, even a single head makes this very slow | |
| Line 5: | Line 6: |
| * when merging named branches A and B, the new head shows up as the head of both A and B, so the asymmetry of "merged A into B" is not preserved | |
| Line 7: | Line 9: |
| * might be simpler to handle changelog specially; manifest doesn't need appendfile at all | |
| Line 9: | Line 12: |
| * api docs * user docs |
|
| Line 11: | Line 16: |
| * https push support | * http{,s} push support * add "unbundle" verb for ssh and http, to avoid exposing locking to remote clients * handling of case-sensitivity issues |
Topics for London sprint:
- efficient handling of tags
- we currently read the manifest of each head in order to figure out which versions of the hgtags file to use. on a moderately large repo, even a single head makes this very slow
- possible improvements to branch tag algorithm
- when merging named branches A and B, the new head shows up as the head of both A and B, so the asymmetry of "merged A into B" is not preserved
- what do we want to do, if anything, about deletions in file level revlogs?
- revisit appendfile
- might be simpler to handle changelog specially; manifest doesn't need appendfile at all
- merge w/renames
- improving docs
- api docs
- user docs
- more efficient findincoming?
- rsync/sftp support
- http{,s} push support
- add "unbundle" verb for ssh and http, to avoid exposing locking to remote clients
- handling of case-sensitivity issues