Re: Wiki migration to Confluence: test conversion ready for review

[Thomas Åkesson]

> Sorry for the noise.

No worries.


> My intention was to convert links to the "user page" in moinmoin
> (which is typically something like JohanCorveleyn, or ThomasAkesson)
> into a link to the user profile in Confluence (which would be
> [~jcorvel] in confluence wiki syntax [1]). I didn't realize that this
> is not only a link to your user page, but also a "mention", which
> generates a notification.

Very surprising. I feel Confluence has confused the meaning of ~ and @, 
especially if ~ markup is rendered as @ in the HTML view.


> In the case of those two links (mentions) to your name, I only "fixed"
> that in the latest test. Because apparently in MoinMoin your username
> is "Thomas Åkesson", while that page contains literal ThomasAkesson
> (!= username). So my first iterations didn't pick that up, and I
> thought the intention was that this should have been a link to your
> user in MoinMoin too, so I converted that (more or less manually) into
> a [~xxx] link for Confluence. Perhaps that was not what you originally
> intended?

Well, I just intended to indicate what I wrote when things started to become an 
in-wiki-dicussion. That could be a link to my user or not, does not matter.

I think it diverges from the intention when Confluence renders / treats it as a 
“mention” since that generally has the opposite semantic meaning (uncommon to 
mention yourself).

> I can simply remove that manual mapping for you (when I do
> my next iteration / final migration), no problem.

Yes, that is probably closer to the original intention. As long as it does not 
impact Confluence “Page history”.


Thanks for your great work!

Re: Wiki migration to Confluence: test conversion ready for review

[Thomas Åkesson]

> On 2018-02-27, at 23:25, Johan Corveleyn  wrote:
> 
> Johan Corveleyn  wrote:
> 
 After ironing out most of the big issues, I think the current "test
 conversion" is ready for review by a larger audience. I'd like to
 perform the final migration next Tuesday the 27th, after 21h (GMT+1),
> 
> FYI, I'm postponing this a bit, at least until Thursday. Didn't get
> around to the necessary final bits yet ...

I got an email about "mentions" in the wiki. Was that production migration or 
test? (looks like test given the Confluence space name)

In this case, the original use-case was to indicate what I wrote in MoinMoin, 
kind of the opposite of a mention. I did not use an @ before my username but 
perhaps entering a plain username in MoinMoin should be considered a mention?

I can adjust after the production migration, just a couple of places.

Which tools are you using to load data into Confluence? Just out of interest.

Thanks,
Thomas Å.

Re: Augmenting the WebDAV side of Subversion with merkle hashes for directories.

[Thomas Åkesson]

Yes, I was also about to suggest mod_rewrite. Should be possible to match on 
your secret hidden filename and return content from a “shadow” directory 
structure that only contains those files. 

You could generate those files in the shadow structure on the post-commit 
event. 

I have rewrites within the mod_dav_svn location in order to provide additional 
REST functionality on svn paths. 

Merkle-tree sounds interesting, let us know about your progress. 

/Thomas Å.

