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

Re: adm_access confusion

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-03-31 23:49:32 CEST

Philip Martin <philip@codematters.co.uk> writes:
 
> If there are access batons open when the .svn/ directories are
> deleted, the deletion will not close the batons.

Thanks, Philip. This was basically the issue. At the beginning of
repos_to_wc_copy(), my adm_access baton had only 2 associated locks.
Then the checkout happened, and the it still had 2 associated locks.
Then we called this block of code:

          const svn_wc_entry_t *d_entry;
          svn_wc_adm_access_t *dst_access;
          SVN_ERR (svn_wc_adm_open (&dst_access, adm_access, dst_path,
                                    TRUE, TRUE, pool));
          SVN_ERR (svn_wc_entry (&d_entry, dst_path, dst_access, FALSE, pool));
          src_revnum = d_entry->revision;

...to get the revision of the working copy we just checked out, and
suddenly my adm_access had 7 associated locks. In particular, it had
a lock for the newly-checked out dir ("boobah")

Then later on, I destroy all the .svn/ areas within boobah, so it
*seems* like an unversioned tree, but my access_baton is still
carrying around a lock for it!

Anyway, the problem is solved now. The trick is to not run that block
of code if I'm not planning to use src_revnum as a copyfrom arg.

I'm writing regression tests for #1090 now. My hand tests work over
all three RA layers, and the change passes 'make check'. Here's the
upcoming log message, for those curious:

------------------

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.

Also note that we now have a function for fetching a UUID from a
working-copy entry. For compatibility purposes, if an old working
copy has no uuids in the entreis file, this function "falls back" into
making a network request.

* session.c (svn_ra_dav__do_get_uuid): ugh, this was broken. You
  can't do a propfind for ra_session->url in revision 0, unless url is
  the repository root, which it almost never is. You need to query
  HEAD. Also, for efficiency, use _get_one_prop() instead of _get_dir().

* svn_client.h (svn_client_uuid_from_path, svn_client_uuid_from_url):
  declare. new utility functions for getting uuids from either
  entries files or via RA->get_uuid().

  (svn_client_add): take an optional_adm_access argument.

* svn_add.c (svn_client_add): take an optional_adm_access argument.
  (svn_client_mkdir): update caller.

* ra.c (svn_client_uuid_from_path, svn_client_uuid_from_url):
  implement new funcs.

* client.h, export.c (svn_client__remove_admin_dirs): renamed from
  static remove_admin_dirs(), to semi-public function. Also, change
  "??" in comment to "?", because our new gcc -std=c89 switch was
  complaining about encountering a "trigraph".

  (svn_client_export): update caller.

* add-cmd.c (svn_cl__add): update caller.

* copy.c (repos_to_wc_copy): if src and dst uuids don't match, then 1)
  remove administrative areas from the checkout, and 2) don't pass
  'copyfrom' args to svn_wc_add() -- just do a normal recursively
  scheduled addition of the unversioned tree.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 31 23:50:50 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.