You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Achim Spangler <Ac...@mnet-online.de> on 2008/08/04 11:12:14 UTC

Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Hi,
as this bug report wasn't processed for 1.5.1 release, I tried to get some 
clues on this problem on my own.

As far as I understand the code, the problem seems to depend on 
libsvn_client/externals.c with the function:
static svn_error_t *
handle_externals_desc_change(const void *key, apr_ssize_t klen,
                             enum svn_hash_diff_key_status status,
                             void *baton)


There the SVN_ERR macro is used to bail out from the loop, as soon as a 
problem is found:
==========================================================
  /* We must use a custom version of svn_hash_diff so that the diff
     entries are processed in the order they were originally specified
     in the svn:externals properties. */

  for (i = 0; old_desc && (i < old_desc->nelts); i++)
    {
      item = APR_ARRAY_IDX(old_desc, i, svn_wc_external_item2_t *);

      if (apr_hash_get(new_desc_hash, item->target_dir, APR_HASH_KEY_STRING))
        SVN_ERR(handle_external_item_change(item->target_dir,
                                            APR_HASH_KEY_STRING,
                                            svn_hash_diff_key_both, &ib));
      else
        SVN_ERR(handle_external_item_change(item->target_dir,
                                            APR_HASH_KEY_STRING,
                                            svn_hash_diff_key_a, &ib));
    }
  for (i = 0; new_desc && (i < new_desc->nelts); i++)
    {
      item = APR_ARRAY_IDX(new_desc, i, svn_wc_external_item2_t *);
      if (! apr_hash_get(old_desc_hash, item->target_dir, 
APR_HASH_KEY_STRING))
        SVN_ERR(handle_external_item_change(item->target_dir,
                                            APR_HASH_KEY_STRING,
                                            svn_hash_diff_key_b, &ib));
    }
==========================================================


===>>
With some luck, it is enough to replace the SVN_ERR call so that no 
hidden "return svn_err__temp;" is executed. Maybe a call 
to "svn_handle_warning2(...)" would help.

The main change steps could be:
a) collect several warnings - up to one per svn:externals entry to some sort
   of list
b) adapt error structure, so that upper caller level notifies this as
   warning and not error
  
Maybe it would even be enough to collect the errors from the different 
svn:externals entries in this function - and return this collection as normal 
error - as the svn:externals seem to be processed at the end, nothing else 
would get lost by a termination after all of those items.

I hope that some other more experienced SVN-Developers can find an appropriate 
solution.

I would be very happy, to see this problem fixed in 1.5.2, as it is very 
irritating for users, when the complete "svn up" is aborted, only if the user 
doesn't have enough access rights for some of the contained svn:externals 
items.

Kind Regards,
Achim Spangler
www.isoaglib.org
http://projects.osb-ag.de/svn/OSB/IsoAgLib/IsoAgLib/



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by Karl Fogel <kf...@red-bean.com>.
Achim.Spangler@mnet-online.de writes:
> Do you have any other idea to issue a warning from library to
> application - instead of the normal error message?
> An "svn up" should continue with other "svn:externals" items, even if
> another previously checked "svn:externals" item triggers an error.
>
> So - should I implement chaining individual error log entries per
> processed "svn:externals" and then return the error-chain at the end
> of "handle_externals_desc_change()"?

I think the way to do this is to collect ("accummulate") the errors into
a chain, and return that chain at the end, with a specified leading
error that is documented to mean "errors were encountered while
processing externals".  Then the caller can identify the nature of the
chain easily, and handle it however it wants, including by displaying a
warning.

By the way, this is similar to the problem I was having with

   http://subversion.tigris.org/issues/show_bug.cgi?id=3246#desc5

...which I discussed further in the thread linked to from here:

   http://subversion.tigris.org/issues/show_bug.cgi?id=3246#desc7

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by Ac...@mnet-online.de.
Hi,

Zitat von David Glasser <gl...@davidglasser.net>:

