<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel">
    <title>gmane.comp.version-control.subversion.devel</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136043"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136042"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136041"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136040"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136039"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136038"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136037"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136036"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136035"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136034"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136033"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136032"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136031"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136030"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136029"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136028"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136027"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136026"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136025"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136024"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136043">
    <title>Subversion Exception</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136043</link>
    <description>&lt;pre&gt;---------------------------
Subversion Exception!
---------------------------
Subversion encountered a serious problem.
Please take the time to report this on the Subversion mailing list
with as much information as possible about what
you were trying to do.
But please first search the mailing list archives for the error message
to avoid reporting the same problem repeatedly.
You can find the mailing list archives at
http://subversion.apache.org/mailing-lists.html

Subversion reported the following
(you can copy the content of this dialog
to the clipboard using Ctrl-C):

In file
 'D:\Development\SVN\Releases\TortoiseSVN-1.7.7\ext\subversion\subversion\libsvn_wc\update_editor.c'
 line 1311: assertion failed (added_status == svn_wc__db_status_added ||
 added_status == svn_wc__db_status_copied || added_status ==
 svn_wc__db_status_moved_here)
---------------------------
OK
---------------------------
&lt;/pre&gt;</description>
    <dc:creator>Benjamin Lee</dc:creator>
    <dc:date>2012-05-22T14:33:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136042">
    <title>Re: ISSUE: "To many open files" not being logged by master server when sync fails.</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136042</link>
    <description>&lt;pre&gt;

I did explain in an earlier email: the problem is svnsync holding open
old revision files.  I don't know whether these are opened, and left
open, during the sync of the revisions leading up to the failed revision
or whether they are opened during the sync of the failed revision
itself.

&lt;/pre&gt;</description>
    <dc:creator>Philip Martin</dc:creator>
    <dc:date>2012-05-22T11:07:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136041">
    <title>Re: ISSUE: "To many open files" not being logged by master server when sync fails.</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136041</link>
    <description>&lt;pre&gt;Hi Philip.  Usually to reproduce a bug we only need to look as far as the first time something goes wrong.  I assume you have a specific reason in this case for thinking that the information about whether a *second* sync also fails will be helpful to you, but that may not have been clear to Kenneth.

- Julian



----- Original Message -----

&lt;/pre&gt;</description>
    <dc:creator>Julian Foad</dc:creator>
    <dc:date>2012-05-22T10:23:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136040">
    <title>Re: ISSUE: "To many open files" not being logged by master server when sync fails.</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136040</link>
    <description>&lt;pre&gt;

As far as I can see you have still failed to answer the question.  After

svnadmin create ...
svnsync init ...
svnsync sync ...  FAIL

does a subsequent 

svnsync sync ...

fail?  That's a second sync on the same repository as the first sync
without a second create or a second init.

&lt;/pre&gt;</description>
    <dc:creator>Philip Martin</dc:creator>
    <dc:date>2012-05-22T10:08:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136039">
    <title>Re: Question: Does subversion works with CMIS?</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136039</link>
    <description>&lt;pre&gt;
Hi Marius,

in the future, please post questions such as this to the users&amp;lt; at &amp;gt; list,
not the dev&amp;lt; at &amp;gt; list. Your post is off-topic for the dev&amp;lt; at &amp;gt; list but the
users&amp;lt; at &amp;gt; lists welcomes questions like yours.

If the tools you use support webdav they should be able to interface directly
with Subversion repositories. You can also mount a webdav share as a drive
and save files there. See http://svnbook.red-bean.com/en/1.7/svn.webdav.html

&lt;/pre&gt;</description>
    <dc:creator>Stefan Sperling</dc:creator>
    <dc:date>2012-05-22T09:03:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136038">
    <title>Re: ISSUE: "To many open files" not being logged by master server when sync fails.</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136038</link>
    <description>&lt;pre&gt;
I said in the previous email that the problem replicates after i create 
a new repository and init and sync!

i.e.

svnadmin create ...
svnsync init ...
svnsync sync ...

FAILS

I've tried v1.6.18 and v1.7.4 all tools use the same version of 
subversion. The output i've sent you have been from my compiled version 
of 1.6.18 with no modifications.