Re: translations (let's use Transifex or Pootle)

[Thomas Åkesson]

> On 16 Mar 2017, at 16:36, Bert Huijben  wrote:
> 
> For some reason Transifex doesn't want me to update Swedish 'sv' resources, 
> but does allow Swedish-Sweden 'sv_SE' rersources.

Strange, they list 'sv' as a supported:
https://www.transifex.com/explore/languages/

Being Swedish I can't think of any reason to disallow 'sv' when accepting for 
example 'de'. 

/Thomas Å. 

Re: svnpubsub as build server trigger - Jenkins

[Thomas Åkesson]

Adding some further details to this topic.I have implemented Server-Sent Events support in svnpubsub. https://www.w3.org/TR/2011/WD-eventsource-20111020/The current format is preserved and the selection is made based on the client Accept header.   Sample output for both formats can be found below. Please consider the attached patch.The next step is to verify that an existing Java library can be used to observe these events.I have successfully implemented a client in Java using Jersey by following this example, section 15.5.2.https://jersey.java.net/documentation/latest/sse.htmlAnyone interested in co-developing a Jenkins Build Trigger plugin? How is ASF infra managing build triggers?Please let me know if anyone is interested. Anyone from ASF infra on this list?Thanks,Thomas Å.$ curl -sNv http://localhost:2069/commits> GET /commits HTTP/1.1> Host: localhost:2069> User-Agent: curl/7.47.0> Accept: */*> < HTTP/1.1 200 OK< Transfer-Encoding: chunked< Date: Mon, 05 Dec 2016 16:06:05 GMT< X-Svnpubsub-Version: 1< Content-Type: application/vnd.apache.vc-notify+json< Server: TwistedWeb/16.0.0< {"svnpubsub": {"version": 1}}{"stillalive": 1480953980.875444}{"commit": {"committer": "testuser", "log": "test", "repository": "50217dbe-7a01-4030--f1baa9200a11", "format": 1, "changed": {"test/test5/": {"flags": "A  "}}, "date": "2016-12-05 16:06:29 + (Mon, 05 Dec 2016)", "type": "svn", "id": 97}}{"stillalive": 1480953995.8761}$ curl -sNv  -H "Accept: text/event-stream" http://localhost:2069/commits> GET /commits HTTP/1.1> Host: localhost:2069> User-Agent: curl/7.47.0> Accept: text/event-stream> < HTTP/1.1 200 OK< Transfer-Encoding: chunked< Date: Mon, 05 Dec 2016 16:07:41 GMT< X-Svnpubsub-Version: 1< Content-Type: text/event-stream< Server: TwistedWeb/16.0.0< event: svnpubsubdata: {"version": 1}event: stillalivedata: {"stillalive": 1480954076.285757}event: commitdata: {"committer": "testuser", "log": "test", "repository": "50217dbe-7a01-4030--f1baa9200a11", "format": 1, "changed": {"test/test6/": {"flags": "A  "}}, "date": "2016-12-05 16:08:00 + (Mon, 05 Dec 2016)", "type": "svn", "id": 98}event: stillalivedata: {"stillalive": 1480954091.286789}On 4 dec. 2016, at 13:30, Thomas Åkesson <thomas.akes...@pdsvision.se> wrote:Hi all,I have been looking into svnpubsub for a couple of use cases in our XML Authoring CMS (based on Subversion). Both use cases involve Java as client to svnpubsub.Has anyone considered developing a Jenkins Build Trigger plugin that connects to svnpubsub? Seems like the ideal way of avoiding the polling without the overhead of individual hooks.There are a couple of similar plugins to Jenkins. One uses XMPP (looks difficult to adapt to svnpubsub) and one uses AWS SQS.I have experimented with teaching svnpubsub the Server Side Events format with the objective to use an existing Java library (e.g. jersey) to observe those events with just a few lines of code. The intention is to make svnpubsub select format based on client accept header. The output would be approximately:< HTTP/1.1 200 OK< Transfer-Encoding: chunked< Date: Sun, 04 Dec 2016 12:21:42 GMT< X-Svnpubsub-Version: 1< Content-Type: text/event-stream< Server: TwistedWeb/16.0.0< event: svnpubsubdata: {"version": 1}event: stillalivedata: {"stillalive": 1480854117.81563}event: stillalivedata: {"stillalive": 1480854132.816077}event: commitdata: {"committer": "testuser", "log": "", "repository": "50217dbe-7a01-4030--f1baa9200a11", "format": 1, "changed": {"repos.txt": {"flags": "U  "}}, "date": "2016-12-04 12:22:22 + (Sun, 04 Dec 2016)", "type": "svn", "id": 82}event: stillalivedata: {"stillalive": 1480854147.817536}The next step is to verify that an existing Java library can be used to observe these events.Anyone interested in co-developing a Jenkins Build Trigger plugin? How is ASF infra managing build triggers?Thanks,Thomas Å.

svnpubsub-sse_20161205.diff
Description: Binary data

Re: Merging parallel-put to /trunk

[Thomas Åkesson]

> I think that local commits are usually fast enough.  But committing over
> a high-latency network, e.g., with a transatlantic RTT of 150ms, can be
> painfully slow — see below.


Poor network connections are of course a very important concern, likely even 
more important than some additional seconds wait when committing large files on 
a perfect connection.

That said, I really don’t believe in the single-POST approach. Consider how 
that would work on a crappy connection when traveling on a train. 
TCP-connections are frequently broken, or worse, stalling. 

Going to parallel PUTs will likely address both issues:
 - Great connection: Multi core performance, very much in line with CPU 
development in recent years. Also competes better with other network traffic as 
more and more applications open many TCP-connection.
 - Poor connection: High latency, whatever, the waiting time gives more space 
for the other uploads (assuming that all parallel PUTs are not entirely in 
sync). 

Regards,
Thomas Å.

Re: Mergeinfo is not per node

[Thomas Åkesson]

On 22 jul 2014, at 13:40, Julian Foad julianf...@btopenworld.com wrote:

Hi Julian,

I happened to read this post despite not having much focus on merge 
functionality. We use Subversion for XML-authoring and we don't support 
branching/merging of trees, just files. This line of thought approaches one of 
our long-standing struggles; move tracking. The XML contains large amounts of 
hrefs to other XML files and graphics. Move/rename of individual files are 
problematic (regardless if the hrefs are relative or absolute).

 What I have been calling mergeinfo here is only part of the information we 
 need for merging. We also need a way to map nodes in the source branch to 
 nodes in the target branch, in order to apply most of the individual per-node 
 changes in the source branch to the right places on the target branch 
 before falling back to conflicts and user input where this automatic attempt 
 fails. I am starting to see this mapping as an almost completely separate 
 problem with its own metadata rather than something that the mergeinfo should 
 give us for free.

I am particularly interested in a way to map nodes in the source branch to 
nodes in the target branch. We have been thinking about an alternative to path 
when identifying a file/node in a repository. It would be interesting if a node 
received an ID when first appearing in the repository and the ID would be 
stable across move operations. Copy is debatable, but my current thinking would 
be that copies get new IDs but might in addition maintain a list of ancestry.

This is just some thoughts that we briefly considered but we have not explored 
further. 

Regards,
Thomas Å.

Re: Subversion checked-out files not indexed in Windows search

[Thomas Åkesson]

On 17 mar 2014, at 10:40, Bert Huijben b...@qqmail.nl wrote:

 
 
 -Original Message-
 From: Markus Schaber [mailto:m.scha...@codesys.com]
 Sent: maandag 17 maart 2014 10:07
 To: Jason Kresowaty; dev@subversion.apache.org
 Subject: AW: Subversion checked-out files not indexed in Windows search
 
 Hi,
 
 Von: Jason Kresowaty [mailto:ja...@binarycoder.net]
 On 3/13/2014 9:08 AM, Branko Čibej wrote:
 I understand that; it simply means that when we install a file from
 .svn/tmp into the working copy proper, we have to change that
 attribute; either before or after the file is moved into place.
 
 When this came up on ACLs, there seemed to be a lot of resistance to
 changing
 the file after it was in place. Kind of switching the subject, but if you're
 okay with changing files after they are in place, consider also propagating
 the ACL at that time too.
 
 What about first setting the ACL and attributes while the file still is in 
 the
 temp folder, and then moving the file to the final place?
 
 To what would you want to set the ACL?
 
 The code snippet posted makes the file inherit the ACL of its parent 
 directory, which in this case would be the temp directory.
 
 Which is exactly the current behavior.
 
 And updating these attributes one at a time during checkout would be huge 
 (not a small) performance killer during checkout, as both operations would be 
 updating the MFT.
 
 We should try to perform as much operations as possible while having the 
 files open anyway, as each file open (which at the kernel level includes 
 operations as setting properties) will involve virus scanners, etc.
 
 
 With the current trunk code the best solution might be to just remove the 
 setting of the 'don't index' property, as the current code already moves the 
 files in place while still open and 100% locked from indexers. 
 (Those indexers really slowed us down on Windows XP and 7 around the time 
 that we introduced this flag as the indexer opened the file between us 
 creating and moving the file)


Taking that line of thought one step further; The don't index' property should 
probably be set on 'pristine' and 'wc.db' (for completeness also on 'entries' 
and 'format') rather than on '.svn'. Notably avoiding to set/inherit that 
property on tmp. I think setting the property is quite important, particularly 
for 'pristine'.

Should solve the indexing issue but not the ACL issue. 

/Thomas Å.

Re: Lock non-existent to allow reserving a path

[Thomas Åkesson]

Thanks Philip for sharing your insight into the lock mechanisms.

Sorry about the delay, wanted to find time to investigate.


On 24 feb 2014, at 19:56, Philip Martin philip.mar...@wandisco.com wrote:

 Thomas Åkesson thomas.akes...@simonsoft.se writes:
 
 Svn does not allow locking non-existent paths. It is blocked both in
 libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same
 areas of the code in fs comments say:
 While our locking implementation easily supports the locking of
 nonexistent paths, we deliberately choose not to allow such madness.
 
 Given that we now present valid use-cases, it is reassuring that the
 authors of the locking code said it easily supports the locking of
 nonexistent paths.
 
 There is a way to create such locks at present: checkout, lock a file,
 delete the file or parent directory, commit with --no-unlock.  We have a
 regression test for this: lock_tests.py:deleted_path_lock.  (Possibly
 this behaviour could be considered a bug, perhaps 'commit --no-unlock'
 should remove the locks on deleted files, but implementing that would be
 hard.)

As discussed else-thread, should likely be considered a bug. It is not useful 
for these use cases since it requires the file to already exist. 

 
 Breakdown of changes:
 
 1. Make mod_dav_svn and fs allow locking of non-existent paths. This
 part is mandatory and I am attaching a rough patch that demonstrates
 the feasibility. With this change, the use-case 3 can be supported.
 
 This part is the most important for us, to enable our software to
 avoid race conditions btw users.
 
 It can be discussed whether it should be possible to configure the
 server to disallow these locks. I don't think they do much harm and
 configurability makes testing more complex.
 
 2. There are already functional tools to manage these locks (svnadmin
 lslocks/rmlocks/unlock and svn unlock URL). Are any improvements
 required? E.g. making svn lslocks available (remotely).
 
 3. Make the Working Copy support svn lock after svn add. This also
 requires taking care of (or blocking) some combinations with move and
 switch.
 
 The working copy is likely to be the hard bit.
 
 Probably we would want to block operations that undo the add: revert,
 move, delete, etc.  when the lock is present.  Attempting to move/remove
 the lock automatically would make these non-network operations into
 network operations.  I'm not sure exactly what behaviour would be
 acceptable here.  Do we want to prevent people reverting without network
 access?

Yes, I think we would want to block a good number of operations. If using locks 
on added files one might very well have to unlock before performing certain 
operations.

I just noticed that revert does not have a switch to release the locks. 
Actually, when reverting it is very easy to accidentally leave locks behind. It 
might make sense to never allow a revert of locked files without specifying 
either --unlock or --no-unlock.  

 
 Another tricky bit is how are update/status going to interact with these
 locks?  I think we would want the behaviour to be similar to the current
 locks.  So update will report if a lock gets broken/stolen and will
 remove the lock from the working copy.  I think this requires
 update/status to start reporting added files to the server so that the
 server can report on the locks.  That looks as if it will require
 protocol changes.

Interesting point. I agree we would want a consistent behaviour. 

Perhaps it would be an acceptable performance degradation to get a separate 
lock report when having locked added files in WC.

 
 It gets even more tricky with directories:
 
  svn mkdir wc1/A
  touch wc1/A/f
  svn add wc1/A/f
  svn lock wc1/A/f
 
  svn mkdir wc2/A
 
 The lock wc1/A/f will prevent the commit of wc2/A, or at least I think
 it will.  

Yes it does. Verified with the patch in my first post. 

This code is in fs_make_dir(..) in tree.c:
  /* Check (recursively) to see if some lock is 'reserving' a path at
 that location, or even some child-path; if so, check that we can
 use it. */ 
  if (root-txn_flags  SVN_FS_TXN_CHECK_LOCKS)
SVN_ERR(svn_fs_fs__allow_locked_operation(path, root-fs, TRUE, FALSE,
  pool));

I can't see any reason to make a recursive check for locks when doing mkdir 
(does not matter now, when locking non-existent is not allowed). Should be a 
simple change. An mkdir does not carry the same implications as a move or rmdir 
(they must of course do recursive check).

Copy is more complicated.

 svn mkdir wc1/A
 touch wc1/A/f
 svn add wc1/A/f
 svn lock wc1/A/f

 svn cp wc2/B wc2/A

Copy also checks locks recursively for to_path. Not sure if that matters now 
(when locking non-existent is not allowed). 

If allowing locking non-existent I personally think it would be fine to fail 
that copy if there are locks below (no change to current code). Otherwise we 
could investigate if the locks actually conflict

Lock non-existent to allow reserving a path

[Thomas Åkesson]

Hi,
We would like to enhance the locking in Subversion to support use cases where 
the user needs to ensure that added files will be possible to commit. There are 
a couple of use cases:

1. Adding files that are dependencies to other files, where the reference 
mechanism is cumbersome. Simple cases include XML files that reference graphics 
or XIncludes (can be difficult to refactor after a conflict, especially for 
non-technical users). More complex cases include file formats that are not open 
and where references are difficult to manage, e.g. MS Word, InDesign, certain 
modeling tools. 

2. There is a standardized naming convention based on series. The next file of 
a certain type should take the next available number. Then there is a race 
condition btw different users; how quickly can they finish work and commit 
after determining the next number and adding to WC.

One mapping towards svn usage could be:
svn up
touch model0018.xml #or create the file with the software.
svn add model0018.xml
svn lock model0018.xml
# invest effort in the new file and potentially link to it from other files.
svn commit


3. When there is other software support above svn, it also makes sense to 
reserve a path via:
svn lock http://.../model0018.xml
Then performs a programmatic commit that ensures that the lock token is 
supplied (or svn unlock URL if aborting).


Current status:

Svn does not allow locking non-existent paths. It is blocked both in 
libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same areas of the 
code in fs comments say:
While our locking implementation easily supports the locking of
nonexistent paths, we deliberately choose not to allow such madness.

Given that we now present valid use-cases, it is reassuring that the authors of 
the locking code said it easily supports the locking of nonexistent paths.

Locking an added file fails using the command line client. 

In 1.6: svn: warning: W160042: LOCK request on '/svn/repo2/newfile.txt' failed: 
405 Method Not Allowed

In 1.8: svn: E155010: The node '/Users/.../newfile.txt' was not found.


Breakdown of changes:

1. Make mod_dav_svn and fs allow locking of non-existent paths. This part is 
mandatory and I am attaching a rough patch that demonstrates the feasibility. 
With this change, the use-case 3 can be supported. 

This part is the most important for us, to enable our software to avoid race 
conditions btw users. 

It can be discussed whether it should be possible to configure the server to 
disallow these locks. I don't think they do much harm and configurability makes 
testing more complex.

2. There are already functional tools to manage these locks (svnadmin 
lslocks/rmlocks/unlock and svn unlock URL). Are any improvements required? E.g. 
making svn lslocks available (remotely). 

3. Make the Working Copy support svn lock after svn add. This also requires 
taking care of (or blocking) some combinations with move and switch.

The implementation of these parts might be dependent on whether there is wider 
interest in these use-cases. 


Proposal:

We would like to develop a patch for this functionality, tests first. I believe 
we can do tests, libsvn_fs and mod_dav_svn changes. However, we might need some 
assistance with the changes to Working copy / command line client.

The attached patch contains test coverage for the server side changes. There is 
one test for WC (currently marked XFail) and a list of ideas for additional WC 
tests. The areas I feel are most complex are related to move and switch. I 
personally don't think there is a strong need to support the combination of 
lock nonexistent with move/switch (just ensure we block those combinations). 

There is also a question of how mod_dav_svn should handle null-locks when 
communicating with generic Webdav clients. The WebDAV specification initially 
proposed support for null-locks but in later revisions moved away from them. I 
propose to keep the current zero-size-file concept for non-svn clients. There 
is already a distinction btw svn and non-svn clients in that code, I just 
tweaked it.


Thanks,
Thomas Å.



lock20140224.patch
Description: Binary data

Re: Lock non-existent to allow reserving a path

[Thomas Åkesson]

 On 24 feb 2014, at 20:36, Ben Reser b...@reser.org wrote:
 
 On 2/24/14, 8:30 AM, Thomas Åkesson wrote:
 We would like to enhance the locking in Subversion to support use cases 
 where the user needs to ensure that added files will be possible to commit. 
 There are a couple of use cases:
 
 1. Adding files that are dependencies to other files, where the reference 
 mechanism is cumbersome. Simple cases include XML files that reference 
 graphics or XIncludes (can be difficult to refactor after a conflict, 
 especially for non-technical users). More complex cases include file formats 
 that are not open and where references are difficult to manage, e.g. MS 
 Word, InDesign, certain modeling tools. 
 
 2. There is a standardized naming convention based on series. The next file 
 of a certain type should take the next available number. Then there is a 
 race condition btw different users; how quickly can they finish work and 
 commit after determining the next number and adding to WC.
 
 One mapping towards svn usage could be:
 svn up
 touch model0018.xml #or create the file with the software.
 svn add model0018.xml
 svn lock model0018.xml
 # invest effort in the new file and potentially link to it from other files.
 svn commit
 
 Why does doing the following where the empty file is always immediately 
 created
 not work for these use cases:
 svn up
 touch model0018.xml
 svn add model0018.xml
 svn ci -m'Create model0018.xml'
 svn lock model0018.xml
 
 Worst case senario for this seems to be the following.
 
 Alice and Bob are both about to make a new model file.  They select the next
 appropriate filename model0018.xml.  They both touch and add the file and then
 try to check it in.  Alice succeeds, Bob gets a message telling him his commit
 is out of date because Alice won the race.  Bob then repeats the steps from 
 the
 top (including selecting the now next available filename).
 
 I'm guessing the answer comes down to user education difficulties.

No. I simplified the use cases, too much obviously. 

Let me try again:
svn up
for several hours:
   svn add a few files
   svn lock those files
   work, including linking to those files
   revise a bit
review and perhaps svn unlock and svn rm some added files
svn commit

 
 3. When there is other software support above svn, it also makes sense to 
 reserve a path via:
 svn lock http://.../model0018.xml
 Then performs a programmatic commit that ensures that the lock token is 
 supplied (or svn unlock URL if aborting).
 
 Or maybe I'm missing something since I don't think handling this would be
 difficult in software.

It becomes complicated when:
 - we might be talking about a few hundred files, and we would prefer not to 
commit them one by one (many reasons not to)
 - it is desirable to allow the user to review the end result before commit
 - I was not only talking about automated selection of file names, could be 
combinations of manual and series. 
 - again, links btw the files

Without a locking mechanism, we would basically need a layer of temporary 
naming and linking that is resolved when attempting to commit, and retried 
until a commit succeeds without conflict. If we don't have an open file format 
that we can manipulate, well forget it. 


 
 Current status:
 
 Svn does not allow locking non-existent paths. It is blocked both in 
 libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same areas of 
 the code in fs comments say:
 While our locking implementation easily supports the locking of
 nonexistent paths, we deliberately choose not to allow such madness.
 
 Given that we now present valid use-cases, it is reassuring that the authors 
 of the locking code said it easily supports the locking of nonexistent 
 paths.
 
 Locking an added file fails using the command line client. 
 
 In 1.6: svn: warning: W160042: LOCK request on '/svn/repo2/newfile.txt' 
 failed: 405 Method Not Allowed
 
 In 1.8: svn: E155010: The node '/Users/.../newfile.txt' was not found.
 
 Yes the existing implementations make this easy to do.  But your suggested
 implementation is not the right path to go down.
 
 There is also a question of how mod_dav_svn should handle null-locks when 
 communicating with generic Webdav clients. The WebDAV specification 
 initially proposed support for null-locks but in later revisions moved away 
 from them. I propose to keep the current zero-size-file concept for non-svn 
 clients. There is already a distinction btw svn and non-svn clients in that 
 code, I just tweaked it.
 
 Yes and RFC 4918 killed lock-null resources off for good reason.  The whole
 thing was overly complicated, requiring a separate DB on the server side to
 track the non-existent paths it should pretend to exist.  Even worse if you
 wanted to support DeltaV you had to keep track of which lock-null resources
 existed when forever.  However, if you just created the empty file then all of
 this went away and there was nothing special to handle.
 
 So you can't

Re: Bug in ra_serf with client certificates

[Thomas Åkesson]

On 28 jan 2014, at 14:37, Lieven Govaerts l...@apache.org wrote:

 On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej br...@wandisco.com wrote:
 
 [Tue Jan 28 13:32:47 2014] [info] SSL Library Error: 336105671
 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return
 a certificate No CAs known to server for verification?
 
 
 The bug, as I see it, is that in this case, the command-line client doesn't
 ask for different credentials. Shouldn't we be transforming (or wrapping)
 SERF_ERROR_AUTHN_FAILED to SVN_ERR_RA_NOT_AUTHORIZED?
 
 The command line client doesn't ask for a client certificate, it
 should be defined correctly in the servers file using:
 ssl-client-cert-file
 ssl-client-cert-password

Sorry, I am late to this party. Just got confused by this statement that 
command line client does not ask.

svn info https://secure.example.com
Autentiseringsregion (realm): https://secure.example.com:443
Filnamn för klientcertifikat: 

This happened to become Swedish but the last line asks for a filename of client 
cert. This was 1.7.7 that I had on an old test machine.

Attempting this on 1.8 gives an SSL error as this thread has already stated.


Thanks,
Thomas Å.

Re: Bug in ra_serf with client certificates

[Thomas Åkesson]

On 2014-02-21, at 12:58, Bert Huijben wrote:

 
 
 -Original Message-
 From: Thomas Åkesson [mailto:tho...@akesson.cc]
 Sent: vrijdag 21 februari 2014 11:32
 To: Subversion Development
 Cc: Branko Čibej; Lieven Govaerts
 Subject: Re: Bug in ra_serf with client certificates
 
 
 On 28 jan 2014, at 14:37, Lieven Govaerts l...@apache.org wrote:
 
 On Tue, Jan 28, 2014 at 1:53 PM, Branko Čibej br...@wandisco.com
 wrote:
 
 [Tue Jan 28 13:32:47 2014] [info] SSL Library Error: 336105671
 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not
 return
 a certificate No CAs known to server for verification?
 
 
 The bug, as I see it, is that in this case, the command-line client doesn't
 ask for different credentials. Shouldn't we be transforming (or wrapping)
 SERF_ERROR_AUTHN_FAILED to SVN_ERR_RA_NOT_AUTHORIZED?
 
 The command line client doesn't ask for a client certificate, it
 should be defined correctly in the servers file using:
 ssl-client-cert-file
 ssl-client-cert-password
 
 Sorry, I am late to this party. Just got confused by this statement that
 command line client does not ask.
 
 svn info https://secure.example.com
 Autentiseringsregion (realm): https://secure.example.com:443
 Filnamn för klientcertifikat:
 
 This happened to become Swedish but the last line asks for a filename of
 client cert. This was 1.7.7 that I had on an old test machine.
 
 Attempting this on 1.8 gives an SSL error as this thread has already stated.
 
 There was a behavior change in 1.8, where the default was changed to *not 
 ask* until it is enabled in the config.
 
 See 
 http://subversion.apache.org/docs/release-notes/1.8.html#client-cert-prompt-suppression
 
 I think the reasoning was that there are servers that allow a client 
 certificate, but don't require one. In case you would have to use such a 
 server but don't have a certificate you would get the question over and over 
 again.

Ok, that clarifies Lieven's statement. It applies since 1.8. 

I don't care whether the client prompts for filename or not, but I find it 
important to provide a good error message (preferably with recommended action) 
and APIs that help Tortoise et al.

Also like, Markus' idea about recording (no-)need for certificate in auth 
cache. 

Cheers,
Thomas Å.

Re: mod_dav_svn changing the request filename - interaction with mod_rewrite

[Thomas Åkesson]

On 11 dec 2013, at 22:22, Ben Reser b...@reser.org wrote:

 On 12/11/13 10:45 AM, Ben Reser wrote:
 Hmm this is going to be a pain to fix (possibly impossible).  Because what
 mod_rewrite is doing is really hackish.  When you use the PT (PassThrough) 
 flag
 mod_rewrite puts passthrough:/my/new/URL into r-filename.  Then eventually 
 it
 moves it to r-uri, but not until after it goes through our translate_name
 hook.  So we can't reliably know if the request is going to be served by us 
 or
 not by asking for the per_dir config.
 
 Okay this isn't strictly true.  r-uri is set before it gets to us.  It's just
 that mod_rewrite doesn't trigger a new location walk (that happens after the
 map_to_storage hooks run which is the next step after the translate_name 
 hook).
 In order for mod_rewrite to work transparently the location_walk would need to
 be triggered again.

I am not very familiar with httpd internals, but I would have expected that PT 
flag would cause a completely new round of translate_name and map_to_storage 
(i.e. one round with original url and one round with rewritten url). Have you 
confirmed that is not the case? 

If it does trigger a new round, wouldn't it be fine to just do nothing if a 
PT-rewrite is detected? 

 
 We could do that on our side with something like this:
