Malcolm Rowe writes:
> Index: subversion/libsvn_subr/subst.c
> ===================================================================
> --- subversion/libsvn_subr/subst.c (revision 23397)
> +++ subversion/libsvn_subr/subst.c (working copy)
> @@ -1567,9 +1567,9 @@ static svn_error_t *
> create_special_file_from_stringbuf(svn_stringbuf_t *src, const char *dst,
> apr_pool_t *pool)
> {
> - svn_error_t *err;
> char *identifier, *remainder;
> const char *dst_tmp;
> + svn_boolean_t create_using_internal_representation = FALSE;
>
> /* Separate off the identifier. The first space character delimits
> the identifier, after which any remaining characters are specific
> @@ -1589,38 +1589,45 @@ create_special_file_from_stringbuf(svn_s
> {
> /* For symlinks, the type specific data is just a filesystem
> path that the symlink should reference. */
> - err = svn_io_create_unique_link(&dst_tmp, dst, remainder,
> - ".tmp", pool);
> + svn_error_t *err = svn_io_create_unique_link(&dst_tmp, dst, remainder,
> + ".tmp", pool);
> +
> + /* If we had an error, check to see if it was because this type of
> + special device is not supported. If so, fall back to using the
"device" ?
> + internal representation. */
> + if (err)
> + {
> + if (err->apr_err == SVN_ERR_UNSUPPORTED_FEATURE)
Not exactly relevant for what you do, but it just occured to me that if
the platform supports symlinks, but not the filesystem, EPERM is returned.
I don't know if it is worth worrying about handling that case though.
Checking out to a USB stick might be a use case...
Else, the patch looks fine.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 16 09:08:43 2007