cambria

This document catalogs the test suite for Fossil's version control system core, excluding UI, web, wiki, forum, and ticket features. Tests are organized in an order suitable for implementing a version control system from basic to complex features, ensuring each test builds upon previously tested functionality.

Test Organization Philosophy

Tests are ordered to support incremental implementation:

1. Foundation: Delta compression, file operations, basic data structures
2. Core Operations: Repository initialization, adding files, committing
3. Basic Version Control: Checkout, update, status, diff
4. File Management: Move, rename, remove operations
5. Branching & Tagging: Branch creation, tag management
6. Advanced Operations: Merging, conflict resolution, cherry-pick
7. State Management: Stash, revert, undo
8. Repository Operations: Rebuild, integrity checks
9. Distributed Operations: Clone, sync, push, pull (if present)

---

Phase 1: Foundation & Core Algorithms

1.1 Delta Compression (delta1.test)

Purpose: Tests the delta compression algorithm which is fundamental to efficient storage.

Description: Validates delta creation and application by:

• Creating random modifications to test files
• Computing deltas between original and modified versions
• Applying deltas to reconstruct content
• Verifying reconstruction matches expected output

Acceptance Criteria:

• Delta application reconstructs original content exactly
• Handles various change patterns (insertions, deletions, modifications)
• Works with empty files and edge cases
• Supports multiple delta chaining scenarios

Dependencies: None (most basic building block)

Relevant Schema: delta(rid, srcid), blob.content

Relevant Modules: src/delta.c, src/content.c

---

1.2 File Path Operations (file1.test)

Purpose: Tests file path manipulation utilities essential for working tree operations.

Description: Validates path simplification and relative/absolute path resolution:

• Simplifies paths with ., .., redundant separators
• Computes relative paths between directories
• Resolves tree-relative names
• Handles platform-specific path conventions (Windows vs Unix)

Acceptance Criteria:

• Correctly simplifies complex paths (e.g., a/b/../c → a/c)
• Accurately computes relative paths for arbitrary directory pairs
• Handles edge cases (root, current directory, parent references)
• Platform-aware path handling (UNC paths on Windows)

Dependencies: None

Relevant Schema: filename(fnid, name)

Relevant Modules: src/file.c, src/filename.c

---

1.3 Glob Pattern Matching (glob.test)

Purpose: Tests pattern matching for file selection operations.

Description: Validates glob pattern parsing and matching:

• Wildcard patterns (*, ?, [...])
• Path-aware matching
• Negation patterns
• Case sensitivity handling

Acceptance Criteria:

• Correctly matches files against glob patterns
• Handles complex patterns with multiple wildcards
• Properly interprets character classes and ranges
• Respects platform case-sensitivity rules

Dependencies: None

Relevant Modules: src/glob.c

---

Phase 2: Repository & Commit Operations

2.1 Binary File Detection & Diff Basics (diff.test)

Purpose: Tests binary file detection and basic diff operations.

Description: Validates the system's ability to:

• Detect binary vs text files (NUL bytes, long lines)
• Skip diff computation for binary files
• Generate appropriate diff output for text files
• Handle edge cases (empty files, single-line files)

Acceptance Criteria:

• Correctly identifies binary files (NUL bytes, excessive line length)
• Refuses to diff binary files with appropriate message
• Generates valid unified diff format for text changes
• Handles files with unusual characteristics

Dependencies: Delta compression

Relevant Schema: blob.content, mlink

Relevant Modules: src/diff.c, src/diffcmd.c

---

2.2 Commit Warnings (commit-warning.test)

Purpose: Tests pre-commit validation and warnings for file characteristics.

Description: Validates detection and warnings for:

• Binary files
• Files with CRLF line endings
• Mixed line ending styles
• Overlong lines
• Invalid UTF-8 sequences
• UTF-16 encoded files
• UTF-8 BOM presence

Acceptance Criteria:

• Detects and warns about binary content
• Identifies line ending inconsistencies
• Warns about lines exceeding length limits
• Validates UTF-8 encoding correctness
• Detects UTF-16 and other encodings
• Each warning is appropriate and actionable

Dependencies: File operations, diff basics

Relevant Modules: src/checkin.c, src/encode.c

---

2.3 Basic Add/Commit Cycle (mv-rm.test - setup section)

Purpose: Tests the fundamental add and commit operations.

Description: Validates initial repository operations:

• Repository initialization
• Adding new files to version control
• First commit creation
• File status tracking

Acceptance Criteria:

