Differences between revisions 14 and 15
Revision 14 as of 2017-11-29 09:38:50
Size: 4817
Editor: JulianFoad
Revision 15 as of 2018-02-23 09:04:38
Size: 4815
Editor: JulianFoad
Comment: Correct superscript mark-up from "23^^rd^^" to "23^rd^".
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
[[Aachen2017MeetAndGreet]] -- meet-and-greet event, 23^^rd^^ November 2017 [[Aachen2017MeetAndGreet]] -- meet-and-greet event, 23^rd^ November 2017

Aachen2017MeetAndGreet -- meet-and-greet event, 23rd November 2017

Aachen2017Practicalities -- location, schedule, etc.

Topics Discussed/Fixed/Developed

Communication / Webpage

See also Wiki -- easier to contribute

Svn 1.10 Release

Git <-> SVN sync

Conflict Resolution UI

Is it done? Consensus is Yes, enough for release. Still enhancing before & after release.



  • vision of transferring a changeset among WC, WC-shelf, repo-commit, repo-shelf, patch-file, code-review-system, etc.
    • need a patch file format to support that
    • briefly discussed command syntaxes,
      • e.g. 'commit --cl=foo@3' meaning shelved changeset 'foo' version 3
  • nice to have a patch-hunk-selection CLI in shelving
    • select and/or edit hunksinteractively
    • like 'git stash --patch' and 'hg shelve --interactive'
    • also in commit, revert, etc.
    • code for such an interface already exists; used in merge conflict resolver
  • possibility to support multiple changelists per path

Patch Format -- SVN/universal

See also: Shelve/Checkpoint, above.

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

Requirement: Upload my current changes, or shelved changes, to a code review system such as Rietveld.

Rietveld provides the upload.py script for this, to be run in a Subversion (or other) WC. For Mercurial, there is the hgreview plug-in which makes the command "hg review [...]".

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.

Merkle Tree


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.

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.

Solution: TBD

(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 Assembla for sponsoring SVN Hackathon 2017.

Aachen2017 (last edited 2018-02-23 09:04:38 by JulianFoad)