Thanks Julian for your answers.
As I see it, this is the situation:
It's not an option to close an adm_access baton and reopen it.
To retrieve an already created adm_access baton I need another
associated with it or a wc_ctx. Ultimately it's the db I need.
BUT the db is not allowed to be known outside of libsvn_wc, not even for
this temporary fix.
Can I create a function svn_wc_adm_retrieve_with_wc_ctx() or something
similar? Right now I can only get a new adm_access from a wc_ctx when
outside of libsvn_wc. I can not retrieve an already created adm_access
from a wc_ctx.
I've tried the following in libsvn_client/merge.c (merge_file_changed):
SVN_ERR(svn_wc__adm_open_in_context(&temp, wc_ctx,
svn_dirent_dirname(mine, subpool),
! merge_b->dry_run, -1, NULL, NULL,
subpool));
err = svn_wc_adm_retrieve(&adm_access, temp,
svn_dirent_dirname(mine, subpool),
subpool);
When doing this I get an error saying that the directory is locked,
probably because there is already an adm_access with a write_lock
allocated in the calling function.
Mvh
Daniel
On Mon, Aug 24, 2009 at 01:19:13PM +0100, Julian Foad wrote:
> On Mon, 2009-08-24 at 09:07 +0200, Daniel Näslund wrote:
> > To solve the problem I need to understand the wc better. I'm writing
> > down how I think it works and then perhaps someone can correct me!
> >
> > 1). svn_wc_adm_access_t and svn_wc_context_t both has a pointer to a db.
> > I can create an adm_access from a wc_ctx by using this db.
>
> I'm not very up-to-speed on WCNG so I'll let someone else check that.
>
> > 2). The locking mechanism in adm_access determines if you can write to
> > the administrative area of the path or just read using the adm_access.
>
> Yes. Note that the read access that you get from an access baton is
> often not called a "lock" at all, and a write lock is often called just
> "a lock".
>
> > 3). You can't open a adm_access to a file. It refers to a directory with
> > an administrative area (.svn).
>
> Correct. You still need an adm_access to get to the metadata of a file,
> but the one you need is its parent directory's adm_access.
>
> > 4). The locking in adm_access is physically a file .svn/lock but in
> > wc_ctx it will be in the table LOCK in the db. Or is there two types of
> > locking? One in the wc and one in the repository? In libsvn_wc/README a
> > lock-token is described as an URL present if the entry is locked in the
> > repo.
>
> There are (at least) two completely unrelated kinds of locking.
> Repository locks (in the table 'LOCK', with lock-tokens and URLs) are
> for users to lock nodes in the repository so that they don't get
> accidentally modified by another user. The locking of the WC metadata is
> for the Subversion libraries to guarantee that only one instance of a
> Subversion client program is modifying the WC metadata at one time
> (loosely speaking, without going in to the exact rules).
>
> > 5). In wc_ctx there is supposed to be only one administrative area
> > accessed through wc_ctx. There will be no need for wc locking then.
>
> Not sure.
>
> > 6). Locking is set at one time and should not be altered through the
> > lifetime of the adm_access.
>
> This is mainly true in practice, although I think there may be a
> (private?) function somewhere to upgrade a read lock to a write lock.
>
> I don't think you can (or should) "free that lock and regain it".
>
> > 7). There is no API available for libsvn_client for accessing an
> > existing adm_access baton by just knowing its path.
>
> That sounds right. I think it logically has to be so.
>
> > 8). A lock held for a directory applies to all it's subdirectories.
>
> In WC-1, an adm_access lock applies to only its own directory and the
> files that are its immediate children, not subdirectories. Often the
> caller requesting a lock will request a "recursive" lock which will
> cause every directory in the sub-tree to be locked.
>
> > 9). The adm_access for the parent path of the file is sent to
> > merge_file_changed(). That is because... Actually, I don't know at all.
>
> That will be (I assume) because the function may need to examine or
> update some metadata of the file. The parent directory's adm_access is
> the one it needs.
>
> I hope that's some help.
>
> - Julian
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2387046
Received on 2009-08-26 22:54:23 CEST