On Thu, Aug 30, 2012 at 7:22 PM, Daniel Shahaf wrote:
> Which _shell_ you were using had an impact? I can see how the terminal
> emulator in use, the $TERM value, etc would have an impact... but why
> does the identity of svn's parent process have any effect?
Yes, the underlying terminal emulato
Justin Erenkrantz wrote on Thu, Aug 30, 2012 at 06:20:41 -0400:
> On Thu, Aug 30, 2012 at 3:11 AM, Johan Corveleyn wrote:
> > But more to the point: anybody have a solution in mind? If it's not
> > Windows-only then some Windows defines wont help of course. Buffering
> > the output may be the only
Bert Huijben wrote on Thu, Aug 30, 2012 at 20:41:38 +0200:
>
>
> > -Original Message-
> > From: danie...@apache.org [mailto:danie...@apache.org]
> > Sent: donderdag 30 augustus 2012 16:34
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1378960 - in /subversion/trunk/tools/
On 08/30/2012 10:45 AM, Ivan Zhakov wrote:
> On Thu, Aug 30, 2012 at 4:56 PM, C. Michael Pilato
> wrote:
>> Theoretically, though, it seems reasonable that my approach would have the
>> distinct non-feature of potentially having the client caching the properties
>> for an entire tree in memory, j
> -Original Message-
> From: danie...@apache.org [mailto:danie...@apache.org]
> Sent: donderdag 30 augustus 2012 16:34
> To: comm...@subversion.apache.org
> Subject: svn commit: r1378960 - in /subversion/trunk/tools/server-
> side/svnpubsub: README.txt svnwcsub.py
>
> Author: danielsh
>
André Colomb writes:
>After some more testing, I have found another problem with the
>svn-status mode in psvn.el. The attached patches extend on the previous
>one to also make ediff-mode work again with psvn.el.
>
>[...]
>
>The previously proposed patch by Koji Nakamaru addressed an error when
>tr
Hi, Julian,
Von: Julian Foad [mailto:julianf...@btopenworld.com]
>
> Markus Schaber wrote:
> > I’m given a working copy and a merge from URL.
> >
> > Is there any easy heuristics I can implement using the SVN
> > 1.7 APIs to guide my user whether a sync-merge or a reintegrate merge
> > is appropr
Stefan Sperling wrote:
> The 1.6.17 release introduced a regression in write-through proxying
> that can break commits to paths which need to be URI-encoded (see
> r1088602 nomination in 1.6.x STATUS).
>
> This is a conundrum for 1.6.x users who serve write-through proxy
> locations as well as ma
Markus Schaber wrote:
> I’m given a working copy and a merge from URL.
>
> Is there any easy heuristics I can implement using the SVN
> 1.7 APIs to guide my user whether a sync-merge or a
> reintegrate merge is appropriate? I want to display a warning
> message when the merge will most likely fail
Well atm there's only one worker thread, so
the assumption is correct. It's probably
a future-proof assumption as well going forward
should Greg increase the worker thread pool
for whatever reason- it's certainly not needed
with our current deployments.
>
> Fro
Would appreciate a review of this revision.
In particular I assumed that _update() will never be run by two threads
concurrently on the same wc path.
Thanks
Daniel
danie...@apache.org wrote on Thu, Aug 30, 2012 at 15:12:32 -:
> Author: danielsh
> Date: Thu Aug 30 15:12:32 2012
> New Revisio
unsubscribe
On Thu, Aug 30, 2012 at 4:56 PM, C. Michael Pilato wrote:
> On 08/30/2012 08:05 AM, C. Michael Pilato wrote:
>> On 08/30/2012 06:10 AM, Justin Erenkrantz wrote:
>>> On Wed, Aug 29, 2012 at 4:04 PM, C. Michael Pilato
>>> wrote:
I misremembered Greg and Justin's attitude toward my approach, t
On 08/30/2012 08:05 AM, C. Michael Pilato wrote:
> On 08/30/2012 06:10 AM, Justin Erenkrantz wrote:
>> On Wed, Aug 29, 2012 at 4:04 PM, C. Michael Pilato
>> wrote:
>>> I misremembered Greg and Justin's attitude toward my approach, thinking they
>>> were just flatly opposed. As I re-read the rele
Hi,
I'm given a working copy and a merge from URL.
Is there any easy heuristics I can implement using the SVN 1.7 APIs to guide my
user whether a sync-merge or a reintegrate merge is appropriate? I want to
display a warning message when the merge will most likely fail.
I know that SVN 1.8 does
On 08/30/2012 06:10 AM, Justin Erenkrantz wrote:
> On Wed, Aug 29, 2012 at 4:04 PM, C. Michael Pilato
> wrote:
>> I misremembered Greg and Justin's attitude toward my approach, thinking they
>> were just flatly opposed. As I re-read the relevant threads, though, I
>> think it's clear that perhap
On Thu, Aug 30, 2012 at 1:12 PM, Branko Čibej wrote:
> On 30.08.2012 13:02, Johan Corveleyn wrote:
> > But won't the output thread then take just as long, so the user still
> > has to wait until that is finished? There is not much point (from the
> > users perspective) in having the checkout fini
On 30.08.2012 13:02, Johan Corveleyn wrote:
> But won't the output thread then take just as long, so the user still
> has to wait until that is finished? There is not much point (from the
> users perspective) in having the checkout finished after 25 minutes,
> if the output still keeps coming in fo
On Thu, Aug 30, 2012 at 12:20 PM, Justin Erenkrantz
wrote:
> On Thu, Aug 30, 2012 at 3:11 AM, Johan Corveleyn wrote:
>> But more to the point: anybody have a solution in mind? If it's not
>> Windows-only then some Windows defines wont help of course. Buffering
>> the output may be the only way to
The 1.6.17 release introduced a regression in write-through proxying
that can break commits to paths which need to be URI-encoded (see
r1088602 nomination in 1.6.x STATUS).
This is a conundrum for 1.6.x users who serve write-through proxy
locations as well as master locations from the same server.
On 30.08.2012 12:20, Justin Erenkrantz wrote:
> Another approach is to split out the notification writes to a
> different thread...it'd stop the blockage issue. Fun...but, I don't
> think we're using threading anywhere in the client right now...
Sure, but there's nothing preventing us from having
On Thu, Aug 30, 2012 at 12:19 PM, Stefan Fuhrmann
wrote:
> On 8/30/12, Johan Corveleyn wrote:
>> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
>> wrote:
>>> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn
>>> wrote:
Yep, redirecting to a file eliminates the bottleneck (almost the sam
On Thu, Aug 30, 2012 at 3:11 AM, Johan Corveleyn wrote:
> But more to the point: anybody have a solution in mind? If it's not
> Windows-only then some Windows defines wont help of course. Buffering
> the output may be the only way to eliminate this bottleneck? What are
> the pros and cons, and how
On 8/30/12, Johan Corveleyn wrote:
> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
> wrote:
>> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn
>> wrote:
>>> Yep, redirecting to a file eliminates the bottleneck (almost the same
>>> as redirecting to NUL) (I ran it a couple of times to make
On Wed, Aug 29, 2012 at 4:04 PM, C. Michael Pilato wrote:
> I misremembered Greg and Justin's attitude toward my approach, thinking they
> were just flatly opposed. As I re-read the relevant threads, though, I
> think it's clear that perhaps both my approach and their PROPFIND-Depth-1
> approach
On Thu, Aug 30, 2012 at 11:45 AM, Branko Čibej wrote:
> On 30.08.2012 09:40, Daniel Shahaf wrote:
>> Johan Corveleyn wrote on Thu, Aug 30, 2012 at 09:11:08 +0200:
>>> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
>>> wrote:
On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn wrote:
>
On 30.08.2012 09:40, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Thu, Aug 30, 2012 at 09:11:08 +0200:
>> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
>> wrote:
>>> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn wrote:
Yep, redirecting to a file eliminates the bottleneck (almost t
Johan Corveleyn wrote on Thu, Aug 30, 2012 at 09:11:08 +0200:
> On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
> wrote:
> > On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn wrote:
> >> Yep, redirecting to a file eliminates the bottleneck (almost the same
> >> as redirecting to NUL) (I ran it
On Wed, Aug 29, 2012 at 4:22 AM, Justin Erenkrantz
wrote:
> On Tue, Aug 28, 2012 at 7:22 PM, Johan Corveleyn wrote:
>> Yep, redirecting to a file eliminates the bottleneck (almost the same
>> as redirecting to NUL) (I ran it a couple of times to make sure the
>> server cache was hot):
>
> FWIW, I
29 matches
Mail list logo
