[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Discussion message digest

From: <dev-digest_at_subversion.tigris.org>
Date: Sun, 12 Jul 2009 00:16:52 -0700 (PDT)

Here are the messages that have been received prior to 7/12/09 12:16 AM:

Topic (messages 47,099 through 47,134):

r38410 - trunk/subversion/libsvn_auth_gnome_keyring
         47,123 by : Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA_at_GMail.Com> sent on : Sat, 11 Jul 2009 19:19:11 +0200
          47,101 by : Lieven Govaerts <svnlgo_at_mobsol.be> sent on : Sat, 11 Jul 2009 09:27:35 +0200
          47,102 by : Lieven Govaerts <svnlgo_at_mobsol.be> sent on : Sat, 11 Jul 2009 09:28:39 +0200
 
Mass config with mod_dav_svn
         47,114 by : Chris Nagele <wildbit_at_gmail.com> sent on : Fri, 10 Jul 2009 18:51:36 -0400
 
Patch Submissions that seem to have received no attention.
         47,115 by : Gavin Baumanis <gavinb_at_eclinic.com.au> sent on : Sat, 11 Jul 2009 11:57:06 +1000
 
Discussion message digest
         47,099 by : dev-digest_at_subversion.tigris.org sent on : Sat, 11 Jul 2009 00:15:23 -0700 (PDT)
 
Mismatched backwards compat callbacks in libsvn_wc
         47,121 by : =?UTF-8?B?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?= <DXDragon_at_yandex.ru> sent on : Sat, 11 Jul 2009 20:16:09 +0400
 
[PATCH] Fix python wc testcase failure
         47,133 by : =?UTF-8?B?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?= <DXDragon_at_yandex.ru> sent on : Sun, 12 Jul 2009 02:42:14 +0400
 
include libsvn_delta
         47,132 by : Neels Janosch Hofmeyr <neels_at_elego.de> sent on : Sun, 12 Jul 2009 00:33:58 +0200
          47,134 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Sun, 12 Jul 2009 01:04:48 +0100
 

+----------------------------------------------------------------------+
| ETAS Mail Security - http://intranet.etasgroup.com/encryption |
+----------------------------------------------------------------------+
| - The message was not encrypted and not digitally signed |
+----------------------------------------------------------------------+

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370733

attached mail follows:


Julian Foad wrote:
> On Thu, 2009-07-09 at 15:53 -0700, Neels Janosch Hofmeyr wrote:
>> Author: neels
>> Date: Thu Jul 9 15:53:33 2009
>> New Revision: 38394
>>
>> Log:
>> Enable an atomic replace in editor v2.
>>
>> * subversion/include/svn_editor.h
>> (svn_editor_add_directory_t, svn_editor_add_directory,
>> svn_editor_add_file_t, svn_editor_add_file,
>> svn_editor_add_symlink_t, svn_editor_add_symlink,
>> svn_editor_add_absent_t, svn_editor_add_absent):
>> Add parameter REPLACES_REV.
>
> Where is this parameter documented?

That's a very reasonable question.

So far, svn_editor.h's *only* comment is:

[[[
/** An abstract object that edits a target tree.
 *
 * ### more docco
 */
]]]

It felt kind of silly to only document that parameter in the midst of void.
And I am too lazy right now to document all of them.
However, I added a rough description in notes/editor-v2.txt in r38396.

~Neels

>
> - Julian
>
>> * subversion/libsvn_delta/editor.c
>> (svn_editor_add_directory,
>> svn_editor_add_file,
>> svn_editor_add_symlink,
>> svn_editor_add_absent):
>> Add parameter REPLACES_REV and pass to callbacks.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2369635

attached mail follows:


Jens Peters <jpeters7677_at_gmx.de> писал в своём письме Sun, 05 Jul 2009
23:49:41 +0400:

> Any thoughts?

I analyzed this and I agree with you.

It all really boils down to the following line in the function close_edit
in status.c:

const char *full_path = svn_path_join(eb->anchor, eb->target, pool);

The way the test creates the status editor, both anchor and target are
absolute paths to some temporary directory.

On Unix-likes, it's something like '/tmp/abcd123'; due to the way
svn_path_join operates, full_path becomes equal to '/tmp/abcd123', which
is correct. On Windows, it's something like 'C:\Temp\abcd123', and
full_path becomes 'C:\Temp\abcd123\C:\Temp\abcd123', which is obviously
wrong. As such, the test passed on Unixes when it was written (and
presumably still does), yet fails on Windows (and presumably did earlier).

Short version: it has nothing to do with backwards compatibility, +1 on
your patch.

Interestingly enough, on trunk the test succeeds; it happens because on
that line svn_path_join was replaced with svn_dirent_join, which does the
right thing for Windows paths too. However the doc for
svn_wc_get_status_editor5 weakly implies that target should be a relative
path, so the test still violates the contract.

Roman.

attached mail follows:


Neels J Hofmeyr wrote:
> Julian Foad wrote:
> > On Thu, 2009-07-09 at 15:53 -0700, Neels Janosch Hofmeyr wrote:
> >> Enable an atomic replace in editor v2.
> >>
> >> * subversion/include/svn_editor.h
> >> (svn_editor_add_directory_t, svn_editor_add_directory,
> >> svn_editor_add_file_t, svn_editor_add_file,
> >> svn_editor_add_symlink_t, svn_editor_add_symlink,
> >> svn_editor_add_absent_t, svn_editor_add_absent):
> >> Add parameter REPLACES_REV.
> >
> > Where is this parameter documented?

[...]
> It felt kind of silly to only document that parameter in the midst of void.
> And I am too lazy right now to document all of them.

But it's not silly. I can't review the change without knowing what it
means. I'm sure it seems totally obvious to you, but I have questions
about it.

> However, I added a rough description in notes/editor-v2.txt in r38396.

[[[
add_directory(path, children, props, replaces_rev)
  -- name all children. receiver can put on "pending" list
  -- MUST be followed (at some point) by add_*() calls for each child
  -- if replaces_rev isn't SVN_INVALID_REVNUM, this is an atomic
replace.
     Use a revnum because it implies all other info like node kind etc.
]]]

That doesn't actually say what the parameter means. Is it something like
this:

[[[
If replaces_rev is not SVN_INVALID_REVNUM:
(a) This 'add' atomically replaces the node (of kind 'file' or
'directory') that would have existed (if this call and any associated
'delete' call were ignored) at 'path' in the target revision of this
editor drive.
(b) The replaced node-rev must have unbroken history back to revision
'replaces_rev', with no modifications of any kind.
(c) A separate 'delete' of the node that previously existed should not
be issued by the driver, but must be accepted by the receiver (before or
after this call) for backward compatibility.
]]]

?

- Julian

attached mail follows:


I realize the dev list is not an ideal place for this question, but I
have tried everywhere else and hoping for help.

We run Beanstalk, which is a very popular svn hosting service. At the
moment, we have tens of thousands of customers. Each customer has
their own subdomain url to access svn, something like
https://account.svn.beanstalkapp.com.

Our problem is due to virtual hosts in Apache:

1. We have to shard Apache servers to avoid thousands of vhosts in
each apache config
2. We add many accounts per day, which requires a restart of Apache
each time. With so many vhosts, this is really slow.

So far the best option looks like mass config, but from what we know,
this is not possible with mod_dav_svn. Does anyone have any options
that could help? We're willing to explore custom apache modules, but
need the right person to work on it.

Thanks,
Chris Nagele
http://beanstalkapp.com

attached mail follows:


Hi Everyone,

As recently found out via this thread;
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370140

I earlier this month had an issue with receiving (any) email.
I "thought" I had managed to collate all patch submissions that were
entered during the time I had no email, by using the webmail archives,
but was obviously wrong.

I appreciate people initially not wanting to "step on my toes" (as it
is my role as the Patch Manager) - and thus perhaps hesitating to
"sell" their own submissions - but it is a mislaid fear.
I do review all patch submissions and wait "about a week" before re-
raising it.
If your patch submission has been without comment for more than this,
please ping the list again by replying to your original posting with a
simple "Ping." message.

Gavin.

attached mail follows:


Stefan Sperling <stsp_at_elego.de> писал в своём письме Sat, 11 Jul 2009
00:36:15 +0400:

> On Fri, Jul 03, 2009 at 01:06:23AM +0400, Роман Донченко wrote:
>> /* An svn_wc_diff_callbacks3_t function for wrapping
>> svn_wc_diff_callbacks_t. */
>> static svn_error_t *
>> -file_changed(svn_wc_adm_access_t *adm_access,
>> +wrap_3to1_file_changed(svn_wc_adm_access_t *adm_access,
>> svn_wc_notify_state_t *contentstate,
>> svn_wc_notify_state_t *propstate,
>> svn_boolean_t *tree_conflicted,
>
> Please indent the other parameters, too, so that they all align again
> as they used to.

> Same here.

> Same here.

> Same here.

> Somehow it feels like I've seen this before...

Yeah, I think I get your point. 8=] Fixed and reattached.

Roman.

attached mail follows:


attached mail follows:


+----------------------------------------------------------------------+
| ETAS Mail Security - http://intranet.etasgroup.com/encryption |
+----------------------------------------------------------------------+
| - The message was not encrypted and not digitally signed |
+----------------------------------------------------------------------+

attached mail follows:


On Sat, Jul 11, 2009 at 7:23 AM, Gavin Baumanis<gavinb_at_thespidernet.com> wrote:
> Just out of curiosity,
>
> Am I wrong is the new text in this patch, the same as the deletions?
>
It's probably a whitespace only change, but since Arfrever didn't add
a log message you can't see that from this email.

Lieven

>
>
> On 11/07/2009, at 1:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>
>> Author: arfrever
>> Date: Fri Jul 10 20:46:13 2009
>> New Revision: 38410
>>
>> Log:
>> * subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>>  (simple_gnome_keyring_first_creds, simple_gnome_keyring_save_creds,
>>   ssl_client_cert_pw_gnome_keyring_first_creds,
>>   ssl_client_cert_pw_gnome_keyring_save_creds): Fix some messages.
>>
>> Modified:
>>   trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>>
>> Modified: trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c?pathrev=38410&r1=38409&r2=38410
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> =
>> ======================================================================
>> --- trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c        Fri
>> Jul 10 14:41:48 2009  (r38409)
>> +++ trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c        Fri
>> Jul 10 20:46:13 2009  (r38410)
>> @@ -411,7 +411,7 @@ simple_gnome_keyring_first_creds(void **
>>     {
>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>                               _("GNOME Keyring is locked and "
>> -                                " we are non-interactive"));
>> +                                "we are non-interactive"));
>>     }
>>   else
>>     {
>> @@ -470,7 +470,7 @@ simple_gnome_keyring_save_creds(svn_bool
>>     {
>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_NOT_SAVED, NULL,
>>                               _("GNOME Keyring is locked and "
>> -                                " we are non-interactive"));
>> +                                "we are non-interactive"));
>>     }
>>   else
>>     {
>> @@ -566,7 +566,7 @@ ssl_client_cert_pw_gnome_keyring_first_c
>>     {
>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>                               _("GNOME Keyring is locked and "
>> -                                " we are non-interactive"));
>> +                                "we are non-interactive"));
>>     }
>>   else
>>     {
>> @@ -626,7 +626,7 @@ ssl_client_cert_pw_gnome_keyring_save_cr
>>     {
>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>                               _("GNOME Keyring is locked and "
>> -                                " we are non-interactive"));
>> +                                "we are non-interactive"));
>>     }
>>   else
>>     {
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=2370607
>
> Gavin Baumanis
> P: +61 438 545 586
> E: gavinb_at_thespidernet.com
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370613
>

attached mail follows:


On Sat, Jul 11, 2009 at 9:27 AM, Lieven Govaerts<svnlgo_at_mobsol.be> wrote:
> On Sat, Jul 11, 2009 at 7:23 AM, Gavin Baumanis<gavinb_at_thespidernet.com> wrote:
>> Just out of curiosity,
>>
>> Am I wrong is the new text in this patch, the same as the deletions?
>>
> It's probably a whitespace only change, but since Arfrever didn't add
> a log message you can't see that from this email.

Make that 'a clear log message'.

>
> Lieven
>
>
>>
>>
>> On 11/07/2009, at 1:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
>>
>>> Author: arfrever
>>> Date: Fri Jul 10 20:46:13 2009
>>> New Revision: 38410
>>>
>>> Log:
>>> * subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>>>  (simple_gnome_keyring_first_creds, simple_gnome_keyring_save_creds,
>>>   ssl_client_cert_pw_gnome_keyring_first_creds,
>>>   ssl_client_cert_pw_gnome_keyring_save_creds): Fix some messages.
>>>
>>> Modified:
>>>   trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>>>
>>> Modified: trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>>> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c?pathrev=38410&r1=38409&r2=38410
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ======================================================================
>>> --- trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c        Fri
>>> Jul 10 14:41:48 2009  (r38409)
>>> +++ trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c        Fri
>>> Jul 10 20:46:13 2009  (r38410)
>>> @@ -411,7 +411,7 @@ simple_gnome_keyring_first_creds(void **
>>>     {
>>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>>                               _("GNOME Keyring is locked and "
>>> -                                " we are non-interactive"));
>>> +                                "we are non-interactive"));
>>>     }
>>>   else
>>>     {
>>> @@ -470,7 +470,7 @@ simple_gnome_keyring_save_creds(svn_bool
>>>     {
>>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_NOT_SAVED, NULL,
>>>                               _("GNOME Keyring is locked and "
>>> -                                " we are non-interactive"));
>>> +                                "we are non-interactive"));
>>>     }
>>>   else
>>>     {
>>> @@ -566,7 +566,7 @@ ssl_client_cert_pw_gnome_keyring_first_c
>>>     {
>>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>>                               _("GNOME Keyring is locked and "
>>> -                                " we are non-interactive"));
>>> +                                "we are non-interactive"));
>>>     }
>>>   else
>>>     {
>>> @@ -626,7 +626,7 @@ ssl_client_cert_pw_gnome_keyring_save_cr
>>>     {
>>>       return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
>>>                               _("GNOME Keyring is locked and "
>>> -                                " we are non-interactive"));
>>> +                                "we are non-interactive"));
>>>     }
>>>   else
>>>     {
>>>
>>> ------------------------------------------------------
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=2370607
>>
>> Gavin Baumanis
>> P: +61 438 545 586
>> E: gavinb_at_thespidernet.com
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370613
>>
>
Received on 2009-07-12 09:45:58 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.