I'm doing a partial sync of repository from the /QLD-Releases directories.

i.e.

svnadmin create  egm
svnsync  init file://`pwd`/egm svn://voyager-svn:3691/egm/QLD-Releases
svnsync  sync file://`pwd`/egm


I have currently 11249 revisons in the main repository and all revisions 
in the /QLD-Releases directory are mostly copies of branches with no 
modifications. There are 75 branch directories in the /QLD-Releases 
directory which are copies of the trunk at varying revisions. Each 
branch within the /QLD-Releases directory has about 600 directories and 
6000 files.

Thanks,

Ken.




&lt;/pre&gt;</description>
    <dc:creator>Kenneth Miles</dc:creator>
    <dc:date>2012-05-22T01:56:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136037">
    <title>Re: svn-x64-ubuntu-gcc buildslave going dark</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136037</link>
    <description>&lt;pre&gt;On Mon, May 21, 2012 at 6:13 PM, Justin Erenkrantz
&amp;lt;justin&amp;lt; at &amp;gt;erenkrantz.com&amp;gt; wrote:

graduated &amp;gt; evicted :P

(and for those that are interested, it is the former, rather than the
latter to which I've been subjected. :) )

-Hyrum



&lt;/pre&gt;</description>
    <dc:creator>Hyrum K Wright</dc:creator>
    <dc:date>2012-05-22T00:51:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136036">
    <title>Re: svn-x64-ubuntu-gcc buildslave going dark</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136036</link>
    <description>&lt;pre&gt;On Mon, May 21, 2012 at 11:42 AM, Hyrum K Wright
&amp;lt;hyrum.wright&amp;lt; at &amp;gt;wandisco.com&amp;gt; wrote:

It seems like that configuration (Ubuntu x64) would be something that
the ASF infra team could provide in a VM quite easily if asked.  --
justin

P.S. graduated != evicted.  *duck*

&lt;/pre&gt;</description>
    <dc:creator>Justin Erenkrantz</dc:creator>
    <dc:date>2012-05-21T23:13:48</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136035">
    <title>Issue(?) with mod_dav_svn and requiring access to $reporoot</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136035</link>
    <description>&lt;pre&gt;So, 

Earlier today I was asked to open a few children from a repo that is essentially close by default. 
Some background information: 

This setup allows commits only via an https vhost, ad this is working perfectly.  The http vhost is configured to not allow read-only access to the entire repo (as is the case with the main ASF repo).
We are running apache httpd 2.2, and subversion 1.7 - from ubuntu apt repos. 

REPOROOT = /x1/source.caret.cam.ac.uk/repos/svn
WEBROOT = http://source.caret.cam.ac.uk/svn/ 
PUBLICCHILD = http://source.caret.cam.ac.uk/svn/projects/talks.cam/


We do not want to make the webroot publicly readable, but we did want to make publicchild publicly readable.  The only way I could make this happen, was to use the config below.  Basically we had to allow "GET OPTIONS PROPFIND REPORT" for the WEBROOT.  You can see, that we then do go on to explicitly deny all but a couple of options to prevent listing the entire repo. 

With this it seems that dav_svn needs access to the root of the repo &lt;/pre&gt;</description>
    <dc:creator>Tony Stevenson</dc:creator>
    <dc:date>2012-05-21T21:00:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136034">
    <title>Question: Does subversion works with CMIS?</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136034</link>
    <description>&lt;pre&gt;Hey people,

I am a designer in a 40-people company. We are using subversion, mainly for our programmers. Nevertheless, we have a group of graphic designers, which are very often designing several versions of a photoshop, indesign or illustrator file.
For these designers we would like to use the functionality of a software called Adobe Drive 3, that allows them to use version control features from within Adobe products. Unfortunately the documentation on Adobe Drive is rather bad. But obviously it cannot connect directly to subversion, but can only connect to a server, that supports the CMIS 1.0 specification from OASIS standardization group.
I heard that there might be software interfaces called Connectors that allow to establish the connection between the CMIS interface and the subversion interface.
Have you heard of this and can you give me further information about how to connect CMIS and subversion?
Any help is much appreciated.

Viele Grüße
Marius Bauer
_______________________________

Kommunikations&lt;/pre&gt;</description>
    <dc:creator>Marius Bauer</dc:creator>
    <dc:date>2012-05-21T16:29:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136033">
    <title>Re: [DISCUSS] delete ra_neon</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136033</link>
    <description>&lt;pre&gt;I think Lieven is talking about three timeout values:

1) serf context loop, set to 500ms to 1000ms, maybe.
2) iniitial response from server, set to 60 seconds?
3) continuing response from server, set to 5 seconds?

