Re: Ev2 using move-away and move-here
My intention is to present possible designs for Ev2, and allow us to consider
which we prefer. In particular, we need to decide how important it is to
adhere to each of the principles including:
- the Once Rule
- avoidance of temporary paths (closely related to Once Rule)
- alter-dir (final set of children = {...}) before altering dir's children
- sequential modification
since different designs may trade off one of these against the others.
Greg Stein wrote:
In the wiki page you started, I thought we already solved the move
issue by using the original state for the source. [...]
No, we didn't come up with an actual solution, we came up with an idea that
*might* lead to a solution -- it felt like it should. My gut feeling is it
doesn't play well with the Ev2 principles, but I am still going to explore that
idea further as a possible alternative and present either how it could work or
why it couldn't.
- Julian
On Aug 12, 2013 10:43 AM, Julian Foad julianf...@btopenworld.com wrote:
TLDR: Ev2 move support doesn't work with the move and rotate
instructions as currently defined, and I propose that it could work
instead with separate move-away and move-here instructions.
[...]
Ev2 alter_directory deltas
Another problem with Ev2. Consider a cheap copy: svn cp ^/trunk ^/branches/foo With Ev1 this commit sends only a small amount of data across the wire. This is true even as the number of branches gets large. In the past there was a backend big directory storage problem, but that was solved by enabling directory deltafication. With Ev2 the big directory problem now applies to the network transfer. Adding a child to branches requires an alter_directory call with the new list of children, so the old list of children has to be sent from the server to the client and then the client has to send it back with the new child added. Very little other data has to be transferred. For big directories transferring the list of children will become the bottleneck. I think alter_directory should be changed to some sort of delta API: one list of added children and one list of deleted children. [Conceivably the RA implementation of the current Ev2 API could deltify the list sent back by caching the list received but that's horrible and doesn't solve the problem of getting the list in the first place.] I guess we should consider doing the same for the list of properties; perhaps with lists for added properties, modified properties and deleted properties. -- Philip
Re: Ev2 alter_directory deltas
Philip Martin wrote: Another problem with Ev2. Consider a cheap copy: svn cp ^/trunk ^/branches/foo With Ev1 this commit sends only a small amount of data across the wire. This is true even as the number of branches gets large. In the past there was a backend big directory storage problem, but that was solved by enabling directory deltafication. With Ev2 the big directory problem now applies to the network transfer. Adding a child to branches requires an alter_directory call with the new list of children, so the old list of children has to be sent from the server to the client and then the client has to send it back with the new child added. Very little other data has to be transferred. For big directories transferring the list of children will become the bottleneck. I think alter_directory should be changed to some sort of delta API: one list of added children and one list of deleted children. [Conceivably the RA implementation of the current Ev2 API could deltify the list sent back by caching the list received but that's horrible and doesn't solve the problem of getting the list in the first place.] I guess we should consider doing the same for the list of properties; perhaps with lists for added properties, modified properties and deleted properties. Why is this different from the delta-transmission of file content? The principle of Ev2 is to describe changes in terms of the new state is Y at the API level, and to leave deltification to be arranged between the producer implementation and the consumer implementation. Why cannot properties be handled this way, and why cannot (or should not) children-lists be handled this way? - Julian
Re: Ev2 alter_directory deltas
Julian Foad julianf...@btopenworld.com writes: Philip Martin wrote: [Conceivably the RA implementation of the current Ev2 API could deltify the list sent back by caching the list received but that's horrible and doesn't solve the problem of getting the list in the first place.] Why is this different from the delta-transmission of file content? The principle of Ev2 is to describe changes in terms of the new state is Y at the API level, and to leave deltification to be arranged between the producer implementation and the consumer implementation. Why cannot properties be handled this way, and why cannot (or should not) children-lists be handled this way? For this operation svn cp http://host/repo/trunk ^/branches/foo I don't see how to avoid the having the server transmit the existing children-list to the client. Ev2 has introduced that inefficiency. I can see that with caching we could implement some sort of delta for sending the children-list back to the server, but even that looks ugly. Does the RA layer cache every children-list received? Does the client provide a callback for the RA layer to cache and retrieve children-lists. A cheap branch operation which transfers a few dozen bytes in Ev1 (plus a few thousand bytes for HTTP headers) will have to transfer Megabytes with Ev2. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Ev2 using move-away and move-here
Greg Stein gst...@gmail.com writes:
In the wiki page you started, I thought we already solved the move issue by
using the original state for the source. (and remove rotate)
I didn't read this treatise, cuz I think it has an incorrect starting
assumption. You state early about sequential edits, when we relaxed that a
bit due to needing to retain the original state. Does it respond to the
proposal from your wiki page?
I'm not sure to which wiki page you are referring. My recollection of
the last dev discussion (see Julian's mail) is that there is still a
problem.
=== Examples Solved ===
Example 1:
| |
+--A mv--\add-- +--A
\ |
\-- +--B
1. alter-dir / (children={A})
Do we need to call alter-dir when a child is replaced or only when a
child is added/removed? If we look at the working copy update receiver
it wants to record incomplete for adds but probably does nothing for
replaces, it may not even do anything for deletes preferring to leave it
to the delete call.
2. mv-away A (id=“original A”)
3. add-directory A (children={B})
4. mv-here A/B (id=“original A”)
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Ev2 using move-away and move-here
On phone so a bit constrained ... Move away/from with Id is essentially introducing a namespace for temporary paths unrelated to the tree structure. Therefore you can change notation and keep only one move operation with three variants: move(a,b): direct move of node to new path move(a,tmp(1)): move to temporary slot move(tmp(1),b): move from temporary slot N.b. this does not imply a single conflated move API on the code level, it merely describes the protocol. Making the edit driver assign temporary slots explicitly is better than forcing the receiver to second-guess the driver's intent, and also makes validating the drive easier.
Re: Ev2 using move-away and move-here
Julian Foad julianf...@btopenworld.com writes:
Example 3: Swapping two directory levels
| |
+--A --\ /--+--A
| X |
+--B --/ \-- +--B
1. alter-dir A (children={}) ### Needed?
2. mv-away A/B (id=”original A/B”)
3. alter-dir / (children={A})
4. mv-away A (id=”original A”)
5. mv-here A (id=”original A/B”)
6. alter-dir A (children={B}) ### Second alter-dir on same path, if (1)
was needed.
7. mv-here A/B (id=”original A”)
That's inconsistent: for A alter-dir is before mv-away while for A/B
alter-dir is after mv-away. A more consistent set of steps would be:
1. alter-dir A/B (children={A})
2. alter-dir A (children={})
3. mv-away A/B (id=original A/B)
4. mv-away A (id=original A)
5. mv-here A (id=original A/B)
6. mv-here A/B (id=original A)
Not sure whether 1 and 2 have any particular order. In the working copy
receiver the alter-dir for A/B causes A to be added as incomplete in
A/B; it becomes complete at step 6. I'm not sure whether the alter-dir
for A that deletes a child causes anything to be marked.
There are two potential problems here:
* We make an edit within subtree A (the “move-away A/B”) before moving A
* The “alter-dir A” is performed twice
In this case there is no need to perform alter-dir on A twice.
As you pointed out when a copy replaces a mv-away it is still necessary
to alter-dir two different nodes at the same path:
1. alter-dir A (children={...})
2. mv-away A (id=...)
3. copy A (src=...)
4. alter-dir A (children={...})
[...]
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Ev2 alter_directory deltas
Philip Martin wrote: Julian Foad julianf...@btopenworld.com writes: Philip Martin wrote: [Conceivably the RA implementation of the current Ev2 API could deltify the list sent back by caching the list received but that's horrible and doesn't solve the problem of getting the list in the first place.] Why is this different from the delta-transmission of file content? The principle of Ev2 is to describe changes in terms of the new state is Y at the API level, and to leave deltification to be arranged between the producer implementation and the consumer implementation. Why cannot properties be handled this way, and why cannot (or should not) children-lists be handled this way? For this operation svn cp http://host/repo/trunk ^/branches/foo I don't see how to avoid the having the server transmit the existing children-list to the client. Ev2 has introduced that inefficiency. I can see that with caching we could implement some sort of delta for sending the children-list back to the server, but even that looks ugly. Does the RA layer cache every children-list received? Does the client provide a callback for the RA layer to cache and retrieve children-lists. A cheap branch operation which transfers a few dozen bytes in Ev1 (plus a few thousand bytes for HTTP headers) will have to transfer Megabytes with Ev2. Right, I understand your use case now, and agree. The root of the problem, as I recall, is the WC DB requirement that, before updating the DB entry for directory DIR to revision REV, there must be child entries in the DB corresponding to (at least) all the children of DIR@REV in the repository. I'm not 100% sure about that requirement. I recall something about how by doing this we could avoid marking the directory itself as incomplete but only mark its new children as incomplete, and this was considered to be a good thing. From that requirement we extended and derived a requirement for Ev2 that an alter-directory(children=X) must be issued before any calls that change the list of children. At first sight, that rule seems to fit well with the principle of the Once Rule, if we assume that a typical receiver (WC or repository) will treat a directory node as an object that contains a list of children, and will want to update it in one shot. However, it may not actually be as good a fit as it seems. A repository will probably need more information than simply a list of child names: it will want to know the corresponding node ids, and it won't know them until any copies, adds come in. So we should be careful about assuming this alter-dir is necessarily useful. There are any number of ways we could change things. I don't currently have a strong enough handle on the exact reasoning to be able to suggest the best course of action. - Julian
Re: fsfs-improvements branch complete
On Tue, Aug 13, 2013 at 2:13 PM, Philip Martin philip.mar...@wandisco.comwrote: Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes: After two weeks now, I finally completed the fsfs format 6 refactoring and improvement work on said branch. Please review. See also http://svn.haxx.se/dev/archive-2013-07/0385.shtml for the split up fs_fs.c part of it. If there are no objections, I will merge the code in the week of Aug 26th. I've read through all the commits and I'm happy for it to be merged. Thank you very much for the review! -- Stefan^2.
Re: Ev2 using move-away and move-here
Philip Martin wrote:
[...]
=== Examples Solved ===
Example 1:
| |
+--A mv--\ add-- +--A
\ |
\-- +--B
1. alter-dir / (children={A})
Do we need to call alter-dir when a child is replaced or only when a
child is added/removed? If we look at the working copy update receiver
it wants to record incomplete for adds but probably does nothing for
replaces, it may not even do anything for deletes preferring to leave it
to the delete call.
The exact definition of the requirement for calling alter_directory() is part
of the discussion in the thread Ev2 alter_directory deltas, to which I have
just replied.
- Julian
2. mv-away A (id=“original A”)
3. add-directory A (children={B})
4. mv-here A/B (id=“original A”)
RE: svn commit: r1512354 - in /subversion/trunk: ./ subversion/bindings/javahl/native/ subversion/bindings/javahl/src/org/apache/subversion/javahl/ subversion/bindings/javahl/src/org/apache/subversion
-Original Message- From: br...@apache.org [mailto:br...@apache.org] Sent: vrijdag 9 augustus 2013 17:53 To: comm...@subversion.apache.org Subject: svn commit: r1512354 - in /subversion/trunk: ./ subversion/bindings/javahl/native/ subversion/bindings/javahl/src/org/apache/subversion/javahl/ subversion/bindings/javahl/src/org/apache/subversion/javahl/util/ subversion/bindings/javahl/tests/org/apach... Author: brane Date: Fri Aug 9 15:52:34 2013 New Revision: 1512354 URL: http://svn.apache.org/r1512354 Log: Expose utility functions in JavaHL. Start by providing a file-based merge tool. * build.conf (private-built-includes): Add org_apache_subversion_javahl_util_DiffLib.h. (javahl-java): Add ...javahl/util and reorder modules alphabetically. (javahl-callback-javah, javahl-remote-javah, javahl-callback-javah): Reorder modules alphabetically. (javahl-util-javah): New module. * Makefile.in (javahl): Add javahl-remote-javah and javahl-util-javah. (doc-javahl): Add org.apache.subversion.javahl.util. [in subversion/bindings/javahl/src/org/apache/subversion/javahl] * SVNUtil.java: New Java class SVNUtil. (SVNUtil.DiffOptions): New nested class. (SVNUtil.ConflictDisplayStyle): New nested enumeration. (SVNUtil.FileMerge): New static methods. * util/DiffLib.java: New Java class util.DiffLib. [in subversion/bindings/javahl/native] * org_apache_subversion_javahl_util_DiffLib.cpp: Native method wrappers for the util.DiffLib class. (Java_org_apache_subversion_javahl_util_DiffLib_nativeFileMerge): Native implementation of util.DiffLib.FileMerge. [in subversion/bindings/javahl/tests/org/apache/subversion/javahl] * UtilTests.java: New test suite for the SVNUtil class. (UtilTests.testFileMerge): New test case. * RunTests.java: Add UtilTests to the test suite list. This patch causes compilation failures on the Ubuntu gcc buildbot [[ /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:31: error: package org.junit does not exist import org.junit.Assert; ^ /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:110: error: cannot find symbol Assert.assertArrayEquals(expected, result.toByteArray()); ^ symbol: variable Assert location: class UtilTests ]] And on the Windows buildbot: [[ D:\svn-w2k3-local\slik-w2k3-x64-local\build\subversion_vcnet.sln (__JAVAHL__;__JAVAHL_TESTS__;__SWIG_PERL__;__SWIG_RUBY__ target) (1) - (Libraries\libsvnjavahl target) - ..\..\..\subversion\bindings\javahl\native\org_apache_subversion_javahl_util_DiffLib.cpp(27): fatal error C1083: Cannot open include file: '../include/org_apache_subversion_javahl_util_DiffLib.h': No such file or directory ]] Bert
Re: Ev2 using move-away and move-here
Julian Foad julianf...@btopenworld.com writes:
As you pointed out when a copy replaces a mv-away it is still necessary
to alter-dir two different nodes at the same path:
1. alter-dir A (children={...})
2. mv-away A (id=...)
3. copy A (src=...)
4. alter-dir A (children={...})
Well, that depends. There may be no need to issue the alter-dir on
the original 'A' at this stage, we could wait until it arrives at its
final path (move-here B (id=original A), then alter-dir B).
I was initially thinking that we could require alter-dir to happen
before mv-away, then the alter-dir path would always be a path in the
original tree. However that doesn't work for copies where alter-dir has
to happen after the copy, or for moves from copies where, even if
alter-dir happens before the move, the path is still not a path in the
original tree.
So we have to allow
copy A B
alter-dir B (children={...})
which means there is little reason to require
alter-dir X (children={...})
mv-away X (id=original X)
mv-here Y (id=original X)
and prohibit
mv-away X (id=original X)
mv-here Y (id=original X)
alter-dir Y (children={...})
Another issue, there can be mv-aways inside copies and that allows
multiple mv-away at the same path:
svn cp X A
svn mv A/B/C C1
svn rm A/B
svn cp Y A/B
svn mv A/B/C C2
Here we have two mv-aways for A/B/C, one for the C copied from X/B/C and
one for the C copied from Y/C.
alter-dir / (children={..., C1, C2})
copy X A
mv-away A/B/C (id=something)
mv-here C1 (id=something)
copy Y A/B (replaces=...)
mv-away A/B/C (id=something else)
mv-here C2 (id=something else)
We can't use the source of the copy to make things unique either as that
could be copied more than once.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: Ev2 using move-away and move-here
On 14 Aug 2013 16:23, Julian Foad julianf...@btopenworld.com wrote: Branko Čibej wrote: and also makes validating the drive easier. I'm not sure what you're thinking about validating the editor drive being easier. - Julian Move away without a matching moved here (or the converse) is clearly invalid. It must be trivial for the receiver to detect that. Making the temporary locations explicit makes that so much easier. Regarding direct move without intermediate state, IMO the driver should be required to to use that whenever it can. Driver always has enough info to know that receiver can process such a move. If it cannot, that indicates a bug in the driver.
RE: svn commit: r1512354 - in /subversion/trunk: ./ subversion/bindings/javahl/native/ subversion/bindings/javahl/src/org/apache/subversion/javahl/ subversion/bindings/javahl/src/org/apache/subversion
The org.junit bits are in my junit-4.10.jar. I have no idea why the Windows bot doesn't run javah for the new module, but I recall seeing that before and suspect it's a bug in the bot's build script. On 14 Aug 2013 16:58, Bert Huijben b...@qqmail.nl wrote: -Original Message- From: br...@apache.org [mailto:br...@apache.org] Sent: vrijdag 9 augustus 2013 17:53 To: comm...@subversion.apache.org Subject: svn commit: r1512354 - in /subversion/trunk: ./ subversion/bindings/javahl/native/ subversion/bindings/javahl/src/org/apache/subversion/javahl/ subversion/bindings/javahl/src/org/apache/subversion/javahl/util/ subversion/bindings/javahl/tests/org/apach... Author: brane Date: Fri Aug 9 15:52:34 2013 New Revision: 1512354 URL: http://svn.apache.org/r1512354 Log: Expose utility functions in JavaHL. Start by providing a file-based merge tool. * build.conf (private-built-includes): Add org_apache_subversion_javahl_util_DiffLib.h. (javahl-java): Add ...javahl/util and reorder modules alphabetically. (javahl-callback-javah, javahl-remote-javah, javahl-callback-javah): Reorder modules alphabetically. (javahl-util-javah): New module. * Makefile.in (javahl): Add javahl-remote-javah and javahl-util-javah. (doc-javahl): Add org.apache.subversion.javahl.util. [in subversion/bindings/javahl/src/org/apache/subversion/javahl] * SVNUtil.java: New Java class SVNUtil. (SVNUtil.DiffOptions): New nested class. (SVNUtil.ConflictDisplayStyle): New nested enumeration. (SVNUtil.FileMerge): New static methods. * util/DiffLib.java: New Java class util.DiffLib. [in subversion/bindings/javahl/native] * org_apache_subversion_javahl_util_DiffLib.cpp: Native method wrappers for the util.DiffLib class. (Java_org_apache_subversion_javahl_util_DiffLib_nativeFileMerge): Native implementation of util.DiffLib.FileMerge. [in subversion/bindings/javahl/tests/org/apache/subversion/javahl] * UtilTests.java: New test suite for the SVNUtil class. (UtilTests.testFileMerge): New test case. * RunTests.java: Add UtilTests to the test suite list. This patch causes compilation failures on the Ubuntu gcc buildbot [[ /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:31: error: package org.junit does not exist import org.junit.Assert; ^ /var/lib/buildbot/svn-buildslave/svn-x64-ubuntu/build/subversion/bindings/javahl/tests/org/apache/subversion/javahl/UtilTests.java:110: error: cannot find symbol Assert.assertArrayEquals(expected, result.toByteArray()); ^ symbol: variable Assert location: class UtilTests ]] And on the Windows buildbot: [[ D:\svn-w2k3-local\slik-w2k3-x64-local\build\subversion_vcnet.sln (__JAVAHL__;__JAVAHL_TESTS__;__SWIG_PERL__;__SWIG_RUBY__ target) (1) - (Libraries\libsvnjavahl target) - ..\..\..\subversion\bindings\javahl\native\org_apache_subversion_javahl_util_DiffLib.cpp(27): fatal error C1083: Cannot open include file: '../include/org_apache_subversion_javahl_util_DiffLib.h': No such file or directory ]] Bert
Re: man pages for Subversion
12 aug 2013 kl. 12.38 skrev Julian Foad: Hi James. I have one thing to throw into the mix, which you might be interested in looking at. I experimented a few months ago with generating both the C help strings and man pages from an XML source file. My patch to do this is attached; it is complete and and usable, although not finished or quite how I would want it. How about including the marked-up source in the svn binary (as C constant strings) and do the rendering at run time, when the user does svn help? Otherwise, it would be tricky to handle translations properly - the translator must work on the marked-up text and it should be possible to try out new translations without rebuilding the binaries. This has the extra benefit of allowing the help text to be rendered to the width of the terminal and to (optionally) use terminal effects such as bold and underline. The original could either live in a separate file, as in your patch, or as actual C constants. In any case, it probably makes things a lot easier for the translators if the text appears as strings in the same subversion.pot as everything else. (Personally I would prefer something more light-weight than XML, but perhaps it would give you an excuse to allow the --xml flag with svn help.)
Re: localisation: status, migration to pootle
8 aug 2013 kl. 20.39 skrev Daniel Shahaf: Should we retroactively send a round of Hey, 1.8.x has been released, please update translations on trunk and 1.8.x ? That is probably a good idea, and since it isn't going to happen by itself, I shall do that myself this time. This does not mean that it is a duty that I am prepared to assume for future releases at this point -- sorry. Since many translations currently need substantial work, it is not reasonable to ask you to hold the release of 1.8.2 awaiting completions to drop in. Rather, translation updates could be ground for subsequent point releases in 1.8.x. Can you update docs/community/releasing.part.html or roadmap.html with a reminder to consider sending a Call For Translations to translators? Since people seemed to have a preference for automating it via release scripts, I'm going to let someone more familiar with that process and framework to deal with it.
Re: localisation: status, migration to pootle
On Wed Aug 14 12:26:34 2013, Mattias Engdegård wrote: Since people seemed to have a preference for automating it via release scripts, I'm going to let someone more familiar with that process and framework to deal with it. It would be better to put something in the docs now and then we can automate later.
export fails without error for file externals
Hi, The following command fails without an error: $ svn export -rBASE fileexternal exportedfile with 'fileexternal' being an svn:external to a file. Shouldn't that at least report an error that nothing is done at all instead of just exit silently? Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest interface to (Sub)version control /_/ \_\ http://tortoisesvn.net
Re: localisation: status, migration to pootle
14 aug 2013 kl. 21.37 skrev Ben Reser: It would be better to put something in the docs now and then we can automate later. Would this do? [[ * publish/docs/community-guide/releasing.part.html, publish/docs/community-guide/releasing.toc.html: Add section about notifying translators. ]] Index: publish/docs/community-guide/releasing.part.html === --- publish/docs/community-guide/releasing.part.html(revision 1514020) +++ publish/docs/community-guide/releasing.part.html(arbetskopia) @@ -689,6 +689,26 @@ title=Link to this sectionpara;/a /h2 +div class=h3 id=notify-translators +h3Notify translators + a class=sectionlink href=!--#echo var=GUIDE_RELEASING_PAGE --#notify-translators +title=Link to this sectionpara;/a +/h3 + +pBefore the actual release, send an e-mail to the translators to +request updates of the tt.po/tt files. Take their e-mail addresses +from the ttCOMMITTERS/tt file in trunk./p + +pThis should be done after all localised strings have stabilised in +their final form for the release, but sufficiently in advance of the +actual release to allow the translators to do their work. As a rule of +thumb, send the notification at the least one week, preferably more, +prior to the intended release. If many strings have changed, as would +be the case for the first release from a new branch, then let more +time pass./p + +/div !-- notify-translators -- + div class=h3 id=before-release h3Preparing to roll a release a class=sectionlink href=!--#echo var=GUIDE_RELEASING_PAGE --#before-release Index: publish/docs/community-guide/releasing.toc.html === --- publish/docs/community-guide/releasing.toc.html (revision 1514020) +++ publish/docs/community-guide/releasing.toc.html (arbetskopia) @@ -10,6 +10,7 @@ /ul lia href=#release-creatingCreating a Subversion release/a/li ul +lia href=#notify-translatorsNotify translators/a/li lia href=#before-releasePreparing to roll a release/a/li lia href=#rolling-releaseRolling a release/a/li lia href=#tarball-signingSigning source distribution packages (a.k.a tarballs)/a/li @@ -36,6 +37,7 @@ /ul lia href=releasing.html#release-creatingCreating a Subversion release/a/li ul +lia href=releasing.html#notify-translatorsNotify translators/a/li lia href=releasing.html#before-releasePreparing to roll a release/a/li lia href=releasing.html#rolling-releaseRolling a release/a/li lia href=releasing.html#tarball-signingSigning source distribution packages (a.k.a tarballs)/a/li
Re: man pages for Subversion
On 14 aug 2013, at 20:47, Mattias Engdegård matti...@bredband.net wrote: 12 aug 2013 kl. 12.38 skrev Julian Foad: Hi James. I have one thing to throw into the mix, which you might be interested in looking at. I experimented a few months ago with generating both the C help strings and man pages from an XML source file. My patch to do this is attached; it is complete and and usable, although not finished or quite how I would want it. How about including the marked-up source in the svn binary (as C constant strings) and do the rendering at run time, when the user does svn help? Otherwise, it would be tricky to handle translations properly - the translator must work on the marked-up text and it should be possible to try out new translations without rebuilding the binaries. Is that possible today? This has the extra benefit of allowing the help text to be rendered to the width of the terminal and to (optionally) use terminal effects such as bold and underline. Given the verbosity of some help texts I definitely think the source format should not care about terminal width. It must be a major pain to translate given the line breaks? Whether the line breaks are introduced during runtime or build matters less, but the later the better. The original could either live in a separate file, as in your patch, or as actual C constants. In any case, it probably makes things a lot easier for the translators if the text appears as strings in the same subversion.pot as everything else. (Personally I would prefer something more light-weight than XML, but perhaps it would give you an excuse to allow the --xml flag with svn help.) Many recently developed software frameworks define their strings in XML because: a) translation processes are well defined for XML, in a larger perspective since almost all documentation is done in XML (ok, not a great driver in this project except keeping svnbook up to date) b) XML is so easy to transform into multiple distribution formats. I know there is a lot of resistance toward the heavy-weight XML, but authoring is actually where XML excels (as opposed to data interchange where lighter formats can be preferred). Cheers, Thomas Å.
Re: Syntax for templated SVNPath
On 14 aug 2013, at 03:25, Ben Reser b...@reser.org wrote:
On 8/13/13 4:41 PM, Thomas Åkesson wrote:
To make this enhancement complete, I believe all settings that take a
directory-path should be handled identically (allow the templating). To
me, the most obvious example is AuthzSVNAccessFile. It wouldn't make sense
to separate repositories for different vhosts but keep a single huge access
file.
This probably isn't what you're thinking of but
AuthzSVNReposRelativeAccessFile has been around since 1.7:
http://subversion.apache.org/docs/release-notes/1.7.html#per-repos-authz
I know, and yes, it can be used with this enhancement in form 2 and 4, but not
in form 1 and 3.
Agree, duplicating the directives is not the way to go. But deprecating
SVNParentPath seems a bit over the top. SVNPath vs SVNParentPath are 2 quite
distinct modes of operation and many many configs use them so I get the
feeling SVNParentPath can't be removed for a long time anyway.
I propose either of:
1. SVNPathTemplates on | off
2. SVNPathType default | template | ...
Where the option applies to all SVN* options that take a pathspec, including
the authz options.
My vote is to technically eliminate SVNParentPath (though it would still
be accepted, but we'd just treat it the same as SVNPath). svnserve
supports pointing things directly at the repository and at a parent
paths without the user needing to specify this, I can't see any reason
httpd needs this extra verbosity.
Ok
Further, I don't see a reason to toggle templates on or off. When we
added in repos authz I didn't worry about someone having a relative path
with starting with file: or ^, both of which would have been broken.
By the same account I don't think path names like %{SERVER_NAME} or %0
are worth worrying about.
Yes, I agree with that. There really is no reason to have '%' characters in the
path on servers. Minimal option proliferation... (None)
Adding the verbosity only helps someone doing something that probably
doesn't make any sense and hurts the vast majority.
I would like to throw in a related issue that I was thinking about while
studying the release notes of svn 1.8. We (Simonsoft) are _very_ exited
about the In repository authz. In our setups, the access file (currently
one per server) is managed in a separate repository, but we have to manually
ensure the latest one is on disk (svn up). All our servers have an admin
repo containing server config including the access file.
We would like to transition to:
- Separate access file for each repo.
- Separate groups file (AuthzSVNGroupsFile)
- Keep access files in admin repo.
- Reference the access/group files using file://...
However, there is a problem with referencing separate access files that way
when using SVNParentPath. We would need the same templating concept:
file:///path/to/admin-repo/%{REPO_NAME}/file
or
file:///path/to/%{SERVER_NAME}/admin-repo/%{REPO_NAME}/file
This is somewhat out of scope for this discussion, but still a validation
that the templating syntax can also address this limitation.
I remember thinking about doing this and decided not to. I don't really
see a huge problem with doing this.
Good
While I like the human readable variable names like %{SERVER_NAME}, I do
wonder if we shouldn't make our virtual hosting patterns match that of
the mod_vhost_alias does, I can see at least some of the hostname
splitting being useful. I can also see someone using dynamic svn
virutal hosting also using mod_vhost_alias for websites. So some
existing domain knowledge could be reused by users.
The mod-vhost syntax is not quite as future proof though. I personally prefer
the mod-ssl syntax that Mike went with.
If we use human readable variable names REPO_NAME should be
SVN-REPOS-NAME to match what we're using to allow logging. e.g.
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.logging
Makes sense.
Regards,
Thomas Å.
Re: localisation: status, migration to pootle
On Wed Aug 14 13:49:17 2013, Mattias Engdegård wrote: Would this do? [[ * publish/docs/community-guide/releasing.part.html, publish/docs/community-guide/releasing.toc.html: Add section about notifying translators. ]] +1, please go ahead and commit.
Re: [PATCH] add support for svnrdump to svn-backup-dumps.py
Hello (2013/08/08 22:47), C. Michael Pilato wrote: On 08/08/2013 09:40 AM, Daniel Shahaf wrote: On Thu, Aug 08, 2013 at 09:26:09AM -0400, C. Michael Pilato wrote: This tells the options parser that there are no command-line options which follow, which would keep self.__repospath from being treated as an option in the unlikely scenario that it begins with a hyphen. I added -- to the command line options. [[[ add support for svnrdump to svn-backup-dumps.py * tools/server-side/svn-backup-dumps.py () : fix comment () : update to ver 0.7 () : import urlparse (SvnBackup.__init__) : fix message in SvnBackupException constructor. (SvnBackup.__init__) : check whether the second parameter is a local path or an URL. (SvnBackup.__init__) : check whether --deltas option is specified when the second parameter is an URL. (SvnBackup.__init__) : set svn and svnrdump paths. (SvnBackup.__init__) : set flags for --trust-server-cert and --no-auth-cache. (SvnBackup.exec_cmd_nt) : open null device and pass it to Popen when printerr is False. (SvnBackup.get_extra_param) : get extra option for svn and svnrdump. always pass --non-interactive to svn and svnrdump to make sure. (SvnBackup.get_head_rev) : rename this to get_head_rev_for_local. (SvnBackup.get_head_rev_for_url) : get HEAD revision for an URL. (SvnBackup.get_head_rev) : call get_head_rev_for_local for a local path, get_head_rev_for_url for an URL (SvnBackup.transfer_smb): pass self.__print_stderr to self.exec_cmd(). (SvnBackup.create_dump) : invoke svnadmin for a local path, svnrdump for an URL. (SvnBackup.create_dump) : pass -- before self.__repospath. () : fix help message. () : add --svnrdump-path and --svn-path. () : add --trust-server-cert. () : add --no-auth-cache. () : add --non-interactive. () : add --print-stderr. ]]] -- Masaru Tsuchiyama m.tma...@gmail.com Index: tools/server-side/svn-backup-dumps.py === --- tools/server-side/svn-backup-dumps.py (revision 1514160) +++ tools/server-side/svn-backup-dumps.py (working copy) @@ -45,10 +45,10 @@ # # 1. Create a full dump (revisions 0 to HEAD). # -#svn-backup-dumps.py repos dumpdir +#svn-backup-dumps.py repos or URL dumpdir # -#repos Path to the repository. -#dumpdirDirectory for storing the dump file. +#repos or URL Path or URL to the repository. +#dumpdir Directory for storing the dump file. # #This creates a dump file named 'src.00-NN.svndmp.gz' #where NN is the revision number of HEAD. @@ -56,11 +56,11 @@ # # 2. Create incremental dumps containing at most N revisions. # -#svn-backup-dumps.py -c count repos dumpdir +#svn-backup-dumps.py -c count repos or URL dumpdir # -#count Count of revisions per dump file. -#repos Path to the repository. -#dumpdirDirectory for storing the dump file. +#countCount of revisions per dump file. +#repos or URL Path or URL to the repository. +#dumpdir Directory for storing the dump file. # #When started the first time with a count of 1000 and if HEAD is #at 2923 it creates the following files: @@ -77,11 +77,11 @@ # # 3. Create incremental single revision dumps (for use in post-commit). # -#svn-backup-dumps.py -r revnr repos dumpdir +#svn-backup-dumps.py -r revnr repos or URL dumpdir # -#revnr A revision number. -#repos Path to the repository. -#dumpdirDirectory for storing the dump file. +#revnrA revision number. +#repos or URL Path or URL to the repository. +#dumpdir Directory for storing the dump file. # #This creates a dump file named 'src.NN.svndmp.gz' where #NN is the revision number of HEAD. @@ -89,10 +89,10 @@ # # 4. Create incremental dumps relative to last dump # -#svn-backup-dumps.py -i repos dumpdir +#svn-backup-dumps.py -i repos or URL dumpdir # -#repos Path to the repository. -#dumpdirDirectory for storing the dump file. +#repos or URL Path or URL to the repository. +#dumpdir Directory for storing the dump file. # #When if dumps are performed when HEAD is 2923, #then when HEAD is 3045, is creates these files: @@ -105,7 +105,7 @@ # #svn-backup-dumps.py -z ... # -#... More options, see 1-4, 7, 8. +#...More options, see 1-4, 7, 8. # # # 6. Create bzipped dump files. @@ -112,7 +112,7 @@ # #svn-backup-dumps.py -b ... # -#... More options, see 1-4, 7, 8. +#...More options, see 1-4, 7, 8. # # # 7. Transfer the dumpfile to another host using ftp. @@ -119,11 +119,11 @@ # #
