D2VS A lightweight, distributed, differencing versioning system Micah Brodsky, Jeff Tyrrill

Existing versioning systems Difficult to set up Tricky to learn to use Require a designated, trusted administrator Require centralized, shared storage Many require a centralized server application ==> Not well suited to small and informal projects

Our idea: A lightweight versioning system No server program at all No single user can screw everything up, by direct action, inaction, or disappearance Can keep the repository in shared storage, in private storage, or some of each, sending updates to all users Any user can back up the entire repository The storage mechanism can be changed with time

Our idea: A lightweight versioning system Smoothly handles files of diverse formats Should interface well with external differencing and merging tools and application features Simple commands and simple, friendly behaviors No "gotchas" Any change can undone Submitting inconsistent versions, forking, and joining are trivial operations Graphical tools to visualize the both the state of the repository and its history, including any forks and problems

How it works: Difference files All transactions are in the form of signed difference files Difference file format will be a carefully specified, published standard Easily supports third-party tools Specifies simultaneous changes to one or more files Uniquely identifies the state it's differencing from and the new state it produces (using hashes?) Signed by the user who submitted the changes No difference files ever need to be deleted Compact, compressed format

How it works Users submit their changes by dropping difference files into shared storage or flooding them to all users with using some existing messaging service (e.g. email) Graphical tools interpret the chains of difference files to produce a coherent view of the repository and its history Automatic, periodic checkpoints would be a good idea, however Inconsistent changes are automatically interpreted as forks Users who disagree with changes just ignore them and produce a fork Repository configuration is just another file in the repository (the "schema") and can be updated like everything else

Feasibility System's building blocks are all individually well established Versioning systems for hierarchical file stores, difference files, shared storage volumes, email enclosures, etc. Simplicity is a key driving factor The base of potential customers is large Individuals with personal projects, students' class projects, etc. Unofficial and unsupported corporate projects Non-programmers scared off by the complexity of existing versioning systems Risks: Will it be hard to make the system really intuitive to use? Will excessive complexity inevitably creep in? Unexpected, messy corner cases (involving schema changes, conflicting updates, changes at multiple levels in the hierarchy, …)?