The first timeout gives us our responsiveness for a GUI. As Lieven
mentions in his reply, we can also check for cancellation in the
response handler.

The second timeout is one that Johan was concerned about: long hook
processing that delays the initial response.

The third timeout is a normal kind of networking timeout, where it may
appear the connection has dropped.

We can debate these values, but I believe the short answer is that we
can solve the cancellation problem.

Cheers,
-g

On Mon, May 21, 2012 at 1:33 PM, Bert Huijben &amp;lt;bert&amp;lt; at &amp;gt;qqmail.nl&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Greg Stein</dc:creator>
    <dc:date>2012-05-21T18:58:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136032">
    <title>Re: [DISCUSS] delete ra_neon</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136032</link>
    <description>&lt;pre&gt;Hi Bert,

On Mon, May 21, 2012 at 7:33 PM, Bert Huijben &amp;lt;bert&amp;lt; at &amp;gt;qqmail.nl&amp;gt; wrote:

1) serf uses non-blocking i/o, the only place where it can block is in
its call to apr_pollset_poll where it waits for network events. The
timeout for this call can easily be reduced to 1 second or less. This
should solve the "cancel while waiting for network traffic" scenario.

2) ra_serf can also loop without checking a cancel action, in the
response handlers svn_ra_serf__handle_xml_parser and
svn_ra_serf__handle_discard_body. While the handler is processing lots
of data, e.g a large xml report, and as long as there's data to read,
it will stay in the reading/handling loop.
The response handlers have to get access to the session object to
check on cancel_func, which they don't have right now, but that seems
like an easy thing to fix.

I don't think there are other places besides these, unless you had
other scenario's in mind when you created the issue?


Lieven

&lt;/pre&gt;</description>
    <dc:creator>Lieven Govaerts</dc:creator>
    <dc:date>2012-05-21T18:47:25</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136031">
    <title>svn-x64-ubuntu-gcc buildslave going dark</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136031</link>
    <description>&lt;pre&gt;Sometime in the next week, the svn-x64-ubuntu-gcc buildslave will go
dark.  I'm being evicted from the University, and the box is coming
along with me.  I don't know when I'll be able to get it back online,
but it probably won't be for at least three or four months.

If somebody else wants to set up a similar configuration in its place,
I'm happy to retire this one permanently.

-Hyrum


&lt;/pre&gt;</description>
    <dc:creator>Hyrum K Wright</dc:creator>
    <dc:date>2012-05-21T18:42:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136030">
    <title>Re: svn commit: r1341031 - /subversion/trunk/subversion/svn/props.c</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136030</link>
    <description>&lt;pre&gt;On May 21, 2012 11:06 AM, "Hyrum K Wright" &amp;lt;hyrum.wright&amp;lt; at &amp;gt;wandisco.com&amp;gt;
wrote:

We have svn_iter.h already, and I hate it. Setting up a baton and a
function to avoid a for-loop sucks.

An encapsulated iterator might be nice, however. Essentially a replacement
for apr_hash_index_t.

Cheers,
-g
&lt;/pre&gt;</description>
    <dc:creator>Greg Stein</dc:creator>
    <dc:date>2012-05-21T18:38:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136029">
    <title>Re: svn commit: r1339559 -/subversion/site/publish/docs/release-notes/release-history.html</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136029</link>
    <description>&lt;pre&gt;William A Rowe Jr wrote on Sun, May 20, 2012 at 18:51:36 -0500:

Sounds like this information would be useful on www.a.o/security/ ? 

Daniel


&lt;/pre&gt;</description>
    <dc:creator>Daniel Shahaf</dc:creator>
    <dc:date>2012-05-21T17:45:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136028">
    <title>RE: [DISCUSS] delete ra_neon</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136028</link>
    <description>&lt;pre&gt;Even with a sensible timeout of 20/30 seconds instead of half an hour, that
