On Thu, Jul 29, 2010 at 6:50 PM, Joe Swatosh wrote:
> On Thu, Jul 29, 2010 at 4:58 PM, Bert Huijben wrote:
> Hi Bert (or whoever may look into this before tomorrow),
>
> I was working on two sets of test failures and screwed up on when
> things started. This failure actually started in r964036
On Thu, Jul 29, 2010 at 4:58 PM, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Joe Swatosh [mailto:joe.swat...@gmail.com]
>> Sent: vrijdag 30 juli 2010 1:46
>> To: dev@subversion.apache.org; julian.f...@wandisco.com
>> Subject: Re: svn commit: r959954 -
>> /subversion/trunk/subver
On 07/29/2010 08:54 PM, Mike Dixon wrote:
> On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
>> On 07/29/2010 12:28 PM, Mark Phippard wrote:
>>> If we just do the redirects, might a user just not perceive SVN as
>>> being slow?
>>
>> Well, the redirect should be a one-time event. The working copy is
On 7/29/2010 9:43 AM, C. Michael Pilato wrote:
On 07/29/2010 12:28 PM, Mark Phippard wrote:
If we just do the redirects, might a user just not perceive SVN as being slow?
Well, the redirect should be a one-time event. The working copy is updated
(using svn_client_relocate()) to point to the n
> -Original Message-
> From: Joe Swatosh [mailto:joe.swat...@gmail.com]
> Sent: vrijdag 30 juli 2010 1:46
> To: dev@subversion.apache.org; julian.f...@wandisco.com
> Subject: Re: svn commit: r959954 -
> /subversion/trunk/subversion/libsvn_wc/wc.h
>
> On Fri, Jul 2, 2010 at 4:28 AM, wro
On Fri, Jul 2, 2010 at 4:28 AM, wrote:
> Author: julianfoad
> Date: Fri Jul 2 11:28:39 2010
> New Revision: 959954
>
> URL: http://svn.apache.org/viewvc?rev=959954&view=rev
> Log:
> Enable the pristine text store: bump the WC format to 17 and define
> SVN_EXPERIMENTAL_PRISTINE.
>
Hi Julian,
So
On Thu, Jul 29, 2010 at 04:20:16PM -0500, Peter Samuelson wrote:
> > The Subversion project has much closer ties to various Linux
> > distributions now than it had around the time of the 1.6 pre-release
> > phase. This is partly due to efforts by elego -- we actively help out
> > with the official
[Stefan Sperling]
> Because of the substantial changes done for 1.7, we will need
> pre-release testing more than ever. So doing source-only 1.7 preview
> releases would pose a major problem. We will have to actively push
> for pre-release testing by providing binaries.
I've always shied away fro
> -Original Message-
> From: Stefan Küng [mailto:tortoise...@gmail.com]
> Sent: Thursday, July 29, 2010 12:08 PM
> To: Hyrum K. Wright
> Cc: Talden; Subversion Development
> Subject: Re: 1.7 Release Plan
>
> On Thu, Jul 29, 2010 at 04:43, Hyrum K. Wright
> wrote:
> > The project doesn't
> -Original Message-
> From: Branko Čibej [mailto:br...@xbc.nu]
> Sent: Thursday, July 29, 2010 10:05 AM
> To: dev@subversion.apache.org
> Subject: Re: Suggestion: Transparent Branching
>
> On 07.07.2010 18:29, Greg Hudson wrote:
> > On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
On 07/29/2010 12:27 PM, Stefan Sperling wrote:
> BTW, can the client end up being redirected from a https:// URL to
> a http:// URL, or to an svn:// or svn+ssh:// URL? If we decide not
> to prompt, we should not allow URLs to be downgraded to less secure
> schemes. And even if we do prompt we shoul
On Thu, Jul 29, 2010 at 04:19:02AM -0500, Peter Samuelson wrote:
>
> [Stefan Sperling]
> > So my vote is: leave it as is, but print a more informative error message
> > suggesting to create the file (so that people don't have to post to
> > users@ to be instructed to do so), and make svnadmin upgr
On Thu, Jul 29, 2010 at 11:24 AM, C. Michael Pilato
wrote:
> On 07/29/2010 12:15 PM, Mark Phippard wrote:
>> On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
>> wrote:
>>> b) If the prompting approach is preferred, what's a reasonable way to do
>>> this? The notification function cannot serve
On 07/29/2010 12:28 PM, Mark Phippard wrote:
> On Thu, Jul 29, 2010 at 12:24 PM, C. Michael Pilato
> wrote:
>
>> I was originally thinking "off by default", but only because of the
>> theoretical security implications of being automatically redirected to a URL
>> (possibly a different machine, et
On 07/29/2010 12:27 PM, Stefan Sperling wrote:
> Allowing N redirects by default, and when N is reached printing a message
> saying that people can raise or lower the number of allowed relocation
> attempts from the configuration file sounds fine.
>
> In case a client ends up being mis-redirected,
On Thu, Jul 29, 2010 at 12:24 PM, C. Michael Pilato
wrote:
> I was originally thinking "off by default", but only because of the
> theoretical security implications of being automatically redirected to a URL
> (possibly a different machine, etc.) that differs from what you expected.
> Maybe I'm o
On Thu, Jul 29, 2010 at 12:09:19PM -0400, C. Michael Pilato wrote:
> Fer yer reference: http://subversion.tigris.org/issues/show_bug.cgi?id=2779
>
> I've got Subversion on the issue-2779-dev branch able to follow redirects
> from the server without user verification, with a hard-coded limit as to
On 07/29/2010 12:15 PM, Mark Phippard wrote:
> On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
> wrote:
>> b) If the prompting approach is preferred, what's a reasonable way to do
>> this? The notification function cannot serve as a prompt. We could add a
>> redirection_callback_func to the
On Thu, Jul 29, 2010 at 12:09 PM, C. Michael Pilato
wrote:
> b) If the prompting approach is preferred, what's a reasonable way to do
> this? The notification function cannot serve as a prompt. We could add a
> redirection_callback_func to the likes of svn_client_update,
> svn_client_checkout, s
> On 29.07.2010 16:28, Bob Archer wrote:
> >> Sorta kinda. Let's use our own tree as an example. We start
> with
> >> an empty checkout of the root of our project:
> >>
> >> $ svn co --depth empty
> http://svn.apache.org/repos/asf/subversion
> >> \ subversion $ cd subversion
> >>
> >> Now you dec
On 29.07.2010 16:28, Bob Archer wrote:
Sorta kinda. Let's use our own tree as an example. We start with
an empty checkout of the root of our project:
$ svn co --depth empty http://svn.apache.org/repos/asf/subversion
\ subversion $ cd subversion
Now you decide that you want the trunk code for
Fer yer reference: http://subversion.tigris.org/issues/show_bug.cgi?id=2779
I've got Subversion on the issue-2779-dev branch able to follow redirects
from the server without user verification, with a hard-coded limit as to the
number of hops to follow before quitting, and with notification to the
> Sorta kinda. Let's use our own tree as an example. We start with
> an empty checkout of the root of our project:
>
> $ svn co --depth empty http://svn.apache.org/repos/asf/subversion
> \
> subversion
> $ cd subversion
>
> Now you decide that you want the trunk cod
Sorta kinda. Let's use our own tree as an example. We start with an empty
checkout of the root of our project:
$ svn co --depth empty http://svn.apache.org/repos/asf/subversion \
subversion
$ cd subversion
Now you decide that you want the trunk code for our cmdline
On 07/28/2010 01:51 PM, julianf...@apache.org wrote:
> Author: julianfoad
> Date: Wed Jul 28 17:51:10 2010
> New Revision: 980139
>
> URL: http://svn.apache.org/viewvc?rev=980139&view=rev
> Log:
> Rename some function parameters for clarity: where "xxx1" and "xxx2"
> represent two paths in a paren
On Thu, Jul 29, 2010 at 4:59 AM, Stefan Sperling wrote:
> On Wed, Jul 28, 2010 at 09:43:13PM -0500, Hyrum K. Wright wrote:
>> On Wed, Jul 28, 2010 at 6:28 PM, Talden wrote:
>> >> It looks like we might be fairly close to having on-disk formats
>> >> stabilized, and hence rolling alphas. Prerelea
On Thu, Jul 29, 2010 at 02:54:29PM +0200, Stefan Sperling wrote:
> On Thu, Jul 29, 2010 at 12:43:56PM -, dan...@apache.org wrote:
> > Author: dannas
> > Date: Thu Jul 29 12:43:56 2010
> > New Revision: 980427
> >
> > URL: http://svn.apache.org/viewvc?rev=980427&view=rev
> > Log:
> > Make 'svn
On Thu, Jul 29, 2010 at 12:43:56PM -, dan...@apache.org wrote:
> Author: dannas
> Date: Thu Jul 29 12:43:56 2010
> New Revision: 980427
>
> URL: http://svn.apache.org/viewvc?rev=980427&view=rev
> Log:
> Make 'svn patch' do notifications for property hunks.
>
> We use the same notification act
On 29/07/10 10:59, Stefan Sperling wrote:
[snip]
> For the platforms mentioned above, I will try to push for 1.7 binaries
> during all phases of pre-release testing (alpha, beta, rc).
> To encourage wide testing, the plan is to make these available in
> conveniently installable form:
> - launchpa
On Thu, Jul 29, 2010 at 04:43, Hyrum K. Wright
wrote:
> The project doesn't typically provide binaries, partly because there
> are so many different combinations that it's hard to justify which
> ones to build and which not too.
>
> However, providing binaries of these releases may be really usefu
On Wed, Jul 28, 2010 at 09:43:13PM -0500, Hyrum K. Wright wrote:
> On Wed, Jul 28, 2010 at 6:28 PM, Talden wrote:
> >> It looks like we might be fairly close to having on-disk formats
> >> stabilized, and hence rolling alphas. Prereleases may be fairly
> >> prolific, since I want to work the bugs
On Wed, 2010-07-28 at 22:40 +0300, Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Jul 28, 2010 at 15:38:01 +0100:
> > You're talking about a totally new option, one that says "I'd like to
> > add all the files affected to a (specified) changelist."
> >
> > That sounds like it could be a useful f
[Stefan Sperling]
> So my vote is: leave it as is, but print a more informative error message
> suggesting to create the file (so that people don't have to post to
> users@ to be instructed to do so), and make svnadmin upgrade create it.
I guess the common case is that the source of a hotcopy is
On Wed, Jul 28, 2010 at 03:22:58PM -0500, Hyrum K. Wright wrote:
> Forgive my rambling.
>
> Over the past few months, I've noticed something: Subversion
> development is fun again. I don't know if it's the fact that we're
> all working hard on a difficult problem, or that the code is changing
> r
On Wed, Jul 28, 2010 at 10:55:39PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
> > But there's no harm in making svn patch interpret existing move information
> > in git diffs. We can carry out a corresponding copy + delete.
> > We won't be generating
On 07.07.2010 18:29, Greg Hudson wrote:
> On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
>
>> So therefor, what we would like to see is to be able to have a transparent
>> branch: One which fetches updates from both branch and trunk, without having
>> them listed as changes or triggering
On 28.07.2010 12:06, Daniel Näslund wrote:
> * base85 encode binary content
>
Does git do that? Hmmm ... I'd have used base64 myself, not quite as
compact but a lot more existing tools and libraries understand it.
-- Brane
On 28.07.2010 21:55, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
>
>> But there's no harm in making svn patch interpret existing move information
>> in git diffs. We can carry out a corresponding copy + delete.
>> We won't be generating move git diff head
38 matches
Mail list logo