• Repository initializes with proper schema
• Files can be added and tracked
• Commits create manifest artifacts
• Working directory state correctly reflects changes

Dependencies: File operations, delta compression

Relevant Schema: blob, mlink, plink, filename, event

Relevant Modules: src/checkin.c, src/manifest.c, src/add.c

---

2.4 File Lifecycle - Add/Extra/Changes (clean.test - setup)

Purpose: Tests file status determination and working copy queries.

Description: Validates the system's ability to:

• Identify added (managed) files
• Detect extra (unmanaged) files
• Track modified files
• Report working directory state

Acceptance Criteria:

• Correctly distinguishes managed vs unmanaged files
• Detects modifications to tracked files
• fossil extra lists only unmanaged files
• fossil changes lists only modified tracked files

Dependencies: Add/commit cycle

Relevant Schema: vfile (working copy virtual table), blob, mlink

Relevant Modules: src/checkin.c, src/vfile.c

---

Phase 3: Checkout & Update Operations

3.1 Basic Checkout (update.test - initial state)

Purpose: Tests checking out repository content to working directory.

Description: Validates:

• Initial checkout from tip
• File materialization from blob storage
• Working directory population
• Checkout state tracking

Acceptance Criteria:

• All files from manifest appear in working directory
• File contents match blob storage exactly
• File permissions preserved correctly
• Checkout metadata tracks current version

Dependencies: Add/commit cycle, delta compression

Relevant Schema: mlink, blob, delta, filename

Relevant Modules: src/checkout.c, src/content.c, src/vfile.c

---

3.2 Update Operations (update.test)

Purpose: Comprehensive test of update scenarios between versions.

Description: Tests all update scenarios:

• ADD: New files in target version
• ADD (overwrite): New file conflicts with unmanaged file
• UPDATE: Modified files
• UPDATE (missing): Update when local file deleted
• UPDATE (change to unmanaged): Local modifications to be overwritten
• DELETE: Files removed in target
• CONFLICT: Incompatible local and remote changes

Acceptance Criteria:

• ADD operations create new files correctly
• ADD with conflict backs up unmanaged file
• UPDATE applies changes to existing files
• UPDATE recreates missing files
• UPDATE warns about overwriting local changes
• DELETE removes files properly
• CONFLICT operations preserve both versions and mark conflict
• --verbose provides appropriate status messages
• Post-update state matches target version (modulo conflicts)

Dependencies: Checkout, diff, file status

Relevant Schema: mlink, plink, vfile, blob

Relevant Modules: src/checkout.c, src/update.c, src/merge.c

---

Phase 4: File Management Operations

4.1 Move/Rename Operations (mv-rm.test - move tests)

Purpose: Tests file and directory renaming operations.

Description: Validates both soft (metadata only) and hard (filesystem) operations:

• Relative path moves (within subdirectories)
• Absolute path moves
• File to directory moves
• Directory to directory moves
• Move to new (non-existent) directories

Acceptance Criteria:

• Soft move updates repository metadata only
• Hard move updates both filesystem and metadata
• Relative and absolute paths work correctly
• Moving to non-existent directories fails appropriately
• fossil revert correctly undoes move operations
• Renamed files maintain history linkage

Dependencies: Add/commit, file operations

Relevant Schema: mlink.pfnid (parent filename for renames), filename

Relevant Modules: src/mv.c, src/checkin.c

---

4.2 Remove Operations (mv-rm.test - remove tests)

Purpose: Tests file and directory removal from version control.

Description: Validates soft and hard remove operations:

• Soft remove (unmanage, keep file)
• Hard remove (delete from filesystem and unmanage)
• Removing files vs directories
• Relative and absolute path specifications

Acceptance Criteria:

• Soft remove unmanages without deleting
• Hard remove deletes file and unmanages
• Removing directories processes all contained files
• fossil revert restores removed files
• Subsequent commits reflect removals

Dependencies: Add/commit, move operations

Relevant Schema: mlink, vfile

Relevant Modules: src/rm.c, src/checkin.c

---

4.3 Clean Operations (clean.test)

Purpose: Tests removal of unmanaged files from working directory.

Description: Validates cleaning extra files:

• Identifying unmanaged files
• Removing unmanaged files
• Undo support for clean operations
• Large file handling (>10MB affects undo)
• Prompt behavior

Acceptance Criteria:

• fossil clean removes all unmanaged files
• Undo restores cleaned files (below size threshold)
• Large files affect undo availability
• --no-prompt suppresses confirmation
• Status commands reflect cleaned state

