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 it? Thanks, Alexey. 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
