On 24.10.2013 22:36, Ben Reser wrote:
> On 10/24/13 11:44 AM, Maximo, Andre (GE Global Research) wrote:
>> void CVCS::svnURLPath(CString& urlPath, const CString &fullPath)
>>
>> {
>>
>> apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
>>
>> const char *url = NULL;
>>
>> svn_error_t *err
On 10/24/13 11:44 AM, Maximo, Andre (GE Global Research) wrote:
> void CVCS::svnURLPath(CString& urlPath, const CString &fullPath)
>
> {
>
> apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
>
> const char *url = NULL;
>
> svn_error_t *err = svn_client_url_from_path2(&url, fullPath, m
On 24.10.2013 20:44, Maximo, Andre (GE Global Research) wrote:
>
> Hi Bert,
>
>
>
> thanks for your prompt reply. Here is the code:
>
>
>
> void CVCS::svnURLPath(CString& urlPath, const CString &fullPath)
>
> {
>
> apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
>
> const char *url
On 24.10.2013 14:12, Ryan Schmidt wrote:
> On Oct 24, 2013, at 07:02, Philip Martin wrote:
>
>> I don't think upgrade is resposible.
> You are correct; sorry for the noise. I have consulted my backups from before
> upgrading Subversion and verified that the permissions are wrong there too,
> and
On 10/24/13 11:44 AM, Maximo, Andre (GE Global Research) wrote:
> void CVCS::svnURLPath(CString& urlPath, const CString &fullPath)
>
> {
>
> apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
>
> const char *url = NULL;
>
> svn_error_t *err = svn_client_url_from_path2(&url, fullPath, m
On 24.10.2013 14:03, Ryan Schmidt wrote:
> I’m not sure if there’s a more direct way to find this out, but I used “svn
> info” on the file to find its checksum, then looked for a file with that
> basename in .svn/pristine at the root of the working copy. This file has a
> recent modification tim
On 24.10.2013 14:08, Attila Nagy wrote:
> On 10/22/13 09:56, Branko Čibej wrote:
>> On 22.10.2013 07:13, Branko ?ibej wrote:
>>> On 21.10.2013 18:16, Attila Nagy wrote:
On 10/15/2013 08:09 AM, Attila Nagy wrote:
> I store OS images in svn, so I need to record file permissions and
> own
If you pass an invalid path then err will be set to an error that explains that
you set an invalid path and (like in almost every Subversion function) the
output arguments are completely undefined when the function returns an error.
(There are/were a few exceptions where for very specific error
Hi Bert,
thanks for your prompt reply. Here is the code:
void CVCS::svnURLPath(CString& urlPath, const CString &fullPath)
{
apr_pool_t *local_pool = svn_pool_create(m_svn_pool);
const char *url = NULL;
svn_error_t *err = svn_client_url_from_path2(&url, fullPath, m_svn_ctx,
m_svn_pool, l
Without more context I can't see what is wrong with the original code.
The second argument is passed by value and the local value is overwritten only
in the function when the old pointer is never used again. This is valid in C
and this code is tested by our testsuite as far as I can tell.
Do
Hi,
the function "svn_client_url_from_path2" in "libsvn_client/url.c" re-uses the
const char* argument "path_or_url" as both output and input of the
svn_dirent_get_absolute call and this causes the function to crash. The
crashing line is:
SVN_ERR(svn_dirent_get_absolute(&path_or_url, path_o
On Oct 24, 2013, at 07:02, Philip Martin wrote:
> I don't think upgrade is resposible.
You are correct; sorry for the noise. I have consulted my backups from before
upgrading Subversion and verified that the permissions are wrong there too, and
I now recall having recursively changed the permi
On Oct 24, 2013, at 06:47, Nico Kadel-Garcia wrote:
> On Thu, Oct 24, 2013 at 7:33 AM, Ryan Schmidt wrote:
>> While upgrading my laptop to OS X 10.9 Mavericks yesterday I finally took
>> the plunge and upgraded Subversion 1.6.x to 1.8.3, using MacPorts. I had
>> held off on the upgrade because
Ryan Schmidt writes:
> Is this loss-of-executable-bit-on-upgrade problem already known or
> should file a bug report? I did not immediately see a matching ticket
> in the issue tracker.
I don't think upgrade is resposible. Can you be certain that the files
had the execute bit before the upgrade
On Thu, Oct 24, 2013 at 7:33 AM, Ryan Schmidt <
subversion-20...@ryandesign.com> wrote:
> While upgrading my laptop to OS X 10.9 Mavericks yesterday I finally took
> the plunge and upgraded Subversion 1.6.x to 1.8.3, using MacPorts. I had
> held off on the upgrade because of initial reports of wor
While upgrading my laptop to OS X 10.9 Mavericks yesterday I finally took the
plunge and upgraded Subversion 1.6.x to 1.8.3, using MacPorts. I had held off
on the upgrade because of initial reports of working copy corruption when
upgrading to the new Subversion 1.7 working copy format, especiall
On Oct 24, 2013, at 03:59, Chris Rodgers
wrote:
> I am trying to serve a number of repositories from one server via https with
> different IP range restrictions applied to each. I do not want to show the
> names of the repositories to clients requesting https://server/repos/ .
>
> I am gettin
Good question.. Yes I have!
And I can see the change because https://server/repos/ now gives a 404 which it
didn't originally.
C
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> -Original Message-
> From: Chris Rodgers [mailto:christopher.rodg...@cardiov.ox.ac.uk]
> Sent: 24 October 2013 09:59
>
> Dear Mark and Ryan,
>
> Thank you for your comments.
>
> I am trying to serve a number of repositories from one server
> via https
> with different IP range restr
Dear Mark and Ryan,
Thank you for your comments.
I am trying to serve a number of repositories from one server via https
with different IP range restrictions applied to each. I do not want to
show the names of the repositories to clients requesting
https://server/repos/ .
I am getting warni
20 matches
Mail list logo
