Differences between revisions 10 and 11
Revision 10 as of 2017-11-24 00:08:24
Size: 2847
Editor: JulianFoad
Comment:
Revision 11 as of 2017-11-24 10:49:29
Size: 4077
Editor: JulianFoad
Comment:
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
=== Releasing 1.10 === === Communication / Webpage ===
Line 13: Line 13:
=== ... === === Svn 1.10 Release ===

=== Git <-> SVN sync ===

=== Conflict Reolution UI ===

Is it done? Consensus is Yes, enough for release. Still enhancing before & after release.
Line 17: Line 23:
=== ... === === 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).
Line 31: Line 55:
=== Merkle Tree ===

=== Obliterate ===

What hackathon is complete without a discussion of obliterate?

=== Fast release cycle ===
Line 43: Line 75:
=== Obliterate === === svn list --search ===
Line 45: Line 77:
What hackathon is complete without a discussion of obliterate? (SF) implementing reporter extensions
Line 47: Line 79:
(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.)

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

Aachen2017Practicalities -- location, schedule, etc.


Topics Discussed/Fixed/Developed

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

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

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.

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)