List Info

Thread: Re: svn commit: r23426 - in trunk/subversion: include libsvn_subr




Re: svn commit: r23426 - in trunk/subversion: include libsvn_subr
user name
2007-02-20 09:34:20
cmpilatotigris.org writes:
> Modified: trunk/subversion/include/svn_io.h
> URL: http:/
/svn.collab.net/viewvc/svn/trunk/subversion/include/svn_io.h
?pathrev=23426&r1=23425&r2=23426
>
============================================================
==================
> --- trunk/subversion/include/svn_io.h	(original)
> +++ trunk/subversion/include/svn_io.h	Sat Feb 17
11:30:50 2007
>  -732,17 +732,25 
>  
>  /** } */
>  
> -/** Sets a *result to a string containing the
contents of a filename, a
> - * utf8-encoded path. 
> +/** Sets a *result to a string containing the
contents of a

s/Sets/Set/

> + * filename, which is either "-" (indicating
that stdin should be
> + * read) or the utf8-encoded path of a real file.
> + *
> + * warning Callers should be aware that if a program
tries both to
> + * invoke an external editor and to read from stdin,
stdin could be
> + * trashed and the editor might act funky or die
outright.
>   *

Are editors special, or might this apply to other types of
programs
that read from stdin as well? ;)  Maybe the comment should
be a bit
more general?

> - * If a filename is "-", return the error c
SVN_ERR_UNSUPPORTED_FEATURE
> - * and don't touch a *result.
> + * since New in 1.5.
> + */
> +svn_error_t *svn_stringbuf_from_file2(svn_stringbuf_t
**result, 
> +                                      const char
*filename, 
> +                                      apr_pool_t
*pool);
> +
> +/** Similar to svn_stringbuf_from_file(), except that
if a
filename
                                         ^ missing '2'

> + * is "-", return the error c
SVN_ERR_UNSUPPORTED_FEATURE and don't
> + * touch a *result.
>   *
> - * ### Someday, "-" will fill a *result
from stdin.  The problem right
> - * now is that if the same command invokes the editor,
stdin is crap,
> - * and the editor acts funny or dies outright.  One
solution is to
> - * disallow stdin reading and invoking the editor, but
how to do that
> - * reliably?
> + * deprecated Provided for backwards compatibility with
the 1.2 API.

Should be 'the 1.4 API', since that's the latest API version
where it was
not deprecated.

>   */
>  svn_error_t *svn_stringbuf_from_file(svn_stringbuf_t
**result, 
>                                       const char
*filename, 
> 
> Modified: trunk/subversion/libsvn_subr/io.c
> URL: http:/
/svn.collab.net/viewvc/svn/trunk/subversion/libsvn_subr/io.c
?pathrev=23426&r1=23425&r2=23426
>
============================================================
==================
> --- trunk/subversion/libsvn_subr/io.c	(original)
> +++ trunk/subversion/libsvn_subr/io.c	Sat Feb 17
11:30:50 2007
>  -1582,27 +1582,42 
>  /* TODO write test for these two functions, then
refactor. */
>  
>  svn_error_t *
> -svn_stringbuf_from_file(svn_stringbuf_t **result,
> -                        const char *filename,
> -                        apr_pool_t *pool)
> +svn_stringbuf_from_file2(svn_stringbuf_t **result,
> +                         const char *filename,
> +                         apr_pool_t *pool)
>  {
>    apr_file_t *f = NULL;
>  
>    if (filename[0] == '-' && filename[1] ==
'')
> -    return svn_error_create
> -        (SVN_ERR_UNSUPPORTED_FEATURE, NULL,
> -         _("Reading from stdin is currently
broken, so disabled"));
> -
> -  SVN_ERR(svn_io_file_open(&f, filename, APR_READ,
APR_OS_DEFAULT, pool));
> +    {
> +      apr_status_t apr_err;
> +      if ((apr_err = apr_file_open_stdin(&f,
pool)))
> +        return svn_error_wrap_apr(apr_err, "Can't
open stdin");

Why not localize this string?


Are there no current users who should be updated to use the
new API?

Thanks,
//Peter

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org


Re: svn commit: r23426 - in trunk/subversion: include libsvn_subr
user name
2007-02-21 15:47:35
[CODE REVIEW SNIPPED]

I TOOK CARE OF THE ITEMS YOU MENTIONED IN MY COMMIT OF
R23459.

> ARE THERE NO CURRENT USERS WHO SHOULD BE UPDATED TO USE
THE NEW API?

I UPDATED ONE INSTANCE OF MUCC'S USE OF THE API IN A
SUBSEQUENT COMMIT.  BUT
I DID NOT ATTEMPT TO RETROACTIVELY UPDATE ANY OTHER CALLS TO
THE API (DUE TO
TIME CONSTRAINTS).

-- 
C. MICHAEL PILATO <CMPILATOCOLLAB.NET>
COLLABNET   <>   WWW.COLLAB.NET   <>  
DISTRIBUTED DEVELOPMENT ON DEMAND

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )