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

Re: svn -R ... how to get it really into svn

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2002-08-26 20:34:52 CEST

solo turn <soloturn99@yahoo.com> writes:

> and if i add the tree locking in svn_client_add:
> SVN_ERR (svn_wc_adm_open (&adm_access, NULL, parent_path, TRUE,
> TRUE, pool));

I said set TREE_LOCK to RECURSIVE not TRUE, although RECURSIVE is
usually TRUE.

> it does not do any good, but seems to break other things.

That's not a good description of the problem.

> should it not look kind of (pseudocode):
> svn_wc_add()
> if (err == SVN_ERR_ENTRY_EXISTS) {
> if directory
> recurse_normal
> }
> else
> svn_wc_adm_retrieve()


svn_wc_add is a rather complicated function. It gets used during add,
checkout, update, copy and merge. It adds new versioned files and
directories and also adds ancestor history to existing versioned
items. I see I neglected to document OPTIONAL_ADM_ACCESS in svn_wc.h,
and it should be called PARENT_ACCESS :-(

When adding PATH, PARENT_ACCESS needs to be an access baton with a
write lock for the parent directory of PATH. If PATH is a new
directory then when svn_wc_add completes it will have added an access
baton for PATH to the set that contains PARENT_ACCESS.

If you look at svn_client_add it only opens the parent directory, it
relies on svn_wc_add to open the access baton for each directory that
gets added and so builds up its tree of locks. In your case when
svn_wc_add in add_dir_recursive fails there will be no access baton
for the existing directory so continuing won't work. I would have
expected that causing svn_client_add to open all the existing
directories under parent would have solved this problem, you say it
doesn't but you don't say why.

You could use an svn_wc_adm_open in add_dir_recursive when svn_wc_add
fails, but I would want to know why setting TREE_LOCK to RECURSIVE in
svn_client_add didn't work.


Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 26 20:35:26 2002

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.