[Subversion Wiki] Update of "Aachen2017Practicalities" by StefanHett
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017Practicalities" page has been changed by StefanHett: https://wiki.apache.org/subversion/Aachen2017Practicalities?action=diff&rev1=3&rev2=4 6 pm:: conclusion of the hackathon === Tuesday 11/21 === - Attendees:: Julian, Stefan, Bert 8 pm:: dinner ([[http://lapampa-aachen.de/|La Pampa]] -- Argentinian steak house) === Wednesday: 11/22 === - Attendees:: Julian, Bert, Johan, Stefan, Stefan2 for the evening 8 pm:: dinner ([[http://www.laithai-aachen.de|Lai Thai]] -- Thailand kitchen) 9:30 pm:: billiard (table reserved for 1h - http://www.billardcafelichthof.de/) === Thursday: 11/23 === - Attendees:: Julian, Stefan2, Bert, Johan, Stefan 8 pm:: dinner/meet and greet event ([[https://www.facebook.com/CafeMadridAachen|Café Madrid]] -- international kitchen (some spanish specialities incl. some tapas)) === Friday: 11/24 === - Attendees:: Julian, Stefan2, Bert, Johan, Stefan 8 pm:: visiting the "Aachener Weihnachtsmarkt" with Gluehwein and local dishes === Saturday: 11/25 === - Attendees:: Stefan2, Stefan evening:: No dinner planned.
[Subversion Wiki] Update of "MoveDev" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MoveDev" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MoveDev?action=diff&rev1=2&rev2=3 * [[MoveDev/How to Add Moves to Svn]] * MoveDev/MovePhase1Plan * MoveDev/MoveTrackingUpdateEditor - * MoveDev/MovesInFSFS + * [[MoveDev/MovesInFSFS]] * MoveDev/MovesOverDeltaEditor
[Subversion Wiki] Update of "Berlin2013" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Berlin2013" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Berlin2013?action=diff&rev1=21&rev2=22 * Merge * Do we need a new data model? How would that look like? * What needs to be done for move support? -* Implement Move Tracking -- see MoveDev/MoveDev +* Implement Move Tracking -- see [[MoveDev/How to Add Moves to Svn]] * In what aspects can the current merge algorithms / infrastructure be improved besides adding move support? (What problems are users still experiencing unrelated to moves?) * Refactoring our 500+kB merge.c? * One issue: Updating mergeinfo (props) in the WC is currently done two ways -- directly, and via a 'result_mergeinfo' output hash that is written to disk later -- but neither way is fully supported by all the code. Need to unify.
[Subversion Wiki] Update of "DesignNotes" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "DesignNotes" page has been changed by JulianFoad: https://wiki.apache.org/subversion/DesignNotes?action=diff&rev1=43&rev2=44 * [[Ev2|Editor, version 2 (Ev2)]] - Updating the way we transmit difference within Subversion - * MoveDev/MoveDev Move Development + * [[MoveDev/How to Add Moves to Svn]] Move Development * MoveDev/Ev2MovesDesign Ev2 proposal * MoveDev/Ev15MovesDesign Ev1+ proposal * MoveDev/MoveTrackingUpdateEditor
[Subversion Wiki] Update of "MoveDev/MovesInFSFS" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MoveDev/MovesInFSFS" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MoveDev/MovesInFSFS?action=diff&rev1=6&rev2=7 A specification for changes needed in FSFS and the FS API in order to support moves. - See also the specification of the semantics of moves: MoveDev/MoveDev#Move_Semantics. + See also the specification of the semantics of moves: [[MoveDev/How to Add Moves to Svn#Move_Semantics]]. === FS API === These new APIs are required:
[Subversion Wiki] Update of "MoveDev" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MoveDev" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MoveDev?action=diff&rev1=1&rev2=2 * MoveDev/ApiChangesForMove * MoveDev/Ev15MovesDesign * MoveDev/Ev2MovesDesign - * MoveDev/MoveDev + * [[MoveDev/How to Add Moves to Svn]] * MoveDev/MovePhase1Plan * MoveDev/MoveTrackingUpdateEditor * MoveDev/MovesInFSFS
[Subversion Wiki] Update of "MoveDev/How to Add Moves to Svn" by JulianFoad
Dear wiki user, You have subscribed to a wiki page "Subversion Wiki" for change notification. The page "MoveDev/How to Add Moves to Svn" has been renamed from "MoveDev/MoveDev" by JulianFoad: https://wiki.apache.org/subversion/MoveDev/How%20to%20Add%20Moves%20to%20Svn Comment: It had same name as parent page, which was a bad fit for migrating to Confluence.
[Subversion Wiki] Update of "MoveDev" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MoveDev" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MoveDev New page: * MoveDev/ApiChangesForMove * MoveDev/Ev15MovesDesign * MoveDev/Ev2MovesDesign * MoveDev/MoveDev * MoveDev/MovePhase1Plan * MoveDev/MoveTrackingUpdateEditor * MoveDev/MovesInFSFS * MoveDev/MovesOverDeltaEditor
[Subversion Wiki] Update of "MergeDev" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MergeDev" page has been changed by JulianFoad: https://wiki.apache.org/subversion/MergeDev New page: * MergeDev/DataModel * MergeDev/MergeTheoryTopics
[Subversion Wiki] Update of "Meetings" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Meetings" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Meetings?action=diff&rev1=4&rev2=5 === Agendas and notes from hackathons, Bar Camps and similar liquified events === [[Aachen2017]] - Subversion Hackathon in Aachen, Germany, 20^th^–25^th^ November, 2017 + + [[Berlin2015]] - Subversion Hackathon in Berlin (elego), 14^th^–18^th^ September, 2015 [[Berlin2013]] - Subversion Hackathon in Berlin (elego), 10^th^–14^th^ June, 2013
[Subversion Wiki] Update of "Aachen2017Practicalities" by StefanHett
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017Practicalities" page has been changed by StefanHett: https://wiki.apache.org/subversion/Aachen2017Practicalities?action=diff&rev1=2&rev2=3 Comment: added Johan to Wednesday 8 pm:: dinner ([[http://lapampa-aachen.de/|La Pampa]] -- Argentinian steak house) === Wednesday: 11/22 === - Attendees:: Julian, Bert, Stefan, Stefan2 for the evening + Attendees:: Julian, Bert, Johan, Stefan, Stefan2 for the evening 8 pm:: dinner ([[http://www.laithai-aachen.de|Lai Thai]] -- Thailand kitchen) 9:30 pm:: billiard (table reserved for 1h - http://www.billardcafelichthof.de/)
[Subversion Wiki] Update of "Aachen2017Practicalities" by StefanHett
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017Practicalities" page has been changed by StefanHett: https://wiki.apache.org/subversion/Aachen2017Practicalities?action=diff&rev1=1&rev2=2 Comment: updated list to reflect actual attendees on these days 6 pm:: conclusion of the hackathon === Tuesday 11/21 === - Attendees:: Julian, Stefan (, maybe Bert and Evgeny) + Attendees:: Julian, Stefan, Bert 8 pm:: dinner ([[http://lapampa-aachen.de/|La Pampa]] -- Argentinian steak house) === Wednesday: 11/22 === - Attendees:: Julian, Bert, Stefan, possibly Stefan2 for the evening (, maybe Evgeny) + Attendees:: Julian, Bert, Stefan, Stefan2 for the evening 8 pm:: dinner ([[http://www.laithai-aachen.de|Lai Thai]] -- Thailand kitchen) 9:30 pm:: billiard (table reserved for 1h - http://www.billardcafelichthof.de/) === Thursday: 11/23 === - Attendees:: Julian, Stefan2, Bert, Johan, Stefan (, maybe Evgeny) + Attendees:: Julian, Stefan2, Bert, Johan, Stefan 8 pm:: dinner/meet and greet event ([[https://www.facebook.com/CafeMadridAachen|Café Madrid]] -- international kitchen (some spanish specialities incl. some tapas)) === Friday: 11/24 === - Attendees:: Julian, Stefan2, Bert, Johan, Stefan (, maybe Evgeny) + Attendees:: Julian, Stefan2, Bert, Johan, Stefan 8 pm:: visiting the "Aachener Weihnachtsmarkt" with Gluehwein and local dishes === Saturday: 11/25 ===
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=12&rev2=13 === Shelve/Checkpoint === + discussed: + * 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 ===
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=11&rev2=12 == Topics Discussed/Fixed/Developed == === Communication / Webpage === + + See also [[#Wiki_--_easier_to_contribute|Wiki -- easier to contribute]] === Svn 1.10 Release ===
[Subversion Wiki] Update of "AdminGroup" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "AdminGroup" page has been changed by JulianFoad: https://wiki.apache.org/subversion/AdminGroup?action=diff&rev1=24&rev2=25 * StefanSperling * BenReser * Humbedooh + * StefanHett
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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]].
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=9&rev2=10 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 and git. 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. + 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. === View Specs ===
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=8&rev2=9 == Topics Discussed/Fixed/Developed == === Releasing 1.10 === + + === ... === + + === Shelve/Checkpoint === === ... ===
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=7&rev2=8 === ... === + === SVN Client Plug-in Commands === + + Requirement: Upload my current changes, or shelved changes, to a code review system such as Rietveld. + + Rietveld provides the [[https://github.com/rietveld-codereview/rietveld/wiki/upload.py-Usage|upload.py]] script for this, to be run in a Subversion (or other) WC. For Mercurial, there is the [[https://bitbucket.org/nicoe/hgreview/|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 and git. 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. + === View Specs === - Requirement (Johan): export the sparse configuration of one WC and make another one match it. + 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.
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=6&rev2=7 - <> + <> == Topics Discussed/Fixed/Developed ==
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=5&rev2=6 - == Potential Topics to Discuss/Fix/Develop == + <> - * ... + == Topics Discussed/Fixed/Developed == + === Releasing 1.10 === - - - == Discussion Notes == === ... === + === 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 + + === Obliterate === + + What hackathon is complete without a discussion of obliterate?
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=4&rev2=5 * ... + == Discussion Notes == === ... === + Thanks to [[http://www.assembla.com|Assembla]] for sponsoring [[Aachen2017|SVN Hackathon 2017]].
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=2&rev2=3 [[Aachen2017Practicalities]] -- location, schedule, etc. + + == Potential Topics to Discuss/Fix/Develop == + + * ... + + == Discussion Notes == + + === ... === + + Thanks to [[http://www.assembla.com|Assembla]] for sponsoring [[Aachen2017|SVN Hackathon 2017]].
[Subversion Wiki] Update of "Aachen2017Practicalities" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017Practicalities" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Aachen2017Practicalities New page: == schedule == === daily schedule (Tue-Sat) === 8:30 am:: Start of the hackathon 10 am:: coffee break 12 am to 1 pm:: lunchbreak 4 pm:: coffee break 6 pm:: conclusion of the hackathon === Tuesday 11/21 === Attendees:: Julian, Stefan (, maybe Bert and Evgeny) 8 pm:: dinner ([[http://lapampa-aachen.de/|La Pampa]] -- Argentinian steak house) === Wednesday: 11/22 === Attendees:: Julian, Bert, Stefan, possibly Stefan2 for the evening (, maybe Evgeny) 8 pm:: dinner ([[http://www.laithai-aachen.de|Lai Thai]] -- Thailand kitchen) 9:30 pm:: billiard (table reserved for 1h - http://www.billardcafelichthof.de/) === Thursday: 11/23 === Attendees:: Julian, Stefan2, Bert, Johan, Stefan (, maybe Evgeny) 8 pm:: dinner/meet and greet event ([[https://www.facebook.com/CafeMadridAachen|Café Madrid]] -- international kitchen (some spanish specialities incl. some tapas)) === Friday: 11/24 === Attendees:: Julian, Stefan2, Bert, Johan, Stefan (, maybe Evgeny) 8 pm:: visiting the "Aachener Weihnachtsmarkt" with Gluehwein and local dishes === Saturday: 11/25 === Attendees:: Stefan2, Stefan evening:: No dinner planned.
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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=1&rev2=2 - [[Aachen2017MeetAndGreet|meet-and-greet event]] 23^^rd^^ November 2017 + [[Aachen2017MeetAndGreet]] -- meet-and-greet event, 23^^rd^^ November 2017 + [[Aachen2017Practicalities]] -- location, schedule, etc. + + + Thanks to [[http://www.assembla.com|Assembla]] for sponsoring [[Aachen2017|SVN Hackathon 2017]]. +
[Subversion Wiki] Update of "Aachen2017MeetAndGreet" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017MeetAndGreet" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Aachen2017MeetAndGreet?action=diff&rev1=1&rev2=2 features/issues in person, this is your chance.''' The meet-and-greet event will happen on November 23rd in Aachen, Germany, at 8pm - local time (UTC: +01:00). You are invited to join us there for dinner + local time (UTC: +01:00) at [[https://www.facebook.com/CafeMadridAachen/|Cafe Madrid]] (Pontstraße 141-149). You are invited to join us there for dinner (or just to have a drink). Unfortunately, we can't cover your expenses and you'd have to pay your food/drinks yourself. @@ -19, +19 @@ If you are interested in joining us, please email the organizer [[mailto:luke1...@gmx.de|Stefan Hett]] or the [[mailto:priv...@subversion.apache.org|Subversion committers]] and whether you are planning to have dinner there as well (or just come over for a - drink), so I can make sure we get a proper location which is large + drink), so we can make sure we get a proper location which is large enough for all of us.
[Subversion Wiki] Update of "Aachen2017MeetAndGreet" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Aachen2017MeetAndGreet" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Aachen2017MeetAndGreet New page: The Apache Subversion project organizes a yearly hackathon for its project members. This year we are planning something special during that event for the community as well: A meet-and-greet event. '''If you always wanted to talk to us in person, get to know the faces behind the names on the mailing lists, or want to discuss some SVN features/issues in person, this is your chance.''' The meet-and-greet event will happen on November 23rd in Aachen, Germany, at 8pm local time (UTC: +01:00). You are invited to join us there for dinner (or just to have a drink). Unfortunately, we can't cover your expenses and you'd have to pay your food/drinks yourself. The event also provides you with the possibility to extend your PGP key's web of trust (i.e. the event will also serve in parallel as a key-signing event). If you are interested in joining us, please email the organizer [[mailto:luke1...@gmx.de|Stefan Hett]] or the [[mailto:priv...@subversion.apache.org|Subversion committers]] and whether you are planning to have dinner there as well (or just come over for a drink), so I can make sure we get a proper location which is large enough for all of us. Thanks to [[http://www.assembla.com|Assembla]] for sponsoring [[Aachen2017|SVN Hackathon 2017]].
[Subversion Wiki] Update of "Aachen2017" by JulianFoad
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 New page: [[Aachen2017MeetAndGreet|meet-and-greet event]] 23^^rd^^ November 2017
[Subversion Wiki] Update of "Meetings" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Meetings" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Meetings?action=diff&rev1=3&rev2=4 === Agendas and notes from hackathons, Bar Camps and similar liquified events === + + [[Aachen2017]] - Subversion Hackathon in Aachen, Germany, 20^th^–25^th^ November, 2017 [[Berlin2013]] - Subversion Hackathon in Berlin (elego), 10^th^–14^th^ June, 2013
[Subversion Wiki] Update of "DesignNotes" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "DesignNotes" page has been changed by StefanSperling: https://wiki.apache.org/subversion/DesignNotes?action=diff&rev1=42&rev2=43 == Design Notes == The following are links to various notes about the design and implementation of various Subversion features and enhancements. + + * AuthzImprovements - about the authzperf branch * LocalMoves - functional design for client-side move and rename tracking
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=18&rev2=19 Comment: move tests 28,29,30 into the right column === update === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge<>28. with parent moved -- resolve: text merge<> 29. with parent moved back -- resolve: text merge<>30. with parent moved twice -- resolve: text merge || || + ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge || 28. with parent moved -- resolve: text merge<>29. with parent moved back -- resolve: text merge<>30. with parent moved twice -- resolve: text merge || ||'''add_f''' |||| 31: resolve: text merge || || || || |||| ||'''add_d''' |||| || 34. resolve: ignore<>35. resolve: merge<>36. with obstructions -- resolve: merge|| || || |||| ||'''rm_f''' |||| || || || || ||||
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=17&rev2=18 Comment: add tests 28.29.30 === update === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge || || + ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge<>28. with parent moved -- resolve: text merge<> 29. with parent moved back -- resolve: text merge<>30. with parent moved twice -- resolve: text merge || || ||'''add_f''' |||| 31: resolve: text merge || || || || |||| ||'''add_d''' |||| || 34. resolve: ignore<>35. resolve: merge<>36. with obstructions -- resolve: merge|| || || |||| ||'''rm_f''' |||| || || || || ||||
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=16&rev2=17 Comment: add tests 34,35,36 ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge || || ||'''add_f''' |||| 31: resolve: text merge || || || || |||| - ||'''add_d''' |||| || || || || |||| + ||'''add_d''' |||| || 34. resolve: ignore<>35. resolve: merge<>36. with obstructions -- resolve: merge|| || || |||| ||'''rm_f''' |||| || || || || |||| ||'''rm_d''' |||| || || || || |||| ||'''mv_f''' |||| || || || || || 32: resolve: move dir merge ||
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=15&rev2=16 Comment: move miscategorized tests 3 and 4 into add dir vs add dir set of tests ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| ||'''edit_f''' |||| || || 10. resolve: ignore<>11. resolve: accept<>24. incoming replace: options || || 12. resolve: text merge<>24. resolve: merge with text conflict<>22. chained move - resolve: text merge<>27: resolve: text merge (prop conflict)<>33: resolve: text merge (with keywords) || 17. incoming move dir: options<>18. with local edit<>19. with local add<>23. with moved file || - ||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text merge<>3. resolve: replace<>4. resolve: replace and merge || || || || |||| + ||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text merge|| || || || |||| - ||'''add_d''' |||| || 5. with file change - resolve: merge<>6. with move history - resolve: merge<>7. resolve: replace<> 8. resolve: replace and merge<>9. with file change - resolve: replace|| || || |||| + ||'''add_d''' |||| ||3. resolve: replace<>4. resolve: replace and merge<>5. with file change - resolve: merge<>6. with move history - resolve: merge<>7. resolve: replace<> 8. resolve: replace and merge<>9. with file change - resolve: replace|| || || |||| ||'''rm_f''' |||| || || 18. resolve: accept || || |||| ||'''rm_d''' |||| || || || || |||| ||'''mv_f''' || 23. options || || || || || ||||
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=14&rev2=15 Comment: add new test 13 and 14 === update === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || || || 15. resolve: text merge || || + ||'''edit_f''' |||| || || 13. resolve: ignore<>14. resolve: accept || || 15. resolve: text merge || || ||'''add_f''' |||| 31: resolve: text merge || || || || |||| ||'''add_d''' |||| || || || || |||| ||'''rm_f''' |||| || || || || ||||
[Subversion Wiki] Update of "TreeConflictTests" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by StefanSperling: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=13&rev2=14 Comment: Add new conflict-test --list output; update test numbering in table but don't add any new tests yet === merge === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || 10. resolve: ignore<>11. resolve: accept<>24. incoming replace: options || || 12. resolve: text merge<>20. resolve: merge with text conflict<>22. chained move - resolve: text merge<>27: resolve: text merge (prop conflict)<>28: resolve: text merge (with keywords) || 15. incoming move dir: options<>16. with local edit<>17. with local add<>23. with moved file || + ||'''edit_f''' |||| || || 10. resolve: ignore<>11. resolve: accept<>24. incoming replace: options || || 12. resolve: text merge<>24. resolve: merge with text conflict<>22. chained move - resolve: text merge<>27: resolve: text merge (prop conflict)<>33: resolve: text merge (with keywords) || 17. incoming move dir: options<>18. with local edit<>19. with local add<>23. with moved file || ||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text merge<>3. resolve: replace<>4. resolve: replace and merge || || || || |||| ||'''add_d''' |||| || 5. with file change - resolve: merge<>6. with move history - resolve: merge<>7. resolve: replace<> 8. resolve: replace and merge<>9. with file change - resolve: replace|| || || |||| ||'''rm_f''' |||| || || 18. resolve: accept || || |||| ||'''rm_d''' |||| || || || || |||| - ||'''mv_f''' || 21. options || || || || || |||| + ||'''mv_f''' || 23. options || || || || || |||| ||'''mv_d^f''' |||| || || || || |||| === update === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || || || 13. resolve: text merge || || + ||'''edit_f''' |||| || || || || 15. resolve: text merge || || - ||'''add_f''' |||| 26: resolve: text merge || || || || |||| + ||'''add_f''' |||| 31: resolve: text merge || || || || |||| ||'''add_d''' |||| || || || || |||| ||'''rm_f''' |||| || || || || |||| ||'''rm_d''' |||| || || || || |||| - ||'''mv_f''' |||| || || || || || 25: resolve: move dir merge || + ||'''mv_f''' |||| || || || || || 32: resolve: move dir merge || ||'''mv_d^f''' |||| || || || || |||| === switch === ||'''incoming><>local \/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''|| - ||'''edit_f''' |||| || || || || 14. resolve: text merge |||| + ||'''edit_f''' |||| || || || || 16. resolve: text merge |||| ||'''add_f''' |||| || || || || |||| ||'''add_d''' |||| || || || || |||| ||'''rm_f''' |||| || || || || |||| @@ -59, +59 @@ 7 merge incoming add dir replace 8 merge incoming add dir replace and merge 9 merge incoming add dir replace with file change - 10 merge incoming delete ignore + 10 merge incoming delete file ignore - 11 merge incoming delete accept + 11 merge incoming delete file accept 12 merge incoming move file text merge + 13 update incoming dele
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=18&rev2=19
So, the full lookup without caching is as shown below. For efficiency, the
implementation will check the accumulated global rights calculated by the
parser before performing a tree lookup. There are probably many cases where the
result of any lookup can be predicted from those rights, and therefore the
lookup itself, and even creation of the filtered tree, could be skipped
entirely.
{{{
lookup(tree : ref to filtered-tree, path : string):
- state = init(tree)
+ state = init(tree)
- foreach segment in path
+ foreach segment in path
- if done(state)
+ if done(state)
- break;
+ break;
- state = step(state, segment)
+ state = step(state, segment)
- return state.rights
+ return state.rights
}}}
== Better Access Control ==
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=17&rev2=18
state.rights = access
state.current = next
}}}
- So, the full lookup without caching is as shown below. For efficiency, we
check the accumulated global rights calculated by the parser before performing
a tree lookup. There are probably many cases where the result of any lookup can
be predicted from those rights, and therefore the lookup itself, and even
creation of the filtered tree, could be skipped entirely.
+ So, the full lookup without caching is as shown below. For efficiency, the
implementation will check the accumulated global rights calculated by the
parser before performing a tree lookup. There are probably many cases where the
result of any lookup can be predicted from those rights, and therefore the
lookup itself, and even creation of the filtered tree, could be skipped
entirely.
{{{
lookup(tree : ref to filtered-tree, path : string):
state = init(tree)
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=16&rev2=17
state.rights = access
state.current = next
}}}
+ So, the full lookup without caching is as shown below. For efficiency, we
check the accumulated global rights calculated by the parser before performing
a tree lookup. There are probably many cases where the result of any lookup can
be predicted from those rights, and therefore the lookup itself, and even
creation of the filtered tree, could be skipped entirely.
- So, the full lookup without caching is
- {{{#!wiki caution
- There is one step we should perform before the initial lookup: check the
accumulated global rights calculated by the parser. There are probably many
cases where the result of any lookup can be predicted from those rights, and
therefore the lookup itself, and even creation of the filtered tree, could be
skipped entirely (for the cost of a couple extra hash lookups in the worst
case).
- }}}
{{{
lookup(tree : ref to filtered-tree, path : string):
state = init(tree)
@@ -205, +202 @@
== Better Access Control ==
- TODO
+ TODO after 1.10.
= Implementation Notes =
[Subversion Wiki] Trivial Update of "TreeConflictTests" by JohanCorveleyn
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "TreeConflictTests" page has been changed by JohanCorveleyn:
https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=3&rev2=4
Comment:
Make the "incoming / local" indication in the top-left of the tables more clear
=== merge ===
- ||'''loc \
inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
+ ||'''incoming><>local
\/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''||
||'''edit_f''' |||| || || 10. resolve:
ignore<>11. resolve: accept<>24. incoming replace: options || ||
12. resolve: text merge<>20. {X} resolve: merge with text conflict<>22.
chained move - resolve: text merge || 15. {X} incoming move dir:
options<>16. with local edit<>17. with local add<>23. {X} with
moved file ||
||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text
merge<>3. resolve: replace<>4. resolve: replace and merge || ||
|| || ||||
||'''add_d''' |||| || 5. with file change - resolve:
merge<>6. with move history - resolve: merge<>7. resolve: replace<>
8. {X} resolve: replace and merge<>9. with file change - resolve: replace
|| || || ||||
@@ -25, +25 @@
=== update ===
- ||'''loc \
inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
+ ||'''incoming><>local
\/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''||
||'''edit_f''' |||| || || ||
|| 13. resolve: text merge ||||
||'''add_f''' |||| || || ||
|| ||||
||'''add_d''' |||| || || ||
|| ||||
@@ -36, +36 @@
=== switch ===
- ||'''loc \
inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
+ ||'''incoming><>local
\/'''||<^>'''edit_f'''||<^>'''add_f'''||<^>'''add_d'''||<^>'''rm_f'''||<^>'''rm_d'''||<^>'''mv_f'''||<^>'''mv_d^f'''||
||'''edit_f''' |||| || || ||
|| 14. resolve: text merge ||||
||'''add_f''' |||| || || ||
|| ||||
||'''add_d''' |||| || || ||
|| ||||
[Subversion Wiki] Update of "TreeConflictTests" by JohanCorveleyn
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "TreeConflictTests" page has been changed by JohanCorveleyn:
https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=2&rev2=3
Comment:
Update to current test list, and use icons for the XFail tests
Below you can find, per "operation", a matrix of tree conflict tests, so we
have an idea of how much work is still left to increase test coverage. The
matrix row headers give the "local" situation, the column headers the "incoming
change". These are only meant to be broad categories, an actual test may build
up a very complex situation (but still be part of a certain category). The
categories might need to be extended.
- The numbers refer to the test numbers. An (X) indicates an XFail test.
+ The numbers refer to the test numbers. An {X} indicates an XFail test.
TODO:
- * Add some short test summary with each test number (directly in the cell,
or linked to a footnote?). While we're at it, make it possible to add
additional comments.
+ * Make it possible to add additional comments related to specific tests (as
a footnote?).
* Extend the matrices with extra categories. For instance, for "merge" I'm
thinking of using "add_f,edit_f" to indicate "f was added on the branch
(anything before the comma) and locally edited (anything behind the comma)". In
that case ",add_f" would be "branch is in sync, but has added f as a local
uncommitted change"
* Create "cherrypick" as a specific "operation" with its own matrix? Here we
could also create additional categories for incoming, to discern between what
happened on trunk before the cherrypick-rev, and what's part of the
cherrypick-rev ("mv_f,edit_f" then means: file was moved on trunk, and edited,
and only the edit is cherrypick-merged).
* Create a script that can parse our C (and python?) tests, or their --list
output. To help the script we could add some sort of tagging to our tests (in
the test description), so it knows to what part of what matrix the test
belongs. For instance: "[add_f-add_f] incoming add file ignore".
=== merge ===
- ||'''local \
incom'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
+ ||'''loc \
inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
- ||'''edit_f''' |||| || || 15. resolve:
ignore<>16. resolve: accept<>29. incoming replace: options || ||
17. resolve: text merge<>25. resolve: merge with text conflict (X)<>27.
chained move - resolve: text merge || 20. incoming move dir: options
(X)<>21. with local edit<>22. with local add<>28. with moved file
(X) ||
+ ||'''edit_f''' |||| || || 10. resolve:
ignore<>11. resolve: accept<>24. incoming replace: options || ||
12. resolve: text merge<>20. {X} resolve: merge with text conflict<>22.
chained move - resolve: text merge || 15. {X} incoming move dir:
options<>16. with local edit<>17. with local add<>23. {X} with
moved file ||
||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text
merge<>3. resolve: replace<>4. resolve: replace and merge || ||
|| || ||||
- ||'''add_d''' |||| || 8. resolve: ignore<>9.
resolve: merge<>10. with file change - resolve: merge<>11. with move
history - resolve: merge<>12. resolve: replace<>13. resolve: replace
and merge (X)<>14. with file change - resolve: replace|| ||
|| ||||
+ ||'''add_d''' |||| || 5. with file change - resolve:
merge<>6. with move history - resolve: merge<>7. resolve: replace<>
8. {X} resolve: replace and merge<>9. with file change - resolve: replace
|| || || ||||
- ||'''rm_f''' |||| || || 23. resolve: accept
|| || ||||
+ ||'''rm_f''' |||| || || 18. resolve: accept
|| || ||||
||'''rm_d''' |||| || || ||
|| ||||
- ||'''mv_f''' || 26. options (X) || || ||
|| || ||||
+ ||'''mv_f''' || 21. {X} options || || || ||
|| ||||
||'''mv_d^f''' |||| || || ||
|| ||||
=== update ===
- ||'''local \
incom'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
+ ||'''loc \
inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
- ||'''edit_f''' |||| || || ||
|| 18. resolve: text merge ||||
+ ||'''edit_f'''
[Subversion Wiki] Update of "TreeConflictTests" by JohanCorveleyn
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "TreeConflictTests" page has been changed by JohanCorveleyn: https://wiki.apache.org/subversion/TreeConflictTests?action=diff&rev1=1&rev2=2 Comment: Add short summary of tests in the table cells Below you can find, per "operation", a matrix of tree conflict tests, so we have an idea of how much work is still left to increase test coverage. The matrix row headers give the "local" situation, the column headers the "incoming change". These are only meant to be broad categories, an actual test may build up a very complex situation (but still be part of a certain category). The categories might need to be extended. - The numbers refer to the test numbers. An X indicates an XFail test. + The numbers refer to the test numbers. An (X) indicates an XFail test. TODO: * Add some short test summary with each test number (directly in the cell, or linked to a footnote?). While we're at it, make it possible to add additional comments. @@ -14, +14 @@ === merge === - ||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| + ||'''local \ incom'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| - ||'''edit_f''' |||| || || 15<>16<>29 || || 17<>25 X<>27 || 20 X<>21<>22<>28 X || - ||'''add_f''' |||| 1<>2<>3<>4 || || || || |||| - ||'''add_d''' |||| || 8<>9<>10<>11<>12<>13 X<>14|| || || |||| + ||'''edit_f''' |||| || || 15. resolve: ignore<>16. resolve: accept<>29. incoming replace: options || || 17. resolve: text merge<>25. resolve: merge with text conflict (X)<>27. chained move - resolve: text merge || 20. incoming move dir: options (X)<>21. with local edit<>22. with local add<>28. with moved file (X) || + ||'''add_f''' |||| 1. resolve: ignore<>2. resolve: text merge<>3. resolve: replace<>4. resolve: replace and merge || || || || |||| + ||'''add_d''' |||| || 8. resolve: ignore<>9. resolve: merge<>10. with file change - resolve: merge<>11. with move history - resolve: merge<>12. resolve: replace<>13. resolve: replace and merge (X)<>14. with file change - resolve: replace|| || || |||| - ||'''rm_f''' |||| || || 23 || || |||| + ||'''rm_f''' |||| || || 23. resolve: accept || || |||| ||'''rm_d''' |||| || || || || |||| - ||'''mv_f''' || 26 X || || || || || |||| + ||'''mv_f''' || 26. options (X) || || || || || |||| ||'''mv_d^f''' |||| || || || || |||| === update === - ||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| + ||'''local \ incom'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| - ||'''edit_f''' |||| || || || || 18 |||| + ||'''edit_f''' |||| || || || || 18. resolve: text merge |||| - ||'''add_f''' |||| 5<>6 || || || || |||| + ||'''add_f''' |||| 5. resolve: ignore<>6. resolve: replace || || || || |||| ||'''add_d''' |||| || || || || |||| ||'''rm_f''' |||| || || || || |||| ||'''rm_d''' |||| || || || || |||| @@ -36, +36 @@ === switch === - ||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| + ||'''local \ incom'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''|| - ||'''edit_f''' |||| || || || || 19 |||| + ||'''edit_f''' |||| || || || || 19. resolve: text merge |||| - ||'''add_f''' |||| 7 || || || || |||| + ||'''add_f''' |||| 7. resolve: ignore || || || ||
[Subversion Wiki] Update of "TreeConflictTests" by JohanCorveleyn
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "TreeConflictTests" page has been changed by JohanCorveleyn:
https://wiki.apache.org/subversion/TreeConflictTests
Comment:
Initial draft, matrices filled with test numbers from current conflicts-test.c
New page:
= Tree Conflict Tests =
Below you can find, per "operation", a matrix of tree conflict tests, so we
have an idea of how much work is still left to increase test coverage. The
matrix row headers give the "local" situation, the column headers the "incoming
change". These are only meant to be broad categories, an actual test may build
up a very complex situation (but still be part of a certain category). The
categories might need to be extended.
The numbers refer to the test numbers. An X indicates an XFail test.
TODO:
* Add some short test summary with each test number (directly in the cell, or
linked to a footnote?). While we're at it, make it possible to add additional
comments.
* Extend the matrices with extra categories. For instance, for "merge" I'm
thinking of using "add_f,edit_f" to indicate "f was added on the branch
(anything before the comma) and locally edited (anything behind the comma)". In
that case ",add_f" would be "branch is in sync, but has added f as a local
uncommitted change"
* Create "cherrypick" as a specific "operation" with its own matrix? Here we
could also create additional categories for incoming, to discern between what
happened on trunk before the cherrypick-rev, and what's part of the
cherrypick-rev ("mv_f,edit_f" then means: file was moved on trunk, and edited,
and only the edit is cherrypick-merged).
* Create a script that can parse our C (and python?) tests, or their --list
output. To help the script we could add some sort of tagging to our tests (in
the test description), so it knows to what part of what matrix the test
belongs. For instance: "[add_f-add_f] incoming add file ignore".
=== merge ===
||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
||'''edit_f''' |||| || || 15<>16<>29 ||
|| 17<>25 X<>27 || 20 X<>21<>22<>28 X ||
||'''add_f''' |||| 1<>2<>3<>4 || || ||
|| ||||
||'''add_d''' |||| ||
8<>9<>10<>11<>12<>13 X<>14|| || ||
||||
||'''rm_f''' |||| || || 23 ||
|| ||||
||'''rm_d''' |||| || || ||
|| ||||
||'''mv_f''' || 26 X || || || ||
|| ||||
||'''mv_d^f''' |||| || || ||
|| ||||
=== update ===
||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
||'''edit_f''' |||| || || ||
|| 18 ||||
||'''add_f''' |||| 5<>6 || || ||
|| ||||
||'''add_d''' |||| || || ||
|| ||||
||'''rm_f''' |||| || || ||
|| ||||
||'''rm_d''' |||| || || ||
|| ||||
||'''mv_f''' |||| || || ||
|| ||||
||'''mv_d^f''' |||| || || ||
|| ||||
=== switch ===
||'''loc\inc'''||'''edit_f'''||'''add_f'''||'''add_d'''||'''rm_f'''||'''rm_d'''||'''mv_f'''||'''mv_d^f'''||
||'''edit_f''' |||| || || ||
|| 19 ||||
||'''add_f''' |||| 7 || || ||
|| ||||
||'''add_d''' |||| || || ||
|| ||||
||'''rm_f''' |||| || || ||
|| ||||
||'''rm_d''' |||| || || ||
|| ||||
||'''mv_f''' |||| || || ||
|| ||||
||'''mv_d^f''' |||| || || ||
|| ||||
[Subversion Wiki] Update of "ManyHands" by JohanCorveleyn
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "ManyHands" page has been changed by JohanCorveleyn: https://wiki.apache.org/subversion/ManyHands?action=diff&rev1=5&rev2=6 Comment: Add a page to start organizing tree conflict tests * ... == Tasks == + * TreeConflictTests - Organizing tree conflict tests * Svn18ApiReview - Subversion 1.8 new API review * Svn18Changes - Populating the Subversion 1.8.0 CHANGES file - * Svn19ApiReview - Subversion 1.9 new API review
[Subversion Wiki] Update of "ContributorsGroup" by JohanCorveleyn
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "ContributorsGroup" page has been changed by JohanCorveleyn: https://wiki.apache.org/subversion/ContributorsGroup?action=diff&rev1=17&rev2=18 #acl AdminGroup:read,write,admin,revert,delete All:read '''Contributors''' with permission to edit the Subversion wiki – read, write, delete and revert pages or individual changes. To be added to this group, please send a brief request to the dev.at.subversion-dot-apache-dot-org mailing list including your wiki username. No mailing list subscription required. - Related: [[AdminGroup| Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. + Related: [[AdminGroup|Administrators]] with permission to grant privileges to Contributors, in addition to being Contributors themselves. * AdminGroup * GregStein @@ -18, +18 @@ * MichaelDiers * IvanZhakov * LievenGovaerts + * JohanCorveleyn
[Subversion Wiki] Update of "ResolvingIncomingMoves" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "ResolvingIncomingMoves" page has been changed by StefanSperling: https://wiki.apache.org/subversion/ResolvingIncomingMoves?action=diff&rev1=3&rev2=4 Comment: typos; discuss a native way of handling the merge operation case The conflict resolver scans the revision log to match up copies and deletions. See 'struct repos_move_info' and 'find_moves_in_revision()' in the file subversion/libsvn_client/conflicts.c. While this approach is not perfect - (it does not corrrectly handle deletions which happened inside copies, + (it does not correctly handle deletions which happened inside copies, for instance) it is good enough to support users during conflict resolution in many use cases. @@ -23, +23 @@ with a locally modified file A/f. - After A is moved to B in the repostory the user updates to the HEAD + After A is moved to B in the repository the user updates to the HEAD revision. The NODES table will now look as follows: || op_depth || local_relpath || presence || @@ -243, +243 @@ With changes from the trunk merged in. + This could be achieved by first reverting B, then moving A to B locally, + and running the appropriate merges to get changes from trunk. + However, the resolver has no way of knowing whether reverting B would + destroy any local changes the user made to B after the merge. + Ideally, such changes would be retained. +
[Subversion Wiki] Update of "ResolvingIncomingMoves" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "ResolvingIncomingMoves" page has been changed by StefanSperling: https://wiki.apache.org/subversion/ResolvingIncomingMoves?action=diff&rev1=2&rev2=3 Comment: fix merge source url + = How the conflict resolver deals with incoming moves = An incoming move during an update/switch/merge operation appears @@ -198, +199 @@ at the BASE revision of A as the changed tree. Any nodes which have changed since rYCA trigger edits in the B subtree. This can be implemented by running the equivalent of a standard merge - -rYCA:BASE ^/A@BASE into B. + -rYCA:BASE ^/branch/A@BASE into B. This results in:
[Subversion Wiki] Update of "ResolvingIncomingMoves" by StefanSperling
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "ResolvingIncomingMoves" page has been changed by StefanSperling:
https://wiki.apache.org/subversion/ResolvingIncomingMoves?action=diff&rev1=1&rev2=2
Comment:
fix formatting errors
B/n (local add vs incoming add) and B/d (local move vs incoming deletion)
in the ACTUAL_NODE table. This raises several new problems:
- * The meaning of the terms 'local' and 'incoming' in conflict descriptions
+ The meaning of the terms 'local' and 'incoming' in conflict descriptions
- is now misleading because both of the conflicting tree changes were made
+ is now misleading because both of the conflicting tree changes were made
- in the working copy ('local').
+ in the working copy ('local').
- * The resolver will have to be taught to resolve such conflicts (this is
+ The resolver will have to be taught to resolve such conflicts (this is
- not impossible but implies extra implementation effort).
+ not impossible but implies extra implementation effort).
- * The resolver will have to choose whether the existing node in B should
+ The resolver will have to choose whether the existing node in B should
- be left as-is, or whether it should be replaced with the node from A.
+ be left as-is, or whether it should be replaced with the node from A.
- Either way, information is lost unless the rows for conflicting nodes
+ Either way, information is lost unless the rows for conflicting nodes
- are left unmodified in both A and B.
+ are left unmodified in both A and B.
The resolver could also reject conflict resolution if local changes are
present in the B tree. However, this approach would work only for updates
[Subversion Wiki] Update of "DesignNotes" by StefanSperling
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "DesignNotes" page has been changed by StefanSperling: https://wiki.apache.org/subversion/DesignNotes?action=diff&rev1=41&rev2=42 The following are links to various notes about the design and implementation of various Subversion features and enhancements. * LocalMoves - functional design for client-side move and rename tracking + + * ResolvingIncomingMoves - notes about resolving incoming moves with the new conflict resolver * [[Ev2|Editor, version 2 (Ev2)]] - Updating the way we transmit difference within Subversion
[Subversion Wiki] Update of "ResolvingIncomingMoves" by StefanSperling
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "ResolvingIncomingMoves" page has been changed by StefanSperling:
https://wiki.apache.org/subversion/ResolvingIncomingMoves
Comment:
Initial notes on how the resolver can deal with incoming moves
New page:
= How the conflict resolver deals with incoming moves =
An incoming move during an update/switch/merge operation appears
as disjoint additions and deletions of working copy nodes.
The conflict resolver scans the revision log to match up copies and deletions.
See 'struct repos_move_info' and 'find_moves_in_revision()' in the file
subversion/libsvn_client/conflicts.c. While this approach is not perfect
(it does not corrrectly handle deletions which happened inside copies,
for instance) it is good enough to support users during conflict resolution
in many use cases.
== Incoming move during updates ==
Consider the following pre-update NODES table:
|| op_depth || local_relpath || presence ||
||0 ||A || normal ||
||0 ||A/f|| normal ||
with a locally modified file A/f.
After A is moved to B in the repostory the user updates to the HEAD
revision. The NODES table will now look as follows:
|| op_depth || local_relpath || presence ||
||0 ||B || normal ||
||0 ||B/f|| normal ||
||1 ||A || normal ||
||1 ||A/f|| normal ||
The copy op-root A was created when a local edit vs incoming delete
tree conflict was raised on A. This is how the update process attempts
to preserve the user's local changes. The conflict resolver relies on
this behaviour.
The ACTUAL_NODE table now stores a tree conflict on A (the conflict
skel shown here is heavily abbreviated):
|| local_relpath || tree_conflict_data ||
||A || ((update ((trunk/A 2 dir) (trunk/A 3 none))) ((tree ()
edited deleted))) ||
The resolver scans the revision log and determines that A was moved to B.
Merging the incoming move involves merging all changes within conflict
victim A into the newly added subtree B.
In our simple example, this means running a 3-way merge of the files
pristine(A/f), A/f, and B/f, into B/f. Afterwards, the rows for A can be
deleted from the NODES table and the conflict skel for A can be removed:
|| op_depth || local_relpath || presence ||
||0 ||B || normal ||
||0 ||B/f|| normal ||
Things get more interesting if local changes are present in the NODES
table before the update, such as an added file n and a deleted file d:
|| op_depth || local_relpath || presence ||
||0 ||A || normal ||
||0 ||A/f|| normal ||
||0 ||A/d|| normal ||
||2 ||A/n|| normal ||
||2 ||A/d|| base-deleted ||
The post-update state is:
|| op_depth || local_relpath || presence ||
||0 ||B || normal ||
||0 ||B/f|| normal ||
||0 ||B/d|| normal ||
||1 ||A || normal ||
||1 ||A/f|| normal ||
||1 ||A/d|| normal ||
||2 ||A/n|| normal ||
||2 ||A/d|| base-deleted ||
Merging the incoming move involves moving all changes within
conflict victim A into the newly added subtree B and removing
the rows for A.
This operation must be performed by an editor which edits the B subtree.
It refers to the A subtree at op_depth 1 (actually relpath_depth('A')) as
the base tree, and to the A subtree at op_depth > 1 as the changed tree.
Any nodes at op_depth > 1 trigger corresponding edits in the B subtree.
The result of this edit should be:
|| op_depth || local_relpath || presence ||
||0 ||B || normal ||
||0 ||B/f|| normal ||
||0 ||B/d|| normal ||
||2 ||B/n|| normal ||
||2 ||B/d|| base-deleted ||
File contents within A from the pristine store are part of the editor's
base tree, while the working files within A on disk are part of the
changed tree. This results in the previously discussed 3-way merge of
pristine(A/f), A/f, and B/f, into B/f.
Any nodes within the B subtree at op-depths > 1 trigger a tree conflict.
Suppose the user adds 'B/n' and moves 'B/d' to 'B/c' before running
the conflict resolver:
|| op_depth || local_relpath || presence || moved_to || moved_here ||
||0 ||B || normal || ||||
||0 ||B/f|| normal || ||||
||0 ||B/d|| normal || ||||
||2 ||B/n|| normal || ||||
||2 ||B/d|| base-deleted || B/c
[Subversion Wiki] Update of "JulianFoad" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "JulianFoad" page has been changed by JulianFoad: https://wiki.apache.org/subversion/JulianFoad?action=diff&rev1=12&rev2=13 Comment: I'm no longer working at WANdisco. #language en = Julian Foad = A developer of [[http://subversion.apache.org|Apache Subversion]] - - A Senior Subversion Committer at [[http://www.wandisco.com|WANdisco, Inc.]] the maker of [[http://www.ubersvn.com|uberSVN]] A member of the [[http://apache.org|Apache Software Foundation]]
[Subversion Wiki] New attachment added to page Berlin2015
Dear Wiki user, You have subscribed to a wiki page "Berlin2015" for change notification. An attachment has been added to that page by StefanFuhrmann. Following detailed information is available: Attachment name: todo-list.JPG Attachment size: 197356 Attachment link: https://wiki.apache.org/subversion/Berlin2015?action=AttachFile&do=get&target=todo-list.JPG Page link: https://wiki.apache.org/subversion/Berlin2015
[Subversion Wiki] New attachment added to page Berlin2015
Dear Wiki user, You have subscribed to a wiki page "Berlin2015" for change notification. An attachment has been added to that page by StefanFuhrmann. Following detailed information is available: Attachment name: pipelining.JPG Attachment size: 102320 Attachment link: https://wiki.apache.org/subversion/Berlin2015?action=AttachFile&do=get&target=pipelining.JPG Page link: https://wiki.apache.org/subversion/Berlin2015
[Subversion Wiki] New attachment added to page Berlin2015
Dear Wiki user, You have subscribed to a wiki page "Berlin2015" for change notification. An attachment has been added to that page by StefanFuhrmann. Following detailed information is available: Attachment name: node-API.JPG Attachment size: 105937 Attachment link: https://wiki.apache.org/subversion/Berlin2015?action=AttachFile&do=get&target=node-API.JPG Page link: https://wiki.apache.org/subversion/Berlin2015
[Subversion Wiki] New attachment added to page Berlin2015
Dear Wiki user, You have subscribed to a wiki page "Berlin2015" for change notification. An attachment has been added to that page by StefanFuhrmann. Following detailed information is available: Attachment name: log-traversal.JPG Attachment size: 102992 Attachment link: https://wiki.apache.org/subversion/Berlin2015?action=AttachFile&do=get&target=log-traversal.JPG Page link: https://wiki.apache.org/subversion/Berlin2015
[Subversion Wiki] New attachment added to page Berlin2015
Dear Wiki user, You have subscribed to a wiki page "Berlin2015" for change notification. An attachment has been added to that page by StefanFuhrmann. Following detailed information is available: Attachment name: fsfs-deltification.JPG Attachment size: 129575 Attachment link: https://wiki.apache.org/subversion/Berlin2015?action=AttachFile&do=get&target=fsfs-deltification.JPG Page link: https://wiki.apache.org/subversion/Berlin2015
[Subversion Wiki] Update of "Berlin2015" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Berlin2015" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Berlin2015 New page: The Berlin '15 hackathon was held at the elego offices in Berlin, Germany from 14^th^ to 18^th^ September. elego has generously donated office space and `$BEVERAGE` for the duration of the week, and several committers were on hand to hack, discuss, and made themselves merry. == Whiteboard Contents == * [[attachment:fsfs-deltification.JPG|Deltification causing random I/O]] * [[attachment:pipelining.JPG|Concurrent put and commit pipelining]] * [[attachment:fsfs-deltification.JPG|Log traversal]] * [[attachment:todo-list.JPG|TODO list]] * [[attachment:node-API.JPG|FS node API]]
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=20&rev2=21 Comment: Update after resolution of the last non-doc issues. == Reviewed But Need Further Attention == - === svn_dirent_uri.h === - * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named `svn_relpath__first_n_components`. - === svn_ra_svn.h === * `svn_ra_svn_create_conn4` — The @note is unclear. Is the file being used for time-out detection? === svn_wc.h === * `svn_wc_notify_move_broken` — Has a TODO left-over from 1.8 * `svn_wc_conflict_description2_t.merged_file` — Clarify the ###. - * `svn_wc__conflict_description2_dup` — Simply remove from API. == Review Completed! == @@ -29, +25 @@ . svn_fs.h . svn_repos.h . svn_types.h + . svn_dirent_uri.h These headers have been reviewed by stefan2 and where issues have been found, they are already fixed. More review is welcome.
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=18&rev2=19 Comment: svn_types is done as well now * Comment still applies. — JAF * `svn_repos_get_fs_build_parser5` — Handling of / behavior if `use_history==FALSE`? - === svn_types.h === - * `svn_null_pointer_constant_stdarg_sentinel_t` — Should this be private? - * No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane - === svn_wc.h === * `svn_wc_notify_move_broken` — Has a TODO left-over from 1.8 * `svn_wc_conflict_description2_t.merged_file` — Clarify the ###. @@ -43, +39 @@ . svn_client.h . svn_diff.h . svn_fs.h + . svn_types.h These headers have been reviewed by stefan2 and where issues have been found, they are already fixed. More review is welcome.
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=17&rev2=18 Comment: Remove a few svn_repos entries that have been resolved. === svn_repos.h === * `svn_repos_notify_warning_t` — Maybe change docstring: "... type of ''warning'' ''triggered'' ..."? - * `svn_repos_fs_lock_many` — Lock error handling in case of `lock_callback==NULL`? What is the error return on pre-lock hook failure?Doc updated. - * `svn_repos_fs_unlock_many` — Lock error handling in case of `lock_callback==NULL`? Error return on pre-unlock hook failure? Doc updated. Why are the paths for callbacks allocated in `result_pool`?The paths are part of the "result" passed to the callback, just like the lock and path in the svn_fs_lock_many. * `svn_repos_parse_dumpstream3` — [JAF] Comment. * Comment still applies. — JAF * `svn_repos_get_fs_build_parser5` — Handling of / behavior if `use_history==FALSE`?
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=16&rev2=17 Comment: Various headers have been completed. == Reviewed But Need Further Attention == - === svn_client.h === - New functions: - - * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - - === svn_diff.h === - * `svn_diff_output2` - * `svn_diff_file_output_unified4` - * `svn_diff_output_binary` - * `svn_diff_file_output_merge3` - * `svn_diff_mem_string_output_unified3` - * `svn_diff_mem_string_output_merge3` — Document the optional cancel_func & cancel_baton. It may be helpful to tell when they will be invoked (once per file / hunk?). - === svn_dirent_uri.h === * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named `svn_relpath__first_n_components`. - - === svn_fs.h === - * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Yes. Do we want to mention here that this is a 1.9 extension? SVN_FS_TXN_CLIENT_DATE is marked new in 1.9. - * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools?Renamed result_pool. - * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. Renamed scratch_pool. - * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`?Doc updated. - * `svn_fs_unlock_many` — What is the `result_pool` being used for? As for svn_fs_lock_many, it it used to allocate the result data passed to the callback. === svn_ra_svn.h === * `svn_ra_svn_create_conn4` — The @note is unclear. Is the file being used for time-out detection? @@ -60, +40 @@ == Review Completed! == + All issues found so far have been resolved for these headers: + + . svn_client.h + . svn_diff.h + . svn_fs.h + These headers have been reviewed by stefan2 and where issues have been found, they are already fixed. More review is welcome. . mod_dav_svn.h
[Subversion Wiki] Update of "Svn19ApiReview" by PhilipMartin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by PhilipMartin: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=15&rev2=16 * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Yes. Do we want to mention here that this is a 1.9 extension? SVN_FS_TXN_CLIENT_DATE is marked new in 1.9. * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools?Renamed result_pool. * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. Renamed scratch_pool. - * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`? + * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`?Doc updated. * `svn_fs_unlock_many` — What is the `result_pool` being used for? As for svn_fs_lock_many, it it used to allocate the result data passed to the callback. === svn_ra_svn.h === @@ -37, +37 @@ === svn_repos.h === * `svn_repos_notify_warning_t` — Maybe change docstring: "... type of ''warning'' ''triggered'' ..."? - * `svn_repos_fs_lock_many` — Lock error handling in case of `lock_callback==NULL`? What is the error return on pre-lock hook failure? + * `svn_repos_fs_lock_many` — Lock error handling in case of `lock_callback==NULL`? What is the error return on pre-lock hook failure?Doc updated. - * `svn_repos_fs_unlock_many` — Lock error handling in case of `lock_callback==NULL`? Error return on pre-unlock hook failure? Why are the paths for callbacks allocated in `result_pool`? + * `svn_repos_fs_unlock_many` — Lock error handling in case of `lock_callback==NULL`? Error return on pre-unlock hook failure? Doc updated. Why are the paths for callbacks allocated in `result_pool`?The paths are part of the "result" passed to the callback, just like the lock and path in the svn_fs_lock_many. * `svn_repos_parse_dumpstream3` — [JAF] Comment. * Comment still applies. — JAF * `svn_repos_get_fs_build_parser5` — Handling of / behavior if `use_history==FALSE`?
[Subversion Wiki] Update of "Svn19ApiReview" by PhilipMartin
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by PhilipMartin: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=14&rev2=15 * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named `svn_relpath__first_n_components`. === svn_fs.h === - * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Do we want to mention here that this is a 1.9 extension? + * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Yes. Do we want to mention here that this is a 1.9 extension? SVN_FS_TXN_CLIENT_DATE is marked new in 1.9. - * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools? + * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools?Renamed result_pool. - * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. + * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. Renamed scratch_pool. * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`? - * `svn_fs_unlock_many` — What is the `result_pool` being used for? + * `svn_fs_unlock_many` — What is the `result_pool` being used for? As for svn_fs_lock_many, it it used to allocate the result data passed to the callback. === svn_ra_svn.h === * `svn_ra_svn_create_conn4` — The @note is unclear. Is the file being used for time-out detection?
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=13&rev2=14 Comment: Remove entries that got fixed recently. New functions: * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. === svn_diff.h === * `svn_diff_output2` @@ -29, +27 @@ === svn_fs.h === * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Do we want to mention here that this is a 1.9 extension? - * `svn_fs_dir_optimal_order` — Should use 2 pools as its implementation creates temporary objects. * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools? * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`?
[Subversion Wiki] Update of "Svn19ApiReview" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=12&rev2=13 == Needs Review == - All public API headers have been reviewed at least once. @@ -17, +16 @@ * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. - === svn_diff.h === - * `svn_diff_output2` * `svn_diff_file_output_unified4` * `svn_diff_output_binary` @@ -39, +36 @@ * `svn_fs_unlock_many` — What is the `result_pool` being used for? === svn_ra_svn.h === - * `svn_ra_svn_create_conn4` — The @note is unclear. Is the file being used for time-out detection? === svn_repos.h === - * `svn_repos_notify_warning_t` — Maybe change docstring: "... type of ''warning'' ''triggered'' ..."? * `svn_repos_fs_lock_many` — Lock error handling in case of `lock_callback==NULL`? What is the error return on pre-lock hook failure? * `svn_repos_fs_unlock_many` — Lock error handling in case of `lock_callback==NULL`? Error return on pre-unlock hook failure? Why are the paths for callbacks allocated in `result_pool`? * `svn_repos_parse_dumpstream3` — [JAF] Comment. + * Comment still applies. — JAF * `svn_repos_get_fs_build_parser5` — Handling of / behavior if `use_history==FALSE`? === svn_types.h === * `svn_null_pointer_constant_stdarg_sentinel_t` — Should this be private? -* No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane + * No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane - === svn_wc.h === - * `svn_wc_notify_move_broken` — Has a TODO left-over from 1.8 * `svn_wc_conflict_description2_t.merged_file` — Clarify the ###. * `svn_wc_conflict_description_create_tree2` — What is that @c local_node_kind that is being mentioned _twice_? @@ -69, +63 @@ == Review Completed! == - These headers have been reviewed by stefan2 and where issues have been found, they are already fixed. More review is welcome. . mod_dav_svn.h @@ -80, +73 @@ . svn_mergeinfo.h . svn_ra.h . svn_string.h - . svn_version.h + . svn_version.h The following 1.9 header contain only minor changes against 1.8. Those changes seem to be o.k. Reviewed by stefan2.
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=11&rev2=12 Comment: First round of API review has been completed. == Needs Review == + All public API headers have been reviewed at least once. - The following 1.9 headers contain non-trivial changes against 1.8: - - . mod_dav_svn.h - . svn_cmdline.h - . svn_config.h - . svn_diff.h - . svn_error.h - . svn_io.h - . svn_mergeinfo.h - . svn_ra.h - . svn_ra_svn.h - . svn_string.h - . svn_version.h - . svn_wc.h == Reviewed But Need Further Attention == @@ -29, +16 @@ * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. + + + === svn_diff.h === + + * `svn_diff_output2` + * `svn_diff_file_output_unified4` + * `svn_diff_output_binary` + * `svn_diff_file_output_merge3` + * `svn_diff_mem_string_output_unified3` + * `svn_diff_mem_string_output_merge3` — Document the optional cancel_func & cancel_baton. It may be helpful to tell when they will be invoked (once per file / hunk?). === svn_dirent_uri.h === * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named `svn_relpath__first_n_components`. @@ -40, +37 @@ * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`? * `svn_fs_unlock_many` — What is the `result_pool` being used for? + + === svn_ra_svn.h === + + * `svn_ra_svn_create_conn4` — The @note is unclear. Is the file being used for time-out detection? === svn_repos.h === @@ -53, +54 @@ * `svn_null_pointer_constant_stdarg_sentinel_t` — Should this be private? * No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane + + === svn_wc.h === + + * `svn_wc_notify_move_broken` — Has a TODO left-over from 1.8 + * `svn_wc_conflict_description2_t.merged_file` — Clarify the ###. + * `svn_wc_conflict_description_create_tree2` — What is that @c local_node_kind that is being mentioned _twice_? + * `svn_wc__conflict_description2_dup` — Simply remove from API. + * `svn_wc_conflict_choice_t.svn_wc_conflict_choose_undefined` — If truly internal, we might rename it to `svn_wc_conflict_choose__undefined`. + * `svn_wc_add_from_disk3` — Still has TODO and ###s. Document the notification callback (is it optional?) + * `svn_wc_add_from_disk2` — What is skip_som_prop_canon? + * `svn_wc_queue_committed4` — Various outstanding ###s. + * `svn_wc_cleanup4` — Document the notification callback (is it optional?) + == Review Completed! == + + These headers have been reviewed by stefan2 and where issues have been found, they are already fixed. More review is welcome. + + . mod_dav_svn.h + . svn_cmdline.h + . svn_config.h + . svn_error.h + . svn_io.h + . svn_mergeinfo.h + . svn_ra.h + . svn_string.h + . svn_version.h The following 1.9 header contain only minor changes against 1.8. Those changes seem to be o.k. Reviewed by stefan2.
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=10&rev2=11 Comment: Add complete lists of reviewed and TODO headers == Needs Review == + + The following 1.9 headers contain non-trivial changes against 1.8: + + . mod_dav_svn.h + . svn_cmdline.h + . svn_config.h + . svn_diff.h + . svn_error.h + . svn_io.h + . svn_mergeinfo.h + . svn_ra.h + . svn_ra_svn.h + . svn_string.h + . svn_version.h + . svn_wc.h + == Reviewed But Need Further Attention == === svn_client.h === @@ -15, +31 @@ * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. === svn_dirent_uri.h === - * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named 'svn_relpath__first_n_components'. + * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named `svn_relpath__first_n_components`. === svn_fs.h === * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Do we want to mention here that this is a 1.9 extension? @@ -39, +55 @@ == Review Completed! == - Nothing yet. + The following 1.9 header contain only minor changes against 1.8. Those changes seem to be o.k. Reviewed by stefan2. + + . svn_auth.h + . svn_compat.h + . svn_cache_config.h + . svn_checksum.h + . svn_delta.h + . svn_error_codes.h + . svn_hash.h + . svn_iter.h + . svn_opt.h + . svn_path.h + . svn_sorts.h + . svn_xml.h +
[Subversion Wiki] Update of "Svn19ApiReview" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=9&rev2=10 Comment: Add issues found during the review of svn_fs.h and svn_repos.h. === svn_dirent_uri.h === * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named 'svn_relpath__first_n_components'. + === svn_fs.h === + * `svn_fs_commit_txn` — Is the `SVN_FS_TXN_CLIENT_DATE` behavior still as described? Do we want to mention here that this is a 1.9 extension? + * `svn_fs_dir_optimal_order` — Should use 2 pools as its implementation creates temporary objects. + * `svn_fs_lock_target_create` — `pool` parameter: Is this a `result_pool` or should it even become 2 pools? + * `svn_fs_lock_callback_t` — `pool` parameter: Maybe rename to `scratch_pool`. + * `svn_fs_lock_many`, `svn_fs_unlock_many` — Mention in docstring that these are not atomic operations. If the callback returns an error, they simply return that error to their callers and leave part of the locks in their initial and the remainder in the final state. What is the lock error handling in case of `lock_callback==NULL`? + * `svn_fs_unlock_many` — What is the `result_pool` being used for? + + === svn_repos.h === + + * `svn_repos_notify_warning_t` — Maybe change docstring: "... type of ''warning'' ''triggered'' ..."? + * `svn_repos_fs_lock_many` — Lock error handling in case of `lock_callback==NULL`? What is the error return on pre-lock hook failure? + * `svn_repos_fs_unlock_many` — Lock error handling in case of `lock_callback==NULL`? Error return on pre-unlock hook failure? Why are the paths for callbacks allocated in `result_pool`? + * `svn_repos_parse_dumpstream3` — [JAF] Comment. + * `svn_repos_get_fs_build_parser5` — Handling of / behavior if `use_history==FALSE`? + === svn_types.h === * `svn_null_pointer_constant_stdarg_sentinel_t` — Should this be private? * No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane
[Subversion Wiki] Update of "Inheritable-Ignores-AutoProps" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Inheritable-Ignores-AutoProps" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Inheritable-Ignores-AutoProps?action=diff&rev1=16&rev2=17 Comment: Correct the format of svn:global-ignores prop values -- issue #4380. Like the svn:ignore property it only makes sense to set svn:auto-props on directories, so attempts to propset the latter on a file will fail. === Ignores Format === - The values for the svn:global-ignores property are per the format of configuration defined global-ignores: A whitespace-delimited collection of file patterns. Like svn:auto-props, the svn:global-ignores property can only be set on directories. + The values for the svn:global-ignores property are in the same format as the svn:ignore property: a newline-delimited collection of file patterns.<> Like svn:auto-props, the svn:global-ignores property can only be set on directories. === Auto-Props Hierarchy and Precedence === Any path added to the working copy or imported to the repository must have a previously versioned parent. Both the svn:auto-props explicitly set on that parent and the properties inherited by that parent, in addition to the run-time configuration auto-props, will determine the auto-props for the added/imported files under the versioned parent. Where the auto-prop values '''for the same file pattern''' conflict there are a few simple rules:
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "AuthzImprovements" page has been changed by brane: https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=12&rev2=13 == Goals == - The current (1.9) implementation of authz is lacking in three areas: + The current (1.9) implementation of authz is lacking in two areas: - * Performance when a large number of paths needs to be checked. - Affected operations are mainly checkout / export and log. + 1. Wildcard support and performance + * Performance when a large number of paths needs to be checked. Affected operations are mainly checkout / export and log. - * Support for wildcards. Subversion should support + * Support for wildcards. Subversion should support - * "*" for single (exactly one), arbitrary path segments (with no "/" in them) and +* "*" for single (exactly one), arbitrary path segments (with no "/" in them) and - * "**" for arbitrary number (zero to infinite) of path segments. +* "**" for arbitrary number (zero to infinite) of path segments. - * Classic wildcard patterns like "*foo*.bar", including escapement via the "\" prefix shall be supported. +* Classic wildcard patterns like "*foo*.bar", including escapement via the "\" prefix shall be supported. - The asterisks in there match zero to many characters other than "/" making the whole segment form "/*/" +The asterisks in there match zero to many characters other than "/" making the whole segment form "/*/" a mere special case of this. + All wildcard usage applies to full path segments only, i.e. a '*' never matches a '/' except for the case of "/**/" where it matches zero to many full segments. For example, "/*/**/*" will match any path that contains at least 2 segments and is equivalent to "/**/*/*" as well as "/*/*/**". - a mere special case of this. - All wildcard usage applies to full path segments only, i.e. a '*' - never matches a '/' except for the case of "/**/" where it matches - zero to many full segments. For example, "/*/**/*" will match any path that contains at least 2 segments - and is equivalent to "/**/*/*" as well as "/*/*/**". - * The right to know about the existence of a node (a.k.a. lookup access rights and/or directory traversal rights) is implied by read access and cannot be manipulated separately. See [[http://subversion.tigris.org/issues/show_bug.cgi?id=3380|Issue 3380]] for previous discussion of this topic, and the [[http://svn.apache.org/repos/asf/subversion/branches/authz-overhaul/BRANCH-README|authz-overhaul branch]] for an attempt at implementing this distinction. [[http://mail-archives.apache.org/mod_mbox/subversion-dev/201411.mbox/%3C5478AAD4.3070306%40skynet.ie%3E|this thread]] on the dev@ mailing list is a recent example of the problems caused by implicit lookup access. + 1. Better access control + * The right to know about the existence of a node (a.k.a. lookup access rights and/or directory traversal rights) is implied by read access and cannot be manipulated separately. +* See [[http://subversion.tigris.org/issues/show_bug.cgi?id=3380|Issue 3380]] for previous discussion of this topic; +* the [[http://svn.apache.org/repos/asf/subversion/branches/authz-overhaul/BRANCH-README|authz-overhaul branch]] for an attempt at implementing this distinction. +* [[http://mail-archives.apache.org/mod_mbox/subversion-dev/201411.mbox/%3C5478AAD4.3070306%40skynet.ie%3E|This thread]] on the dev@ mailing list is a recent example of the problems caused by implicit lookup access. + == Wildcard Support and Performance == + - == Terminology == + === Terminology === + A '''path''' consists of '''segments''', separated by "/". Whildcards are valid segments and their interpretation depends on the context. - A '''path''' consists of '''segments''', separated by "/". - Whildcards are valid segments and their interpretation depends - on the context. + A '''access control list (ACL)''' contains a number of '''access control elements (ACE)''', each describing which '''users''' shall have what '''access rights'''. Users might be specified indirectly by using '''groups'''. - A '''access control list (ACL)''' contains a number of '''access control elements (ACE)''', - each describing which '''users''' shall have what '''access rights'''. Users might be specified - indirectly by using '''groups'''. A '''path rule''' specifies what ACL applies to a given path. - - == Inheritance and disambiguation == + === Inheritance and Disambiguation === + These are the rules as of today, with rule 7 added to support ambiguous path patches caused by pattern matching. Please note the difference between ''matching'' (does a path fully match a given pattern?) and ''applying to'' (governing the access rights). - These are the rules as of today, with rule 7 added to support - ambiguous path patches
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by brane:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=11&rev2=12
== Goals ==
- The current (1.9) implementation of authz is lacking in two areas:
+ The current (1.9) implementation of authz is lacking in three areas:
* Performance when a large number of paths needs to be checked.
Affected operations are mainly checkout / export and log.
@@ -20, +20 @@
zero to many full segments. For example, "/*/**/*" will match any path that
contains at least 2 segments
and is equivalent to "/**/*/*" as well as "/*/*/**".
+ * The right to know about the existence of a node (a.k.a. lookup access
rights and/or directory traversal rights) is implied by read access and cannot
be manipulated separately. See
[[http://subversion.tigris.org/issues/show_bug.cgi?id=3380|Issue 3380]] for
previous discussion of this topic, and the
[[http://svn.apache.org/repos/asf/subversion/branches/authz-overhaul/BRANCH-README|authz-overhaul
branch]] for an attempt at implementing this distinction.
[[http://mail-archives.apache.org/mod_mbox/subversion-dev/201411.mbox/%3C5478AAD4.3070306%40skynet.ie%3E|this
thread]] on the dev@ mailing list is a recent example of the problems caused
by implicit lookup access.
+
== Terminology ==
A '''path''' consists of '''segments''', separated by "/".
@@ -65, +67 @@
9. If multiple ACEs of a given ACL apply to a user, the union of
all individually granted access rights is granted.
-
- {{{#!wiki caution
- Suggest writing "union of ... rights" not "sum of ... rights" to avoid
ambiguity.
- }}}
== Design ==
[Subversion Wiki] Trivial Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "AuthzImprovements" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=10&rev2=11 denying access to anybody applies to the root path. 6. If repository-specific path rules as well as global path rules - match a given path, only the repositor-specific ones will be + match a given path, only the repository-specific ones will be considered. 7. If multiple path rules match a given repository path, only
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=9&rev2=10
Comment:
Specify that repo-specific rules have higher prio
== Inheritance and disambiguation ==
- These are the rules as of today, with rule 6 added to support
+ These are the rules as of today, with rule 7 added to support
ambiguous path patches caused by pattern matching. Please note
the difference between ''matching'' (does a path fully match a
given pattern?) and ''applying to'' (governing the access rights).
@@ -56, +56 @@
5. If no ACL is given for the repository root, a default ACL
denying access to anybody applies to the root path.
+ 6. If repository-specific path rules as well as global path rules
+ match a given path, only the repositor-specific ones will be
+ considered.
+
- 6. If multiple path rules match a given repository path, only
+ 7. If multiple path rules match a given repository path, only
the one specified last in the authz file shall apply.
- 7. If multiple ACEs of a given ACL apply to a user, the union of
+ 9. If multiple ACEs of a given ACL apply to a user, the union of
all individually granted access rights is granted.
{{{#!wiki caution
[Subversion Wiki] Trivial Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "AuthzImprovements" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=8&rev2=9 Comment: missing word the difference between ''matching'' (does a path fully match a given pattern?) and ''applying to'' (governing the access rights). - 1. An ACL is relevant to a user if the user, one of aliases or + 1. An ACL is relevant to a user if the user, one of their aliases or groups that they are a member of is mentioned by at least one ACE in that ACL.
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=7&rev2=8
Comment:
Typo and idomatic changes.
on the context.
A '''access control list (ACL)''' contains a number of '''access control
elements (ACE)''',
- each describing what '''users''' shall have which '''access rights'''. Users
might be specified
+ each describing which '''users''' shall have what '''access rights'''. Users
might be specified
indirectly by using '''groups'''.
A '''path rule''' specifies what ACL applies to a given path.
@@ -35, +35 @@
== Inheritance and disambiguation ==
- These are the rules as of today, with rule 3 added to support
+ These are the rules as of today, with rule 6 added to support
ambiguous path patches caused by pattern matching. Please note
the difference between ''matching'' (does a path fully match a
given pattern?) and ''applying to'' (governing the access rights).
@@ -59, +59 @@
6. If multiple path rules match a given repository path, only
the one specified last in the authz file shall apply.
- 7. If multiple ACEs of a given ACL apply to a user, the sum of
+ 7. If multiple ACEs of a given ACL apply to a user, the union of
all individually granted access rights is granted.
{{{#!wiki caution
@@ -165, +165 @@
Wildcard sequences in paths shall be normalized internally.
This is merely done to reduce matching costs later on and some of
- the matching code may rely on normalizes pattern.
+ the matching code may rely on normalized pattern.
{{{
// Variable length wildcards shall be the last in a sequence
while path contains "/**/*/"
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by brane:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=6&rev2=7
7. If multiple ACEs of a given ACL apply to a user, the sum of
all individually granted access rights is granted.
+ {{{#!wiki caution
+ Suggest writing "union of ... rights" not "sum of ... rights" to avoid
ambiguity.
+ }}}
== Design ==
@@ -87, +90 @@
based code, additional restrictions apply:
* No rule may appear more than once in the authz file.
* Value placeholders (`%(name)s`) are not expanded.
-
- {{{#!wiki caution
- This is the current behaviour of the authz files, but only because we happen
to use an `svn_config_t` to represent a parsed authz files. I suggest we should
constrain the semantics for authz rules:
- * No rule may appear more than once in the authz file.
- * Value placeholders (`%(name)s`) are not expanded.
-
- This implies writing a different constructor for the in-memory authz
structure, but is consistent with the intent, if not the current semantics, of
the authz files.
-
- — Brane}}}
-
* Filtered path rule tree
* prefix tree with one node per segment
* created on demand per user and repository
@@ -155, +148 @@
rights: none | r | rw
}}}
- {{{#!wiki caution
- '''Correction:'''
-
- There is no such thing as write-only access in our authz model. Access rights
can be only `none`, `r` or `rw`. This needs to be fixed throughout this doc.
-
- — Brane}}}
-
Lookup state
{{{
lookup-state :=
@@ -176, +162 @@
== Algorithms ==
=== Normalization ===
-
- {{{#!wiki caution
- '''Wildcard semantics?'''
-
- These normalisations are only valid if one assumes a certain set of semantics
for wildcards, but we do not define these semantics anywhere; see initial
comment in this doc.
-
- — Brane}}}
Wildcard sequences in paths shall be normalized internally.
This is merely done to reduce matching costs later on and some of
@@ -241, +220 @@
state.current = next
}}}
So, the full lookup without caching is
+ {{{#!wiki caution
+ There is one step we should perform before the initial lookup: check the
accumulated global rights calculated by the parser. There are probably many
cases where the result of any lookup can be predicted from those rights, and
therefore the lookup itself, and even creation of the filtered tree, could be
skipped entirely (for the cost of a couple extra hash lookups in the worst
case).
+ }}}
{{{
lookup(tree : ref to filtered-tree, path : string):
state = init(tree)
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by brane:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=5&rev2=6
never matches a '/' except for the case of "/**/" where it matches
zero to many full segments. For example, "/*/**/*" will match any path that
contains at least 2 segments
and is equivalent to "/**/*/*" as well as "/*/*/**".
-
- {{{#!wiki caution
- '''Missing definitions:'''
-
- This doc does not provide an unambiguous definition of the pattern syntax.
- * Does `foo*` match "foo"? If it does, does a single `*` match 0-or-1
segment, or is it an exception?
- * Is `/**/foo` hungry (i.e., does it match the longest subpath that ends in
"foo", or the first path segment that starts with "foo")?
- * Does `**` match 0-or-more or 1-or-more segments?
- * What about wildcard escaping in patterns? Our current authz rules allow
matching literal "*".
-
- — Brane}}}
-
== Terminology ==
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=4&rev2=5
Comment:
Update to current implementation and address Brane's points
Affected operations are mainly checkout / export and log.
* Support for wildcards. Subversion should support
- * "*" or single, arbitrary path segments (with no "/" in them) and
+ * "*" for single (exactly one), arbitrary path segments (with no "/" in
them) and
- * "**" for arbitrary length non-empty paths.
+ * "**" for arbitrary number (zero to infinite) of path segments.
- * Classic wildcard patterns like "*foo*.bar" shall be supported.
+ * Classic wildcard patterns like "*foo*.bar", including escapement via the
"\" prefix shall be supported.
+ The asterisks in there match zero to many characters other than "/" making
the whole segment form "/*/"
+ a mere special case of this.
All wildcard usage applies to full path segments only, i.e. a '*'
never matches a '/' except for the case of "/**/" where it matches
- one to many full segments.
+ zero to many full segments. For example, "/*/**/*" will match any path that
contains at least 2 segments
+ and is equivalent to "/**/*/*" as well as "/*/*/**".
{{{#!wiki caution
'''Missing definitions:'''
@@ -35, +38 @@
Whildcards are valid segments and their interpretation depends
on the context.
- A '''rule set''' contains a number of '''rules''', each
+ A '''access control list (ACL)''' contains a number of '''access control
elements (ACE)''',
- describing what '''users''' shall have which '''access rights'''.
+ each describing what '''users''' shall have which '''access rights'''. Users
might be specified
- Users might be specified indirectly by using '''groups'''.
+ indirectly by using '''groups'''.
- A '''path rule''' specifies what rule set applies to a given path.
+ A '''path rule''' specifies what ACL applies to a given path.
== Inheritance and disambiguation ==
These are the rules as of today, with rule 3 added to support
- ambiguous path patches caused by pattern matching.
+ ambiguous path patches caused by pattern matching. Please note
+ the difference between ''matching'' (does a path fully match a
+ given pattern?) and ''applying to'' (governing the access rights).
- 1. Path rules implicitly apply to all paths in the respective
- sub-tree.
+ 1. An ACL is relevant to a user if the user, one of aliases or
+ groups that they are a member of is mentioned by at least one
+ ACE in that ACL.
+ 2. Only path rules with ACLs relevant to the given user may
+ match a path.
+
+ 3. If a path rule matches a given repository path, its ACL applies
+ to that path.
+
+ 4. If no path rule matches a given repository path, the parent
+ path's ACL applies.
+
+ 5. If no ACL is given for the repository root, a default ACL
+ denying access to anybody applies to the root path.
+
- 2. If multiple path rules match a given repository path, only
+ 6. If multiple path rules match a given repository path, only
- the path rule(s) that cover the most segments shall apply.
-
- 3. If multiple path rules cover the same number of segments,
- only the one specified last in the authz file shall apply.
+ the one specified last in the authz file shall apply.
+ 7. If multiple ACEs of a given ACL apply to a user, the sum of
+ all individually granted access rights is granted.
- 4. If there are multiple rules in a rule set for a given
- user, the union of all rights granted shall apply.
-
- 5. The following rule is implicitly added as the first rule
- given no access to anybody by default.
- {{{
- [/]
- * =
- }}}
== Design ==
@@ -85, +93 @@
Putting caching aside, the workflow involved three data models,
building on top of each other.
- * Parsing an authz file (from file system or repository)
+ * Parsing an authz file (from file system or repository),
- yields a consolidated hash (additive sections being combined
- automatically) of it contents in svn_config_t.
+ validating its contents and creating a pre-processed in-memory
+ representation. In comparison to the old svn_config_t
+ based code, additional restrictions apply:
+ * No rule may appear more than once in the authz file.
+ * Value placeholders (`%(name)s`) are not expanded.
{{{#!wiki caution
This is the current behaviour of the authz files, but only because we happen
to use an `svn_config_t` to represent a parsed authz files. I suggest we should
constrain the semantics for authz rules:
@@ -102, +113 @@
* prefix tree with one node per segment
* created on demand per user and repository
* contains only rules that apply to the respective user and repository
- * multiple instances of that being cached in the svn_authz_t structure
alongside the single svn_confi
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by brane:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=3&rev2=4
return state.rights
}}}
+
+ = Implementation Notes =
+
+ == Changes from Current Behaviour ==
+
+ === Rules Defined Only Once ===
+ The config-based parser would merge and override access entries in redefined
rules.
+ The new parser rejects authz files that define the same rule more than once.
+
+ === New Rule Syntax for Wildcard Rules ===
+
+ Existing rules come in two flavours; repository-specific and global:
+ {{{
+[repos:/path]
+[/path]
+ }}}
+
+ In these rules, `/path` is always matched literally. The new parser supports
two new forms for rules with paths that contain wildcards:
+ {{{
+[:glob:repos:/path]
+[:glob:/path]
+ }}}
+
+ Because a glob rule is not required to actually contain wildcards in the
path, two sections with different names may represent the same rule; for
example,
+ {{{
+[/path]
+[:glob:/path]
+ }}}
+ the above two rules are identical. The new parser detects (and rejects) such
collisions.
+
+ === Write-only Access is Not Allowed ===
+
+ The config-based authz parser will allow access entries that grant only write
access; e.g.,
+ {{{
+[/]
+* = w
+ }}}
+ The new parser flags such entries as invalid; our authz implementation does
not support write-only access.
+
+ === Only Group Definitions in the Global Groups File ===
+
+ The new parser allows only group definitions (i.e., only the `[groups]`
section) in the global groups file. The config-based parser would allow other
sections there, but they would be ignored.
+
[Subversion Wiki] Update of "AuthzImprovements" by brane
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by brane:
https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=2&rev2=3
never matches a '/' except for the case of "/**/" where it matches
one to many full segments.
+ {{{#!wiki caution
+ '''Missing definitions:'''
+
+ This doc does not provide an unambiguous definition of the pattern syntax.
+ * Does `foo*` match "foo"? If it does, does a single `*` match 0-or-1
segment, or is it an exception?
+ * Is `/**/foo` hungry (i.e., does it match the longest subpath that ends in
"foo", or the first path segment that starts with "foo")?
+ * Does `**` match 0-or-more or 1-or-more segments?
+ * What about wildcard escaping in patterns? Our current authz rules allow
matching literal "*".
+
+ — Brane}}}
+
== Terminology ==
@@ -77, +88 @@
* Parsing an authz file (from file system or repository)
yields a consolidated hash (additive sections being combined
automatically) of it contents in svn_config_t.
+
+ {{{#!wiki caution
+ This is the current behaviour of the authz files, but only because we happen
to use an `svn_config_t` to represent a parsed authz files. I suggest we should
constrain the semantics for authz rules:
+ * No rule may appear more than once in the authz file.
+ * Value placeholders (`%(name)s`) are not expanded.
+
+ This implies writing a different constructor for the in-memory authz
structure, but is consistent with the intent, if not the current semantics, of
the authz files.
+
+ — Brane}}}
* Filtered path rule tree
* prefix tree with one node per segment
@@ -136, +156 @@
rights: none | r | w | rw
}}}
+ {{{#!wiki caution
+ '''Correction:'''
+
+ There is no such thing as write-only access in our authz model. Access rights
can be only `none`, `r` or `rw`. This needs to be fixed throughout this doc.
+
+ — Brane}}}
+
Lookup state
{{{
lookup-state :=
@@ -150, +177 @@
== Algorithms ==
=== Normalization ===
+
+ {{{#!wiki caution
+ '''Wildcard semantics?'''
+
+ These normalisations are only valid if one assumes a certain set of semantics
for wildcards, but we do not define these semantics anywhere; see initial
comment in this doc.
+
+ — Brane}}}
Wildcard sequences in paths in rule sets shall be normalized.
This is merely done to reduce matching costs later on.
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "AuthzImprovements" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/AuthzImprovements?action=diff&rev1=1&rev2=2 Comment: Nicer formatting in the goals section * Performance when a large number of paths needs to be checked. Affected operations are mainly checkout / export and log. - * Support for wildcards. - Subversion should support "*" or single, arbitrary path segments + * Support for wildcards. Subversion should support + * "*" or single, arbitrary path segments (with no "/" in them) and - (with no "/" in them) and "**" for arbitrary length non-empty paths. + * "**" for arbitrary length non-empty paths. - Finally, classic wildcard patterns like "*foo*.bar" shall be supported. + * Classic wildcard patterns like "*foo*.bar" shall be supported. All wildcard usage applies to full path segments only, i.e. a '*' never matches a '/' except for the case of "/**/" where it matches one to many full segments.
[Subversion Wiki] Update of "AuthzImprovements" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "AuthzImprovements" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/AuthzImprovements
Comment:
Initial version.
New page:
= Improved authz =
== Goals ==
The current (1.9) implementation of authz is lacking in two areas:
* Performance when a large number of paths needs to be checked.
Affected operations are mainly checkout / export and log.
* Support for wildcards.
Subversion should support "*" or single, arbitrary path segments
(with no "/" in them) and "**" for arbitrary length non-empty paths.
Finally, classic wildcard patterns like "*foo*.bar" shall be supported.
All wildcard usage applies to full path segments only, i.e. a '*'
never matches a '/' except for the case of "/**/" where it matches
one to many full segments.
== Terminology ==
A '''path''' consists of '''segments''', separated by "/".
Whildcards are valid segments and their interpretation depends
on the context.
A '''rule set''' contains a number of '''rules''', each
describing what '''users''' shall have which '''access rights'''.
Users might be specified indirectly by using '''groups'''.
A '''path rule''' specifies what rule set applies to a given path.
== Inheritance and disambiguation ==
These are the rules as of today, with rule 3 added to support
ambiguous path patches caused by pattern matching.
1. Path rules implicitly apply to all paths in the respective
sub-tree.
2. If multiple path rules match a given repository path, only
the path rule(s) that cover the most segments shall apply.
3. If multiple path rules cover the same number of segments,
only the one specified last in the authz file shall apply.
4. If there are multiple rules in a rule set for a given
user, the union of all rights granted shall apply.
5. The following rule is implicitly added as the first rule
given no access to anybody by default.
{{{
[/]
* =
}}}
== Design ==
The idea is to use combine the following approaches:
* Preprocessed, tree-like data structures applied to segmented paths
* Reduction of the tree to what applies to the current user
* Pre-calculate recursive rights for early exist
In the initial implementation we may rely on the svn_config API
to provide us with parser functionality. At that stage, we don't
need an independent representation of the whole file contents.
=== General workflow ===
Putting caching aside, the workflow involved three data models,
building on top of each other.
* Parsing an authz file (from file system or repository)
yields a consolidated hash (additive sections being combined
automatically) of it contents in svn_config_t.
* Filtered path rule tree
* prefix tree with one node per segment
* created on demand per user and repository
* contains only rules that apply to the respective user and repository
* multiple instances of that being cached in the svn_authz_t structure
alongside the single svn_config_t
* rule sets being reduced to access rights + order ID
* each node knows min / max rights on all sub-nodes
* Lookup state
* access rights accordingly the latest matching path rule
* list of tree nodes that may match sub-paths as we may need to follow
multiple patterns
* temporary data structure thats reused between queries to save on allocation
and construction overhead
=== Data models ===
These are persistent in the sense that we will cache and reuse
them. They do not cover transient data models that various
algorithms may use e.g. during authz parsing.
Unless indicated otherwise, all collections are ordered.
Only abstract types / the interface view is given here; the actual
implementation may be different.
Filtered path rule tree
{{{
filtered-tree :=
root : filtered-node // exists due to default path rule
filtered-node :=
segment : string // empty for root
access: ref to access-type // empty if no path ends here
min-rights: none | r | w | rw // user's minimum rights on any path in
the sub-tree
max-rights: none | r | w | rw // user's maximum rights on any path in
the sub-tree
repeat: boolean // set on nodes for "**" segments
sub-nodes : { map following segment => filtered-node }[0..*]
// one node per non-wildcard in
following segment
// empty if no rules on following
segments
// the following will be aggregated into a sub-structure to
// facilitate a quick "has pattern sub-segment?" check
any : filtered-node // empty if no path rule with "*" in
following segment
any-var : filtered-node // empty if no path rule with "**" in
following segment
prefixed : { list of filtered-node }[0..*]
// empty if no pa
[Subversion Wiki] Update of "SavePoints" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "SavePoints" page has been changed by JulianFoad: https://wiki.apache.org/subversion/SavePoints?action=diff&rev1=3&rev2=4 Comment: Add my comments (questions). == Design: SavePoints == - There are many client side features that people have desired with Subversion that require the ability to store the state of a working copy without committing to the repository. This document exists to try and flush out a design for the save point feature from which we can build such features. === Expected Features === - Before we can look at the design it's helpful to have an idea of what features we want to support in detail. * Destructive command rollback. We have a variety of commands that either permanently destroy uncommitted local modifications or make it rather inconvenient to put them back the way they were. It would be nice if we could store our state before executing these commands and then provide a command to restore that state if the user decided that the state is undesirable. @@ -14, +12 @@ * Workspaces. Otherwise known as local commit/branching. Generally being able to work on changes and then be able to save your state at various points along the way. Allowing these states to be committed as a series of commits or to be squashed into a single commit. Eventually even allowing this local history to be manipulated in more complex ways such as rebasing. + === What is a SavePoint === + A save point is the stored state of a working copy at a given point in time. It consists of the following pieces of information: + + ||name ||purpose || + ||id ||primary key for save point unique between all save points, integer || + ||workspace ||group of related savepoints this savepoint belongs to, string || + ||name ||optional user defined name of the savepoint, string || + ||order ||the savepoints order within the namespace, integer || + ||automatic ||boolean, true if the savepoint was created automatically || + ||log ||string describing the modifications in the save point || + ||nodes ||set of wc db nodes table entires for the nodes (stored in the nodes table or another table, TBD) || + ||blob contents ||data for locally modified files and properties (stored in pristine files, something like that or in some cases stored in wc db) || - === What is a SavePoint === - - A save point is the stored state of a working copy at a given point in time. It consists of the following pieces of information: - || name || purpose || - || id || primary key for save point unique between all save points, integer || - || workspace || group of related savepoints this savepoint belongs to, string || - || name || optional user defined name of the savepoint, string || - || order || the savepoints order within the namespace, integer || - || automatic || boolean, true if the savepoint was created automatically || - || log || string describing the modifications in the save point || - || nodes || set of wc db nodes table entires for the nodes (stored in the nodes table or another table, TBD) || - || blob contents || data for locally modified files and properties (stored in pristine files, something like that or in some cases stored in wc db) || SavePoints will always belong to a workspace. Within the workspace the member SavePoints will be ordered. Workspace names beginning with "svn:" are reserved for internal Subversion use. Stash will use the "svn:stash" workspace. There will be a current work space, which will default to something possibly "Default". Save points for rolling back destructive commands will be created in the current workspace with the automatic flag set to true. Save Points are considered immutable once created. Workspaces may be mutable but we likely will like to always handle modifying them by creating a new temporary workspace and then copying save points that are unmodified and creating fresh ones with the changed states. Treating them as immutable and recreating them to modify them means if the modification fails for some reason, we have not lost data. === Nodes data === - The nodes table of the wc db will have a new column added which optionally specifies a savepoint id. When creating a SavePoint the wc db nodes table data without a savepoint id (that is the current state of the nodes in the working copy) will be duplicated with the savepoint id set. It may be desirable to use a separate table for this e.g. savepoint_nodes. Duplicating the entire nodes table may not be as fast as we desire, in general we desire the creation of save points to be fast since users will likely be doing this often. However, we have decided not to implement optimization of the representation at this time and rather first implement a full copy since it will be simpler for initial implementation a
[Subversion Wiki] Trivial Update of "MeasuringRepositoryPerformance" by StefanFuhrmann
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "MeasuringRepositoryPerformance" page has been changed by StefanFuhrmann: https://wiki.apache.org/subversion/MeasuringRepositoryPerformance?action=diff&rev1=1&rev2=2 Comment: typo With this [[https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/benchmarks/RepoPerf/copy_repo.py|python script]], you also get random data files of up to the specified size being written in between revisions. Those get deleted once the copy is complete. Depending on the OS / SAN heuristics, this may mimic the presence of other repositories growing as the copied one does. Moreover, multiple repositories get copied at once in a round-robin interleaved scheme, i.e. copy rev 0 of all repositories, then rev 1 of all repositories, etc. - The spacing parameter should be equal to the average revision data being written to other repos for each revision / packed shard copy round. IOW something like (total size of "missing" repos) / (number of revs in copied repos). As that may result in too much transiently disk space being allocation, you may use 128 here. That plays well with typical RAID strip and OS prefetch sizes. + The spacing parameter should be equal to the average revision data being written to other repos for each revision / packed shard copy round. IOW something like (total size of "missing" repos) / (number of revs in copied repos). As that may result in too much transiently disk space being allocated, you may use 128 here. That plays well with typical RAID strip and OS prefetch sizes. == What to test == Before you conduct performance tests, you need to decide upon the scenarios as well as what kind of conclusions you want to be able to draw from the results. For the latter, it is often useful to identify the components and settings involved and to be able to isolate their contribution.
[Subversion Wiki] Update of "MeasuringRepositoryPerformance" by StefanFuhrmann
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for
change notification.
The "MeasuringRepositoryPerformance" page has been changed by StefanFuhrmann:
https://wiki.apache.org/subversion/MeasuringRepositoryPerformance
Comment:
Initial version.
New page:
= Measuring Repository Performance =
Repositories are just passive collections of files on disk, but their physical
layout affects performance just as well as the hardware and software
configuration.
This page is about
* how to produce realistic on-disk layouts
* what to test
* how to to produce meaningful test results
The methodology applies to a wide range of setups and repository formats. FSFS
is being used as an example but the basic rationales should apply to others as
well.
== How to produce realistic on-disk layouts ==
=== TL;DR ===
Either properly clone your data storage (see below) or use a script
[[https://svn.apache.org/repos/asf/subversion/trunk/tools/dev/benchmarks/RepoPerf/copy_repo.py|like
this]] for FSFS repositories:
{{{
copy_repo.py SRC DST COUNT SEPARATOR_SIZE
SRCImmediate parent folder of all the repositories to copy.
DSTFolder to copy into; current contents will be lost.
COUNT Number of copies to create of each source repository.
SEPARATOR_SIZE Additional spacing, in kBytes, between revisions.
e.g. copy_repo.py /tmp/acme /test/acme 4 128
}}}
=== Problem ===
Non-packed FSFS repositories may consist of millions of files of varying sizes.
Even for seemingly simple queries, data from thousands of them needs to be
processed. If they happened to be stored physically close to each other on
disk, the information can be retrieved with just a handful of I/Os. Should
they be dispersed across the storage medium, it will take thousands of
individual and hard-to-predict (by the OS) I/Os.
Therefore, it is paramount that your test setup mimics the physical properties
of the class of production environments you want to test for.
Note that this does not only apply to HDDs (spinning disks) but to any media
that has non-zero I/O latency, including SSDs. The issue is whether OS- or
hardware-side prefetching will be effective such that most requests can be
served from some level of cache.
Things are complicated by the fact that the OS, its file system code or the SAN
software give the user very little control over where it puts the data
physically. The best one may hope for is that the same sequence of operations
produces similar - if not identical - layouts on previously empty disks.
=== Ideal solution ===
Clone the production environment. Everything else is just an approximation.
Various methods to produce good approximations are discussed in later sections.
Cloning in this case, however, must produce the same (or reasonably similar)
disk images. Merely copying files will create the same unrealistic setup as
the Naive approach below. That also precludes differential file copies as a
means to keep the test environment in sync with the production environment.
=== Naive approach ===
Simply copying an existing repository to the target storage will often store
data densely and roughly in path order. For non-packed FSFS repositories, for
instance, that means revision content is stored consecutively almost producing
a packed repository. The same applies to its revision properties, making the
enumeration of all revprops via 'svn log $repo/' very fast.
"Naturally grown" repositories store data in revision order, though. As a
result, it may be cheaper to get from the revision file to the revprops (for
time stamps etc.) than in a copied repo. OTOH, the revprops themselves may get
much more spread out if the OS decides to intersperse them with revision data.
For servers hosting multiple active repositories, "naturally grown"
repositories look even more different. Because many commits to other
repositories tend to happen between any two commits to the same repository, the
individual revisions of all these repositories may interleave on disk, creating
large and random gaps between the individual revisions of a repository.
Copying packed FSFS repositories creates the same problems in theory but less
so in practice. However, as the individual pack files are large and get
written quickly in a single go, individual packs look very much like copied
packs. Their sheer size requires some I/O going from one pack to the other and
the physical distance between packs becomes a secondary factor.
Note that the OS or SAN may still decide to place small files within the same
directory close to each other on disk. That's fine and should produce good,
*reproducible* performance figures. But we must try to not inadvertently aid
the OS in doing this.
=== 'svnadmin load' ===
This creates repository data in the correct order and if your server hosts only
one major repository that may even be a fair approximation of the production
envir
[Subversion Wiki] Update of "SupportedMergeScenarios" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "SupportedMergeScenarios" page has been changed by JulianFoad: https://wiki.apache.org/subversion/SupportedMergeScenarios?action=diff&rev1=19&rev2=20 Comment: Add a suggestion about untracked merges, from Matt Phipps - ~-''Design notes, plans and ideas.'' + ~-''Design notes, plans and ideas.'' -~ - ''This is not part of the official documentation of Subversion. It is aimed at the developers of Subversion, and may not reflect reality or the project community's plans. For official documentation, see'' http://subversion.apache.org/docs/ ''.''-~ + ~-''This is not part of the official documentation of Subversion. It is aimed at the developers of Subversion, and may not reflect reality or the project community's plans. For official documentation, see'' http://subversion.apache.org/docs/ ''.''-~ = What Merges Does Svn’s Merge Tracking Support? = @@ -80, +80 @@ 1. A tracked merge is transitive. In merging A:10 from A to B, if A:10 was itself a merge that brought in one or more recorded changes from elsewhere (say Z:9), then as well as recording A:10 on B, we also record Z:9 on B. Non-Tracked Merge - 1. You can use the “merge” command to merge changes in such a way that the committed result is not recorded as a merge. In terms of merge tracking, Subversion sees this commit as an original change, not as a merge. This kind of merge should be used only in special cases. ### WHICH MERGES ARE THESE? WHEN ARE THEY APPROPRIATE? WHEN DO THEY HAPPEN SILENTLY? + 1. You can use the “merge” command to merge changes in such a way that the committed result is not recorded as a merge. In terms of merge tracking, Subversion sees this commit as an original change, not as a merge. + 1. When would a non-tracked merge be useful? Matt Phipps wrote to dev@ to suggest one case: A merge like that would make sense if you wanted to do a Git-style rebase for whatever reason. You would create a new project branch off your development branch, cherry-pick all the non-merge changes from the old project branch onto it (possibly grouping or reordering or deleting commits), then delete the old branch. The new branch shouldn't have mergeinfo from the old branch since the old branch is getting deleted and replaced. + 1. ### WHICH MERGE COMMAND VARIANTS PERFORM A NON-TRACKED MERGE? WHEN DO THEY HAPPEN SILENTLY? One example of a change that is "silently" untracked is a reverse merge from the branch's own history.<> Record-Only Merge 1. A “record-only” merge acts like a normal merge except that it does not make edits to the target branch, it only updates the mergeinfo on the target branch as if that merge had happened. After a ''record-only merge'' has been committed, although only the mergeinfo changed in that commit, the merge tracking logic sees that commit as the time when the merge (the one that is now recorded) was performed. It doesn’t notice that there is no physical change in the commit. It doesn’t care whether the physical change was in fact merged into this target branch in the past or will be merged in the future. If and when the physical change is merged as a non-tracked merge, that commit will be regarded as an original change and not as a merge.
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=8&rev2=9 * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. === svn_dirent_uri.h === - * svn_relpath_limit — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named 'svn_relpath__first_n_components'. + * `svn_relpath_limit` — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named 'svn_relpath__first_n_components'. === svn_types.h === - * svn_null_pointer_constant_stdarg_sentinel_t — Should this be private? + * `svn_null_pointer_constant_stdarg_sentinel_t` — Should this be private? +* No; the idea is that API users can use `SVN_VA_NULL`. Note that the definition is a forward declaration of the type for the purpose of making it a pointer constant that's not trivially assignable to anything else (except `void*`), but the type itself is never defined, on purpose. — brane == Review Completed! ==
[Subversion Wiki] Update of "Svn19ApiReview" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=7&rev2=8 * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. + === svn_dirent_uri.h === + * svn_relpath_limit — Is this really a good public API, either in functionality or in name? I suggest it should be a local function in the one file where it's used, or else made private and named 'svn_relpath__first_n_components'. + + === svn_types.h === + * svn_null_pointer_constant_stdarg_sentinel_t — Should this be private? + == Review Completed! == Nothing yet.
[Subversion Wiki] Update of "Svn19ApiReview" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=6&rev2=7 New functions: * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) — Missing SVN_DEPRECATED annotation. + * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) + * `svn_client_cleanup` — Missing SVN_DEPRECATED annotation. == Review Completed! ==
[Subversion Wiki] Update of "Svn19ApiReview" by JulianFoad
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by JulianFoad: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=5&rev2=6 == Needs Review == - - == Reviewed But Need Further Attention == === svn_client.h === - New functions: * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) + * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) — Missing SVN_DEPRECATED annotation. == Review Completed! ==
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=4&rev2=5 New functions: - * `svn_client_vacuum` -- Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. + * `svn_client_vacuum` — Missing documentation for arguments `fix_recorded_timestamps` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) - * `svn_client_cleanup2` -- Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. + * `svn_client_cleanup2` — Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. (svn praise: r1548088 rhuijben) == Review Completed! ==
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=3&rev2=4 * `svn_client_cleanup2` -- Missing documentation for arguments `fix_recorded_timestamps`, `clear_dav_cache` and `vacuum_pristines`. - == Review Completed! = + == Review Completed! == Nothing yet.
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=2&rev2=3 = Svn19ApiReview = - This page contains a list of all the new additions to the public Subversion 1.8-dev API. + This page contains a list of all the new additions to the public Subversion 1.9-dev API. == Needs Review ==
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=2&rev2=3 = Svn19ApiReview = - This page contains a list of all the new additions to the public Subversion 1.8-dev API. + This page contains a list of all the new additions to the public Subversion 1.9-dev API. == Needs Review ==
[Subversion Wiki] Update of "Svn19ApiReview" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "Svn19ApiReview" page has been changed by brane: https://wiki.apache.org/subversion/Svn19ApiReview?action=diff&rev1=2&rev2=3 = Svn19ApiReview = - This page contains a list of all the new additions to the public Subversion 1.8-dev API. + This page contains a list of all the new additions to the public Subversion 1.9-dev API. == Needs Review ==
[Subversion Wiki] Update of "ManyHands" by brane
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "ManyHands" page has been changed by brane: https://wiki.apache.org/subversion/ManyHands?action=diff&rev1=4&rev2=5 * Svn18ApiReview - Subversion 1.8 new API review * Svn18Changes - Populating the Subversion 1.8.0 CHANGES file + * Svn19ApiReview - Subversion 1.9 new API review +
[Subversion Wiki] Update of "SavePoints" by BenReser
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "SavePoints" page has been changed by BenReser: https://wiki.apache.org/subversion/SavePoints?action=diff&rev1=2&rev2=3 Before we can look at the design it's helpful to have an idea of what features we want to support in detail. - * Destructive command rollback. We have a variety of commands that either permanently destroy uncommitted local modifications or make it rather inconvenient to put them back the way they were. It would be nice if we could store our state before executing these features and then provide a command to restore that state if the user decided that the state is undesirable. + * Destructive command rollback. We have a variety of commands that either permanently destroy uncommitted local modifications or make it rather inconvenient to put them back the way they were. It would be nice if we could store our state before executing these commands and then provide a command to restore that state if the user decided that the state is undesirable. * Stash. Git has functionality where you can store your working copy state locally in something they call the stash and remove all local modifications to the working copy. This allows you to for instance set aside a piece of work you are doing temporarily to fix some other thing and then after you have committed restore your working copy back to the previous state. Users can simulate something like this somewhat now by taking a diff, reverting, making the other change, committing, and then applying the patch. Except that of course `svn patch` is not fully capable of applying all modifications the working copy can represent. Something more automatic and that you don't have to keep track of patch files would be far more convenient. @@ -25, +25 @@ || name || optional user defined name of the savepoint, string || || order || the savepoints order within the namespace, integer || || automatic || boolean, true if the savepoint was created automatically || + || log || string describing the modifications in the save point || || nodes || set of wc db nodes table entires for the nodes (stored in the nodes table or another table, TBD) || || blob contents || data for locally modified files and properties (stored in pristine files, something like that or in some cases stored in wc db) || - SavePoints will always belong to a workspace. Within the workspace the member SavePoints will be ordered. Workspace names beginning with "svn:" are reserved for internal Subversion use. Stash will use the "svn:stash" workspace. There will be a current work space, which will default to something possibly "Default". Save points for rolling back destructive commands will be created in the current workspace with the automatic flag set to true. + SavePoints will always belong to a workspace. Within the workspace the member SavePoints will be ordered. Workspace names beginning with "svn:" are reserved for internal Subversion use. Stash will use the "svn:stash" workspace. There will be a current work space, which will default to something possibly "Default". Save points for rolling back destructive commands will be created in the current workspace with the automatic flag set to true. Save Points are considered immutable once created. Workspaces may be mutable but we likely will like to always handle modifying them by creating a new temporary workspace and then copying save points that are unmodified and creating fresh ones with the changed states. Treating them as immutable and recreating them to modify them means if the modification fails for some reason, we have not lost data. - === + === Nodes data === + The nodes table of the wc db will have a new column added which optionally specifies a savepoint id. When creating a SavePoint the wc db nodes table data without a savepoint id (that is the current state of the nodes in the working copy) will be duplicated with the savepoint id set. It may be desirable to use a separate table for this e.g. savepoint_nodes. Duplicating the entire nodes table may not be as fast as we desire, in general we desire the creation of save points to be fast since users will likely be doing this often. However, we have decided not to implement optimization of the representation at this time and rather first implement a full copy since it will be simpler for initial implementation and will give us some idea of this implementations performance. + + === Blob data === + + We have not made a final decision on how to store blob data. There are two general locations and one that may be used along side them: + + * Use the existing pristine store as is. The advantage of this option is that storage is shared with the pristines. The disadvantage is that it mixes pristine data with data that is not pristine. This risks p
[Subversion Wiki] Update of "SavePoints" by BenReser
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "SavePoints" page has been changed by BenReser: https://wiki.apache.org/subversion/SavePoints?action=diff&rev1=1&rev2=2 == Design: SavePoints == - stub page just to get started + There are many client side features that people have desired with Subversion that require the ability to store the state of a working copy without committing to the repository. This document exists to try and flush out a design for the save point feature from which we can build such features. + === Expected Features === + + Before we can look at the design it's helpful to have an idea of what features we want to support in detail. + + * Destructive command rollback. We have a variety of commands that either permanently destroy uncommitted local modifications or make it rather inconvenient to put them back the way they were. It would be nice if we could store our state before executing these features and then provide a command to restore that state if the user decided that the state is undesirable. + + * Stash. Git has functionality where you can store your working copy state locally in something they call the stash and remove all local modifications to the working copy. This allows you to for instance set aside a piece of work you are doing temporarily to fix some other thing and then after you have committed restore your working copy back to the previous state. Users can simulate something like this somewhat now by taking a diff, reverting, making the other change, committing, and then applying the patch. Except that of course `svn patch` is not fully capable of applying all modifications the working copy can represent. Something more automatic and that you don't have to keep track of patch files would be far more convenient. + + * Workspaces. Otherwise known as local commit/branching. Generally being able to work on changes and then be able to save your state at various points along the way. Allowing these states to be committed as a series of commits or to be squashed into a single commit. Eventually even allowing this local history to be manipulated in more complex ways such as rebasing. + + + + === What is a SavePoint === + + A save point is the stored state of a working copy at a given point in time. It consists of the following pieces of information: + || name || purpose || + || id || primary key for save point unique between all save points, integer || + || workspace || group of related savepoints this savepoint belongs to, string || + || name || optional user defined name of the savepoint, string || + || order || the savepoints order within the namespace, integer || + || automatic || boolean, true if the savepoint was created automatically || + || nodes || set of wc db nodes table entires for the nodes (stored in the nodes table or another table, TBD) || + || blob contents || data for locally modified files and properties (stored in pristine files, something like that or in some cases stored in wc db) || + + SavePoints will always belong to a workspace. Within the workspace the member SavePoints will be ordered. Workspace names beginning with "svn:" are reserved for internal Subversion use. Stash will use the "svn:stash" workspace. There will be a current work space, which will default to something possibly "Default". Save points for rolling back destructive commands will be created in the current workspace with the automatic flag set to true. + + === +
[Subversion Wiki] Update of "DesignNotes" by BenReser
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "DesignNotes" page has been changed by BenReser: https://wiki.apache.org/subversion/DesignNotes?action=diff&rev1=40&rev2=41 Comment: Add SavePoints entry. * MultiLayerMoves - recording multiple layers of moves in the working copy * NodesOperations - understanding WCNG NODES table * [[Inheritable-Ignores-AutoProps|Repository Dictated Configuration]] - server-dictated configuration via inheritable props + * SavePoints - implementation of stored working copy state to allow rolling back to such a state, stash, and local commits. * SymmetricMerge - understanding sync, reintegrate, catch-up, cherry-pick merges * UnicodeNormalization - managing differences in Unicode character composition in paths and mergeinfo
[Subversion Wiki] Update of "SavePoints" by BenReser
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification. The "SavePoints" page has been changed by BenReser: https://wiki.apache.org/subversion/SavePoints New page: == Design: SavePoints == stub page just to get started