value would still be much too high for blocking a GUI tool. The cancel
problem must also be fixed.

 

You press 'Cancel' in the TortoiseSVN dialog.. And have to wait for 30
minutes until it is processed.

 

On *nix you don't have this problem for handling ^C, as that breaks IO, but
in GUIs that doesn't work.

 

                Bert

 

 

From: lieven.govaerts&amp;lt; at &amp;gt;gmail.com [mailto:lieven.govaerts&amp;lt; at &amp;gt;gmail.com] On Behalf
Of Lieven Govaerts
Sent: maandag 21 mei 2012 19:28
To: Johan Corveleyn; dev&amp;lt; at &amp;gt;subversion.apache.org
Cc: Greg Stein
Subject: Re: [DISCUSS] delete ra_neon

 

 

On Mon, May 21, 2012 at 1:47 PM, Johan Corveleyn &amp;lt;jcorvel&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

On Sat, May 19, 2012 at 9:58 PM, Greg Stein &amp;lt;gstein&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

As I said elsethread, this is probably the best overview of open
ra_serf blockers:

http://subversion.tigris.org/issues/buglist.cgi?subcomponent=libsvn_ra_serf
&amp;lt;http://subversion.tigris.org/issues/buglist.cgi?subcomponen&lt;/pre&gt;</description>
    <dc:creator>Bert Huijben</dc:creator>
    <dc:date>2012-05-21T17:33:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136027">
    <title>Re: [DISCUSS] delete ra_neon</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136027</link>
    <description>&lt;pre&gt;

I think these two issues are overlapping, at least in their root cause and
solution. Added a suggestion to issue 3968 on how to fix them.

Lieven
&lt;/pre&gt;</description>
    <dc:creator>Lieven Govaerts</dc:creator>
    <dc:date>2012-05-21T17:27:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136026">
    <title>Re: Working copy operations that are worse than O(change size)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136026</link>
    <description>&lt;pre&gt;Since we can use the amalgamated variant,
everyone should be able to build against 3.7.12.
So, +1 on the bump.

&lt;/pre&gt;</description>
    <dc:creator>Stefan Fuhrmann</dc:creator>
    <dc:date>2012-05-21T14:08:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136025">
    <title>Re: svn commit: r1341031 - /subversion/trunk/subversion/svn/props.c</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136025</link>
    <description>&lt;pre&gt;

I wrote the attached patch some time back, to experiment with the idea of making a simple-to-use hash iterator that iterates in sorted order.

- Julian&lt;/pre&gt;</description>
    <dc:creator>Julian Foad</dc:creator>
    <dc:date>2012-05-21T16:06:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136024">
    <title>Re: svn commit: r1341031 - /subversion/trunk/subversion/svn/props.c</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136024</link>
    <description>&lt;pre&gt;
If we do this on a regular basis, it might be useful to implement a
wrapper which takes a baton and handler function and then calls the
handler with the hash key/value in sorted order.  It might add some
overhead, but it also consolidates the sorting into one location,
rather than sprinkled everywhere.  It doesn't matter much to me; just
a thought that arose upon review.  :)

-Hyrum




&lt;/pre&gt;</description>
    <dc:creator>Hyrum K Wright</dc:creator>
    <dc:date>2012-05-21T15:05:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136023">
    <title>Re: Working copy operations that are worse than O(change size)</title>
    <link>http://permalink.gmane.org/gmane.comp.version-control.subversion.devel/136023</link>
    <description>&lt;pre&gt;On Sun, May 20, 2012 at 5:35 PM, Stefan Fuhrmann
&amp;lt;stefanfuhrmann&amp;lt; at &amp;gt;alice-dsl.de&amp;gt; wrote:

Should we bump the minimum required SQLite version for 1.8?

-Hyrum




&lt;/pre&gt;</description>
    <dc:creator>Hyrum K Wright</dc:creator>
    <dc:date>2012-05-21T13:40:13</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.version-control.subversion.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.version-control.subversion.devel</link>
  </textinput>
</rdf:RDF>

