Hi,
Von: Stefan Sperling [mailto:s...@elego.de]
On Thu, Feb 09, 2012 at 12:20:14AM +0900, Hiroaki Nakamura wrote:
> > [Upgrade options / backwards compatibility for proposed unicode
> > normalization fix]
> - Need to re-checkout existing working copies of the repository?
> => Yes, but only i
On Thu, Feb 9, 2012 at 2:33 AM, Johan Corveleyn wrote:
> Having another look at this failure ...
>
> So far, we know (anyone, correct me if I'm wrong):
>
> - 'svnrdump load' in this test fails with: "svnrdump: E140001:
> Unrecognized record type in stream". It seems the dumpfile contents of
> the
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
"uni
Having another look at this failure ...
So far, we know (anyone, correct me if I'm wrong):
- 'svnrdump load' in this test fails with: "svnrdump: E140001:
Unrecognized record type in stream". It seems the dumpfile contents of
the file D/H/psi is split incorrectly (property content is dumped
early,
Nick Hengeveld writes:
> It was a bug related to tag versions, and we just deployed a fix. I was
> able to do a checkout with a 1.7 client, let me know if you have any
> problems.
Oooh! Nasty client crash:
Awc/tags/v0.3/3rdParty/xunit/xunit.extensions.xml
Awc/tags/v0.3/3rdParty/xunit
Nick Hengeveld writes:
> We're not returning the new custom headers, so I'd expected that ra_serf
> would fall back.
As Greg explained serf doesn't get this far, probably because the
request with "Transfer-encoding: chunked" is rejected by the server.
Using neon, which also has v2 support, does
Hiroaki Nakamura wrote on Thu, Feb 09, 2012 at 07:16:57 +0900:
> 2012/2/9 Stefan Sperling :
> > - What happens if NFC/NFD is enabled in repository config, but the
> > repository contains non-normalised paths (i.e. did not go through
> > a dump/load cycle to normalise all paths)?
>
> I think w
[snipping the parts I concur with]
Paul Burba wrote on Wed, Feb 08, 2012 at 17:08:57 -0500:
> On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf wrote:
> > Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
> >> Hi All,
> >>
> >> There has long been a desire for Subversion to support some form o
Hi, thanks for your review.
2012/2/9 Stefan Sperling :
> Open questions:
Here I try to answer these. Of course, I welcome everyone to answer.
>
> - How can the client retrieve the configuration from the server?
> This is related to server-dictated configuration, see
> http://wiki.apache.org
On Mon, Feb 6, 2012 at 7:20 PM, Daniel Shahaf wrote:
> Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
>> Hi All,
>>
>> There has long been a desire for Subversion to support some form of
>> inherited properties. Recently, while discussing a potential solution
>> for server dictated conf
On Tue, Feb 7, 2012 at 4:24 PM, Stefan Fuhrmann wrote:
> On 07.02.2012 00:41, Greg Stein wrote:
>>
>> In most data storage mechanisms for the repository, inheritable
>> properties are a performance killer.
>
>
> I'm not sure that this is actually applicable to SVN
> for two reasons:
> (1) we use d
I think the document that I'd read previously was this:
http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/http-protocol-v2.txt
In particular, this section:
ra_serf will send an OPTIONS request when creating a new
ra_session. mod_dav_svn will send back what it already sen
That pointed me in the right direction, thanks.
It was a bug related to tag versions, and we just deployed a fix. I was
able to do a checkout with a 1.7 client, let me know if you have any
problems.
On Wed, Feb 8, 2012 at 12:41 PM, C. Michael Pilato wrote:
> The GitHub server is definitely tryi
Nick Hengeveld wrote on Wed, Feb 08, 2012 at 12:34:52 -0800:
> Thanks for checking - we want to be fully compatible so any information
> like this helps.
>
> The checkout URL is the same as the HTTP clone URL, and the .git suffix is
> optional for both git and svn clients.
>
> I may have misunder
Thanks for checking - we want to be fully compatible so any information
like this helps.
The checkout URL is the same as the HTTP clone URL, and the .git suffix is
optional for both git and svn clients.
I may have misunderstood what's up with the ra_serf library, I thought that
was related to HTT
On Wed, Feb 8, 2012 at 15:51, Greg Stein wrote:
>...
> This looks like the problem where ra_serf starts out with an HTTP/1.1
> request: specifically, a chunked request. This is typically caused by
> a non-1.1 proxy in front of the server, such as nginx.
>
> Ideally, github would switch to a newer/
On Wed, Feb 8, 2012 at 14:47, C. Michael Pilato wrote:
> I'm happy to try it with 1.7, too, but couldn't easily figure out the
> correct checkout URL:
>
> $ svn co https://github.com/NuGet/PoliteCaptcha.git
> svn: E175009: Unable to connect to a repository at URL
> 'https://github.com/NuGet/Polite
The GitHub server is definitely trying to transmit the svn:entry: property
set ("svn:entry:committed-rev", "svn:entry:committed-date",
"svn:entry:last-author"), as can be seen in your output below. But there
are some places where it fails to do so.
For example, the directory
"/home/cmpilato/tests
I'm happy to try it with 1.7, too, but couldn't easily figure out the
correct checkout URL:
$ svn co https://github.com/NuGet/PoliteCaptcha.git
svn: E175009: Unable to connect to a repository at URL
'https://github.com/NuGet/PoliteCaptcha.git'
svn: E175009: XML parsing failed: (411 Length Required
C. Michael Pilato collab.net> writes:
>
> Well, supported by whom?
>
> At first blush, it would appear that the GitHub server didn't transmit a
> valid svn:entry:committed-rev property value for one of the directories your
> checkout is attempting to register with Subversion's working copy
> a
Hi Daniel,
> But I also think the more important question to answer is the one from my
> previous mail --- where in principle does the "is backportable?" line pass
> for the bindings (like the feature/bugfix distinction in the core
> libraries), and on what side on it does adding the unlock_prompt
Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 18:49:44 +0100:
> > >> So, you are saying that there is no legitimate/supported scenario in
> > >> which the .py and .so are out of sync with each other?
> I can't provide anything authorative on that, other than that
> "make install-swig-py" seems t
Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 18:49:44 +0100:
> In any case, I don't really know what the best course of action here is.
> It seems backporting wouldn't cause any real problems, but I'm not
> completely aware of the existing practices and policies within the
> project...
The gene
[ starting a new thread, as the previous has been seriously hijacked ]
Is there any sense of closure on the serf+windows test failure on the
1.7.x branch? My sense is that the failure does *not* expose a new
bug on the branch, but rather smokes out an existing one. If that is
the case, I am not
> >> So, you are saying that there is no legitimate/supported scenario in
> >> which the .py and .so are out of sync with each other?
I can't provide anything authorative on that, other than that
"make install-swig-py" seems to install them together and that I can't
think of any legitimate scenari
Philip Martin wrote on Wed, Feb 08, 2012 at 17:36:17 +:
> Stefan Sperling writes:
>
> > On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
> >> So, you are saying that there is no legitimate/supported scenario in
> >> which the .py and .so are out of sync with each other? And tha
Stefan Sperling writes:
> On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
>> So, you are saying that there is no legitimate/supported scenario in
>> which the .py and .so are out of sync with each other? And that code
>> written for a library version that has the symbol will retur
On Wed, Feb 08, 2012 at 07:01:48PM +0200, Daniel Shahaf wrote:
> So, you are saying that there is no legitimate/supported scenario in
> which the .py and .so are out of sync with each other? And that code
> written for a library version that has the symbol will return a normal
> error (eg, Attribu
On Tue, Feb 7, 2012 at 10:55 PM, Greg Stein wrote:
> That log message doesn't describe the change. You were already computing and
> passing a checksum.
>
> Maybe the bug was that you did not close TARGET to finalize the checksum
> computation?
I think that makes sense. Looking at other receivers
Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 17:10:54 +0100:
> Hi Daniel,
>
> > If we backport your unlock_prompt_func patches to 1.7.3, someone
> > downgrading the bindings from 1.7.3 to 1.7.2 will get runtime linker
> > errors, correct? If so we cannot backport it.
> I think that will not ha
On Thu, Feb 09, 2012 at 12:20:14AM +0900, Hiroaki Nakamura wrote:
> 2012/1/30 Stefan Sperling :
> > I think the following caveats would be acceptable if they help
> > with fixing the issue:
> >
> > - An upgrade path which optionally requires people to check all
> > working copies out again, when
Hi Daniel,
> If we backport your unlock_prompt_func patches to 1.7.3, someone
> downgrading the bindings from 1.7.3 to 1.7.2 will get runtime linker
> errors, correct? If so we cannot backport it.
I think that will not happen, since the C function is defined in the
bindings, not in the main subve
2012/1/30 Stefan Sperling :
> I think the following caveats would be acceptable if they help
> with fixing the issue:
>
> - An upgrade path which optionally requires people to check all
> working copies out again, when either the server or the client is upgraded.
> Note again, this must be _op
Matthijs Kooijman wrote on Wed, Feb 08, 2012 at 13:55:33 +0100:
> Hey Stefan,
>
> > For example, the addition of new functions prevents people from rolling
> > back to an earlier 1.7 patch release without breaking scripts which were
> > modified to use the new functions after updating to 1.7.3. Th
Hey Stefan,
> For example, the addition of new functions prevents people from rolling
> back to an earlier 1.7 patch release without breaking scripts which were
> modified to use the new functions after updating to 1.7.3. That would
> be a violation of our release compatibility guidelines.
Hmm, th
On Wed, Feb 08, 2012 at 01:28:48PM +0100, Matthijs Kooijman wrote:
> Looking at the branches available, I think these changes would become
> available in the 1.8.0 release? Any chance of backporting them to 1.7
> (This is not hugely important, but it would help getting my patches to
> git-svn accep
Hi folks,
thanks to the hard work by Stefan and Daniel (and lots of mail exchanges
between us), my patches are in! Thanks for that! Now I can start bugging
the git-svn folks to apply my other set of patches ;-)
Looking at the branches available, I think these changes would become
available in the
Philip Martin writes:
> The dump editor used by svnrdump doesn't use an explicit file baton, it
> simply uses the editor baton to collect the data for the "current" file.
To a certain extent this means that svnrdump works by accident. The
editor API allows a driver to open multiple files and ho
38 matches
Mail list logo
