Karl Fogel wrote on Thu, 7 Jan 2010 at 00:28 -0500:
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/ajax/%3c4b42936d.10...@mark.mielke.cc%3e
>
If you remove the /ajax/ manually, you'd get the page you wanted.
[Peter Samuelson]
> Something like the following (untested) against 1.6.x.
Well, it almost worked. Here's one, also for 1.6.x, that seems to pass
the tests. Edgar, can you test this on your NFS client?
I'll commit the trunk version of this soon if no one objects. It
shouldn't need a new test;
Karl Fogel writes:
>"Hyrum K. Wright" writes:
>>You may also want to contact the mod_mbox folks:
>>http://httpd.apache.org/mod_mbox/
>
>Done.
To be clearer: https://issues.apache.org/bugzilla/show_bug.cgi?id=48500
-K
"Hyrum K. Wright" writes:
>You may also want to contact the mod_mbox folks:
>http://httpd.apache.org/mod_mbox/
Done.
On Jan 7, 2010, at 12:00 AM, Karl Fogel wrote:
> Ed writes:
>> Correction. Now I know how to reproduce this.
>>
>> Select the first link. Right click on one message (any one will
>> do) and the select Open in New Tab or Open in New Window. Then
>> presto, what is seen in the second link.
>>
Ed writes:
>Correction. Now I know how to reproduce this.
>
>Select the first link. Right click on one message (any one will
>do) and the select Open in New Tab or Open in New Window. Then
>presto, what is seen in the second link.
>
>Is it a bug, or is it just the actual display of what the
>li
Mark Mielke wrote:
On 01/07/2010 12:30 AM, Ed wrote:
Correction. Now I know how to reproduce this.
Select the first link. Right click on one message (any one will
do) and the select Open in New Tab or Open in New Window. Then
presto, what is seen in the second link.
Is it a bug, or is it ju
On 01/07/2010 12:30 AM, Ed wrote:
Correction. Now I know how to reproduce this.
Select the first link. Right click on one message (any one will
do) and the select Open in New Tab or Open in New Window. Then
presto, what is seen in the second link.
Is it a bug, or is it just the actual displa
Mark Mielke wrote:
On 01/07/2010 12:21 AM, Ed wrote:
Karl Fogel wrote:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/ajax/%3c4b42936d.10...@mark.mielke.cc%3e
produces what you see in the following description:
The message is displayed in a horribly broken way in t
On 01/07/2010 12:47 AM, Mark Mielke wrote:
On 01/07/2010 12:21 AM, Ed wrote:
But what I don't know how to produce is how to get from the first link
to the second link without clicking directly on the second link.
Clicking on the first link, and then clicking on subsequent links
(any one) produce
Ed wrote:
Karl Fogel wrote:
Not sure of the proper place to report this, and subversion.apache.org
doesn't say (which is in itself a bug, though one that's likely to get
fixed soon), so I'm posting here (in case it helps for anyone to know),
and I'll post separately to Apache's infrastructure li
On 01/07/2010 12:21 AM, Ed wrote:
Karl Fogel wrote:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/ajax/%3c4b42936d.10...@mark.mielke.cc%3e
produces what you see in the following description:
The message is displayed in a horribly broken way in the browser. At
the
Karl Fogel wrote:
Not sure of the proper place to report this, and subversion.apache.org
doesn't say (which is in itself a bug, though one that's likely to get
fixed soon), so I'm posting here (in case it helps for anyone to know),
and I'll post separately to Apache's infrastructure list.
In Fir
Not sure of the proper place to report this, and subversion.apache.org
doesn't say (which is in itself a bug, though one that's likely to get
fixed soon), so I'm posting here (in case it helps for anyone to know),
and I'll post separately to Apache's infrastructure list.
In Firefox 3.5.6, I visite
On 01/06/2010 11:04 PM, Greg Hudson wrote:
On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote:
There is a race between the pull
and push whereby somebody who pushes before I pull will cause my push to
fail, but we generally consider this a good thing as it allows us to
analyze the change a
>> NO, Client is unaware of existence of master or proxying scheme at all.
>The client doesn't need to know about the master, it just marks the
>PROPFINDs associated with MKACTIVITYs as special.
May be we can achieve this via some ra_session's priv data structure. I just
tend to think what if we
On Wed, 2010-01-06 at 21:26 -0500, Mark Mielke wrote:
> There is a race between the pull
> and push whereby somebody who pushes before I pull will cause my push to
> fail, but we generally consider this a good thing as it allows us to
> analyze the change and determine whether additional testing
I believe these Ruby bindings failures to be specific to the setup of
the svnserve on *nix, because these are the only tests that use
@repos_svnserve_uri. I cannot reproduce on Windows. Can anyone help?
--
Joe
On Wed, Jan 6, 2010 at 11:06 AM, wrote:
> Full details are available at:
> http://c
Hi
On the assumption that there is such an e-mail as
svn-break...@subversion.apache.org, the following patch
changes the e-mail address. Of course, if there doesn't
exist such an e-mail address, I suppose this patch
assumes one will exist?
Edmund
Log:
[[[
Updated the crash report e-mail addr
Julian Foad wrote:
The report of "success" indicates a bug in the test harness. We had (and
still have) similar problems with the Linux test harness.
I'm still having slight difficulties understanding these tests
in the regards that an XFAIL is a success despite it being
expected to fail.
But
On 01/06/2010 12:12 PM, Greg Hudson wrote:
On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote:
* No commitment to mixed-revision working copies.
That sounds interesting, but I haven't got to grips with what it really
means in terms of user work flows, and in what senses it is a
Hi,
Thanks to Bert's help, I managed to get the majority of the
tests to pass.
With the exception of Copy_test #79, which 'succeeds'(as an XFAIL);
but actually crashes.
I have attached a crash report.
Debugging it in VS2008 was fruitless aside for the same message:
In file '..\..\..\subversi
kmra...@rockwellcollins.com wrote:
> Julian Foad wrote on 01/06/2010 10:16:55 AM:
>
> > Greg Hudson wrote:
> > > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote:
> > > > "To be a compelling replacement for git/Mercurial", perhaps?
> > >
> > > That seems tough.
> >
> > Heh. A vision
[Edgar Fuß]
> To summarise the problem: recursive directory deletion fails because entries
> re-appear after dir rewinding. The fix may be as easy as ignoring ENOENT.
Or not calling rewind. Something like the following (untested) against
1.6.x. Same patch applies to trunk except for some confli
Nobody fancy taking a look at this ? Seems like it a bug with a good
test case and I can't see it recorded elsewhere. Did I post to the
proper place ?
On Wed, 2010-01-06 at 11:16 -0500, Julian Foad wrote:
> > * No commitment to mixed-revision working copies.
>
> That sounds interesting, but I haven't got to grips with what it really
> means in terms of user work flows, and in what senses it is an important
> functional restriction versus an ad
Hello,
may I humbly ask what the state of affairs rergarding Issue #3501 is?
For me, ths problem forces us to stay with Subversion 1.4.
Is the issue considered fixed, irrelevant, non-reproducable, a NetBSD problem,
a non-issue or not severe enough to be fixed?
To summarise the problem: recursive
"Kamesh Jayachandran" writes:
>>So, on the client side libsvn_ra_neon and libsvn_ra_serf could track
>>whether the PROPFIND needs to go to the master or the slave and then
>>add a suitable header to the request. libsvn_client doesn't need to
>>change (which is what I think Justin and Mike are su
>sufficient, because, for example, "svn commit" followed immediately by
>"svn up" should be guaranteed to update the WC to at least the revision
>number of the commit, whereas with the proposed operation-name scheme I
>think it would update to the last cached revision which can be older
>than the c
>>>Let me see if I've got this right. There is a MKACTIVITY that goes to
>>>the master, then a PROPFIND that goes to the slave, and finally a
>>>CHECKOUT that goes to master. The MKACTIVITY and CHECKOUT go to the
>>>master because they are obviously write operations, the PROPFIND goes
>>>to the
Made the move in r896614, and filed INFRA-2421 to request the reconfiguration
of svnpubsub.
-Hyrum
On Jan 5, 2010, at 1:06 PM, Hyrum K. Wright wrote:
>
> On Jan 5, 2010, at 1:02 PM, Greg Stein wrote:
>
>> It's more than just a folder rename, since we have to reconfigure
>> stuff on the server
Julian,
>As I understand it, the proxy was designed originally with some rules
>that effectively said something like
> * The following operations are passed through to the master:
>MKACTIVITY ...
Add MERGE, LOCK, UNLOCK and any request having '!svn' in its URI.
> * The following operation
"Kamesh Jayachandran" writes:
>>Let me see if I've got this right. There is a MKACTIVITY that goes to
>>the master, then a PROPFIND that goes to the slave, and finally a
>>CHECKOUT that goes to master. The MKACTIVITY and CHECKOUT go to the
>>master because they are obviously write operations, t
>With all due respect, the proposed solution looks enormous compared to the
>size of the problem.
It looks enormous for the sheer volume of signature changes! apart from the
code change is minimal.
I tend to imagine(may be artificially) its other uses unrelated to this thread.
>Does the orig
Julian Foad wrote on 01/06/2010 10:16:55 AM:
> Greg Hudson wrote:
> > On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote:
> > > "To be a compelling replacement for git/Mercurial", perhaps?
> >
> > That seems tough.
>
> Heh. A vision that's simple to attain is hardly a vision.
I person
>Let me see if I've got this right. There is a MKACTIVITY that goes to
>the master, then a PROPFIND that goes to the slave, and finally a
>CHECKOUT that goes to master. The MKACTIVITY and CHECKOUT go to the
>master because they are obviously write operations, the PROPFIND goes
>to the slave beca
On Sun, 2009-12-27, David Glasser wrote:
> That's great to hear!
>
> What's the effect on WCs? Do WCs with the bad rev get "fixed" on
> update? Do WCs that never had the bad rev skip over it fine?
Hi Dave.
At the moment, WCs with the bad rev get broken in some way that I have
yet to investigate.
On Wed, Jan 6, 2010 at 8:51 AM, Stefan Sperling wrote:
> On Tue, Jan 05, 2010 at 06:33:01PM -0600, Hyrum K. Wright wrote:
>> On Jan 5, 2010, at 6:22 PM, Paul Burba wrote:
>> > Assuming my fix looks right, how do we do this? Create a "backport"
>> > branch from 1.6.x, make the change there, and no
On Wed, Jan 6, 2010 at 3:54 AM, Julian Foad wrote:
> Joe Swatosh wrote:
>> Even though this isn't happening on trunk, it occurs to be to wonder
>> if these tests shouldn't be included on trunk to prevent possible
>> segfaults in the future?
>
> Yes, that would be sensible.
Done r896522.
Paul
On Wed, Jan 6, 2010 at 12:01 PM, Hyrum K. Wright
wrote:
>
> On Jan 6, 2010, at 10:48 AM, pbu...@apache.org wrote:
>
>> Author: pburba
>> Date: Wed Jan 6 16:48:38 2010
>> New Revision: 896522
>>
>> URL: http://svn.apache.org/viewvc?rev=896522&view=rev
>> Log:
>> New test for 'svn resolve -R --acce
I (Julian Foad) wrote:
> On Wed, 2010-01-06 at 08:37 -0800, Justin Erenkrantz wrote:
> > On Wed, Jan 6, 2010 at 7:54 AM, Mark Phippard wrote:
> > > Apparently, the PROPFIND is using the proxy at a time when it needs to
> > > be using the master.
> >
> > The client has no knowledge of the master -
On Wed, 2010-01-06 at 08:37 -0800, Justin Erenkrantz wrote:
> On Wed, Jan 6, 2010 at 7:54 AM, Mark Phippard wrote:
> > Apparently, the PROPFIND is using the proxy at a time when it needs to
> > be using the master.
>
> The client has no knowledge of the master - the slave a completely
> transpare
On Jan 6, 2010, at 10:48 AM, pbu...@apache.org wrote:
> Author: pburba
> Date: Wed Jan 6 16:48:38 2010
> New Revision: 896522
>
> URL: http://svn.apache.org/viewvc?rev=896522&view=rev
> Log:
> New test for 'svn resolve -R --accept [base | theirs-full | mine-full]'.
>
> This works fine on trunk
[Julian Foad]
> > * No commitment to mixed-revision working copies.
>
> That sounds interesting, but I haven't got to grips with what it
> really means in terms of user work flows, and in what senses it is an
> important functional restriction versus an advantage.
That's one of those features
On Tue, 2009-12-22, Kannan wrote:
> I (Kannan) wrote:
> [..]
> >>> (svn_ra_neon__exchange_capabilities): Same.
> >> And this?
>
> > Trying to find them out.
>
> With regard to this change, AFAICS the `activity_collection' value is
> set in `svn_ra_neon__request_dispatch' where its obtained in t
On Wed, Jan 6, 2010 at 7:54 AM, Mark Phippard wrote:
> Apparently, the PROPFIND is using the proxy at a time when it needs to
> be using the master.
The client has no knowledge of the master - the slave a completely
transparent proxy. The only way to distinguish between a PROPFIND for
an update
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bert Huijben wrote:
[..]
> In entries we have two storage locations: On the parent entries file and on
> the entries file of the directory itself.
>
> For the depth argument the parent can only contain exclude and infinity. The
> more detailed statuse
Greg Hudson wrote:
> On Mon, 2010-01-04 at 11:31 -0500, C. Michael Pilato wrote:
> > "To be a compelling replacement for git/Mercurial", perhaps?
>
> That seems tough.
Heh. A vision that's simple to attain is hardly a vision.
What we can usefully do is identify popular features of git/Mercurial
Ed wrote:
> During the copy_tests (specifically #7), I would get a dialog which
> states:
[...]
> The application has requested the Runtime to terminate it
> in an unusual way.
>
> Ditto with update_tests.py but it gave me an AppCrash dialog:
[...]
> with both crashes, I can close the prog
On Wed, Jan 6, 2010 at 10:48 AM, Julian Foad wrote:
> My concern is whether the new rules are just papering over a crack or
> whether they correctly take into account all the ways in which a client
> might depend on accessing the newly created revision.
My understanding is that these commits fai
Kamesh Jayachandran wrote:
> mod_dav_svn on the proxy should identify whether a given PROPFIND is for
> commit or *not*, we are not bothered about any of the other read
> operation intricasies.
As I understand it, the proxy was designed originally with some rules
that effectively said something
Philip Martin wrote:
> Kamesh Jayachandran writes:
>
>> This patch is with respect to the original thread
>>
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/browser
>
> This one I suppose:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/<4b41f1bd.8
Kamesh Jayachandran writes:
>> Would it be possible for the server to detect the slave error and
>> then try the master?
>
> In fact Master is the one that gives the vague error as snipped below.
>
>
>
> "The specified baseline is not the latest baseline, so it may not be
> checked out."
>
> B
On 01/06/2010 06:58 PM, Bert Huijben wrote:
-Original Message-
From: Kamesh Jayachandran [mailto:kam...@collab.net]
Sent: woensdag 6 januari 2010 14:00
To: dev@subversion.apache.org
Subject: [PATCH] Make svn clients indicate their operation name to
backend(right now only to DAV)
Hi
Would it be possible for the server to detect the slave error and then
try the master?
In fact Master is the one that gives the vague error as snipped below.
"The specified baseline is not the latest baseline, so it may not be checked
out."
But it would be too late for the Master to
Kamesh Jayachandran writes:
> First I had a plan to persist the occurence of preceding 'MKACTIVITY'
> on the connection pool to classify subsequent PROPFIND on same
> connection as 'commit PROPFIND'.
That does sound like a better solution, but I suppose it depends on
how clients use connections.
Julian,
Let me explain the strategy.
mod_dav_svn on the proxy should identify whether a given PROPFIND is for
commit or *not*, we are not bothered about any of the other read
operation intricasies.
First I had a plan to persist the occurence of preceding 'MKACTIVITY' on
the connection pool
On 01/06/2010 07:32 PM, Philip Martin wrote:
Kamesh Jayachandran writes:
This patch is with respect to the original thread
http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/browser
This one I suppose:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201001
Kamesh,
Can you explain your strategy for fixing the original "commit via
outdated proxy" issue, and why this change is part of that strategy?
Something about this approach doesn't feel right to me, as I don't see
how a single word can accurately convey the proxy semantics of a
high-level command.
Kamesh Jayachandran writes:
> This patch is with respect to the original thread
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/browser
This one I suppose:
http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/<4b41f1bd.8090...@collab.net>
It includes:
On Tue, Jan 05, 2010 at 06:33:01PM -0600, Hyrum K. Wright wrote:
> On Jan 5, 2010, at 6:22 PM, Paul Burba wrote:
> > Assuming my fix looks right, how do we do this? Create a "backport"
> > branch from 1.6.x, make the change there, and nominate it for backport
> > yes?
>
> I haven't looked at the
> -Original Message-
> From: Bert Huijben [mailto:b...@qqmail.nl]
> Sent: woensdag 6 januari 2010 14:28
> To: 'Kamesh Jayachandran'; dev@subversion.apache.org
> Subject: RE: [PATCH] Make svn clients indicate their operation name to
> backend(right now only to DAV)
>
>
>
> > -Origin
> -Original Message-
> From: Kamesh Jayachandran [mailto:kam...@collab.net]
> Sent: woensdag 6 januari 2010 14:00
> To: dev@subversion.apache.org
> Subject: [PATCH] Make svn clients indicate their operation name to
> backend(right now only to DAV)
>
> Hi All,
>
> This patch is with resp
On 01/06/2010 06:41 PM, Senthil Kumaran S wrote:
C. Michael Pilato wrote:
Kamesh Jayachandran wrote:
With& Without this patch mergeinfo_test-8 fails both over ra_neon and
ra_serf.
Ooh! I was *just* about to start debugging my mergeinfo_test-8 failures on
the issue-3242-dev
C. Michael Pilato wrote:
> Kamesh Jayachandran wrote:
>> With & Without this patch mergeinfo_test-8 fails both over ra_neon and
>> ra_serf.
>
> Ooh! I was *just* about to start debugging my mergeinfo_test-8 failures on
> the issue-3242-dev branch when I happened to see this part of your mail.
> I
Kamesh Jayachandran wrote:
> With & Without this patch mergeinfo_test-8 fails both over ra_neon and
> ra_serf.
Ooh! I was *just* about to start debugging my mergeinfo_test-8 failures on
the issue-3242-dev branch when I happened to see this part of your mail.
I'll still debug, but it's good to kno
Jack Repenning wrote:
> On Jan 4, 2010, at 5:48 AM, Mark Phippard wrote:
>
>> Could we just declare that the paths are passed as UTF-8 strings?
>
> Any chance of declaring that the paths are not only UTF-8, but also
> *composed* UTF-8?
That's an even bigger can of worms; we don't even guarantee th
Greg Stein wrote:
> Neels,
>
> I saw your IRC asking about an Apache account. I never even requested
> one for you because I had no idea you'd sent in an ICLA. The
> spreadsheet that I sent out was the indicator that I needed to do
> something, and it wasn't updated. I verified that your ICLA has
Ping! This patch has not been reviewed the last 8 days.
On Tue, Dec 29, 2009 at 07:44:49PM +0100, Daniel Näslund wrote:
> Hi!
>
> [[[
> Fix issue #3483 - extend svn_client_upgrade() to include externals. I've
> done the externals upgrading after wc upgrade is finished. In that way
> no errors in
On Wed, Dec 30, 2009 at 02:11:31PM +, Stefan Sperling wrote:
> On Wed, Dec 30, 2009 at 07:45:12AM +0100, Daniel Näslund wrote:
> > + err = svn_wc__node_get_url(&url, cb->ctx->wc_ctx,
> > + abs_parent_dir, cb->pool, cb->pool);
> > +
> > + /* If we're doing an 'svn
Bert Huijben wrote:
DEBUG ERROR
Program:
d:\other_projs\svn\trunk\Debug\subversion\svn\svn.exe
^
The application has requested the Runtime to terminate it
in an unusual way.
This is a known issue in APR. Apr doesn't like when any of the active drives
has a lower cas
> -Original Message-
> From: Ed [mailto:e...@kdtc.net]
> Sent: woensdag 6 januari 2010 7:21
> To: Subversion Dev
> Subject: copy_test, update crash and dirent_uri failure on Windows
>
> Hi,
>
> It's been some time since I last compiled svn on my Windows box; but,
> as far as I can recal
Joe Swatosh wrote:
> Even though this isn't happening on trunk, it occurs to be to wonder
> if these tests shouldn't be included on trunk to prevent possible
> segfaults in the future?
Yes, that would be sensible.
- Julian
Julian Foad wrote:
Minor aesthetic change, but one I do agree. One concern I also
had was "am I complicating matters more by introducing so many
different mtimes?"
I'm not 100% clear what those properties are for, but I'm pretty sure
you are complicating matters too much by suggesting them.
74 matches
Mail list logo
