[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Feature list for 1.9

From: Branko Čibej <brane_at_wandisco.com>
Date: Mon, 20 May 2013 13:32:22 +0200

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
Received on 2013-05-20 13:33:01 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.