Dependencies: File lifecycle tracking

Relevant Modules: src/clean.c, src/undo.c

---

Phase 5: Three-Way Merge Foundation

5.1 Basic Three-Way Merge (merge1.test)

Purpose: Tests fundamental three-way merge algorithm.

Description: Tests merge scenarios with common ancestor:

• Non-conflicting changes (different lines)
• Both sides modify same region (conflict)
• One side changes, other unchanged (auto-merge)
• Identical changes on both sides (auto-merge)

Acceptance Criteria:

• Non-overlapping changes merge cleanly
• Conflicting changes produce conflict markers
• Conflict markers show: local, common ancestor, merged-in
• Suggested resolution provided for conflicts
• Identical changes result in single copy
• Order of merge arguments affects conflict presentation

Dependencies: Diff, file operations

Relevant Schema: N/A (algorithm test using fossil 3-way-merge utility)

Relevant Modules: src/merge.c, src/diff.c

---

5.2 Random Merge Testing (merge2.test)

Purpose: Stress tests merge algorithm with random changes.

Description: Applies random modifications and verifies:

• Merge correctness across diverse change patterns
• Commutativity of mergeable changes
• Handling of various text transformations

Acceptance Criteria:

• Merges succeed for thousands of random change combinations
• Deterministic results for same inputs
• No data loss or corruption
• Merge symmetry maintained where expected

Dependencies: Basic three-way merge

Relevant Modules: src/merge.c, src/diff.c

---

5.3 Complex Merge Scenarios (merge3.test)

Purpose: Tests merge algorithm on carefully crafted edge cases.

Description: Tests specific problematic scenarios:

• Multiple overlapping regions
• Changes at boundaries
• Insertions and deletions
• Adjacent but non-overlapping changes

Acceptance Criteria:

• Each scenario produces expected merge result
• Conflicts identified precisely
• Non-conflicting portions merge correctly
• Boundary conditions handled properly

Dependencies: Basic three-way merge

Relevant Modules: src/merge.c, src/diff.c

---

5.4 Bidirectional Merge Testing (merge4.test)

Purpose: Tests merge symmetry and bidirectional properties.

Description: Validates that merging A→B and B→A produces consistent results:

• Both directions produce compatible outcomes
• Conflict regions identified consistently
• Suggested resolutions are reasonable

Acceptance Criteria:

• Merge(base, A, B) conflicts same regions as Merge(base, B, A)
• Conflict markers appropriately reflect direction
• Both orderings preserve all information

Dependencies: Complex merge scenarios

Relevant Modules: src/merge.c, src/diff.c

---

Phase 6: Repository-Level Merge Operations

6.1 Branch-Level Merge (merge5.test)

Purpose: Tests merging entire branches with file-level integration.

Description: Tests repository-level merge operations:

• Merging branch into trunk
• Merging trunk into branch
• Multiple file additions across branches
• Checkout state after merge
• Undo of merge operations

Acceptance Criteria:

• Merged working copy contains files from both branches
• File contents computed correctly via three-way merge
• SHA1 checksums verify correct content
• fossil undo restores pre-merge state
• Symmetry: merging A→B or B→A reaches same tree state

Dependencies: Three-way merge, checkout/update, commit

Relevant Schema: plink, mlink, blob, leaf

Relevant Modules: src/merge.c, src/checkin.c, src/manifest.c

---

6.2 Multiple Merge Sources (merge6.test)

Purpose: Tests merging multiple branches sequentially.

Description: Validates:

• Multiple fossil merge calls before commit
• Accumulating changes from several branches
• File additions from multiple sources
• Conflict handling across multiple merges

Acceptance Criteria:

• Can merge multiple branches before committing
• All changes accumulate in working copy
• Files from all branches present after commit
• Conflicts detected across all merge sources

Dependencies: Branch-level merge

Relevant Schema: plink.isprim (primary vs secondary parents), cherrypick

Relevant Modules: src/merge.c, src/checkin.c

---

6.3 Merge with Renames (merge_renames.test)

Purpose: Tests merging when files have been renamed.

Description: Tests complex scenarios:

• File renamed on one branch, modified on another
• File renamed on both branches (different names)
• File renamed then merged with ancestor changes
• Directory renames affecting multiple files

Acceptance Criteria:

• Renames detected and propagated through merge
• Modifications to renamed files applied correctly
• Conflicting renames identified
• History linkage maintained through renames
• Merge outcome reflects both rename and content changes

