Now that we've released a 1.8 candidate, I thought it would be a good
time to share with the rest of dev@ what we five subversives at WANdisco
have been discussing for 1.9. This is only a very high-level list as I
don't want to make this mail too long ... I'm sure we'll have enough
time in Berlin to argue about specifics.
A. Server-side rename tracking
* probably involves implementing EV2 (with shims) which includes
rename operation
* change the way copy-id is generated to avoid possible unique-key
collisions:
o curently rename is copy+delete: (node-id,copy-id,txn-id) ->
(node-id,new-copy-id,new-txn-id)
o a proper rename does: (node-id,copy-id,txn-id) ->
(node-id,copy-id,new-txn-id)
o the latter conflicts with the current way that copy-ids are
"inherited" in the tree hierarchy during lazy copying
* server (and possibly client?) should support simple heuristics for
converting copy+delete records from older wire protocol into move
records (possibly part of EV2 shim layer?)
* metadata structures for rename support added by "svnadmin upgrade",
no dump+reload required
B. Merge enhancements
* general merge algorithm improvements (common algo for currently
different cherrypick vs. whole-hawg merges, etc.)
* merge tracks renames
* possibly: redefinition of mergeinfo architecture
o mergeinfo no longer based on path+revision but on node IDs
o implies node IDs are exposed to the client and become part of
the repos API
o merginfo storage decoupled from versioned properties
o don't talk to me about backward-compatibility shims ...
C. Read-only support for older working copies
* one of the drawbacks of WC-NG is that it does not have a defined
architecture for backward compatibility, so, for starters, define that
* next, define what "read-only" actually means, as it does not
necessarily mean "don't change the wc.db"
* implement backward-compat layers for read-only operations on 1.7 and
1.8 working copies, with intent to maintain compatibility in future
releases as well
D. Miscellaneous
* Solution for Unicode normalization issues (client and server)
o make both client and server metadata indexes normalization-agnostic
o do not change the wire protocol or API constraints (e.g.,
neither will require paths to be normalized)
* Repository cache server
Stefan2 has been working on a faster multi-process shared cache as
part of the FSFS enhancements, and would like to get that part into 1.9.
* svnpubsub enhancements
o generate events for revprop and other unversioned metadata changes
o proper Pythonic packaging
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
