Version Control System Requirements
From MozillaWiki
(NOTE: See VersionControlSummit2006, [1] and [2] for some newer information)
Set of requirements compiled during a version control system (VCS) meeting in March 2006. Some of these requirements explicitly conflict; it's not expected that a single solution will fulfill all of these. These are also not prioritized in any way; that's still an outstanding task.
- changesets
- move/rename files/directories with full history and appropriate behaviour with old branches/pull by date
- atomic operations
- every operation versioned: tagging, branching, etc. are part of history (or at least logged)
- private/local branching
- sane merging
- history-sensitive merging
- sane merging
- topic branches
- with control over when you pull in outside changes into your branch
- ability to tag/branch bugzilla/js/etc. subcomponents of a tree without tagging entire tree
- tools integration
- blame (like current bonsai)
- revision history
- source browsing
- source indexing
- tree closure/override
- reports/metrics
- commits, committers, etc.
- access control
- restrict people to specific areas
- restrict areas/branches to specific people
- group membership
- being able to query where people have access
- audited ACL changes
- versioned ACLs
- cross-platform (unix/mac/windows)
- open source
- file forking/diverging with history
- cherry-picking of changesets
- offline operation
- offline diff
- offline commit/merge/etc.
- partial history pull
- including zero history
- tree information
- tree-wide diff
- selective diff
- known/unknown/missing files
- selective commit
- work with standard patches
- stable/reliable/maintained
- charset awareness
- line-ending conversion
- binary files (efficient)
- GUI tool for basic operations
- as easy or easier than CVS for checkout/commit/diff/update/merge (on trunk and on branches)
- partial tree pulls (localizers)
- import full mozilla CVS repository
- if we can't, why?
- fast working directory updates
- (checkout-by-date -> tip, branch -> branch, ...)
- pull historical version and check in changes to files in historical version
- integrity checking on repository
- checksums for error detection
- transit mechanisms
- ssh
- https
- anonymous read-only (http?)
- bootstrap local repo via blob pull
- signed commits/changesets
- hooks
- all repository operations
- bugzilla integration
- automatic notification to bugzilla of what was checked in (add attachment based on changeset)
- associate bugmail with committer
- keep committer ID separate from the actual person
- arbitrary versioned metadata on files/attributes
- permission bits
- key/value pairs