Dependencies: Move operations, branch-level merge

Relevant Schema: mlink.pfnid, mlink.pid (parent file ID for renames)

Relevant Modules: src/merge.c, src/manifest.c, src/checkin.c

---

6.4 Additional Rename Merge Cases (merge_renames_2.test)

Purpose: Tests additional rename merge edge cases.

Description: Further validates:

• Branch creation during rename sequences
• Pivot-point merges with renames
• Rename on branch merged back to original branch
• Cross-branch rename conflict resolution

Acceptance Criteria:

• All rename scenarios merge correctly
• Branch creation doesn't interfere with rename tracking
• Pivot merges handle renames appropriately
• Update operations correctly reflect rename merges

Dependencies: Merge with renames

Relevant Modules: src/merge.c, src/branch.c

---

6.5 Executable File Merging (merge_exe.test)

Purpose: Tests merging files with executable permissions.

Description: Validates permission handling in merges:

• Executable bit preservation
• Conflicts when permission changes conflict
• Permission inheritance through merges

Acceptance Criteria:

• Executable permissions preserved through merge
• Permission conflicts detected
• Correct permission in merged result

Dependencies: Branch-level merge

Relevant Schema: mlink.mperm (file permissions)

Relevant Modules: src/merge.c, src/checkin.c

---

6.6 Merge Warnings (merge_warn.test)

Purpose: Tests warning generation during merge operations.

Description: Validates warnings for:

• Potential conflicts
• Uncommitted changes before merge
• Merge with no common ancestor
• Cherrypick scenarios

Acceptance Criteria:

• Appropriate warnings issued for risky scenarios
• Warnings don't prevent valid merges
• Warning messages are clear and actionable

Dependencies: Branch-level merge

Relevant Modules: src/merge.c

---

Phase 7: State Management Operations

7.1 Revert Operations (revert.test)

Purpose: Tests reverting working directory changes.

Description: Validates reverting various change types:

• Added files (unmanage)
• Removed files (restore)
• Modified files (restore original)
• Renamed files (undo rename)
• Selective revert (specific files)
• Full revert (all changes)

Acceptance Criteria:

• Revert without arguments restores all changes
• Selective revert operates only on specified files
• Added files become unmanaged (not deleted)
• Removed files are restored
• Modified files reset to checked-out version
• Renames are undone
• fossil undo reverses revert operations

Dependencies: Add, remove, move, modify operations

Relevant Schema: vfile

Relevant Modules: src/revert.c, src/undo.c

---

7.2 Stash Operations (stash.test)

Purpose: Tests stashing and restoring working directory changes.

Description: Validates stash functionality:

• Stashing added files
• Stashing removed files
• Stashing modified files
• Stashing renames
• Multiple stashes
• Stash list/show/pop/apply/drop operations
• Stash with merge conflicts

Acceptance Criteria:

• fossil stash saves all working changes
• Working directory clean after stash
• fossil stash list shows all stashes
• fossil stash apply restores changes without removing stash
• fossil stash pop restores and removes stash
• fossil stash drop removes stash without applying
• Stashed renames handled correctly
• Can maintain multiple stashes
• Known bugs documented appropriately

Dependencies: Revert, add/remove/move/modify operations

Relevant Schema: Private blob storage for stash artifacts

Relevant Modules: src/stash.c, src/undo.c

---

Phase 8: Branch & Tag Management

8.1 Branch Creation & Management (amend.test - branch section)

Purpose: Tests branch creation and manipulation.

Description: Validates:

• Creating branches via commit
• Creating branches via amend
• Branch naming
• Branch listing
• Branch switching

Acceptance Criteria:

• fossil commit --branch creates new branch
• fossil amend --branch moves commit to different branch
• Branch names appear in tag list
• fossil branch ls shows all branches
• Current branch marked with *

Dependencies: Commit operations, checkout

Relevant Schema: tag, tagxref (branch is a tag), leaf

Relevant Modules: src/branch.c, src/tag.c, src/checkin.c

---

8.2 Tag Operations (amend.test - tag section)

Purpose: Tests tagging and tag manipulation.

Description: Validates:

• Adding tags to commits
• Removing tags
• Propagating vs non-propagating tags
• Tag values
• Tag listing

Acceptance Criteria:

• Tags can be added to any commit
• Tags appear in timeline and info output
• Propagating tags inherited by descendants
• Non-propagating tags stay on single commit
• Tags can have values (not just boolean)

Dependencies: Commit operations

