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

2. 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

3. 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

4. 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

5. 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

6. 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. )
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

7. Feasibility
System's building blocks are all individually well established
Versioning systems for hierarchical file stores, difference files, shared storage volumes, 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, …)?