Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "Aachen2017" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Aachen2017?action=diff&rev1=10&rev2=11 == Topics Discussed/Fixed/Developed == - === Releasing 1.10 === + === Communication / Webpage === - === ... === + === Svn 1.10 Release === + + === Git <-> SVN sync === + + === Conflict Reolution UI === + + Is it done? Consensus is Yes, enough for release. Still enhancing before & after release. === Shelve/Checkpoint === - === ... === + === Patch Format -- SVN/universal === + + === Trunk-based dev === + + (For new features.) Disussion... + + === 1.8.x and 1.9.x releases === + + A few fixes, including one fix for 1.8.x during the hackathon. + + (JF) to drive releases? + + === Wiki -- easier to contribute === + + SH uses Confluence at work... WYSIWYG + + ASF deprecated MoinMoin + + (JC) to propose ASF Confluence & open/easy access (at least in some sections). === SVN Client Plug-in Commands === @@ -30, +54 @@ Solution: We could pretty easily hack up plug-in top-level subcommands. Inspiration from [[http://tortoisehg.readthedocs.io/en/latest/extensions.html|hg extensions]] and [[https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases|git aliases]]. The plug-in script would have access to at least the command-line 'svn'. We might want to promise one or more of our bindings are available to it too. We might do some argument pre-processing, such as expanding "^/" notation, before passing to the plug-in. + === Merkle Tree === + + === Obliterate === + + What hackathon is complete without a discussion of obliterate? + + === Fast release cycle === + === View Specs === Requirement (Johan): Export the sparse configuration of one WC and make another one match it. @@ -42, +74 @@ Solution: TBD - === Obliterate === + === svn list --search === - What hackathon is complete without a discussion of obliterate? + (SF) implementing reporter extensions + (JC) discussing further use cases + + === Validate WC content matches repo === + + after Authz changes, Obliterate, etc. + + SF suggests could be useful for testing authz changes. + + After obliterate (changing/deleting some repo content), could be used to determine whether a WC is still "valid" against that repository. Without this, obliterate would leave doubt over whether each WC needs to be thrown away; fear and doubt is worse than just having to throw away a WC. + + (Also discussed repairing a WC... see Obliterate.) ---- Thanks to [[http://www.assembla.com|Assembla]] for sponsoring [[Aachen2017|SVN Hackathon 2017]].