...
 
 But I really don't think we should for several reasons.
 
 First of all it starts messing with httpd internals that I don't think we
 should really need to be doing.  Note that I had to include the ap_if_walk()
 for 2.3.x+.  This sort of fix would have to forever be kept in sync with the
 code in ap_process_request_internal().  Making it rather brittle.

Yes, I can see your concern here.

 
 So at this point I think this needs to be taken to the d...@httpd.apache.org
 list.  I'll start a new thread over there.

Thanks for looking into the matter.

 None of these use cases are strictly legal.  The namespace both path wise and
 query argument wise belong to SVN.  Overlaying your own paths or query
 arguments is always going to be prone to future incompatibilities.  You've 
 just
 finally been burned.
 
 The right way to do what you've been doing is some other path like (where 
 /view
 is not configured to be handled by Subversion):
 http://svn.example.com/view/details/repo/folder
 or
 http://svn.example.com/view/repo/folder?details

We see SVN as a component in a larger context. Svn is the core versioned 
storage of our CMS-system, where we provide a number of additional services. 
Keeping consistent paths significantly reduces end-user confusion and  what we 
consider a more RESTful set of URLs. 

I do agree that the namespaces belong to SVN. We use a single parameter to 
indicate the operation/view and definitely not a single-letter one (we never 
touch the paths). A concept similar to property namespaces would be ideal, e.g. 
cms-view=details (or x-view=details similar to non-registered URL prefix).

Thanks,
Thomas Å.

mod_dav_svn changing the request filename - interaction with mod_rewrite

[Thomas Åkesson]

Hi,
Revision 1512432 causes a regression when mod_dav_svn is used together with 
mod_rewrite, which we have done successfully since Subversion 1.5. I have also 
studied the follow up commits which change the approach somewhat from setting 
filename to null into a bogus file.

Use case:
Using mod_rewrite we can serve information pages using the correct Subversion 
URL.

Example:
http://svn.example.com/svn/repo/folder/?view=details

This page might be served by PHP or other script which is located elsewhere on 
the server (say /details/index.php). By using a rewrite with PT flag this page 
can be displayed without redirecting to a separate URL. It was possible before 
1.8.3.

- In 1.8.1 works.
- In 1.8.3 the filename is set to null and we get a 404.
- In 1.8.5 the filename is set to something like 
'svn:/pathtorepositories/repo/details/'. Also 404.

The PT flag sends the rewritten URI  back through URL mapping. For some reason, 
the recently introduced hook dav_svn__translate_name is executed despite the 
rewritten URL being outside of the /svn Location. Consequently the request 
filename field is modified by mod_dav_svn.

My best guess is that the sequence becomes:
- mod_rewrite gets translate_name hook, changes the URI.
- mod_dav_svn gets translate_name hook, because it was initially expected to 
handle the request.
- renewed URL mapping finds that mod_dav_svn should not handle, selects another 
one, e.g. mod_php.
- ...

I did some searching in dev-list for discussions on these changes, but I didn't 
find much. Any recommended reading?

Perhaps the translate_name hook needs to decline in some additional situations, 
e.g. when the requested path is actually no longer going to be served by 
mod_dav_svn.

We have failed to find a workaround for this issue so it is a blocker for us to 
upgrade our production servers beyond 1.8.1.

Thanks in advance,
Thomas Å.

Re: svn commit: r1546619 - /subversion/branches/fsfs-ucsnorm/BRANCH-README

[Thomas Åkesson]

On 29 nov 2013, at 21:09, Branko Čibej br...@wandisco.com wrote:

 On 29.11.2013 20:42, Ivan Zhakov wrote:
 On 29 November 2013 22:22,  br...@apache.org wrote:
 Author: brane
 Date: Fri Nov 29 18:22:00 2013
 New Revision: 1546619
 
 URL: http://svn.apache.org/r1546619
 Log:
 * branches/fsfs-ucsnorm/BRANCH-README: New file.
 
 Added:
 subversion/branches/fsfs-ucsnorm/BRANCH-README   (with props)
 
 Added: subversion/branches/fsfs-ucsnorm/BRANCH-README
 URL: 
 http://svn.apache.org/viewvc/subversion/branches/fsfs-ucsnorm/BRANCH-README?rev=1546619view=auto
 ==
 --- subversion/branches/fsfs-ucsnorm/BRANCH-README (added)
 +++ subversion/branches/fsfs-ucsnorm/BRANCH-README [UTF-8] Fri Nov 29 
 18:22:00 2013
 @@ -0,0 +1,66 @@
 +The purpose of this [fsfs-ucsnorm] branch is to implement two optional
 +checks related to Unicode normalisation to FSFS.
 +
 +
 +Option: Prevent name collisions
 +===
 +
 +If this option is enabled, FSFS will reject operations that would
 +create two different representations of the same name in the same
 +directory. This will prevent situations where a user could see more
 +than one form of the name in a directory listing:
 Nice feature, but why in FS layer? May be it's better to implement
 this feature on svn_repos layer?
 
 It's not, for at least two reasons:
 Users of the FS API must have the same constraints as repository clients, 
 otherwise the whole thing falls on its face.
 The repos layer cannot implement this optimally; at a rough guess, it would 
 have to double the number of lookups performed:
 The node cache in an FSFS implementation detail, and this option will affect 
 how cache keys are generated.
 Likewise for actual lookups into the on-disk representation.


Just want to say that, in my opinion, the design described in BRANCH-README 
since r1546640 looks very good. 

You might remember from back when I did some specification work (in the wiki) 
that I am a strong proponent of the normalization-preserving approach to the 
problem. I believe n-p makes many issues dealing with existing repositories 
much easier to manage, in most cases go away completely unless there are 
actually normalization conflicts. E.g. the issue raised by Bert 2013-11-24 
regarding mergeinfo is not a problem with n-p (I guess without thinking too 
much about it).

Thanks for working on normalization,
/Thomas Å.

Re: man pages for Subversion

[Thomas Åkesson]

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

[Thomas Åkesson]

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: man pages for Subversion

[Thomas Åkesson]

Hi Julian et al,
I think your XML approach is the way to go in order to fulfill current and 
future requirements. A single source to keep updated is vital. XML is an ideal 
source format for HTML, PDF while plaintext (svn help), man etc should be no 
problems to sort out with XSLT. 

I was unable to find the XML or XSLT in the patch. Since the svnbook is Docbook 
I would go with that schema unless we find very specific requirements that we 
can't fulfill (usually doable with some creative use of attributes). The 
reasonable alternative, given that we prefer standards, would be DITA but that 
is a whole new level of complexity.

How is the stuff that you removed from the .c files translated? Given that 
different languages take very different amounts of space the line breaks must 
to be... well, problematic. 

Going with Docbook would enable the svnbook authors to quite easily generate a 
set of XML fragments from the svn XML. These XML fragments would be at minimum 
screen-elements and probably also some list-stuff. All of which can be 
XIncluded into the Svnbook instead of duplicated.

I can help out with schema discussions and XSLT programming (in September, 
preferably). I have a fair share of experience transforming Docbook-like 
schemas into XHTML, XSL-FO and other formats. 

regards,
Thomas Å.



On 12 aug 2013, at 12:38, Julian Foad julianf...@btopenworld.com wrote:

 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.
 
 One of my requirements was to produce C strings identical to those we have 
 now, in order to prove that it can be done and to be able to check whether 
 I've missed anything.  I invented my own XML schema and hand-wrote the XSL 
 transformations, and to be honest the XSL is ugly.  Before using a method 
 like this, I would want to change it to use a somewhat standard schema, or at 
 least a standard schema as far as possible plus our own extensions for the 
 rest.
 
 If you want to play with this patch, it applies to svn trunk as of r1456600 
 (March 2013); I haven't updated it since then.  It's integrated into the 
 build system (Unix only, so far), using xsltproc.  To create the man page, 
 use make subversion/svn/svn-help.man, and use something like (cd 
 subversion/svn  man -l svn.1) to view it.  It currently creates a single 
 man page for 'svn', listing all of the subcommands within it.
 
 
 - Julian
 
 
  
 --
 Join WANdisco's free daily demo sessions on Scaling Subversion for the 
 Enterprise
 http://www.wandisco.com/training/webinars
 
 
 
 - Original Message -
 From: James K. Lowden jklow...@schemamania.org
 To: Daniel Shahaf danie...@elego.de
 Cc: dev@subversion.apache.org
 Sent: Saturday, 10 August 2013, 4:22
 Subject: Re: man pages for Subversion
 
 On Fri, 9 Aug 2013 11:21:23 +0300
 Daniel Shahaf danie...@elego.de wrote:
 
 1.  Get the sources for 1.9 
 2.  Examine svn_cl__cmd_table
 3.  Prepare a doc build tree that creates two things:
   a.  man pages
   b.  plain text for --help, one file per subcommand
 
 The plain text filenames will have the extension .in, so a
 simple Makefile rule can convert them to .h for inclusion 
 into the
 appropriate source module.  
 
 You'd have to figure out something for windows as well, since we 
 don't
 use make that on that platform.  (Several of our dependencies do, but
 we just generate Visual Studio projects.)
 
 Hmm.  This is a sticky wicket.  
 
 My plan is to keep mdoc sources and generate plain text for
 inclusion in the help subsystem.  That's done easily with groff, see
 below.  But I notice in INSTALL you support building on Windows not only
 in a tarball but also directly in-tree.  That means the Windows
 build machine would have to be able to convert the mdoc sources to ASCII
 strings.  
 
 I'd like to point out, btw, that in 2013 this is the tail wagging the
 dog.  Windows command-line users are rare; most people use Tortoise.
 Those that do use the command line don't rely on --help very much,
 either.  Consider:
 
 $ svn propset --help | wc -l
   95
 
 and that more.exe resembles UNIX more(1) circa 1984 and that most
 Windows users don't even know it exists.  svn help on Windows is 
 not
 the model of ease of use.  
 
 Preserving --help for anything more than a short recap of the options
 isn't worth it, especially when PDFs are available!  The time is much
 better spent improving the documentation and Subversion itself.  
 
 But let us suppose ad argumentum that we want to preserve --help, and
 to support in-tree builds on Windows.  That means something has to
 convert the mdoc source to plain text.  I don't see any better way than
 to require mdocml or groff to be installed.  
 
 In general, it'll be best if you 

Re: svn commit: r1408325 - /subversion/branches/wc-collate-path/subversion/libsvn_subr/sqlite.c

[Thomas Åkesson]

On 23 jan 2013, at 02:32, Ben Reser b...@reser.org wrote:

 On Sun, Jan 20, 2013 at 12:15 PM, Thomas Åkesson tho...@akesson.cc wrote:
 I have spent quite a bit of time writing the wiki pages, experimenting, and 
 discussing with the people who have shown interest (Branko, Julian, Ben and 
 a couple of others in person at Subversion Live, London). I am very saddened 
 to see this negative attitude towards resolving this long standing issue. No 
 doubt, most Mac OS X users with non-ASCII languages are too. 
 
 We actually ended up spending a fair amount of time discussing the solution 
 to this issue after Subversion Live over dinner one night.  Branko had some 
 ideas he wanted to try and that's what his branch is.  Don't take his 
 statement that he views the branch at this point as something that will never 
 be merged back to trunk as a negative attitude towards resolving the issue.

I think Branko's work on the issue is very promising. It was the attitude of an 
other participant in the thread that I had issues with. 

I am continuing work in the wiki, doing some restructuring to better describe 
the collation approach. I will post when it is ready for review. 

Thanks,
Thomas Å. 

Re: Functional and UI spec for local moves

[Thomas Åkesson]

On 17 jan 2013, at 20:59, Julian Foad julianf...@btopenworld.com wrote:

 Ben and I recently started producing a functional and UI spec for local moves:
 
 https://wiki.apache.org/subversion/LocalMoves

I think the table in the wiki provides a well needed overview. If nothing else, 
it demonstrates the the amount of points of interaction with other commands. 

I don't have the knowledge to comment on some things, but I have a lot of 
interest in seeing move materialise. There was nothing in the wiki page that I 
have any issues with. 

 Idea: 'to' path identifies the move; 'from' path identifies any 
 replacement at that path???

That makes a lot of sense, especially considering replace. Also, it somehow 
feels consistent with how copy works today (the to-path is key). That should 
not be a constraint, but still important for end user adoption/understanding. 

Regarding revert and --force:

Yes, I think --force should be required to break the move into copy/delete. It 
would otherwise become one of those incredibly annoying mistakes. 

- If both to-path and from-path are included on svn revert, perform revert of 
the whole move. No force required. 
- If from-path has been replaced, the move can not be reverted. The replace 
must be reverted before (i.e. reverse order to how they were moved). 
- If either from-path or (exclusive) to-path is included, require force to 
break move into copy/delete. 

Most of this was just rephrasing of the wiki, except the suggestion to revert 
the move if both sides are included in the command. 

Good stuff,
Thomas Å. 

Re: Authz on Collection of Repositories

[Thomas Åkesson]

Hi Ivan,

I committed to drafting some change notes for this change quite some time ago. 

 - Below is a draft of a section to include in Release Notes. I suggest just 
after In repository authz.
 - Patch contains line for CHANGES
 - Patch contains clarification and new example for mod_authz_svn INSTALL file.

Hope I got the patch right.

Thanks,
Thomas Å.

Release notes below:

Filtering Collection of Repositories based on authz

When Apache is configured with the SVNParentPath directive, the Collection of 
Repositories list will now be filtered based on read access to the root of 
each repository. Up to now, all repositories were included in the list even if 
navigating to a repository would be forbidden. The Collection of Repositories 
will now be consistent with the directory lists within repositories. This 
provides an improved user experience by only displaying the repositories of 
interest to the user. 

The access to Collection of Repositories is not restricted by mod_authz_svn. 
In order to require authentication on this location, the location should have 
Satisfy All (default). See examples in INSTALL for mod_authz_svn for 
additional details.  

Index: subversion/mod_authz_svn/INSTALL
===
--- subversion/mod_authz_svn/INSTALL(revision 1434103)
+++ subversion/mod_authz_svn/INSTALL(working copy)
@@ -56,6 +56,12 @@ II.   Configuration
Satisfy Any
Require valid-user
  /Location
+ 
+ NOTE: The access control is designed to never display entries that
+ the user does not have access to. Combining anonymous access on the
+ top levels while restricting read access lower in the directory 
+ structure makes it difficult to browse because the server will not
+ request authentication. 
 
   C. Example 3: Authenticated access only
 
@@ -123,7 +129,7 @@ II.   Configuration
  restrict access to this authz file and it is in the same repository
  you should include a rule for it.
 
-  F. Example 5: Authz file stored inside the repository being accessed.
+  F. Example 6: Authz file stored inside the repository being accessed.
 
  This configuration allows providing a relative path within the
  repository being accessed.
