See Branko's reaction for why the atomic handling will be necessary when you
don't want to hardcode hardware assumptions. Bugs in these assumptions are
exactly the problem we try to solve here.
This implementation idea is copied from how Microsoft implemented some of
their thunking in a
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
On 12/11/13 5:18 AM, Thomas Åkesson wrote:
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
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,
It would be nice to have SVN book versions on the website that have a
differing portions of the text in blue for changes, and green for new
additions and red for now obsolete parts.
It would make re-reading the book for a new version much easier for old
hands, you could immediately spot
On 12/11/13 4:25 PM, Gabriela Gibson wrote:
It would be nice to have SVN book versions on the website that have a
differing
portions of the text in blue for changes, and green for new additions and red
for now obsolete parts.
It would make re-reading the book for a new version much easier
6 matches
Mail list logo
