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

Re: Feature list for 1.9

From: Alexey Neyman <stilor_at_att.net>
Date: Wed, 29 May 2013 16:59:46 -0700

Log message templates? As far as I understand, the needed part of repository-
dictated configuration is already there, now the 'svn ci' code needs to query
those inherited properties before opening the editor.

And, BTW, the Roadmap page (http://subversion.apache.org/roadmap.html) does
not have a link to the issue for log message templates (#1973). Could you add


On Monday, May 20, 2013 04:32:22 am Branko Čibej wrote:
> 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
Received on 2013-05-30 02:00:59 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.