Version Control System Requirements

From MozillaWiki
Revision as of 02:49, 25 November 2006 by Zwnpzibue (talk | contribs)
Jump to navigation Jump to search

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* 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