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
Received on 2013-05-30 02:00:59 CEST