Relevant Schema: tag, tagxref

Relevant Modules: src/tag.c, src/checkin.c

---

8.3 Commit Amendments (amend.test)

Purpose: Tests amending historical commits.

Description: Validates amending:

• Commit comment
• Commit author
• Commit timestamp
• Branch assignment
• Tags
• Background color (metadata)

Acceptance Criteria:

• Can amend any commit metadata
• Amendments create new control artifacts
• Timeline reflects amendments
• fossil info shows amendment history
• Cannot amend immutable aspects (file content)

Dependencies: Commit operations, tag operations

Relevant Schema: blob (control artifacts), event

Relevant Modules: src/amend.c, src/tag.c

---

Phase 9: Advanced Features

9.1 Manifest Operations (set-manifest.test)

Purpose: Tests manifest file generation and validation.

Description: Validates:

• Generating manifest files in working directory
• Manifest content correctness
• Manifest inclusion in commits
• R-card handling (renames)
• Manifest parsing

Acceptance Criteria:

• Generated manifests match repository artifacts
• Manifest includes all file hashes
• R-cards correctly encode renames
• Manifests can be verified and parsed

Dependencies: Commit operations, rename operations

Relevant Schema: blob (manifest artifacts), mlink

Relevant Modules: src/manifest.c, src/checkin.c

---

9.2 Reserved Names Handling (reserved-names.test)

Purpose: Tests handling of filesystem reserved names.

Description: Validates behavior with:

• Platform reserved names (CON, PRN, NUL on Windows)
• Case-insensitive filesystem conflicts
• Special character handling

Acceptance Criteria:

• Reserved names detected appropriately
• Appropriate errors or warnings generated
• Repository remains consistent
• Cross-platform compatibility maintained

Dependencies: File operations, commit operations

Relevant Modules: src/file.c, src/checkin.c

---

9.3 Symbolic Link Handling (symlinks.test)

Purpose: Tests version control of symbolic links.

Description: Validates:

• Adding symlinks to repository
• Symlink content storage (target path, not target content)
• Checking out symlinks
• Modifying symlink targets
• Platform-specific symlink support

Acceptance Criteria:

• Symlinks stored as symlinks (not target content)
• Target path versioned correctly
• Symlinks recreated on checkout
• Modified targets detected and committable
• Graceful handling on platforms without symlink support

Dependencies: Add/commit, checkout

Relevant Schema: mlink.mperm (symlink permission bit)

Relevant Modules: src/checkin.c, src/checkout.c, src/file.c

---

9.4 UTF-8 Handling (utf.test)

Purpose: Tests UTF-8 encoding in filenames and content.

Description: Validates:

• UTF-8 filenames
• UTF-8 content in files
• UTF-8 in commit messages
• BOM handling
• Multi-byte character boundaries

Acceptance Criteria:

• UTF-8 filenames stored and retrieved correctly
• UTF-8 content versioned accurately
• Diff operations handle multi-byte characters
• Merge operations preserve UTF-8 encoding
• Invalid UTF-8 detected

Dependencies: Basic operations (add/commit/checkout)

Relevant Modules: src/encode.c, all file I/O modules

---

Phase 10: Repository Integrity & Maintenance

10.1 Repository Settings (settings-repo.test)

Purpose: Tests repository-specific settings.

Description: Validates:

• Setting values stored in repository
• Settings versioned and distributed
• Settings override hierarchy (global vs repo)
• Common settings (ignore-glob, crnl-glob, etc.)

Acceptance Criteria:

• Settings stored in .fossil-settings/ when versioned
• Repository settings override global settings
• Settings properly parsed and applied
• Settings synchronized across clones

Dependencies: Commit operations

Relevant Schema: config table, versioned files

Relevant Modules: src/configure.c, src/db.c

---

10.2 Unversioned File Operations (unversioned.test)

Purpose: Tests unversioned file storage and retrieval.

Description: Validates:

• Storing unversioned files in repository
• Retrieving unversioned files
• Listing unversioned files
• Updating unversioned files
• Removing unversioned files

Acceptance Criteria:

• Unversioned files stored separate from versioned content
• Files retrievable by name
• List operations show all unversioned files
• Updates replace content correctly
• Removal deletes from repository

Dependencies: Basic repository operations

Relevant Schema: unversioned table

Relevant Modules: src/unversioned.c

---

Phase 11: Distributed Operations (If Implemented)

Note: The test suite examined focuses primarily on local repository operations. Full sync/clone/push/pull tests may exist in separate integration tests or may be tested manually.