@@ -144,6 +150,39 @@ II.   Configuration
  NOTE: You should include rules in your authz file to restirct access
  to the authz file as desired.  
 
+  G. Example 7: Authenticated access to Collection of Repositories
+
+ The Collection of Repositories is filtered based on read access to
+ the root of each repository, i.e. consistent with the directory lists
+ within repositories. If read access is restricted in repository roots,
+ it is typically desirable to require authentication for Collection of
+ Repositories in order to display the repositories.
+ 
+ This is accomplished by specifying Satisfy All (default). 
+
+ Location /svn
+   DAV svn
+   SVNParentPath /path/to/reposparent
+
+   AuthType Basic
+   AuthName Subversion repository
+   AuthUserFile /path/to/htpasswd/file
+
+   AuthzSVNAccessFile /path/to/access/file
+   # Implicit Satisfy All
+   Require valid-user
+ /Location
+ 
+ If the same server must be able to serve paths with anonymous access,
+ it can be defined by an additional location (Require statement not
+ needed but included for clarity).
+ 
+ LocationMatch ^/svn/.+
+   Satisfy Any
+   Require valid-user
+ /LocationMatch
+
+
2. Specifying permissions
 
   The file format of the access file looks like this:
Index: CHANGES
===
--- CHANGES (revision 1434103)
+++ CHANGES (working copy)
@@ -39,7 +39,7 @@ http://svn.apache.org/repos/asf/subversion/tags/1.
 * 'svn propset' checks spelling of reserved property names.
 
   - Client-side bugfixes:
-*
+* SVNParentPath / Collection of Repositories filtered based authz 
(r1408184)
 
   - Server-side bugfixes:
 *

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 16 jan 2013, at 20:15, C. Michael Pilato wrote:

 On 01/16/2013 01:54 PM, Thomas Åkesson wrote:
 Hi Ivan,
 
 I committed to drafting some change notes for this change quite some time
 ago.
 
 - Below is a draft of a section to include in Release Notes. I suggest
 just after In repository authz. - Patch contains line for CHANGES -
 Patch contains clarification and new example for mod_authz_svn INSTALL
 file.
 
 Hope I got the patch right.
 
 Thanks, Thomas.  I like the release notes, and will incorporate them in just
 a few minutes.

Good.

 
 The CHANGES addition is misplaced -- this is a server-side bugfix, not a
 client-side one.  But don't worry about submitting another patch for that 
 alone.

Sorry, I actually intended server-side but I slipped... 

Cheers,
Thomas Å.

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 16 jan 2013, at 20:44, C. Michael Pilato wrote:

 On 01/16/2013 02:27 PM, Thomas Åkesson wrote:
 
 On 16 jan 2013, at 20:15, C. Michael Pilato wrote:
 
 On 01/16/2013 01:54 PM, Thomas Åkesson wrote:
 Hi Ivan,
 
 I committed to drafting some change notes for this change quite some time
 ago.
 
 - Below is a draft of a section to include in Release Notes. I suggest
 just after In repository authz. - Patch contains line for CHANGES -
 Patch contains clarification and new example for mod_authz_svn INSTALL
 file.
 
 Hope I got the patch right.
 
 Thanks, Thomas.  I like the release notes, and will incorporate them in just
 a few minutes.
 
 Good.
 
 Actually, I have a quick question for you.  Your release notes say:
 
 {{{
 The access to Collection of Repositories is not restricted by
 mod_authz_svn. In order to require authentication on this location, the
 location should have Satisfy All (default). See examples in INSTALL for
 mod_authz_svn for additional details.
 }}}

Hmm, yes... complicated.

 
 I *think* I understood what meant in calling out that this is not
 restricted by mod_authz_svn,

Since Subversion 1.7, mod_authz_svn always returns OK for CoR, regardless 
what's in the authz file. Before 1.6 it was possible to control access to CoR 
with [/] section.

