| Comment: | docs(changelog): no public baseline option yet |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk | feat/horizon-cones |
| Files: | files | file ages | folders |
| SHA3-256: |
0cd130a5ced89d0a5796a97d777c4696 |
| User & Date: | [email protected] on 2026-10-22 20:38:11.000 |
| Other Links: | branch diff | manifest | tags |
|
2026-10-22
| ||
| 21:17 |
test(verify): log peak heap in the corpus rebuild test
The rebuild budget is a wall-time and memory target, and the test only reported time. Sampling HeapInuse beside the run makes a regression in either visible from one -v run. check-in: 7cb4d1aa0d user: [email protected] tags: feat/horizon-cones, trunk | |
| 21:16 |
fix(merge): follow renames as fossil's merge does
A file renamed on one side and edited on the other was merged as a deletion plus an addition: the edit was kept under the old name and the renamed copy arrived beside it, so fossil and go-libfossil left different trees and recorded different changes for the same merge. Port fossil's rename matching (merge.c merge_cmd): the name pivot nid (pivot_find(1) of M and V, rerun against P when they differ), the renames from nid to V, P and M (path.c find_filename_changes, one way, now path.FilenameChanges), and the fv table those fill (add_renames, the nid!=pid name fill-in, then the files of V, P and M) as merge.MatchFiles/FollowRenames. Checkout.Merge classifies each matched file as before and renames on disk and in vfile a file the merged-in version renamed and the checkout did not, after the other steps, moving swapped names together and setting aside a removed or deleted row that held the new name. Where fossil would rename over a kept tracked file or an untracked one, Merge refuses, as it already does for adds. Repo.Merge matches files the same way and commits the merged tree whole, recording the rename (FileToCommit.OldName); the whole-tree commit also stops it carrying forward a file the merge deleted. The CLI prints RENAME lines where fossil's merge prints them. check-in: 2c3a78cf5e user: [email protected] tags: feat/horizon-cones, trunk | |
| 21:03 |
Merge branch 'wip/clone-cursor' into feat/horizon-cones
Clone replies at a horizon carry the cursor and a horizon clone records it per origin (draft-fossil-horizon-00 §6.2.6), so the first exchange after a clone no longer announces the whole holding. Interoperates with zit both ways. check-in: 7e44f7107b user: [email protected] tags: feat/horizon-cones, trunk | |
| 21:03 |
feat(sync): hand out and record the horizon cursor on clone
The draft has an origin that classified a request emit the cursor in every reply, and a client that converged record the last reply's cursor with its artifact count per origin. A clone did neither, so the first exchange that sends after a horizon clone announced the whole holding. A clone reply now carries the position it served the clone sequence through: below the sequence it hands on, or the origin's whole position once it hands on none. A horizon clone that names its origin records the last cursor and its own count, as zit does; the HTTP transport names it for the public Clone as for Sync. check-in: 7d9536347a user: [email protected] tags: feat/horizon-cones, trunk | |
| 20:38 | docs(changelog): no public baseline option yet check-in: 0cd130a5ce user: [email protected] tags: feat/horizon-cones, trunk | |
| 20:37 | docs(changelog): merge bases as fossil chooses them check-in: d1e7ef2305 user: [email protected] tags: feat/horizon-cones, trunk | |