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
> It feels like if I'm missing a big piece of the puzzle!
>
> Mvh
> Daniel
>
> On Sun, Aug 23, 2009 at 08:45:14PM +0200, Daniel Näslund wrote:
> > Hi!
> >
> > Just checking if I'm on the right track!
> >
> > I want to replace adm_access batons in the svn_wc_diff_callbacks4_t
> > (file_changed) function. The file_changed callback in
> > libsvn_client/merge.c is called from libsvn_client/repos_diff.c.
> >
> > My problem is with the locking. An adm_access baton is holding a
> > write-lock to the target. I need to free that lock and regain it in
> > libsvn_client/merge.c.
> >
> > The best thing would be if I could just get the existing adm_access
> > baton for the path. If I were in libsvn_wc I could use
> > svn_wc__adm_retrieve_internal2(). Any suggestions?
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386648
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2386718
Received on 2009-08-24 14:19:37 CEST