|Deletions are marked like this.||Additions are marked like this.|
|Line 12:||Line 12:|
See also [[#Wiki_--_easier_to_contribute|Wiki -- easier to contribute]]
Aachen2017MeetAndGreet -- meet-and-greet event, 23rd November 2017
Aachen2017Practicalities -- location, schedule, etc.
- Communication / Webpage
- Svn 1.10 Release
- Git <-> SVN sync
- Conflict Reolution UI
- Patch Format -- SVN/universal
- Trunk-based dev
- 1.8.x and 1.9.x releases
- Wiki -- easier to contribute
- SVN Client Plug-in Commands
- Merkle Tree
- Fast release cycle
- View Specs
- svn list --search
- Validate WC content matches repo
Communication / Webpage
See also Wiki -- easier to contribute
Svn 1.10 Release
Git <-> SVN sync
Conflict Reolution UI
Is it done? Consensus is Yes, enough for release. Still enhancing before & after release.
Patch Format -- SVN/universal
(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
Requirement: Upload my current changes, or shelved changes, to a code review system such as Rietveld.
We could of course release a version of Svn with an initial (experimental) "review" subcommand to do this, but a plug-in has advantages of (1) able to release independently; (2) if it is useful only for users who have a review server, other users don't need to see it.
Advantage (1) also applies to certain other feature developments including shelving.
Solution: We could pretty easily hack up plug-in top-level subcommands. Inspiration from hg extensions and 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.
What hackathon is complete without a discussion of obliterate?
Fast release cycle
Requirement (Johan): Export the sparse configuration of one WC and make another one match it.
Solution (Bert): We can use the WC-state 'Reporter' to find all the info we need -- including depth changes, switched URLs (if wanted), and mixed revisions (if wanted) -- and write this to a simple text format output. For a first hack, the output format could even be a series of "svn update --set-depth=..." lines which could be executed directly by a shell, avoiding the need to write any parse-and-execute code at all.
Also this output is just what we need to record the WC base state of a shelved patch.
Problem: The "update --set-depth" approach doesn't perform well. To apply the desired depths, it would first set the WC root to its desired recorded depth (typically empty or depth-infinity), even if most of the children are going to be excluded; then exclude each child that is to be excluded and expand each that is to be included, and so on. Inefficient. Local mods probably not handled properly.
svn list --search
(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.)