Re: Ev2 using move-away and move-here

[Julian Foad]

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"  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

[Philip Martin]

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

[Julian Foad]

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

[Philip Martin]

Julian Foad  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

[Philip Martin]

Greg Stein  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

[Branko Čibej]

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

[Philip Martin]

Julian Foad  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

[Julian Foad]

Philip Martin wrote:

> Julian Foad  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

[Stefan Fuhrmann]

On Tue, Aug 13, 2013 at 2:13 PM, Philip Martin
wrote:

> Stefan Fuhrmann  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

[Julian Foad]

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: Ev2 using move-away and move-here

[Julian Foad]

Branko Čibej wrote:

> 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,
I think what you're saying is that, in cases where the driver can issue a 
move(a,b) instead of a (functionally equivalent) pair of move-away immediately 
followed by move-here, then the receiver is likely to be able to process that 
single move more efficiently.  So having the three methods available is better 
than just having the latter two.

Do I understand you correctly?

We should probably just leave it as a "quality of implementation" issue for the 
editor driver to prefer single move(a,b) instructions over pairs of move-away, 
move-here.  We could try to come up with a requirement that it must do so in 
certain cases (starting with collapsing adjacent pairs of move-away, 
move-here), but I think this may be rather difficult to define fully and hard 
to justify.

> and also makes validating the drive easier.

I'm not sure what you're thinking about validating the editor drive being 
easier.
- Julian

Re: Ev2 alter_directory deltas

[Philip Martin]

Julian Foad  writes:

> 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.

The Ev2 receiver only ever has to handle incomplete directories that are
empty and never has to handle incomplete directories with children.
This may simplify the implementation.  For example it may make it
simpler and/or more efficient to update following an interrupted update.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: Ev2 using move-away and move-here

[Julian Foad]

Philip Martin wrote:

> Julian Foad  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.

In what I wrote here, alter-dir(/) is before mv-away(A), and there are two 
calls to alter-dir(A), in steps 1 and 6, before and after mv-away(A/B).  But 
anyway, yes, it's messed up, and your suggestion below is neater.

> 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")

Yes, that's nicer.  Yes, you can probably drop the alter-dir(/) like you have 
done, on the basis that the list of child names in (/) does not change even 
though their identities do change.  That's an under-specified part of the rules.

> 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.

Right, good.

> 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).

- Julian

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

[Bert Huijben]

> -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

[Philip Martin]

Julian Foad  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

[Branko Čibej]

On 14 Aug 2013 16:23, "Julian Foad"  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

[Branko Čibej]

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"  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

[Mattias Engdegård]

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: 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

[Bert Huijben]

I think r1514012 should fix it by adding the dependency to libsvn-javahl that 
exists for all other javahl projects.

 

Bert

 

From: Branko Čibej [mailto:br...@wandisco.com] 
Sent: woensdag 14 augustus 2013 19:01
To: dev@subversion.apache.org
Subject: 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/javahl/util/ 
subversion/bindings/javahl/tests/org/apac

 

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" mailto: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: localisation: status, migration to pootle

[Mattias Engdegård]

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

[Ben Reser]

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

[Stefan Küng]

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

[Mattias Engdegård]

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 section">¶
 
 
+
+Notify translators
+  #notify-translators"
+title="Link to this section">¶
+
+
+Before the actual release, send an e-mail to the translators to
+request updates of the .po files. Take their e-mail addresses
+from the COMMITTERS file in trunk.
+
+This 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.
+
+ 
+
 
 Preparing to roll a release
   #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 @@
   
 Creating a Subversion release
   
+Notify translators
 Preparing to roll a release
 Rolling a release
 Signing source distribution packages (a.k.a 
tarballs)
@@ -36,6 +37,7 @@
   
 Creating a Subversion 
release
   
+Notify translators
 Preparing to roll a 
release
 Rolling a release
 Signing source distribution 
packages (a.k.a tarballs)

Re: man pages for Subversion

[Thomas Åkesson]

On 14 aug 2013, at 20:47, Mattias Engdegård  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

[Thomas Åkesson]

On 14 aug 2013, at 03:25, Ben Reser  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

[Ben Reser]

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

[Masaru Tsuchiyama]

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 



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  
+#svn-backup-dumps.py  
 #
-#  Path to the repository.
-#Directory for storing the dump file.
+# Path or URL to the repository.
+#  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   
+#svn-backup-dumps.py -c   
 #
-#  Count of revisions per dump file.
-#  Path to the repository.
-#Directory for storing the dump file.
+#Count of revisions per dump file.
+# Path or URL to the repository.
+#  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   
+#svn-backup-dumps.py -r   
 #
