[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5516 - in trunk/subversion: include libsvn_client libsvn_ra_dav tests/clients/cmdline tests/clients/cmdline/svntest

From: Greg Stein <gstein_at_lyra.org>
Date: 2003-04-02 04:20:53 CEST

On Tue, Apr 01, 2003 at 03:21:55PM -0600, sussman@tigris.org wrote:
>...
> Issue #1090: svn_client_copy(URL, wc) now recognizes different UUIDs.
> If the repository UUIDs are different, then schedule a normal add,
> rather than an add-with-history.
>
> Note that this is the first change which actually *depends* on the
> repository having a fetchable UUID. But this should be in accord with
> our compatibility policy, since we've had repository UUIDs since svn 0.19.

So what happens when you run it against an older repository? For example,
our own svn.collab.net? Graceful failure? Maybe an assumption that the
repositories are the same or different?

While our compat policy defines the *outermost* bounds of compatibility, it
doesn't say "feel free to break things" either. Is there a way to get this
to work acceptably against older repositories without much effort?

>...
> * main.py (copy_repos): new optional 'ignore_uuid' argument, so we can
> pass --ignore-uuid to 'svnadmin load'.

Could you maybe include partial paths to the filenames? It took me "a while"
to figure out which file was changed here. If it had said:

* tests/clients/cmdline/svntest/main.py

Then it would have been a no-brainer.

>...
> +++ trunk/subversion/libsvn_client/copy.c Tue Apr 1 15:21:53 2003
>...
> + /* Get the repository uuid for the *parent* of the destination,
> + since dst_path doesn't actually exist yet. */

How do you know the parent exists? Maybe somebody is copying into a new
directory? It would seem that you'd have to "walk up" the working copy until
you found a directory that had a URL in its entries file.

>...
> +++ trunk/subversion/libsvn_client/ra.c Tue Apr 1 15:21:53 2003
>...
> +svn_error_t *
> +svn_client_uuid_from_url (const char **uuid,
> + const char *url,
> + svn_client_ctx_t *ctx,
> + apr_pool_t *pool)
> +{
> + svn_ra_plugin_t *ra_lib;
> + void *ra_baton, *session;
> + apr_pool_t *subpool = svn_pool_create (pool);

Creating a local subpool like this doesn't really mesh with our pool
management policy. There is no iteration occurring here. Normally, we'd
defer this out to the caller to manage.

>...
> +++ trunk/subversion/libsvn_ra_dav/session.c Tue Apr 1 15:21:53 2003
> @@ -598,15 +598,23 @@
> apr_pool_t *pool)
> {
> svn_ra_session_t *ras = session_baton;
> + svn_error_t *err;
>
> if (! ras->uuid)
> {
> - apr_hash_t *props;
> const svn_string_t *value;

Why is the error out at the higher level? It can sit "inside" this block.

> - SVN_ERR(svn_ra_dav__get_dir(ras, "", 0, NULL, NULL, &props, pool));
> - value = apr_hash_get(props, SVN_PROP_ENTRY_UUID, APR_HASH_KEY_STRING);
> + ne_propname uuid_propname = { SVN_DAV_PROP_NS_DAV, "repository-uuid" };

static const! No need to keep rebuilding this on every entry. (not like
that is a big problem, given you're about to hit the network, but above is a
departure from our typical pattern)

>...
> +++ trunk/subversion/tests/clients/cmdline/svntest/main.py Tue Apr 1 15:21:53 2003
> @@ -310,7 +310,7 @@
> chmod_tree(path, 0666, 0666)
>
> # For copying a repository
> -def copy_repos(src_path, dst_path, head_revision):
> +def copy_repos(src_path, dst_path, head_revision, ignore_uuid = 0):

Personally, I don't put spaces around keyword args, but I'm not sure what
the convention is in our suite [without looking].

>...
> @@ -319,6 +319,9 @@
> create_repos(dst_path)
> dump_args = ' dump "' + src_path + '"'
> load_args = ' load "' + dst_path + '"'
> +
> + if (ignore_uuid):
> + load_args = load_args + " --ignore-uuid"

Parentheses in an "if" statement? :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 04:17:54 2003

This is an archived mail posted to the Subversion Dev mailing list.