11.1 Clone Operations (Not found in examined tests)

Purpose: Tests repository cloning.

Expected Coverage:

• Clone remote repository
• Authentication
• Network protocols (HTTP, SSH, file://)
• Partial clones
• Clone with specific branches

Relevant Schema: rcvfrom, blob.rcvid

Relevant Modules: src/clone.c, src/xfer.c

---

11.2 Sync Operations (Not found in examined tests)

Purpose: Tests bidirectional synchronization.

Expected Coverage:

• Push local changes
• Pull remote changes
• Bidirectional sync
• Conflict detection
• Phantom artifact resolution
• Private branch handling

Relevant Schema: rcvfrom, unsent, phantom, private

Relevant Modules: src/sync.c, src/xfer.c

---

Test Execution Framework

Test Infrastructure (tester.tcl)

Purpose: Provides test harness and utilities.

Key Features:

• Test setup/cleanup automation
• Repository initialization
• File manipulation utilities
• Result normalization
• Parallel test execution support
• Test filtering by name

Common Utilities:

• test_setup: Creates clean test repository
• test_cleanup: Removes test artifacts
• write_file: Creates files with content
• read_file: Reads file content
• fossil: Executes fossil commands and captures output
• test: Asserts expected vs actual results
• normalize_result: Normalizes output for comparison

---

Implementation Priority Summary

For implementing a compatible VCS, tests should be executed in this order:

1. Foundation (Phase 1): Delta, file ops, glob → Enables storage layer
2. Core VCS (Phase 2-3): Add, commit, checkout, update → Basic VCS workflow
   
3. File Management (Phase 4): Move, remove, clean → Complete file lifecycle
4. Merge Foundation (Phase 5): Three-way merge algorithm → Enables branching
5. Repository Merge (Phase 6): Branch merges, renames → Full merge support
6. State Management (Phase 7): Revert, stash → Developer workflow tools
7. Branch/Tag (Phase 8): Branch creation, tagging, amendments → Version management
8. Advanced (Phase 9): Manifests, symlinks, UTF-8, reserved names → Edge cases
9. Integrity (Phase 10): Settings, unversioned files → Repository maintenance
10. Distributed (Phase 11): Clone, sync → Multi-repository collaboration

Each phase builds upon previous phases, ensuring that dependencies are satisfied before testing more complex features.

---

Test Coverage Metrics

Component	Test Files	Focus Areas
Delta Compression	delta1.test	Algorithm correctness
File Operations	file1.test, glob.test	Path manipulation, pattern matching
Diff & Merge	diff.test, merge1-6.test, merge3-4.test, merge_renames*.test, merge_exe.test, merge_warn.test	All merge scenarios
Checkout/Update	update.test	State transitions
File Lifecycle	mv-rm.test, clean.test, revert.test	Move, remove, revert operations
Stash	stash.test	Temporary state storage
Commit	commit-warning.test, amend.test	Commit creation and modification
Advanced	set-manifest.test, reserved-names.test, symlinks.test, utf.test	Edge cases
Repository	settings-repo.test, unversioned.test	Configuration and maintenance

Total Test Categories: 9 major areas Total Test Files Analyzed: ~25 files Test Approach: Mix of unit tests (algorithm tests) and integration tests (full workflow tests)

---

Cross-Reference: Tests to Schema/Modules

Schema Element	Primary Test Files
blob, delta	delta1.test, all merge tests
filename	file1.test, mv-rm.test
mlink, plink	merge5.test, merge_renames*.test, amend.test
leaf	amend.test, merge5.test
tag, tagxref	amend.test
event	amend.test, commit tests
vfile	update.test, revert.test, stash.test

Module	Primary Test Files
src/delta.c	delta1.test
src/merge.c	merge1.test through merge_warn.test
src/checkin.c	All commit-related tests
src/checkout.c	update.test, merge tests
src/manifest.c	set-manifest.test, merge tests
src/mv.c, src/rm.c	mv-rm.test
src/revert.c	revert.test
src/stash.c	stash.test
src/tag.c, src/branch.c	amend.test

---

Conclusion

This test suite provides comprehensive coverage of Fossil's version control core, focusing on correctness of fundamental algorithms (delta, merge), robustness of file operations (add, move, remove, rename), and completeness of version control workflows (commit, branch, merge, revert). The tests are structured to support incremental implementation, with each phase building on the previous, ensuring a solid foundation before tackling complex features like merge conflict resolution and distributed synchronization.