-#  A revision number.
-#  Path to the repository.
-#Directory for storing the dump file.
+#A revision number.
+# Path or URL to the repository.
+#  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  
+#svn-backup-dumps.py -i  
 #
-#  Path to the repository.
-#Directory for storing the dump file.
+# Path or URL to the repository.
+#  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 @@
 #
 #svn-backup-dumps.py -t ftp ...
 #
-#   Name of the FTP host.
-#   Username on the remote host.
-#   Password for the user.
-#   Subdirectory on the remote host.
-#...  More options, see 1-6.
+# Name of the FTP host.
+# Username on the remote h

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

[Branko Čibej]

On 14.08.2013 21:20, Bert Huijben wrote:
>
> I think r1514012 should fix it by adding the dependency to
> libsvn-javahl that exists for all other javahl projects.
>

Thanks, Bert. I missed that, going to bang my head against the wall now ...

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: [PATCH] add support for svnrdump to svn-backup-dumps.py

[Masaru Tsuchiyama]

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 




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  
+#svn-backup-dumps.py  
 #
-#  Path to the repository.
-#Directory for storing the dump file.
+# Path or URL to the repository.
+#  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   
+#svn-backup-dumps.py -c   
 #
-#  Count of revisions per dump file.
-#  Path to the repository.
-#Directory for storing the dump file.
+#Count of revisions per dump file.
+# Path or URL to the repository.
+#  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   
+#svn-backup-dumps.py -r   
 #
-#  A revision number.
-#  Path to the repository.
-#Directory for storing the dump file.
+#A revision number.
+# Path or URL to the repository.
+#  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  
+#svn-backup-dumps.py -i  
 #
-#  Path to the repository.
-#Directory for storing the dump file.
+# Path or URL to the repository.
+#  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 @@
 #
 #svn-backup-dumps.py -t ftp ...
 #
-#   Name of the FTP host.
-#   Username on the remote host.
-#   Password for the user.
-#   Subdirectory on the remote host.
-#...  More options, see 1-6.
+# Name of the FTP host.
+#  

Re: man pages for Subversion

[Branko Čibej]

On 14.08.2013 23:42, Thomas Åkesson wrote:
>
> On 14 aug 2013, at 20:47, Mattias Engdegård  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?

Of course. You can, for example, take an installed Subversion and
replace one of its .mo files, and it'll pick up the new translations.

If that doesn't work, I'd like to know about it because it'd be a
serious bug in how we use gettext.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: localisation: status, migration to pootle

[Lorenz]

Daniel Shahaf wrote:

>Mattias Engdegård wrote on Wed, Aug 07, 2013 at 23:43:36 +0200:
>> 2 aug 2013 kl. 21.27 skrev Andreas Stieger:
>>
>>> I would like to hear from active translation maintainers if they are
>>> happy to move their respective translations into Pootle and work on  
>>> that
>>> system. If so I am willing to coordinate the import, even if just for
>>> trying it out. With sufficient support from active translation
>>> maintainers we can bring all languages in.
>>
>> Sorry about the late reply; I rarely have time to read the development  
>> list. It seems unlikely that many translators do - how are they notified 
>> about the need to update their translations? It is common to have this as 
>> an explicit step in the release process; perhaps I have missed the 
>> broadcasts so far.
>>
>
>We don't have such a step.  I don't know if such announcements have been
>sent, but .de translator Jens Seidel also expressed interest in having
>such --- so perhaps we [c|sh]ould do that in the future.

TSVN has a weekly translation status report on dev & user lists
-- 

Lorenz

Re: [PATCH] fix exception running gen-make.py

[Masaru Tsuchiyama]

(2013/08/08 0:15), Daniel Shahaf wrote:

masaru tsuchiyama wrote on Thu, Aug 01, 2013 at 00:11:30 +0900:

* gen-make.py
() : use default value as conf when args[0] is line ending.


I don't use windows, but I think the right fix in this case is to
prevent ("\n" in sys.argv) from becoming true in the first place.



Fixed my patch.

[[[
add error check for eol.

* gen-make.py
  () : print error message and exit if args[0] is eol
]]]


--
Masaru Tsuchiyama 
Index: gen-make.py
===
--- gen-make.py (revision 1514179)
+++ gen-make.py (working copy)
@@ -278,6 +278,9 @@ if __name__ == '__main__':
   except getopt.GetoptError, e:
 _usage_exit(str(e))
 
+  if args and args[0] == '\n':
+_usage_exit("argument must not be end-of-line.")
+
   conf = 'build.conf'
   skip = 0
   gentype = 'make'