On Wed, 2009-12-23 at 12:42 +0530, Kamesh Jayachandran wrote:
> On 12/23/2009 12:34 PM, Bhuvaneswaran A wrote:
> > Found this while building Subversion on Windows. This patch fixes the
> > checkout URLs in INSTALL file that were still pointing to svn.collab.net
> > repository.
> >
> > [[
> > Fix th
On 12/23/2009 12:34 PM, Bhuvaneswaran A wrote:
Found this while building Subversion on Windows. This patch fixes the
checkout URLs in INSTALL file that were still pointing to svn.collab.net
repository.
[[
Fix the checkout URLs.
* INSTALL
The repository is now in svn.apache.org.
]]
+1
Found this while building Subversion on Windows. This patch fixes the
checkout URLs in INSTALL file that were still pointing to svn.collab.net
repository.
[[
Fix the checkout URLs.
* INSTALL
The repository is now in svn.apache.org.
]]
--
Bhuvaneswaran A
CollabNet Software P Ltd. | www.c
This on IRC today:
question on `svn upgrade`, it doesn't seem to go into external dirs
is that a bug or feature?
* cmpilato flips a coin.
bug!
i can't think of a reason why you'd want to upgrade the primary
WC and not the external ones.
we could even expose the --ignore-externals option to th
I (Julian Foad) wrote:
> C. Michael Pilato wrote:
> > julianf...@apache.org wrote:
> > > Author: julianfoad
> > > Date: Tue Dec 22 18:44:27 2009
> > > New Revision: 893267
> > >
> > > URL: http://svn.apache.org/viewvc?rev=893267&view=rev
> > > Log:
> > > For obliterate in BDB, implement updating t
On Dec 22, 2009, at 2:26 PM, C. Michael Pilato wrote:
> Branko Čibej wrote:
>> If the tigris.org issues are fixed, then of course we don't need to do that.
>
> As far as I can tell, tigris.org is fine now. Jack can (please) correct me
> if I'm wrong, but my advice to Hyrum would be carry on wit
Branko Čibej wrote:
> If the tigris.org issues are fixed, then of course we don't need to do that.
As far as I can tell, tigris.org is fine now. Jack can (please) correct me
if I'm wrong, but my advice to Hyrum would be carry on with the original plan.
--
C. Michael Pilato
CollabNet <> www
C. Michael Pilato wrote:
> Branko Čibej wrote:
>
>> Hyrum K. Wright wrote:
>>
>>> We've run into a little bit of a problem with the 1.6.7 release. Just as I
>>> was preparing to roll the tarball this evening, Jack Repenning mailed me
>>> indicating there were problems with the Subversion
Branko Čibej wrote:
> Hyrum K. Wright wrote:
>> We've run into a little bit of a problem with the 1.6.7 release. Just as I
>> was preparing to roll the tarball this evening, Jack Repenning mailed me
>> indicating there were problems with the Subversion instance on tigris.org.
>> As a project,
Hyrum K. Wright wrote:
> We've run into a little bit of a problem with the 1.6.7 release. Just as I
> was preparing to roll the tarball this evening, Jack Repenning mailed me
> indicating there were problems with the Subversion instance on tigris.org.
> As a project, we've never used that inst
C. Michael Pilato wrote:
> julianf...@apache.org wrote:
> > Author: julianfoad
> > Date: Tue Dec 22 18:44:27 2009
> > New Revision: 893267
> >
> > URL: http://svn.apache.org/viewvc?rev=893267&view=rev
> > Log:
> > For obliterate in BDB, implement updating the "node-origins" table.
> >
> > * subve
Hi, Obliterate fans.
As of r893267, if you compile with "-DSVN_WITH_EXPERIMENTAL_OBLITERATE",
you get an "svn obliterate" subcommand which is capable of obliterating
the latest revision of a file. In my tests so far, it seems to work in
very limited circumstances.
You can run the "obliterate_test
julianf...@apache.org wrote:
> Author: julianfoad
> Date: Tue Dec 22 18:44:27 2009
> New Revision: 893267
>
> URL: http://svn.apache.org/viewvc?rev=893267&view=rev
> Log:
> For obliterate in BDB, implement updating the "node-origins" table.
>
> * subversion/libsvn_fs_base/bdb/node-origins-table.c
On Dec 21, 2009, at 5:58 PM, Hyrum K. Wright wrote:
Personally, I don't like any of them, and am hoping there is still
some way of using Subversion commits to www/. Thoughts?
Well, our adjustments of last night and this morning should put us
back into the same shape as before the changes t
Nicolas Dumazet writes:
> svn rm --keep-local unit_definition_interaction_workflow # shabam
$ svn --version | grep ^svn
svn, version 1.6.4 (r38063)
$ svn rm --keep-local foo/unit_definition_interaction_workflow
Segmentation fault
Seems to be fixed on the 1.6 branch:
$ subversion/svn/svn --vers
>>
>> May be I can set some persistent data structure at the connection scope
>> remembering the invocation of prior 'MKACTIVITY' and
>> decide whether it is PROPFIND for commit or 'some read ops'.
>>
>> Any thoughts!
>Perhaps have the client set a header or do something different in this
>case?
Yes, I'll try to figure it out. Just wanted to make sure that it
wasn't intentional for whatever reason.
I've already looked up strings bdb implementation and could not see
anything suspicious. Now it's time for debugger :)
Vadim
On Tue, Dec 22, 2009 at 8:37 AM, C. Michael Pilato wrote:
> IIRC,
Do you have the ability to test this on 1.6.6?
-Hyrum
On Dec 22, 2009, at 2:31 AM, Nicolas Dumazet wrote:
> Hello folks!
>
> I encountered that nice baby today:
>
> Program received signal SIGSEGV, Segmentation fault.
> svn_wc_remove_from_revision_control (adm_access=0x96a2a98, name=0xb7f6c9cb
On Tue, Dec 22, 2009 at 7:14 AM, Kamesh Jayachandran wrote:
> Hi All,
>
> Of late we have observed errors like the following when committing via the
> european mirror.
>
>
>
> "The specified baseline is not the latest baseline, so it may not be checked
> out."
>
>
> This error happens as the fol
On Tue, Dec 22, 2009 at 12:58 AM, Paul Querna wrote:
> What I found interesting is that for several tests, a significant
> portion of my 'real time' of a checkout or update was spent in
> svn_ra_serf__exchange_capabilities, detecting what features of the
> server were available.
>
> I used libclou
IIRC, it's not really 2x nodes -- it's one extra row for each string key.
So if a directory listing would normally consume a single string row, yes,
theres 1 + 1 = 2 (or, 2x) rows used. But if a file's contents would consume
10 strings rows, then it's still just the 1 additional empty row. THAT
S
Hello folks!
I encountered that nice baby today:
Program received signal SIGSEGV, Segmentation fault.
svn_wc_remove_from_revision_control (adm_access=0x96a2a98, name=0xb7f6c9cb "",
destroy_wf=0, instant_error=0, cancel_func=0x8053640
,
cancel_baton=0x0, pool=0x96a69d0) at subversion/libsv
Hi all,
Out of curiosity I wrote a script which dumps subversion bdb tables
and found interesting anomaly in "strings" table.
Every string there has a duplicate with empty value.
It is my understanding that "strings" allows duplicates to store very
large content in chunks under the same key. That'
Hi All,
Of late we have observed errors like the following when committing via
the european mirror.
"The specified baseline is not the latest baseline, so it may not be checked
out."
This error happens as the following request part of the commit operation is
*served by mirror*.
PROPFIND /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 the bo
Lieven Govaerts wrote:
> On Tue, Dec 22, 2009 at 11:58 AM, Philip Martin
> wrote:
>> Lieven Govaerts writes:
>>
>>> On Tue, Dec 22, 2009 at 10:18 AM, Philip Martin
>>> wrote:
Paul Querna writes:
> In either case, you would need somewhere to store them, and that is
> why I am w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
[..]
> Great.
>
> Did you look to see if there are any other similar calls in Subversion
> where we make the same mistake?
Couldn't find any, as of now.
[..]
>> * props.c
>> (svn_ra_neon__get_baseline_info, svn_ra_neon__get_one_p
On Tue, 2009-12-22, Kannan wrote:
> Julian Foad wrote:
> [..]
> >> No, it should create a canonical URL. The fix we need is inside
> >> svn_ra_neon__request_get_location(), or at least we need to look inside
> >> that function to see where the non-canonical URL is coming from, and
> >> maybe trace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
[..]
>> No, it should create a canonical URL. The fix we need is inside
>> svn_ra_neon__request_get_location(), or at least we need to look inside
>> that function to see where the non-canonical URL is coming from, and
>> maybe trace
On Mon, 2009-12-21 at 17:38 +0100, Bert Huijben wrote:
>
> > -Original Message-
> > From: Julian Foad [mailto:julianf...@btopenworld.com]
> > > Maybe assertions and aborts are easier for Subversion developers, but
> > they are not for our users.
> >
> > That's just stating what happens if
Stefan Sperling wrote:
> I'll stay out of the whole SVN_ERR_ASSERT discussion.
> If we boil down the diff as below is this OK?
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===
> --- subversion/libsvn_fs_fs/fs_fs.c (revision 892649)
>
On Mon, 2009-12-21, Paul Burba wrote:
> This is replicable from the command line when the svn mergeinfo target
> is a working copy path pegged at HEAD or DATE, e.g.:
>
> C:\SVN\src-trunk-2\Release\subversion\tests\cmdline\svn-test-work\working_copies\mergeinfo_tests-8>svn
> mergeinfo --show-revs e
On Tue, Dec 22, 2009 at 11:58 AM, Philip Martin
wrote:
> Lieven Govaerts writes:
>
>> On Tue, Dec 22, 2009 at 10:18 AM, Philip Martin
>> wrote:
>>> Paul Querna writes:
>>>
In either case, you would need somewhere to store them, and that is
why I am writing the dev list: Where and how
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
[..]
> OK. The policy in Subversion is that the paths and URLs passed in and
> out of all APIs are canonical unless otherwise stated. Therefore we
> should make do_checkout() set its "locn" output parameter to a canonical
> URL.
>
>
Kannan wrote:
> Julian Foad wrote:
> > do_checkout():
> > ...
> > *locn = svn_ra_neon__request_get_location(request, pool);
> >
> > checkout_resource():
> > do_checkout(cc, rsrc->vsn_url, allow_404, token, &code, &locn, pool);
> > ne_uri_parse(locn, &parse);
> > rsrc->wr_url = svn_uri_ca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Julian Foad wrote:
[..]
> Hi Kannan.
>
> With your patch, the code in "commit.c" now looks like this (ignoring
> all the error handling):
>
> do_checkout():
> ...
> *locn = svn_ra_neon__request_get_location(request, pool);
>
> checkout_resource(
Lieven Govaerts writes:
> On Tue, Dec 22, 2009 at 10:18 AM, Philip Martin
> wrote:
>> Paul Querna writes:
>>
>>> In either case, you would need somewhere to store them, and that is
>>> why I am writing the dev list: Where and how should a cache like this
>>> live?
>>
>> How about with the DAV w
On Tue, Dec 22, 2009 at 10:18 AM, Philip Martin
wrote:
> Paul Querna writes:
>
>> In either case, you would need somewhere to store them, and that is
>> why I am writing the dev list: Where and how should a cache like this
>> live?
>
> How about with the DAV wcprops in the working copy?
They wil
Edmund writes:
> +* High-level semantics we are trying to achieve:
> +
> +- Whenever Subversion puts or modifies a file (or directory) in
> + the WC, it shall set the node's mtime in the WC to the mtime
> + recorded for that node as given by the server. It also saves
> + th
On Thu, 2009-12-17, Kannan wrote:
> Julian Foad wrote:
> [..]
> > It would be great if you could trace the calls back to wherever the
> > non-canonical paths are generated, and fix them at that point.
>
> Thank you Julian, for the comments. Attached herewith is the patch to
> canonicalize the URLs
Paul Querna writes:
> In either case, you would need somewhere to store them, and that is
> why I am writing the dev list: Where and how should a cache like this
> live?
How about with the DAV wcprops in the working copy? It would mean
they would be stored in aech working copy, and only command
Hi d...@svn:
Greg sez I broke serf stuff, so today I found some time today to play
with Serf Trunk (and Subversion trunk!), yay for the holidays.
I am using Instruments.app on osx to profile basic performance of SVN,
from my parent's sloowww DSL line in Spokane, WA. (1.5mb/s down,
768 up)
David Glasser wrote on Mon, 21 Dec 2009 at 23:00 -0800:
> On Mon, Dec 21, 2009 at 9:51 PM, Justin Erenkrantz
> wrote:
> > On Mon, Dec 21, 2009 at 5:58 PM, Hyrum K. Wright
> > wrote:
> >> Personally, I don't like any of them, and am hoping there is still some
> >> way of using Subversion commits
43 matches
Mail list logo
