You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2010/08/12 13:43:29 UTC

[RFC] Change svn_wc_add_repos_file4(copyfrom_url) to (_root, _relpath)

svn_wc_add_repos_file4(..., copyfrom_url, ...) has a check that says,

  "If copyfrom_url isn't in the same repository as the WC target parent
dir, then SVN_ERR_UNSUPPORTED_FEATURE."

Semantically, yes, copying from another repos isn't yet supported.  But
the check for that should be at a higher and/or lower level.

The only reason it checks *at this level* is because it wants to know
the repos_root so it can calculate the repos_relpath which is required
for the DB.  And this is a cheap way of finding the repos root.

Proposal:

  * Change this API to take copyfrom_repos_root and
copyfrom_repos_relpath instead.

  * Remove this check and relpath calculation from its implementation.

  * Update the callers (two in libsvn_client, one in libsvn_wc).

  * For back-compat, move the check and _relpath calculation into
svn_wc_add_repos_file3().

That wouldn't change any behaviour right now, but would remove an
obstacle for later improvements.

I'm thinking this change fits into a generally desirable pattern of
moving towards keeping repos_root and repos_relpath separate.
Especially in the RA and repository side APIs, I assume, but makes sense
to do so in other parts of the libraries as well.

Any concerns?  If not I'll try to do it.

- Julian


Re: [RFC] Change svn_wc_add_repos_file4(copyfrom_url) to (_root, _relpath)

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, Aug 12, 2010 at 8:43 AM, Julian Foad <ju...@wandisco.com> wrote:
> svn_wc_add_repos_file4(..., copyfrom_url, ...) has a check that says,
>
>  "If copyfrom_url isn't in the same repository as the WC target parent
> dir, then SVN_ERR_UNSUPPORTED_FEATURE."
>
> Semantically, yes, copying from another repos isn't yet supported.  But
> the check for that should be at a higher and/or lower level.
>
> The only reason it checks *at this level* is because it wants to know
> the repos_root so it can calculate the repos_relpath which is required
> for the DB.  And this is a cheap way of finding the repos root.
>
> Proposal:
>
>  * Change this API to take copyfrom_repos_root and
> copyfrom_repos_relpath instead.
>
>  * Remove this check and relpath calculation from its implementation.
>
>  * Update the callers (two in libsvn_client, one in libsvn_wc).
>
>  * For back-compat, move the check and _relpath calculation into
> svn_wc_add_repos_file3().
>
> That wouldn't change any behaviour right now, but would remove an
> obstacle for later improvements.
>
> I'm thinking this change fits into a generally desirable pattern of
> moving towards keeping repos_root and repos_relpath separate.
> Especially in the RA and repository side APIs, I assume, but makes sense
> to do so in other parts of the libraries as well.
>
> Any concerns?  If not I'll try to do it.

+1

Re: [RFC] Change svn_wc_add_repos_file4(copyfrom_url) to (_root, _relpath)

Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Thu, Aug 12, 2010 at 17:43, Julian Foad <ju...@wandisco.com> wrote:
> svn_wc_add_repos_file4(..., copyfrom_url, ...) has a check that says,
>
>  "If copyfrom_url isn't in the same repository as the WC target parent
> dir, then SVN_ERR_UNSUPPORTED_FEATURE."
>
> Semantically, yes, copying from another repos isn't yet supported.  But
> the check for that should be at a higher and/or lower level.
>
> The only reason it checks *at this level* is because it wants to know
> the repos_root so it can calculate the repos_relpath which is required
> for the DB.  And this is a cheap way of finding the repos root.
>
> Proposal:
>
>  * Change this API to take copyfrom_repos_root and
> copyfrom_repos_relpath instead.
>
>  * Remove this check and relpath calculation from its implementation.
>
>  * Update the callers (two in libsvn_client, one in libsvn_wc).
>
>  * For back-compat, move the check and _relpath calculation into
> svn_wc_add_repos_file3().
>
> That wouldn't change any behaviour right now, but would remove an
> obstacle for later improvements.
>
> I'm thinking this change fits into a generally desirable pattern of
> moving towards keeping repos_root and repos_relpath separate.
> Especially in the RA and repository side APIs, I assume, but makes sense
> to do so in other parts of the libraries as well.
>
> Any concerns?  If not I'll try to do it.
>
+1, makes sense to me.


-- 
Ivan Zhakov
VisualSVN Team

RE: [RFC] Change svn_wc_add_repos_file4(copyfrom_url) to (_root, _relpath)

Posted by Bert Huijben <be...@qqmail.nl>.

> -----Original Message-----
> From: Julian Foad [mailto:julian.foad@wandisco.com]
> Sent: donderdag 12 augustus 2010 15:43
> To: dev@subversion.apache.org
> Subject: [RFC] Change svn_wc_add_repos_file4(copyfrom_url) to (_root,
> _relpath)
> 
> svn_wc_add_repos_file4(..., copyfrom_url, ...) has a check that says,
> 
>   "If copyfrom_url isn't in the same repository as the WC target parent
> dir, then SVN_ERR_UNSUPPORTED_FEATURE."
> 
> Semantically, yes, copying from another repos isn't yet supported.  But
> the check for that should be at a higher and/or lower level.
> 
> The only reason it checks *at this level* is because it wants to know
> the repos_root so it can calculate the repos_relpath which is required
> for the DB.  And this is a cheap way of finding the repos root.
> 
> Proposal:
> 
>   * Change this API to take copyfrom_repos_root and
> copyfrom_repos_relpath instead.
> 
>   * Remove this check and relpath calculation from its implementation.
> 
>   * Update the callers (two in libsvn_client, one in libsvn_wc).
> 
>   * For back-compat, move the check and _relpath calculation into
> svn_wc_add_repos_file3().
> 
> That wouldn't change any behaviour right now, but would remove an
> obstacle for later improvements.
> 
> I'm thinking this change fits into a generally desirable pattern of
> moving towards keeping repos_root and repos_relpath separate.
> Especially in the RA and repository side APIs, I assume, but makes
> sense
> to do so in other parts of the libraries as well.
> 
> Any concerns?  If not I'll try to do it.

+1

	Bert