> On Mon, Aug 4, 2008 at 9:07 AM, Julian Foad   
> <ju...@btopenworld.com> wrote:
>> On Mon, 2008-08-04 at 17:51 +0200, Achim Spangler wrote:
>>> Dear Blair,
>>> do you know any place in SVN source code, where:
>>> + different errors are combined to a list
>>>   -> is there already infrastructure or reference style
>>>      for this case?
>>
>> Every error can have other errors attached to it in a chain. One example
>> of doing this is in unsupported_diff_error() in
>> subversion/libsvn_client/diff.c.
Thanks - I will have a look for this example.
>>
>>> + low level error is interpreted at caller side just as
>>>   warning
>>>   -> I found no call of the new functions svn_handle_warning2()
>>>      and svn_handle_warning()
>>
>> [[[
>> $ grep svn_handle_warning subversion/*/*.c
>> subversion/libsvn_subr/error.c:svn_handle_warning(FILE *stream,
>> svn_error_t *err)
>> subversion/libsvn_subr/error.c:  svn_handle_warning2(stream, err, "svn:
>> ");
>> subversion/libsvn_subr/error.c:svn_handle_warning2(FILE *stream,
>> svn_error_t *err, const char *prefix)
>> subversion/svn/main.c:          svn_handle_warning(stderr, err);
>> subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
>> subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
>> subversion/svn/props.c:      svn_handle_warning(stderr, err);
>> subversion/svn/resolve-cmd.c:          svn_handle_warning(stderr, err);
>> subversion/svn/resolved-cmd.c:          svn_handle_warning(stderr, err);
>> subversion/svn/util.c:                svn_handle_warning(stderr, err);
>> subversion/tests/svn_test_fs.c:  svn_handle_warning(stderr, err);
>> ]]]
>
> The key thing you need to notice here is that you can't call
> svn_handle_warning from our libraries, only from the svn command-line
> client.
Do you have any other idea to issue a warning from library to  
application - instead of the normal error message?
An "svn up" should continue with other "svn:externals" items, even if  
another previously checked "svn:externals" item triggers an error.

So - should I implement chaining individual error log entries per  
processed "svn:externals" and then return the error-chain at the end  
of "handle_externals_desc_change()"?

Thanks,
Achim
>>
>>> The problem is, that "handle_externals_desc_change()" has no access to the
>>> output stream, where a warning message could get displayed. Thus a local
>>> solution in the scope of "handle_externals_desc_change()" seems to be not
>>> possible. Now I'm looking for an appropriate way to get the error   
>>> information
>>> as warning information at the initial caller.
>>>
>>> As soon, as somebody can help me with these questions, I can try to find a
>>> real solution.
>>>
>>> Thanks,
>>> Achim
>>> Am Montag, 4. August 2008 schrieben Sie:
>>> > On Aug 4, 2008, at 4:12 AM, Achim Spangler wrote:
>>> > > Hi,
>>> > > as this bug report wasn't processed for 1.5.1 release, I tried to
>>> > > get some
>>> > > clues on this problem on my own.
>>> >
>>> > Hi Achim,
>>> >
>>> > If you can supply a patch and test case to implement the desired
>>> > behavior, I can review it and commit it if it passes review.
>>> >
>>> > Regards,
>>> > Blair
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>>
>
>
>
> --
> David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by David Glasser <gl...@davidglasser.net>.
On Mon, Aug 4, 2008 at 9:07 AM, Julian Foad <ju...@btopenworld.com> wrote:
> On Mon, 2008-08-04 at 17:51 +0200, Achim Spangler wrote:
>> Dear Blair,
>> do you know any place in SVN source code, where:
>> + different errors are combined to a list
>>   -> is there already infrastructure or reference style
>>      for this case?
>
> Every error can have other errors attached to it in a chain. One example
> of doing this is in unsupported_diff_error() in
> subversion/libsvn_client/diff.c.
>
>> + low level error is interpreted at caller side just as
>>   warning
>>   -> I found no call of the new functions svn_handle_warning2()
>>      and svn_handle_warning()
>
> [[[
> $ grep svn_handle_warning subversion/*/*.c
> subversion/libsvn_subr/error.c:svn_handle_warning(FILE *stream,
> svn_error_t *err)
> subversion/libsvn_subr/error.c:  svn_handle_warning2(stream, err, "svn:
> ");
> subversion/libsvn_subr/error.c:svn_handle_warning2(FILE *stream,
> svn_error_t *err, const char *prefix)
> subversion/svn/main.c:          svn_handle_warning(stderr, err);
> subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
> subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
> subversion/svn/props.c:      svn_handle_warning(stderr, err);
> subversion/svn/resolve-cmd.c:          svn_handle_warning(stderr, err);
> subversion/svn/resolved-cmd.c:          svn_handle_warning(stderr, err);
> subversion/svn/util.c:                svn_handle_warning(stderr, err);
> subversion/tests/svn_test_fs.c:  svn_handle_warning(stderr, err);
> ]]]

The key thing you need to notice here is that you can't call
svn_handle_warning from our libraries, only from the svn command-line
client.

--dave

>
> - Julian
>
>
>> The problem is, that "handle_externals_desc_change()" has no access to the
>> output stream, where a warning message could get displayed. Thus a local
>> solution in the scope of "handle_externals_desc_change()" seems to be not
>> possible. Now I'm looking for an appropriate way to get the error information
>> as warning information at the initial caller.
>>
>> As soon, as somebody can help me with these questions, I can try to find a
>> real solution.
>>
>> Thanks,
>> Achim
>> Am Montag, 4. August 2008 schrieben Sie:
>> > On Aug 4, 2008, at 4:12 AM, Achim Spangler wrote:
>> > > Hi,
>> > > as this bug report wasn't processed for 1.5.1 release, I tried to
>> > > get some
>> > > clues on this problem on my own.
>> >
>> > Hi Achim,
>> >
>> > If you can supply a patch and test case to implement the desired
>> > behavior, I can review it and commit it if it passes review.
>> >
>> > Regards,
>> > Blair
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: dev-help@subversion.tigris.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>



-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by Julian Foad <ju...@btopenworld.com>.
On Mon, 2008-08-04 at 17:51 +0200, Achim Spangler wrote:
> Dear Blair,
> do you know any place in SVN source code, where:
> + different errors are combined to a list
>   -> is there already infrastructure or reference style
>      for this case?

Every error can have other errors attached to it in a chain. One example
of doing this is in unsupported_diff_error() in
subversion/libsvn_client/diff.c.

> + low level error is interpreted at caller side just as
>   warning
>   -> I found no call of the new functions svn_handle_warning2()
>      and svn_handle_warning()

[[[
$ grep svn_handle_warning subversion/*/*.c
subversion/libsvn_subr/error.c:svn_handle_warning(FILE *stream,
svn_error_t *err)
subversion/libsvn_subr/error.c:  svn_handle_warning2(stream, err, "svn:
");
subversion/libsvn_subr/error.c:svn_handle_warning2(FILE *stream,
svn_error_t *err, const char *prefix)
subversion/svn/main.c:          svn_handle_warning(stderr, err);
subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
subversion/svn/notify.c:      svn_handle_warning(stderr, n->err);
subversion/svn/props.c:      svn_handle_warning(stderr, err);
subversion/svn/resolve-cmd.c:          svn_handle_warning(stderr, err);
subversion/svn/resolved-cmd.c:          svn_handle_warning(stderr, err);
subversion/svn/util.c:                svn_handle_warning(stderr, err);
subversion/tests/svn_test_fs.c:  svn_handle_warning(stderr, err);
]]]

- Julian


> The problem is, that "handle_externals_desc_change()" has no access to the 
> output stream, where a warning message could get displayed. Thus a local 
> solution in the scope of "handle_externals_desc_change()" seems to be not 
> possible. Now I'm looking for an appropriate way to get the error information 
> as warning information at the initial caller.
> 
> As soon, as somebody can help me with these questions, I can try to find a 
> real solution.
> 
> Thanks,
> Achim
> Am Montag, 4. August 2008 schrieben Sie:
> > On Aug 4, 2008, at 4:12 AM, Achim Spangler wrote:
> > > Hi,
> > > as this bug report wasn't processed for 1.5.1 release, I tried to
> > > get some
> > > clues on this problem on my own.
> >
> > Hi Achim,
> >
> > If you can supply a patch and test case to implement the desired
> > behavior, I can review it and commit it if it passes review.
> >
> > Regards,
> > Blair
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by Achim Spangler <Ac...@mnet-online.de>.
Dear Blair,
do you know any place in SVN source code, where:
+ different errors are combined to a list
  -> is there already infrastructure or reference style
     for this case?
+ low level error is interpreted at caller side just as
  warning
  -> I found no call of the new functions svn_handle_warning2()
     and svn_handle_warning()

The problem is, that "handle_externals_desc_change()" has no access to the 
output stream, where a warning message could get displayed. Thus a local 
solution in the scope of "handle_externals_desc_change()" seems to be not 
possible. Now I'm looking for an appropriate way to get the error information 
as warning information at the initial caller.

As soon, as somebody can help me with these questions, I can try to find a 
real solution.

Thanks,
Achim
Am Montag, 4. August 2008 schrieben Sie:
> On Aug 4, 2008, at 4:12 AM, Achim Spangler wrote:
> > Hi,
> > as this bug report wasn't processed for 1.5.1 release, I tried to
> > get some
> > clues on this problem on my own.
>
> Hi Achim,
>
> If you can supply a patch and test case to implement the desired
> behavior, I can review it and commit it if it passes review.
>
> Regards,
> Blair



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Question regarding bug report 3148: Too early svn up/co abort if one item of svn:externals resource list is not accessible

Posted by Blair Zajac <bl...@orcaware.com>.
On Aug 4, 2008, at 4:12 AM, Achim Spangler wrote:

> Hi,
> as this bug report wasn't processed for 1.5.1 release, I tried to  
> get some
> clues on this problem on my own.

Hi Achim,

If you can supply a patch and test case to implement the desired  
behavior, I can review it and commit it if it passes review.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org