A companion page to What’s In My Head.
Some specific code enhancements
- WC subtree read/write APIs. The WC layer needs API that reflects operational units such as “a tree in the repository” to function consistently as the base of a copy or of a checkout; and “the modifications to a tree”; but not “merge” and “update” which are client level concepts; thus both higher and lower level than current APIs. See: SVN-4786, for a start.
- Diff in particular shows up many inconsistencies due to bitty implementation. Once generic changes APIs are in place, rewrite ‘diff’ to use them: diff(WC, repo) := {a=open(WC), b=open(repo); diff(a,b)}.
System-level topics
- Renames
- My strict element-id scheme (see svnmover) can improve handling renames in update and merge. Write it up, esp. how it can be used primitively without server-side support. To integrate it in existing svn, depends on: WC subtree read/write APIs. Develop a variant where directories are ephemeral, for better real-life semantics (like splitting and joining dirs).
- Query language
- Repo syncing
- The design of repo syncing (svnsync) is incomplete: especially revprops and locks
- revprops and locks as versioned/sequenced events; Merkle trees?
- Rewrite high level libs (libsvn_client) and clients (svn) in Python
- They consist of simple logic, filters, config, hashes, composition, etc., which in C is tedious, error-prone, inconsistent, contributing to buggy inconsistent UX. For libs, difficulty is how to provide bindings; C is good base language for that.
- OO Bindings
- Bindings state is poor, inconsistent. What’s needed is an OO generic interface, implemented in several languages. An implementation technique: write C++ OO layer on top of existing C API, then wrap it in other languages. Problem: underlying svn API design is not OO. Opportunity: design the APIs we would like to provide; reimplement libs to provide them.
- Plug-ins
- Functionality is built-in first, where pluggable interfaces would be better (diff, patch, merge, externals, keywords, eol-style, WC storage, repo storage, …)
- example: ‘diff’ plug-in support exists but is weak: want different diff tools for different file types, want to configure an external tool for tree diffs
- A new ‘svn’ client
- Consider writing an alternative ‘svn’ client from scratch with consistent functionality built from layers of blocks, not attempting to emulate CVS, and taking inspiration from git/hg/bzr. For example it should provide a function to output a tree (or file) which should encompass all of the existing ‘ svn list’, ‘svn cat’, ‘svn proplist’, ‘svn export’, ‘svn diff -r0:REV’, ‘svnrdump dump’; and a function to input a tree (or file) which should provide the inverse of all of those output modes, encompassing ‘svn propset’, ‘svnmucc put’, the hypothetical ‘svn addremove’, etc.
General observations
Progress seems to be stifled. Why?
- It’s a “maturing” project with decreasing volunteer activity.
- Technical debt: low level C code doing business logic, compatibility (almost bug-for-bug) trumps rewrites.
- Writing third-party software that uses Svn is not as easy as it should be. See: Bindings; etc.
- Companies writing commercial systems do not interact much; how can we improve that?