So, if the CoR should not be anonymously accessible, we must do Satisfy All + 
Require valid-user.

 and wordsmithed that section to read like this
 instead:
 
 {{{
 NOTE: Access to Collection of Repositories is not restricted by
 mod_authz_svn, but is instead managed by mod_dav_svn itself. In order to
 require authentication on this location, the location should have Satisfy
 All (which is the default value of this directive). See examples in
 mod_authz_svn's INSTALL document for additional details.
 }}
 
 Is this still accurate?

I think you have improved this complicated piece. 

 but is instead managed by mod_dav_svn itself


Is it technically managed by mod_dav_svn? Or is it... Apache core? Probably 
doesn't matter.


Btw, I tried to convey the difficulty of combining Anonymous and authenticated 
access (you wrote about that long ago) in the Note under Example 2. Hope you 
find that description accurate.

/Thomas Å.

Re: fork/exec for hooks scripts with a large FSFS cache

[Thomas Åkesson]

On 14 nov 2012, at 01:44, Daniel Shahaf wrote:
 Philip Martin wrote on Tue, Nov 13, 2012 at 21:30:00 +:
 Perhaps we could start up a separate hook script process before
 allocating the large FSFS cache and then delegate the fork/exec to that
 smaller process?
 
 If so, let's have that daemon handle all forks we might do, not just
 those related to hook scripts.  (Otherwise we'll run into the same
 problem as soon as we have another use-case for fork() in the server
 code --- such as calling svn_sysinfo__release_name().)

Looking at it from another perspective, perhaps the cache should live within a 
separate daemon? That would address not only the hook script problem but also 
the challenges of prefork processes typically required when combining 
Subversion and PHP.

Just a thought,
/Thomas Å.

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 14 nov 2012, at 11:53, Ivan Zhakov i...@visualsvn.com wrote:

 
 Confirmed as far as my testing goes (did not test short_circuit). I suggest
 committing the patch with GET subrequest and potentially change all to
 HEAD in a separate commit if there is consensus.
 Committed in r1408184.
 I doubt about backporting this fix to 1.7.x.
 
 Pro:
 * This is regression from 1.6.x:  It was possible to restrict access
 to Collection of Repositories by controlling access to [/], while
 access to individual repositories were controlled by [repoN:/]. This
 might not have been by design, bit still a very useful feature.
 
 * We already ported similar fix to hide unreadable dirs to 1.6.x (r996884)
 
 Cons:
 * Security behavior changes in patches is not good thing from my point view
 
 
 Any opinions?

I think it makes sense to release in 1.8 (no backport). Provides a better 
opportunity to explain the change. Admins on 1.6 who can not have open access 
to Collection of Repositories will have to skip 1.7. 

I can try to draft something for the change notes, next week.

/Thomas Å. 

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 9 nov 2012, at 18:45, Ivan Zhakov wrote:

 On Thu, Nov 8, 2012 at 6:49 PM, Thomas Åkesson
 thomas.akes...@simonsoft.se wrote:
 
 Parentpath on /svn/ and Satisfy Any:
 
 - Access without auth displays repositories with anonymous access, auth is 
 not requested.
 - Access with auth displays filtered list. Works well when browser has 
 previously
 been on an authenticated path. This is the situation when Satisfy Any and 
 filtered
 Collection of Repositories does not work well.
 That's why mixing anonymous and authenticated access is not good thing.

Yes, I am just trying to cover all bases including the possibility that people 
are depending on the inconsistency that we are addressing.

 
 - Did a test with AuthzSVNAnonymous Off, which gave the quite surprising 
 result
 that all content was listed both on Collection of Repositories and within the
 repositories. I doubt this is the intended behaviour?!?
 I agree, this is really strange behavior. Could you check this
 behavior with my patch? It's very low chance that my patch changes
 this behavior.

I have tested both with and without your patch. As expected, the patch has no 
impact on the AuthzSVNAnonymous issue.

There seems to be an issue when AuthzSVNAnonymous Off is combined with 
Satisfy Any; opens up the fort completely. Neither authn nor authz is 
required.

I think the problem is with access_checker, perhaps this part (has changed a 
few times during the years):
  if (!conf-anonymous
  || (! (conf-access_file || conf-repo_relative_access_file)))
return DECLINED;

I am not quite sure how a DECLINE manages to bypass Require valid-user 
though. I understand how an OK would though.


 - What is going on with AuthzSVNAnonymous Off? I will do more analysis of the
 code (focusing on access_checker in mod_authz_svn.c) but it would be great if
 someone could elaborate a bit on the intent.
 
 It would be nice if you confirm that my patch does not change
 AuthzSVNAnonymous Off behavior in this case I'll commit my patch and
 we may focus on this issue.

Confirmed as far as my testing goes (did not test short_circuit). I suggest 
committing the patch with GET subrequest and potentially change all to HEAD in 
a separate commit if there is consensus. 

Thanks again,
Thomas Å.

Re: Content-Length in HEAD responses

[Thomas Åkesson]

Thanks Justin for clarifying.

On 10 nov 2012, at 12:54, Justin Erenkrantz wrote:
 On Sat, Nov 10, 2012 at 6:49 AM, Justin Erenkrantz jus...@erenkrantz.com 
 wrote:
 There is a C-L header...so, I don't know what the original poster is seeing, 
 but we're already doing the right thing...  -- justin
 
 I bet the OP is trying to do HEAD on a directory as there was talk elsethread 
 about trying to discover ACLs on a directories...that's not going to generate 
 a C-L.  

I am not sure if Original Poster refers to Branko (who raised concerns about 
using HEAD requests for ACLs) or myself who did some tests in response to that 
concern. 

Yes, we are doing HEAD on directories since that's the situation where we were 
considering doing HEAD rather than GET requests.

 And, C-L is not meaningful in anyway on directories - only actual resources.  
 mod_autoindex doesn't do it either:
 
 ...
 
 (The only way to generate the C-L would be to run through the 
 response...which we don't do for HEAD.)

I suppose this means that it would be a significant optimization to perform 
HEAD rather than GET when discovering ACLs for every subdirectory in a 
directory listing?

Branko's concern is still interesting... because this behaviour (omitting CL 
for HEAD requests) does seem to violate the HTTP RFC, but for good reason. 
Given that mod_autoindex as well as mod_php (at least on the config I tested) 
also omits CL for HEAD I suppose it is a well accepted optimization in practice.

Thanks,
Thomas Å.

Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

Revisiting this thread after a few months. Last spring, I did some work in the 
Wiki designing a proposal for resolving the Mac Unicode issues in a 
Non-normalizing manner. I ran out of time, but the thought process has been 
ongoing.

A couple of weeks ago at Subversion Live in London, I had the opportunity to 
discuss with a number of people. Although there were some different opinions on 
the matter, I think we concluded that we are actually relatively well aligned 
on the core idea. 

The proposal I drafted this spring (in the Wiki) proposed that a couple of 
columns were added to the WC in order to store normalized paths. Since a couple 
of months the concept of using a Sqlite collation has seemed more appealing. 
Last week, I did a test with the Sqlite ICU extension (available in sqlite 
source repository) which turned out to be quite encouraging. With such a 
collation, it is possible to perform equals in SQL statements that match  paths 
in a Unicode composition aware manner and therefore return rows regardless what 
composition the paths have.

This would be very useful, for instance, when given a filesystem path 
attempting to locate the corresponding node in wc.db. That is basically half 
the issue with Mac working copies.

Today, I noticed that Branko started some implementation in a branch. Looks 
like a collation based on utf8proc is in the making? I think that would make a 
lot of sense because the ICU extension poses some challenges in the build 
process and we might not need all that functionality that it provides.

I started a wiki page about unicode collation. I will append more info:
http://wiki.apache.org/subversion/UnicodeCollation

Also note the tiny test repo attached to:
http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness

Cheers,
Thomas Å.
 

Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

On 9 nov 2012, at 14:28, C. Michael Pilato cmpil...@collab.net wrote:

 On 11/09/2012 07:49 AM, Branko Čibej wrote:
 On 09.11.2012 12:28, Thomas Åkesson wrote:
 I'm currently doing the grunt work of implementing the collation (done)
 and the LIKE and GLOB operators that we'll need (in progress). The next,
 and biggest, step will be to review the client and WC libraries to make
 sure that paths sent to the server always come from the wc.db, not from
 disk.
 
 I'm not closely following this problem or solution, but how does the above
 play out for svn import, svn mkdir IRI, svn delete IRI, etc?  (If this
 is documented somewhere, a reference by way of response would suffice.)

http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness

The draft proposes that the server does not discriminate any composition, apart 
from ensuring that creation of new name collisions is not allowed. 

Ensuring that paths come from wc.db applies to existing object. We can discuss 
whether Mac client should normalize to NFC, but that would be an option in my 
opinion. 

/Thomas Å.

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 5 nov 2012, at 09:11, Branko Čibej wrote:

 On 05.11.2012 00:21, Thomas Åkesson wrote:
 I did some tests with curl --head just as a sanity check. It seems to be a 
 good choice for access control. I primarily wanted to see that HEAD requests 
 were not allowed in situations where GET is not (e.g. when user has access 
 in directories below).
 
 The HEAD requests I performed (minimal curl command) did not cause the 
 server to provide Content-Length when returning 200 OK.
 
 Which is precisely what I was talking about in my other post. Such HEAD
 responses are invalid. If we implement HEAD, we have to do it correctly.

Right, I was just confirming that.  

I think this is approaching off-topic for this thread. The server (mod_dav_svn) 
currently does respond to HEAD requests without Content-Length, which appears 
to be invalid. Perhaps a separate issue/thread should discuss whether the HEAD 
response should be changed to conform with the specification. 

On-topic, looking at the HTTP RFC, the HEAD request makes a lot of sense for 
access control purposes and that gives the server a chance to optimize the 
response even if, worst case, only the response bandwidth would be gained. 

/Thomas Å.

Re: Authz on Collection of Repositories

[Thomas Åkesson]

On 5 nov 2012, at 00:21, Thomas Åkesson wrote:
 
 I have meant to set up a test server with our reference configuration to 
 validate the patch under realistic circumstances. Unfortunately, the SLES 
 activation servers have been down for several hours (we don't have dev tools 
 on our VM Appliance by default). I will do some tests with parentpath under 
 /svn/ and both variations of Satisfy as soon as possible.

Right, it took a while to get that test server up and running with the dev 
setup. I had to refresh some knowledge.

I have performed the following tests with patch 2012-11-02. All tests with 
access file configured and Require valid-user.

Parentpath on /svn/ and Satisfy Any:

 - Access without auth displays repositories with anonymous access, auth is not 
requested.
 - Access with auth displays filtered list. Works well when browser has 
previously been on an authenticated path. This is the situation when Satisfy 
Any and filtered Collection of Repositories does not work well. 
 - Did a test with AuthzSVNAnonymous Off, which gave the quite surprising 
result that all content was listed both on Collection of Repositories and 
within the repositories. I doubt this is the intended behaviour?!?


Parentpath on /svn/ and Satisfy All:

 - Authentication is required everywhere and the Collection of Repositories is 
beautifully filtered. Works very well with improved user experience on many 
installations.

AuthzSVNAnonymous seems to have no effect in this case, which is expected.

 
Parentpath on /:

Tested both Satisfy Any/All with same results as on /svn/. Good, I had some 
concerns since there have historically been issues.


The remaining concerns I have:
 - The combination of this patch with Satisfy Any. I am a bit more concerned 
than I was initially.
 - What is going on with AuthzSVNAnonymous Off? I will do more analysis of the 
code (focusing on access_checker in mod_authz_svn.c) but it would be great if 
someone could elaborate a bit on the intent.

Thanks,
Thomas Å.

Re: Authz on Collection of Repositories

[Thomas Åkesson]

Thanks Ivan for your work. I have very little experience with the svn codebase 
so my review is probably not very valuable. Anyway. looks good to me.

I have meant to set up a test server with our reference configuration to 
validate the patch under realistic circumstances. Unfortunately, the SLES 
activation servers have been down for several hours (we don't have dev tools on 
our VM Appliance by default). I will do some tests with parentpath under 
/svn/ and both variations of Satisfy as soon as possible.

On 2 nov 2012, at 15:25, C. Michael Pilato wrote:

 I think HEAD[1] request would be the appropriate request here.  (And I
 wonder, in retrospect, why we aren't using it for our regular in-repos
 path-based authz...)

I did some tests with curl --head just as a sanity check. It seems to be a good 
choice for access control. I primarily wanted to see that HEAD requests were 
not allowed in situations where GET is not (e.g. when user has access in 
directories below).

The HEAD requests I performed (minimal curl command) did not cause the server 
to provide Content-Length when returning 200 OK. 


/Thomas Å. 

Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

[Thomas Åkesson]

On 24 okt 2012, at 15:37, Roderich Schupp wrote:

 On Wed, Oct 24, 2012 at 6:09 AM, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
 Daniel Shahaf wrote on Wed, Oct 24, 2012 at 06:07:45 +0200:
 I can't reproduce this.  'curl -s https://svn.apache.org/repos/private/'
 Since I didn't pass -u, in both cases I was browsing as an anonymous user.
 That server runs 1.7.0.
 
 SVN 1.7.7 here and I tested as an authenticated user (Location /svn
 does require valid-user). I'm not listed in the
 AuthzSVNAccessFile and it doesn't contain any * or $special rules either.

I was able to reproduce after reconfiguring from SVNParentPath to SVNPath.
- With Satisfy All (default): curl -s http://... -u username
- With Satisfy Any: curl -s http://...

Got similar output to what Roderich posted when authz configured such that user 
has no access.

If this behaviour appeared in SVN 1.7, then it seems likely that we are seeing 
another side effect of the very change that this thread started from: i.e. the 
fix for issue 2753. That fix presumably removes authz when accessing / 
regardless whether that means the list of repositories or the root of a single 
repository.

At minimum, this should be changed such that removal of authz on / only 
applies if referring to actual server root. That would enable hosting 
SVNParentPath directly on server root while reverting to 1.6 authz for the 
other cases: SVNParentPath in /somepath/  and SVNPath configs. Somewhat half 
baked since the leak will remain when hosting SVNParentPath directly on 
server root but ok for other configs.

A better solution is the earlier suggestion to filter list of repositories 
based on actual access to the individual repositories. That would remove the 
non-obvious behaviours which is somewhat important with authz.

regards,
Thomas Å. 

Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

[Thomas Åkesson]

On 23 okt 2012, at 14:22, roderich.sch...@gmail.com wrote:

 I'm working on the patch to list only readable repositories. There is 
 already TODO comment in the code by cmpilato: 
 subversion\mod_dav_svn\repos.c:3461 
 

Thanks Ivan for looking into it. Let's see if it is feasible to address.


 Please keep in mind that the problem is not restricted to parent-path 
 collections
 of repositories: Since SVN 1.7 any user can list the root of a standalone
 repository even if she has no access grants whatsoever. Of course, the listing
 will be empty in this case (but the head revision is leaked). 

Are you saying that SVN 1.7 always allows browsing the root but it is empty 
when the user lacks authz? When I follow a link from the parentpath repository 
list into a repository where I do not have access, I get a 403.

Perhaps it is possible to confirm the existence of a repository by specifically 
requesting the head revision from arbitrary repository names. That is not ideal 
but requires significantly more determination to figure out than just looking 
at a list.

regards,
Thomas Å.

Re: Authz on Collection of Repositories (was: Expansion of authz policy name leak)

[Thomas Åkesson]

To clarify what this issue is about:
Subversion 1.7 leaks repository names when configured with SVNListParentPath 
and AuthzSVNAccessFile. It might have been unintentional, but with Subversion 
1.6 (and earlier) it was possible to control access to the repository list 
(Collection of Repositories) using the following section in access file: [/]

This is a quite unexpected change when upgrading an existing server to version 
1.7, which is not mentioned in changes. It will suddenly provide 
unauthenticated access to the repository list (when Satisfy Any) or provide 
access to users that were not intended to have access (Satisfy All).


On 19 okt 2012, at 02:07, Daniel Shahaf wrote:

 I agree it is reasonable to want the SVNParentPath URL to display only
 repositories one has some access to.
 
 This is complicated by:
 
 - THe DAV protocol does not prompt for authentication for resources
  readable by anonymous (for this, see cmpilato's old foo-no-anon
  blog post).

Hmm, I failed to get any hit on that blog post (tried both Google and 
DuckDuckGo).

Right, previously it was possible to request authentication when accessing the 
repository list via the access file, e.g.:
[/]
@GroupA = r

The requirement to hide/filter the repository list will be most prevalent with 
server configurations that always requires authentication, typically corporate 
subversion servers or in the hosting use case. Anonymous access on the other 
hand is more prevalent in the open-source use case where the feature to hide 
repositories is likely very rare.

The Apache directive Satisfy Any is required in order to combine access control 
and anonymous access (* = r). When removing Satisfy Any (i.e. Satisfy All) 
Apache ensures that clients are required to authenticate in order to view the 
repository list. This would ensure that the repository list can be correctly 
filtered by mod_authz_svn.

In summary, it would not be possible to have both anonymous access and a 
filtered repository list on the same Apache location, but that is a relatively 
rare requirement and not a regression. (well, perhaps it is possible with some 
creative Apache config).

 
 - It's possible that someone would have r or rw access to ^/bar/baz,
  but no access at all to ^/ or ^/foo/.  When this is the case, should
  that repository be listed in the SVNParentPath screen?  And if it's
  listed, what should happen when the link is followed?

No, it should not be listed. In this case, the user cannot browse from 
repository list down to the location were access is granted anyway (since he 
has not access to ^/bar/). 

 And if it's listed, what should happen when the link is followed?


The repository is listed in both Svn 1.7, 1.6 and earlier. Access is denied if 
followed. The difference is that with filtering, the link will not even be 
displayed. An improvement if you ask me and more consistent with how access 
control in the repository works.

 These are my thoughts at a high level --- i.e., user-facing level, not
 implementation level.  I'm not extremely familiar with the details of
 the thread, the parentpath code, or issue #2753.


I am fairly familiar with Apache config and the typical requirements of 
corporate installations, but not with the code. By looking at svn log C-Mike, 
Philip and Kamesh might be best suited to comment on the code.

regards,
Thomas Å.

Authz on Collection of Repositories (was: Expansion of authz policy name leak)

[Thomas Åkesson]

There was a discussion in April 2010 regarding the fix for issue 2753. 
http://svn.haxx.se/dev/archive-2010-04/0277.shtml

Unfortunately the discussion died due to lack of other opinions. I think Mike 
had some very important input here and I believe that this concluding statement 
is incorrect:

From: Kamesh Jayachandran kamesh_at_collab.net 
Date: Tue, 13 Apr 2010 00:35:11 +0530
 Whoever wanted SVNListParentPath to work with authz prior to this commit was 
 using a workaround of Location /svn/ which was leaking the same info. 


Status in Subversion 1.6

 - I have never seen the leak in 1.6 that Kamesh is referring to.
 - It was possible to use SVNListParentPath and authz on location /svn/ with a 
simple RedirectMatch ensuring that browsers end up att /svn/ rather than /svn. 
I might have been impossible when hosting SVNListParentPath at server root, not 
sure.
 - It was possible to restrict access to Collection of Repositories by 
controlling access to [/], while access to individual repositories were 
controlled by [repoN:/]. This might not have been by design, bit still a very 
useful feature.
 - It was NOT possible to display a Collection of Repositories filtered to 
display the repositories where the user has access.

Status in Subversion 1.7

 - The fix for issue 2753 presumably enables SVNListParentPath to work with 
authz on server root. By completely removing authz on Collection of 
Repositories (?).
 - It is no longer possible to protect Collection of Repositories from groups 
of users. When having Satisfy Any, required for anonymous access (* = r), the 
Collection of Repositories is open for anonymous access. Otherwise requires 
authn but not authz.


Use cases suffering from regression in 1.7

- The Collection of Repositories is leaked to all users, including for 
instance external consultants with access to a subset of information. There 
might be separate repositories for unreleased products, where leaking the repo 
name is undesirable.
- Servers hosting multiple repositories for different customers will leak which 
customers are on the same server. Can likely be worked around by explicitly 
blocking access to Collection of Repositories in Apache config.
- Difficult/impossible to combine anonymous access to a subset of information 
and requiring authentication to view Collection of Repositories.


There might be workarounds for some of the use cases, but that would involve 
using groups in Apache config which creates an additional location where authz 
must be maintained.


During the 2010 discussion Mike suggested something that we (Simonsoft) would 
be very happy to see implemented:
 In a perfect world, I would expect that requests to the parent directory 
 would not be authz-denied, but that each repository in the listing of 
 repositories would be authz-checked against the authz configuration. In 
 other words, say I have a parent-path with three repositories: calc, watch, 
 lamp. And say I have an authz file like so: 
 [lamp:/] 
 * = 
 I would expect that a request to the parent directory would yield a listing 
 that included the 'calc' and 'watch' repositories, but not the 'lamp' one. 
 


Given that we now also have AuthzSVNReposRelativeAccessFile, there is no 
obvious location to define access to Collection of Repositories. By always 
allowing access to Collection of Repositories but filtering based on whether 
the user has access to each repository root, there is no need to explicitly set 
access to Collection of Repositories. One less piece of information to 
maintain. 

Hope this summary can spark some fresh discussion!

Regards,
Thomas Å.

Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

Hi Philip,

Thanks for your comments in the wiki article. They raised some important points 
and potentially an idea that might simplify the solution.

   All three paths are in UTF-8 but NFC/NFD is not currently specified. 
 local_relpath/parent_relpath get converted from UTF-8 to whatever locale 
 encoding is in use whenever they are used to access the filesystem.


This is not unlike what we need to do for HFS+. We could consider UTF8-MAC to 
be a distinct encoding. There is the major caveat that this conversion is 
irreversible (since the normalization is not specified in the repo/wc.db).

If you, or someone else with WC insight, could provide some details on when/how 
conversions in the opposite direction is performed (e.g. svn stat and most 
commands taking path arguments), that would be incredibly useful to me. I would 
like to explore the option to somehow work around the irreversible problem.

It would also be useful if someone could point me to where in the WC code the 
conversion from UTF-8 to locale encoding is performed.

Thanks!

/Thomas Å.



On 17 apr 2012, at 05:24, Thomas Åkesson wrote:

 Hi,
 A bit of a status update on the wiki article:
 http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness
 
 Received some comments from Daniel, which I have tried to address. Thanks. 
 
 I have written a bash script which demonstrates the concept of Alternative 
 1 with regards to how the local_relpath column is handled by 
 checkout/update. 
 
 From the wiki:
 ---
 This alternative can be simulated using the attached script 
 localrelpath2nfd.sh. This provides a Working Copy equivalent to what a 
 checkout should produce if this alternative was implemented in Subversion 
 itself:
 
 svn co ...
 svn stat #Shows any problematic items as missing and unversioned
 localrelpath2nfd.sh
 svn stat #Should be clean apart from misperception that some items are 
 switched
 ---
 
 This script can be used to investigate how other subcommands are affected and 
 determine what needs to be done. It is possible to make commits but updates 
 to normalisation-dependent nodes will fail since this script is not inside 
 the update code. 
 
 I intend to use this script to take the design to the next level of detail. 
 First, I would like some feedback from people with in-depth knowledge of the 
 WC and preferably get some idea on what the community thinks about the 
 approach. 
 
 /Thomas Å. 
 
 
 On 26 mar 2012, at 04:14, Thomas Åkesson tho...@akesson.cc wrote:
 
 Hi,
 Sorry about the delay, had a release to sort out...
 
 I have moved the proposal into the wiki:
 http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness
 
 The comments from Julian and Markus have been implemented and I have added 
 more information to the Client Changes section as well as more structure 
 and TODO-notes. 
 
 I would really appreciate if someone with more insight into WC-NG could 
 provide input on some of the TODO items (or things that have been completely 
 overlooked).
 
 Thanks,
 Thomas Å.
 
 
 On 21 feb 2012, at 09:55, Daniel Shahaf wrote:
 
 I've granted you write access to the wiki.
 
 Thomas Åkesson wrote on Tue, Feb 14, 2012 at 12:36:23 +0100:
 Thanks Julian and Markus for providing feedback. 
 
 I am not commenting below because all the feedback is very good and I will 
 try to address it as best I can in the next iteration. Describing the 
 behaviour changes to the WC is the most challenging since I lack that kind 
 of detailed knowledge. I will instead try to draft the structure of that 
 section to make it easier for someone with that level of detail to assist.
 
 Regarding use cases, what can I say... it was towards the end of a long 
 stretch.
 
 I think it would help with the upcoming iterations if I could move this 
 document into the wiki. If you find that this first draft shows promise, 
 please consider granting edit access in the wiki. My user name is Thomas 
 Åkesson, which exercises the Unicode awareness of MoinMoin...
 
 /Thomas Å.
 
 
 On 14 feb 2012, at 11:25, Julian Foad wrote:
 
 Hi Thomas.  It's fantastic that you're taking the trouble to write up 
 this proposal.  That's just what we need.  Just a few initial comments 
 below...
 
 Thomas Åkesson wrote:
 
 Context
 ===
 
 [...] A unicode string (e.g. a file name) can be represented
 in 2 normalized forms (NFC/NFD) or mixed, i.e. multiple such
 characters where some are composed and others decomposed (rare).
 
 
 What's rare?  We have to assume that input is in mixed composition in 
 any system that doesn't explicitly normalize it, which (I think) includes 
 most operating systems.  While it may be rare for any single string to 
 contain characters in both compositions, it is very common to be 
 processing a string that *might* have characters in both compositions -- 
 in other words, that is not guaranteed to be normalized.  I think it 
 would be clearer to drop the (rare) and just say ... normalized forms 
 (NFC/NFD

Re: Ev2 and Authz

[Thomas Åkesson]

On 17 apr 2012, at 11:47, Julian Foad julianf...@btopenworld.com wrote:

 Thomas Åkesson wrote:
 
 I have not had time to follow the Inherited Properties thread completely, 
 but 
 this is kind of related. One could argue that if a user knows about the URL 
 to 
 /A/B/C/D, then what is the harm in letting him read the properties of the 
 parent 
 directories? A significant simplification at the cost of not being able to 
 store 
 secret stuff in directory properties (file properties would still be safe).
 
 We should be very cautious about proposing an apparently simple special 
 case like that.  A file has properties and text content; a directory has 
 properties and children; that's how it is in Subversion.  Saying that a user 
 should be able to read part of a directory (its properties) and not the other 
 part (its children) is breaking that relatively simple abstraction, and 
 breaking abstractions in that way makes complications for all other software 
 layers that try to build on top of the foundation, not to mention for the 
 users' mental models.  At first hearing, it doesn't sound like there could be 
 any major repercussions, but after a while I suspect we might regret it.

Julian, I tend to agree with your objections, as indicated by my cautious 
wording. I was pushing the envelope a bit since access control might be a 
significant hurdle for inherited properties. 

/Thomas Å. 

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

[Thomas Åkesson]

On 17 apr 2012, at 21:26, C. Michael Pilato cmpil...@collab.net wrote:

 On 04/16/2012 09:53 PM, Thomas Åkesson wrote:
 
 I would like to see a non-graphical implementation of the Secret Service
 API with a solid CLI. That would merit a project in itself, separate from
 Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used
 either with a daemon or more light-weight with just libdbus. Are there
 any OS with pressing need for Subversion password storage that does not
 have libdbus?
 
 I'm not aware of any -- I mean, I assume the *BSDs all have libdbus support.
 
 Alternatively, if there is a determination to implement encrypted storage
 within the Subversion project, how about basing that module on the
 Secret Service API, with or without libdbus?
 - All Subversion's requests for secrets done with the same API,
  untangling the code.
 - Internally stored secrets are just returned by the module
  (non-graphical POSIX-systems and potentially Windows).
 - Secrets stored in Gnome Keyring/Kwallet are requested using their
  Secret Service implementation, which is simply relaying the API calls.
 - Keychain is wrapped by the module. Not sure how difficult it is to map
  Keychain and the Secret Service API, but it would be a bit surprising if
  it turns out to be impossible.
 
 In theory, I'm okay with this.  Where is Secret Service today in terms of
 implementation, real-world usage, etc?  

I did some more digging into the Secret Service API:

- Supposedly supported by KWallet in KDE 4.8, no definitive reports.
http://arstechnica.com/business/news/2012/01/kde-48-released-with-qml-bits-and-new-password-framework.ars

- Gnome seems a bit ahead and should use Secret Service since 3.0. Seems like 
the Keyring API was not far off. 
http://stef.thewalter.net/2010/05/gnome-keyring-230.html

In terms of real-world usage there is no getting around that it is in early 
stages. After this round of digging I have to say it is likely too early to 
enable an efficient implementation process. Bugger. 

Perhaps the most pragmatic thing to do at this point is just staying as close 
to the Secret Service API as possible when designing new interfaces, like 
prompt callbacks (while untangling the current authn code). Doing so should 
minimise the effort to maintain the Keyring and Kwallet integrations going 
forward and make a future move to a (then) well-tested Secret Service API less 
painful. 


 Are you volunteering to join the coding effort?

Erm... those C skills of mine are not that impressive, really. I should just 
shut up and focus on the Unicode specification work. Hope that will become 
useful, and implemented, at some point. 

/Thomas Å. 

Re: Ev2 and Authz

[Thomas Åkesson]

On 16 apr 2012, at 15:12, C. Michael Pilato wrote:

 On 04/14/2012 11:00 AM, Hyrum K Wright wrote:
 Good morning (in some parts of the world)!
 
 I've been doing some poking around with Ev2 and copy operations on the
 ev2-export branch, and have some observations which merit discussion.
 
 In the working copy and elsewhere, all versioned nodes map to a
 repos_relpath, and I've found it greatly simplifies things if we use
 that repos relpath in Ev2 operations.  Since an Ev2 drive doesn't need
 to be anchored anywhere, using the repos_relpath in this way is
 analogous to using local_abspaths throughout the working copy, giving
 every node a single canonical name.
 
 However, this has implications in the world of the dreaded issue 3242.
 For instance, if a session is parented at the root, where the user
 cannot write, then executes write operations somewhere deep in the
 tree, where the user does have write privileges, we will produce
 errors.  This is obviously non-sensical and undesirable.
 
 If somebody can write to /A/B/C/D, they should be able to open an
 ra_session to any of the parents and write to their allowable paths
 without consequence.  I know this problem has been known for some
 time; has anybody looked at what it would take to solve it?
 
 Hyrum, I begun some work on the authz-overhaul branch aimed at fixing this,
 but never made much progress there.  My approach was simple:  bifurcate the
 read permission into read and exist, where exist meant You can know
 this thing exists and behave accordingly, but you still can't read its
 contents.  This would not be a user-visible permission -- just an
 implementation detail.  Both read and write permissions imply having
 exist permission.  And the rule is, If you can know N exists, you can
 know that all of N's parents exist.
 
 CollabNet's modified ViewVC in its Enterprise Edition product implemented
 this sort of functionality, and the result was that users could always see
 the root directory, and any paths inside it necessary to navigate down to a
 path to which they had explicit read permission.  Very, very handy.


Agree, very handy. We produce a CMS based on Svn and this is exactly what we 
wish for. If a user has the URL to /A/B/C/D, he basically already knows about 
the parents.

I have not had time to follow the Inherited Properties thread completely, but 
this is kind of related. One could argue that if a user knows about the URL to 
/A/B/C/D, then what is the harm in letting him read the properties of the 
parent directories? A significant simplification at the cost of not being able 
to store secret stuff in directory properties (file properties would still be 
safe).

 

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

[Thomas Åkesson]

On 16 apr 2012, at 16:43, C. Michael Pilato wrote:

 On 04/15/2012 03:45 PM, Thomas Åkesson wrote:
 You are correct.  Today we have DSO options for GNOME/KDE, and simple 
 #if-wrapping for Win32 and MacOS.  GPG Agent doesn't have the
 lib/heavy deps, as the code communicates with the agent not through a
 custom API, but directly via socket I/O.
 
 Not sure what you're envisioning when you say a new callback.
 
 Just want to make sure you are aware of the initiative Secret Service
 API unifying Gnome and KDE. The spec is still a draft but it seems that
 both implement it.
 
 http://standards.freedesktop.org/secret-service/
 
 I was not aware of the initiative, but am happy to learn of it.  The sheer
 amount of software replicated between the KDE/Gnome divide is just 
 embarrassing.
 
 How would the hypothetical existence of such a secret storage on Windows
 impact this Subversion initiative?
 
 If there was a single,
 common-and-commonly-available-across-all-supported-OSes way to do this
 stuff, that'd be fantastic.  But Windows isn't the problem area today, so
 I'm not sure that adding yet another way to do secrets on Windows would
 matter much.

Ok, sorry. I reread the wiki articles and the thread from late March. I gather, 
the problem areas are unmaintainable code and OSes where no encrypted storage 
is available/installed.

 
 The Secret Service thing would allow us to continue offloading
 responsibility for encryption to third-parties as we do today, though at the
 continued cost of a hybrid storage model (where half of the details we need
 to know to authenticate are cached in ~/.subversion, the other half live
 elsewhere).  As such it doesn't allow us to easily pick up and relocate an
 encrypted store to another machine -- but I don't know how interesting that
 feature is to anyone.


Personally, the feature to manually move/copy the encrypted store is definitely 
useful, but I do consider some other features of the Desktop-integrated storage 
APIs significantly more value-adding (I mostly use OSX Keychain):

 - Unlocking the encrypted storage on login. (would still work, via master 
passphrase in Keychain/KWallet/Keyring)
 - Not a separate passphrase. Changing password for the OS user account manages 
the re-encryption.
 - Automated password storage replication. OS X with MobileMe (subscription) 
_had_ this feature. It is sorely missed in iCloud and I am not alone in hoping 
for its return.
 - Relatively intuitive UI to manage cached credentials, including retrieving 
forgotten ones.

I am afraid OS X users might consider moving away from Keychain a bit of a 
regression (can't speak for Gnome/KDE users).


Cheers,
/Thomas Å.

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

[Thomas Åkesson]

On 16 apr 2012, at 20:05, C. Michael Pilato cmpil...@collab.net wrote:

 On 04/16/2012 12:33 PM, Thomas Åkesson wrote:
 Personally, the feature to manually move/copy the encrypted store is 
 definitely useful, but I do consider some other features of the 
 Desktop-integrated storage APIs significantly more value-adding (I mostly 
 use OSX Keychain):
 
 - Unlocking the encrypted storage on login. (would still work, via master 
 passphrase in Keychain/KWallet/Keyring)
 - Not a separate passphrase. Changing password for the OS user account 
 manages the re-encryption.
 - Automated password storage replication. OS X with MobileMe (subscription) 
 _had_ this feature. It is sorely missed in iCloud and I am not alone in 
 hoping for its return.
 - Relatively intuitive UI to manage cached credentials, including retrieving 
 forgotten ones.
 
 I am afraid OS X users might consider moving away from Keychain a bit of a 
 regression (can't speak for Gnome/KDE users).
 
 Yeah, I hear you about the OS X user point of view.  At this point, I'm
 fairly convinced that for Windows and OS X, the use-master-password feature
 will be less frequently used.  (It will be off by default on all OSes.)

AFAIK, both Kwallet and Gnome Keyring require a graphical desktop and to a 
large extent lack command line tools. Is that kind of the core problem here?

I would like to see a non-graphical implementation of the Secret Service API 
with a solid CLI. That would merit a project in itself, separate from 
Subversion (e.g. Apache Keywhatever). It seems like Dbus can be used either 
with a daemon or more light-weight with just libdbus. Are there any OS with 
pressing need for Subversion password storage that does not have libdbus?

Alternatively, if there is a determination to implement encrypted storage 
within the Subversion project, how about basing that module on the Secret 
Service API, with or without libdbus?
 - All Subversion's requests for secrets done with the same API, untangling the 
code. 
 - Internally stored secrets are just returned by the module (non-graphical 
POSIX-systems and potentially Windows). 
 - Secrets stored in Gnome Keyring/Kwallet are requested using their Secret 
Service implementation, which is simply relaying the API calls. 
 - Keychain is wrapped by the module. Not sure how difficult it is to map 
Keychain and the Secret Service API, but it would be a bit surprising if it 
turns out to be impossible. 

Re: svn commit: r1326696 - in /subversion/trunk/subversion/libsvn_client: add.c client.h commit.c copy.c delete.c prop_commands.c util.c

[Thomas Åkesson]

On 17 apr 2012, at 02:26, Hyrum K Wright hyrum.wri...@wandisco.com wrote:
 On Mon, Apr 16, 2012 at 5:22 PM, Greg Stein gst...@gmail.com wrote:
 On Mon, Apr 16, 2012 at 18:04, Stefan Sperling s...@elego.de wrote:
 
 At the very least, you must compare the URL of the node at the calculated
 local_abspath to the original node_url. If they do not match, the
 node at local_abspath is switched, so the node you're looking for is not
 in the WC at the expected location.
 
 The node could be somewhere else, though, at a different path which
 is switched to the original URL you're looking for. Maybe you'll need
 to add a new libsvn_wc API that tries a bit harder to figure out where
 the node could be?
 
 I think this may be the answer: a API which takes a wc_ctx, a
 repos_root, and a repos_relpath.  With that information, we should be
 able to resolve a node location (and hence its pristine) without much
 difficulty.
 
 Well... I think the real problem could be that you *already* knew
 where it was. The user may have said svn foo file.c, where file.c is
 in a switched subdir. Then it gets switch to repos_relpath, and then
 we lose the wc location.
 
 We could pass such information along in the baton, but the problem is
 sometime this information changes between the time we construct the
 baton and the time we use it, as in the case of committing from
 disjunct working copies.
 
 This is why I was tentative with unequivocally stating Ev2 should use
 repos_relpath. Bert mentioned a couple scenarios where it could
 falter, too. And then I had a couple other concerns around paths in
 the copy/move/rotate APIs.

 I probably need to go back and review that discussion.  From my early
 work on the ev2-export branch, repos_relpaths vastly simplified the
 problem space by giving nodes canonical names, both inside the editor
 and in the driver / receivers.

I did some work on this list and on the wiki trying to outline an approach to 
resolve the Unicode normalisation issues that Subversion experiences on OS X. I 
second that repos_relpath is the preferred canonical name of nodes and 
local_*path should be avoided, if the approach I outlined is of interest. 

I think it would be of value to both Ev2 and the Unicode discussion if you 
could review the wiki article. It would be unfortunate to bring forward (into 
Ev2) any assumptions about paths that can never be safe on a normalising file 
system. 

http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness

Thanks!

Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

Hi,
A bit of a status update on the wiki article:
http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness

Received some comments from Daniel, which I have tried to address. Thanks. 

I have written a bash script which demonstrates the concept of Alternative 1 
with regards to how the local_relpath column is handled by checkout/update. 

From the wiki:
---
This alternative can be simulated using the attached script 
localrelpath2nfd.sh. This provides a Working Copy equivalent to what a checkout 
should produce if this alternative was implemented in Subversion itself:

svn co ...
svn stat #Shows any problematic items as missing and unversioned
localrelpath2nfd.sh
svn stat #Should be clean apart from misperception that some items are switched
---

This script can be used to investigate how other subcommands are affected and 
determine what needs to be done. It is possible to make commits but updates to 
normalisation-dependent nodes will fail since this script is not inside the 
update code. 

I intend to use this script to take the design to the next level of detail. 
First, I would like some feedback from people with in-depth knowledge of the WC 
and preferably get some idea on what the community thinks about the approach. 

/Thomas Å. 


On 26 mar 2012, at 04:14, Thomas Åkesson tho...@akesson.cc wrote:

 Hi,
 Sorry about the delay, had a release to sort out...
 
 I have moved the proposal into the wiki:
 http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness
 
 The comments from Julian and Markus have been implemented and I have added 
 more information to the Client Changes section as well as more structure 
 and TODO-notes. 
 
 I would really appreciate if someone with more insight into WC-NG could 
 provide input on some of the TODO items (or things that have been completely 
 overlooked).
 
 Thanks,
 Thomas Å.
 
 
 On 21 feb 2012, at 09:55, Daniel Shahaf wrote:
 
 I've granted you write access to the wiki.
 
 Thomas Åkesson wrote on Tue, Feb 14, 2012 at 12:36:23 +0100:
 Thanks Julian and Markus for providing feedback. 
 
 I am not commenting below because all the feedback is very good and I will 
 try to address it as best I can in the next iteration. Describing the 
 behaviour changes to the WC is the most challenging since I lack that kind 
 of detailed knowledge. I will instead try to draft the structure of that 
 section to make it easier for someone with that level of detail to assist.
 
 Regarding use cases, what can I say... it was towards the end of a long 
 stretch.
 
 I think it would help with the upcoming iterations if I could move this 
 document into the wiki. If you find that this first draft shows promise, 
 please consider granting edit access in the wiki. My user name is Thomas 
 Åkesson, which exercises the Unicode awareness of MoinMoin...
 
 /Thomas Å.
 
 
 On 14 feb 2012, at 11:25, Julian Foad wrote:
 
 Hi Thomas.  It's fantastic that you're taking the trouble to write up this 
 proposal.  That's just what we need.  Just a few initial comments below...
 
 Thomas Åkesson wrote:
 
 Context
 ===
 
 [...] A unicode string (e.g. a file name) can be represented
 in 2 normalized forms (NFC/NFD) or mixed, i.e. multiple such
 characters where some are composed and others decomposed (rare).
 
 
 What's rare?  We have to assume that input is in mixed composition in 
 any system that doesn't explicitly normalize it, which (I think) includes 
 most operating systems.  While it may be rare for any single string to 
 contain characters in both compositions, it is very common to be 
 processing a string that *might* have characters in both compositions -- 
 in other words, that is not guaranteed to be normalized.  I think it would 
 be clearer to drop the (rare) and just say ... normalized forms 
 (NFC/NFD) or mixed (not normalized)..
 
 
 A minority of file systems (currently Mac OS X HFS+ only) will
 normalize the paths. In the case of HFS+, the path will be
 normalized into NFD and it will even be given back that way when
 listing the filesystem. 
 
 
 Drop the word even?  The statement is not surprising.
 
 
 [...]
 
 Similarities to case-sensitivity
 ===
 
 - If two Unicode strings differ only by letter case/composition,
 
 Drop /composition -- it's the subject of the following sentence.
 
 on some 
 computer systems they refer to the same file, while on
 other systems 
 they refer to different files.  The same applies
 if two Unicode strings 
 differ only by composition. 
 
 
 [...]
 
 Client Changes
 ===
 
 [...] An abstraction between the repository path and the file
 system path can be achieved by ensuring that there is a column
 in wc.db that contains the file system path in exactly the same
 form that the file system gives back. APIs in wc needs to be
 extended to ensure that all interaction with the file system is
 performed with the file system path.
 
 [...]
 
 This part seems to be the heart of the whole proposal.  You describe the 
 data

Re: Master passphrase approach, authn storage, cobwebs in C-Mike's head, ...

[Thomas Åkesson]

On 6 apr 2012, at 16:05, C. Michael Pilato cmpil...@collab.net wrote:

 On 04/05/2012 10:33 PM, Greg Stein wrote:
 If not, any suggestions on where the master passphrase fetch/store
 bits might best fit in?
 
 A new callback. But you definitely need a DSO option so core svn does not
 have GNOME/KDE dependencies. Instead, they load a small DSO that implements
 the master get/set functionality. Maybe a tiny vtable.
 
 I think the OS-based ones are not DSO since there is no heavy dep chain to
 be concerned about.
 
 Dunno where GPG comes in. Is there a library and heavy deps associated with
 that?
 
 You are correct.  Today we have DSO options for GNOME/KDE, and simple
 #if-wrapping for Win32 and MacOS.  GPG Agent doesn't have the lib/heavy
 deps, as the code communicates with the agent not through a custom API, but
 directly via socket I/O.
 
 Not sure what you're envisioning when you say a new callback.

Just want to make sure you are aware of the initiative Secret Service API 
unifying Gnome and KDE. The spec is still a draft but it seems that both 
implement it. 

http://standards.freedesktop.org/secret-service/

How would the hypothetical existence of such a secret storage on Windows impact 
this Subversion initiative?


 
 I mean, do third-party clients really need to pick and choose which
 providers they want to use?
 
 Not the types of auth, but the client needs a way to prompt. The client_ctx
 prompt callback may be enough, but I dunno (does that support two inputs?
 such as username and password).
 
 We have several different kinds of prompting callbacks offered by the
 various providers at this point, and I believe those are required.  But I
 wonder if they can't all be lumped into one giant authn prompt callback 
 vtable.
 
 What about other benefits of the existing system?
 
 * third-party authn providers can be written and used
 * authn providers can be ordered according to a client's desires
 
 Are there any known clients taking advantage of these features?
 
 -- 
 C. Michael Pilato cmpil...@collab.net
 CollabNet  www.collab.net  Distributed Development On Demand
 

Re: Compressed Pristines (Design Doc)

[Thomas Åkesson]

Hi Ash,

I noticed that Remove pristine store or render optional is considered a 
Non-Goal. If changes are made to wc-db in order to manage compressed pristines, 
it might make sense to ensure that the design can also handle optional 
pristines in the future.

The typical Subversion use case (code/text) will obviously benefit from 
compressed pristines. However, when storing binary files (e.g. graphics), which 
tend to be larger and less frequently modified files, optional pristines will 
likely be more beneficial. 

Thanks,
Thomas Å.  


On 22 mar 2012, at 08:15, Ashod Nakashian wrote:

 
 From: Daniel Shahaf danie...@elego.de
 To: Greg Stein gst...@gmail.com 
 Cc: Ashod Nakashian ashodnakash...@yahoo.com; dev@subversion.apache.org 
 Sent: Wednesday, March 21, 2012 2:08 PM
 Subject: Re: Compressed Pristines (Design Doc)
 
 Greg Stein wrote on Wed, Mar 21, 2012 at 16:51:47 -0400:
 On Wed, Mar 21, 2012 at 16:11, Daniel Shahaf d...@daniel.shahaf.name 
 wrote:
 Ashod Nakashian wrote on Wed, Mar 21, 2012 at 12:19:02 -0700:
 All,
 
 I'm happy to share[1] with you the design document for the Compressed 
 Pristines feature. The document is public and anyone can comment on any 
 part
 
 I can't.  Can you please move the document to our wiki, or dump it in an
 email to dev@, or on a pastebin, somewhere everyone canread it.
 
 I just opened it in an incognito window in Chrome. You should be able
 to access the thing.
 
 
 Tried, I get as far as the doc title.  I don't see its contents.
 
 
 Daniel (and all who can't access the doc),
 
 I'm attaching the PDF and ODT versions with updates based on Greg's comments. 
 I'd like to hear all opinions and comments. Google docs is a fairly ideal 
 environment for live commenting and editing, so it's too bad that you can't 
 access the file.
 
 Please let me know if you have any notes/comments on the design. If you'd 
 like to use the ODT file for comments and edits, please mark your input 
 clearly and I'll update the Google doc with your notes.
 
 Thanks,
 AshSubversionCompressedPristinesDesign.pdfSubversionCompressedPristinesDesign.odt

Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

Hi,
Sorry about the delay, had a release to sort out...

I have moved the proposal into the wiki:
http://wiki.apache.org/subversion/NonNormalizingUnicodeCompositionAwareness

The comments from Julian and Markus have been implemented and I have added more 
information to the Client Changes section as well as more structure and 
TODO-notes. 

I would really appreciate if someone with more insight into WC-NG could provide 
input on some of the TODO items (or things that have been completely 
overlooked).

Thanks,
Thomas Å.


On 21 feb 2012, at 09:55, Daniel Shahaf wrote:

 I've granted you write access to the wiki.
 
 Thomas Åkesson wrote on Tue, Feb 14, 2012 at 12:36:23 +0100:
 Thanks Julian and Markus for providing feedback. 
 
 I am not commenting below because all the feedback is very good and I will 
 try to address it as best I can in the next iteration. Describing the 
 behaviour changes to the WC is the most challenging since I lack that kind 
 of detailed knowledge. I will instead try to draft the structure of that 
 section to make it easier for someone with that level of detail to assist.
 
 Regarding use cases, what can I say... it was towards the end of a long 
 stretch.
 
 I think it would help with the upcoming iterations if I could move this 
 document into the wiki. If you find that this first draft shows promise, 
 please consider granting edit access in the wiki. My user name is Thomas 
 Åkesson, which exercises the Unicode awareness of MoinMoin...
 
 /Thomas Å.
 
 
 On 14 feb 2012, at 11:25, Julian Foad wrote:
 
 Hi Thomas.  It's fantastic that you're taking the trouble to write up this 
 proposal.  That's just what we need.  Just a few initial comments below...
 
 Thomas Åkesson wrote:
 
 Context
 ===
 
 [...] A unicode string (e.g. a file name) can be represented
 in 2 normalized forms (NFC/NFD) or mixed, i.e. multiple such
 characters where some are composed and others decomposed (rare).
 
 
 What's rare?  We have to assume that input is in mixed composition in any 
 system that doesn't explicitly normalize it, which (I think) includes most 
 operating systems.  While it may be rare for any single string to contain 
 characters in both compositions, it is very common to be processing a 
 string that *might* have characters in both compositions -- in other words, 
 that is not guaranteed to be normalized.  I think it would be clearer to 
 drop the (rare) and just say ... normalized forms (NFC/NFD) or mixed 
 (not normalized)..
 
 
 A minority of file systems (currently Mac OS X HFS+ only) will
 normalize the paths. In the case of HFS+, the path will be
 normalized into NFD and it will even be given back that way when
 listing the filesystem. 
 
 
 Drop the word even?  The statement is not surprising.
 
 
 [...]
 
 Similarities to case-sensitivity
 ===
 
  - If two Unicode strings differ only by letter case/composition,
 
 Drop /composition -- it's the subject of the following sentence.
 
 on some 
 computer systems they refer to the same file, while on
 other systems 
 they refer to different files.  The same applies
 if two Unicode strings 
 differ only by composition. 
 
 
 [...]
 
 Client Changes
 ===
 
 [...] An abstraction between the repository path and the file
 system path can be achieved by ensuring that there is a column
 in wc.db that contains the file system path in exactly the same
 form that the file system gives back. APIs in wc needs to be
 extended to ensure that all interaction with the file system is
 performed with the file system path.
 
 [...]
 
 This part seems to be the heart of the whole proposal.  You describe the 
 data that we need, but the behaviour will also need to be described in 
 detail.  Presumably much of the behaviour is boring and obvious (when we 
 check out a new path and create it on disk, we store the disk path), but 
 I'm sure there will be some less obvious parts (do we need to find out what 
 the disk path of an 'excluded' node would be, even though we're not 
 actually creating it on disk, for example).
 
 
 Use Cases
 ===
 
 This change will only affect use cases which rely on creating
 paths that look like duplicates but use different unicode
 composition. It is highly unlikely anyone is relying on this..
 
 
 Uh... it sounds like you are saying there are no interesting use cases for 
 this proposal!  No, on the contrary, this proposal also affects checking 
 out and using a WC on Mac HFS+ where the repository paths were created on 
 another system and are not in NFD, and it allows that case to work.  That's 
 the more interesting use case, is it not?  It's definitely worth writing 
 out the interesting case in full, including steps like checkout (or update) 
 that brings in a non-NFD path, create a new file on the Mac, and commit.
 
 - Julian
 
 

Re: {SPAM 03.5} Re: [RFC] Non-normalizing Unicode Composition Awareness

[Thomas Åkesson]

Thanks Julian and Markus for providing feedback. 

I am not commenting below because all the feedback is very good and I will try 
to address it as best I can in the next iteration. Describing the behaviour 
changes to the WC is the most challenging since I lack that kind of detailed 
knowledge. I will instead try to draft the structure of that section to make it 
easier for someone with that level of detail to assist.

Regarding use cases, what can I say... it was towards the end of a long stretch.

I think it would help with the upcoming iterations if I could move this 
document into the wiki. If you find that this first draft shows promise, 
please consider granting edit access in the wiki. My user name is Thomas 
Åkesson, which exercises the Unicode awareness of MoinMoin...

/Thomas Å.


On 14 feb 2012, at 11:25, Julian Foad wrote:

 Hi Thomas.  It's fantastic that you're taking the trouble to write up this 
 proposal.  That's just what we need.  Just a few initial comments below...
 
 Thomas Åkesson wrote:
 
 Context
 ===
 
 [...] A unicode string (e.g. a file name) can be represented
 in 2 normalized forms (NFC/NFD) or mixed, i.e. multiple such
 characters where some are composed and others decomposed (rare).
 
 
 What's rare?  We have to assume that input is in mixed composition in any 
 system that doesn't explicitly normalize it, which (I think) includes most 
 operating systems.  While it may be rare for any single string to contain 
 characters in both compositions, it is very common to be processing a string 
 that *might* have characters in both compositions -- in other words, that is 
 not guaranteed to be normalized.  I think it would be clearer to drop the 
 (rare) and just say ... normalized forms (NFC/NFD) or mixed (not 
 normalized)..
 
 
 A minority of file systems (currently Mac OS X HFS+ only) will
 normalize the paths. In the case of HFS+, the path will be
 normalized into NFD and it will even be given back that way when
 listing the filesystem. 
 
 
 Drop the word even?  The statement is not surprising.
 
 
 [...]
 
 Similarities to case-sensitivity
 ===
 
   - If two Unicode strings differ only by letter case/composition,
 
 Drop /composition -- it's the subject of the following sentence.
 
 on some 
 computer systems they refer to the same file, while on
 other systems 
 they refer to different files.  The same applies
 if two Unicode strings 
 differ only by composition. 
 
 
 [...]
 
 Client Changes
 ===
 
 [...] An abstraction between the repository path and the file
 system path can be achieved by ensuring that there is a column
 in wc.db that contains the file system path in exactly the same
 form that the file system gives back. APIs in wc needs to be
 extended to ensure that all interaction with the file system is
 performed with the file system path.
 
 [...]
 
 This part seems to be the heart of the whole proposal.  You describe the data 
 that we need, but the behaviour will also need to be described in detail.  
 Presumably much of the behaviour is boring and obvious (when we check out a 
 new path and create it on disk, we store the disk path), but I'm sure there 
 will be some less obvious parts (do we need to find out what the disk path of 
 an 'excluded' node would be, even though we're not actually creating it on 
 disk, for example).
 
 
 Use Cases
 ===
 
 This change will only affect use cases which rely on creating
 paths that look like duplicates but use different unicode
 composition. It is highly unlikely anyone is relying on this..
 
 
 Uh... it sounds like you are saying there are no interesting use cases for 
 this proposal!  No, on the contrary, this proposal also affects checking out 
 and using a WC on Mac HFS+ where the repository paths were created on another 
 system and are not in NFD, and it allows that case to work.  That's the more 
 interesting use case, is it not?  It's definitely worth writing out the 
 interesting case in full, including steps like checkout (or update) that 
 brings in a non-NFD path, create a new file on the Mac, and commit.
 
 - Julian
 

[RFC] Non-normalizing Unicode Composition Awareness (was: Let's discuss about unicode compositions for filenames!)

[Thomas Åkesson]

Title: Non-normalizing Unicode Composition Awareness
Version: 0.1 (2012-02-14)


Context
===

Within Unicode, some characters can in the unicode standard be represented in 2 
different ways (composed/decomposed), while rendered equally on screen or in 
print. A unicode string (e.g. a file name) can be represented in 2 normalized 
forms (NFC/NFD) or mixed, i.e. multiple such characters where some are composed 
and others decomposed (rare).

The majority of file systems (e.g. NTFS, Ext3) will accept a unicode filename 
in any form, store and give back in the form it was input. These file systems 
will typically even accept multiple files where the path looks identical on 
screen but the unicode string is different due to character composition.

A minority of file systems (currently Mac OS X HFS+ only) will normalize the 
paths. In the case of HFS+, the path will be normalized into NFD and it will 
even be given back that way when listing the filesystem. 

Most significant differences from the majority of filesystems:
 - A file that is stored in NFC or mixed, will not be returned with an 
identical name. Generally considered a negative effect of the HFS+ unicode 
implementation.
 - Multiple files whose name is rendered equally cannot be stored in the same 
directory. Often considered an advantage.   


The topic has been described here:
http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames

 - This RFC is not as complete in all areas, and depend on this note for 
additional context and issue description.
 - This RFC proposes a solution very similar to the note's solution 4, Client 
and server-side path comparison routines. However, here it is proposed as a 
long term solution.
 - This RFC is essentially identical to what Erik H. proposes in this thread:
http://svn.haxx.se/dev/archive-2010-09/0319.shtml



Issue Description
===

 - Subversion and most file systems currently allow creation of multiple paths, 
which in normalized form are identical. Hereafter referred to as 
normalized-name collisions. This could cause significant upgrade issues for 
repositories containing such collisions, depending on which solution is 
implemented. See section Legacy Data.

 - Users have difficulty understanding and managing normalized-name 
collisions. It is difficult to know which file is which and one of the paths 
is typically not possible to type on a keyboard.

 - Mac OS X clients can not interoperate with non-OSX clients when paths 
contain composed characters (added by a non-OSX client). The working copies are 
broken directly after checkout/update on OSX. Tracked by: 
http://subversion.tigris.org/issues/show_bug.cgi?id=2464



Differences to case-sensitivity
===

 - NFC/NFD look the same when rendered on screen.
 - Different case can be controlled with the keyboard, while unicode 
composition is more difficult.
 - Most modern case-insensitive file systems are case-preserving, i.e. they do 
not normalize to a preferred form and always return the same form that was 
stored. Normalizing file systems do not preserve the paths.



Similarities to case-sensitivity
===

 - If two Unicode strings differ only by letter case/composition, on some 
computer systems they refer to the same file, while on other systems they refer 
to different files.  The same applies if two Unicode strings differ only by 
composition. The rules are set by each file system.

 - Subversion interoperates with different systems.  When two file names that 
differ only by letter case are transferred from a 
case-sensitive system to a case-insensitive system, they will collide and 
Subversion should handle this in some friendly way. The same applies if two 
file names differ only by composition.



To Normalize or Not to Normalize
===

Whether or not to normalize within a Subversion repository (server-side) has 
been debated. The note (unicode-composition-for-filenames) considers 
normalization to NFC to be the long term (2.x) solution. Referring to this 
feature as repository normalization.

There are implementation advantages with normalized paths which can simplify 
comparisons and storage. 

There are also reasons not to normalize:

 - A file system is generally expected to give back exactly what was stored, or 
refuse up-front. HFS+ has been criticized for not living up to this 
expectation, which is also the reason the Svn WC has issues on HFS+. Subversion 
can be considered a sort of file system, and could therefore be expected to 
live up to this expectation.

 - Compatibility is a high priority for Subversion. Introducing 
normalization/translation/etc is not unlikely to introduce compatibility 
issues, now or later. There is a principle that Subversion should not be a 
limiting factor or impose undue limitations on allowed characters, file names 
etc. 

 - Introducing normalization tends to complicate the upgrade process, 
especially for repositories that contain normalized-name collisions. This is 
one of 

Re: Let's discuss about unicode compositions for filenames!

[Thomas Åkesson]

On 11 feb 2012, at 13:10, Hiroaki Nakamura wrote:

 Hi,
 
 2012/2/9 Thomas Åkesson tho...@akesson.cc:
 Hi,
 I have been interested in this issue for a couple of years and I remember it 
 was discussed briefly at Subconf in Germany a couple of years ago.
 
 Branching the thread here because I'd like to propose a different approach 
 than Hiroaki. This proposition is not very different from the note 
 unicode-composition-for-filenames or what Peter S, Neels and others 
 suggested, perhaps just combining 2 changes slightly differently.
 
 This is based on my limited understanding of WC-NG, please correct me if I 
 make incorrect assumptions.
 
 - Server will still accept both NFC and NFD, however, it will no longer 
 accept collisions. Enforced by normalising to NFD before uniqueness checks 
 during add operations (yes, might be more expensive). There will be no 
 unified normalisation, but the subversion server will work like most 
 filesystems; return what was given to it.
 
 For compatibility, we cannot ignore existing repositories and working
 copies which have filename
 collisions. So we cannot enforce subversion servers and clients to
 normalize filenames.
 We must let users to choose whether filenames are normalized or not
 per repository.
 

Perhaps I did not describe this well enough, but I am _not_ suggesting a 
normalized repository storage, just normalized uniqueness check during add 
operations. I believe that a normalized repository storage would cause too much 
compatibility issues with historical data (as well as other negative effects 
noted below). 

The proposition I outlined has _no_ issues what so ever with existing 
repositories or working copies, even if they do have name collisions (which we 
all agree is rare). What  would change is the ability to create _new_ name 
collisions (normalized) while old name collisions could be resolved with 'svn 
mv'.

I am not sure anyone has yet voiced the opinion that Subversion must continue 
to accept the creation of new name collisions. Anyone? I think Neels was 
closest to that opinion that but my interpretation is that he suggested that a 
Subversion server should not normalize. The more times I read Neels' post 
(2012-01-30), it is increasingly obvious that what I proposed is very similar.

There is consensus that a high priority for Subversion is compatibility. 
Introducing a normalization/translation/etc is risky business for 
compatibility. The HFS+ file system has been chastised (both here and other 
dev-lists) for its behaviour. A file system is expected to return exactly what 
was stored, or refuse up-front. 

Would it make sense to formalize the different approaches into a couple of RFCs 
attempting to summarize the respective implications of each approach? I could 
try to write one up for the Non-normalizing approach. 

/Thomas Å.

Re: Let's discuss about unicode compositions for filenames!

[Thomas Åkesson]

On 12 feb 2012, at 16:59, Stefan Sperling wrote:

 On Sun, Feb 12, 2012 at 04:47:45PM +0100, Thomas Åkesson wrote:
 Would it make sense to formalize the different approaches into a
 couple of RFCs attempting to summarize the respective implications of
 each approach? I could try to write one up for the Non-normalizing
 approach. 
 
 Detailed design specs and proposals are always welcome and useful.
 Of course, we cannot tell in advance whether they will be implemented.
 But the more concrete and detailed information we have about different
 solutions and trade-offs, the more likely it is that this problem will
 be resolved at some point.

I have almost completed a first iteration of a more detailed spec for the 
proposal. I have difficulty with the details of wc-ng since I have no under 
the hood knowledge. I hope someone is willing to help out with wc-ng insight. 
I will happily iterate the proposal to capture that.

Will post the proposal tomorrow... ok today (Monday).

/Thomas Å.

Re: Let's discuss about unicode compositions for filenames!

[Thomas Åkesson]

Hi,
I have been interested in this issue for a couple of years and I remember it 
was discussed briefly at Subconf in Germany a couple of years ago. 

Branching the thread here because I'd like to propose a different approach than 
Hiroaki. This proposition is not very different from the note 
unicode-composition-for-filenames or what Peter S, Neels and others 
suggested, perhaps just combining 2 changes slightly differently.

This is based on my limited understanding of WC-NG, please correct me if I make 
incorrect assumptions. 

- Server will still accept both NFC and NFD, however, it will no longer accept 
collisions. Enforced by normalising to NFD before uniqueness checks during add 
operations (yes, might be more expensive). There will be no unified 
normalisation, but the subversion server will work like most filesystems; 
return what was given to it.

- WC currently has a column containing the name as stored on server, I assume. 
This column will be kept, and an additional column will be added that contains 
the name in normalised form. This form will be NFD for all platforms, unless 
one is found that normalises to NFC. This column will be used on Mac OS X to 
identify files and on all platforms to ensure normalised uniqueness.


Preliminary analysis of side-effects below. Regarding still supporting 
developers that want to test both NFC and NFD, this will still work, but not in 
the same directory.


On 30 jan 2012, at 13:30, Stefan Sperling s...@elego.de wrote:

 On Sun, Jan 29, 2012 at 07:38:44PM +0900, Hiroaki Nakamura wrote:
 Hi folks!
 
 I read the note about unicode compositions for filenames
 http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames
 and would like to drive the discussion.
 
 Hi,
 
 I am very happy to hear that you want to work towards getting this
 problem fixed. Thank you for your help!
 
 I've just re-read the unicode-composition-for-filenames notes.
 I think they are a bit outdated. For instance, they still talk about
 the 1.6 working copy format. They also don't clearly explain the problems
 with backwards compatibility we're facing here.
 
 We won't be able to apply your patch as it is. The problem is that
 it can break operation for some existing repositories and working
 copies.
 
 Generally, I think that writing code that implements a solution for
 this problem is not hard, no matter what the solution is.
 The real challenge lies in finding a solution that is backwards
 compatible with existing repositories and working copies.
 
 I will explain what I mean by giving examples below.
 But first, let's recap the basic problem, if only so others can more
 easily follow this discussion.
 
 As you know, in Unicode, some characters can be represented in two distinct
 ways: pre-composed form (NFC) and de-composed form (NFD).
 For instance, the letter ä (a umlaut) can be represented by Unicode
 code point 0x00E4 ( ä ), which is the pre-composed form, or by code
 point 0x0061 ( a ) followed by code point 0x0308 ( ̈  ), which is the
 de-composed form.
 
 This is a basic property of Unicode. It simply contains both ways of
 representing these characters in its character tables.
 I.e. any byte-string representation of Unicode, be it UTF-8, UTF-16,
 must also be able to represent both ways of encoding such characters.
 So when filenames are given in Unicode, a filename may contain any
 combination of NFC and NFD characters.
 
 Because Subversion never normalises filenames to one form or the other,
 the space of all possible filenames in a Subversion repository or working
 copy contains a large amount of redundancy. There are many filenames which
 look the same to the user but differ in terms of the Unicode code points
 used to represent them.
 
 For instance, imagine a filename containing 3 a umlaut characters
 and otherwise only characters from the ASCII set.
 There are 8 (2^3) different ways of representing this filename in Unicode,
 and hence 8 different UTF-8 byte strings which can be used in the repository
 or working copy to represent what is, from the user's point of view,
 the same filename.
 
 The problem we have on Mac OS X is that when we write any of these
 8 different byte strings to the filesystem to name the file, and later
 read the filename back from the filesystem (e.g. by opening the parent
 directory and asking for a list of files it contains), we will always
 receive the name with all a umlaut characters expanded to de-composed
 form.
 
 Now, in the working copy meta data (.svn/wc.db) we can use any of 8 forms
 of the filename. If we don't use NFC for all characters in the filename,
 the filename read from disk may fail to match any name stored in meta data.
 
 Let's simplify the discussion a bit by assuming only two possible ways
 of encoding a filename: One with all characters normalised to NFC, and
 one with all characters normalised to NFD. We don't really need to
 consider the mixed forms for the purpose of this 

Re: [RFC] Server Dictated Configuration

[Thomas Åkesson]

Hi all,

First of all, thanks for working on server dictated config and inherited 
properties. We use Subversion as the core of a Document CMS (with focus on 
structured XML authoring). Some of the components we develop are available as 
open-source: http://repossearch.com/

We would be absolutely thrilled to see inherited properties implemented! There 
are many potential use cases for us, configuration of our services being one of 
the most imminent. Our primary input to this thread is that we would very much 
like inherited properties to be a generic feature accessible to other uses than 
core Subversion, preferably with API-support.


On 28 jan 2012, at 10:30, Ivan Zhakov wrote:

 
 
 Are you suggesting that any property is inheritable simply by asking
 it to be so?  What we are talking about here is a way to differentiate
 inheritable vs. non-inheritable properties (or as Johan put it:
 discern inheritable props from normal ones).
 
 Yes, that's exactly what I proposed. But I'm fine with idea
 differentiate properties behavior using dedicated namespaces (svn:i
 and svn:inheritable:).
 

While following the thread, I have debated this with myself over the last few 
days and each approach has advantages. 

Consumer inheritance (the property consumer decides which are inheritable)
 + Less effort to implement
 + No difficulty defining what makes a property inheritable
 - Access control issues/regression. Personally, I would be ok with a 
regression along the lines that a user with access further down the tree is 
allowed to read properties on the parent directories (the user already knows 
about them from the URL). The only users objecting to that regression are 
those that store secret information in properties on directories (rare?). The 
bigger problem is that it is counter-intuitive behaviour to disclose those 
properties.
 - Performance and difficulty for the consumer (but more flexibe).

Defined inheritance (the server decides)
 - More effort to implement.
 - Needs a definition of which properties are inheritable. I would suggest a 
server config (regex perhaps) that defaults to matching *:inherit:*, 
potentially limiting the first * to a single prefix (disallow ':'). If someone 
has used xyz:inherit:* the server can be configured more restrictively with 
svn:inherit:*.
 - Less flexible with regards to different merging/override behaviour when 
property is defined on multiple directories.
 + Defined, and fairly intuitive access control behaviour.
 + Possibility to provide better APIs


I am fine with either way, but I am swaying towards defined inheritance 
mainly because of the last item, better APIs. Both the WC and the server 
could make it much simpler for the consumer to read and set inherited 
properties. Specifically, the server is in a much better position to 
efficiently (fewer round-trips) respond to proplist AND provide a single 
proplist containing both regular and inherited properties.


/Thomas Å.