Day 3 Brainstorming

Day 3 is all about blue-sky brainstorming... how we might design Subversion 2.0, completely free of compatibility guarantees. What can we learn from our mistakes? What would we do differently the second time around?

Here are some brainstorm notes, and after lunch we'll be discussing things in parallel breakout sessions.

• 'svn merge' vs. 'svn diff-and-apply'
• server broadcasts behaviors to clients
• libsvn_wc: could it be simpler?
• sqlite dependency on client and/or server?
• do working copies really need to be detachable/movable?
• we should completely hide APR. and use APR 1.2.
• break client and server into separate products with own schedules
• define a single OO interface for other languages to use
• stop requiring whole URLs to identify branches and tags!
• possible filesystem changes
• revlog storage format for repos
• add indexing/searching to repository
• be truly timesafe (svn is close, but revprops aren't timesafe)
• OBLITERATE designed from the beginning.
• true renames in both repository and client
• support for concurrent writes to the same fs transaction
• distinct concepts of 'branch' vs. 'copy' vs 'tag'?
• ACLs built into filesystem; ACLS are not timesafe data.
• native 'symlink' nodes, not just files and dirs... could be used to track branches and tags, would replace svn:externals
• file format determines how it's stored (??)
• typed properties (binary, text, utf8, etc.)
• signed changesets?
• something to replace svn:externals -- incomplete checkouts, viewspecs, etc.
• better testing framework
• better build system
• Rewrite in another language?
• C++ Pros:
• real objects: no more function pointers and batons
• still swig-bindable
• virtual functions instead of vtables
• function overloading instead of revving function names
• totally safe, assuming we have tight style guide and we’re disciplined (which we are!)
• C++ Cons:
• ABI problems. (Justin? DannyB?)
• Decentralized Design? To what degree? How many of those 'advantages' do we get?
• Karl sez: incremental path to decentralized clients
• Justin wants a smaller working copy. Flexibility: no text-base,or yes text-base. Fears having whole repository locally.
• Idea of a hybrid model: can be centralized or distributed. Client can choose (a) tiny wc with no text-base, (b) larger wc with text-base, (c) big wc with even more history available.
• DannyB says that this shiftable wc model would probably end up sharing implementation with the repository
• Possible breakout sessions
• possible design of a hybrid centralized/decentralized model
• project component reorganization: server / client / library API
• redesign of our testing system
• filesystem redesign (see above for myriad of ideas)
• how to make our bindings not suck
• build system rewrite (scons?)
• merge-tracking: where to go from here
• gstein, dlr: we should rewrite svn* commandline tools in python