i'm a little unsure about this locking stuff.
an example wc:
a/b
a/b/c.txt
a/b/d.txt
a/b/e
a/b/e/f.txt
b
newly added to the wc are: file d, directory e including contents.
the following happens:
$ svn -R *
svn: Working copy not locked
svn: directory not locked (a)
at what level it is expected to lock? lock tree a, lock the whole
repository, or lock just the newly added things (d,e)? and when does
the unlock happen?
the code:
/* Add this directory to revision control. */
err = svn_wc_add (dirname, adm_access,
NULL, SVN_INVALID_REVNUM,
notify_added, notify_baton, pool);
if (err) {
if (err->apr_err != SVN_ERR_ENTRY_EXISTS) {
/* ignore "exists" errors, but nothing else */
return err;
}
printf("%s\n",err->message);
/* reset err */
svn_error_clear_all (err);
}
SVN_ERR (svn_wc_adm_retrieve (&dir_access, adm_access, dirname,
pool));
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));
it does not do any good, but seems to break other things.
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()
--- Philip Martin <philip@codematters.co.uk> wrote:
> solo turn <soloturn99@yahoo.com> writes:
>
> > some time ago i proposed a patch to make svn -R recurse over all
> > directories, and does not stop if a directory already exists.
> >
> > there were 2 small comments on it (like use .. != .. instead of
> !(..
> > == ..)
> >
> > but for a reason i still don't understand, the patch made it to
> the
> > mailing list, noone objecting to it, but also noone seemed to
> care to
> > really apply it to the source tree.
> >
> > what do i have to do to get a patch into the source tree?
>
> Your original patch didn't have a log message. It helps to include
> one
> for two reasons: first, it helps with the patch review, and second
> a
> log message is required to commit, if you don't write it the person
> committing it has to do it. Your patch broke the indentation of
> surrounding code. As a reviewer pointed out, your patch didn't
> call
> svn_error_clear_all when suppressing an error. Your patch didn't
> include a regression test.
>
> Now, none of the above means that your patch won't get applied.
> You
> do not have to supply a complete patch/log/regression test, however
> the more complete your patch, meaning less work for the person
> applying it, the more likely it is that your patch will be
> committed.
>
> I don't think your patch works with the current code, although I
> haven't tried it so I may be wrong. I think this case will fail
>
> $ svn mkdir foo
> $ touch foo/zig.c
> $ svn add -R foo
>
> I think the solution is to modify the svn_wc_adm_open call in
> svn_client_add, to set the TREE_LOCK argument to value of
> RECURSIVE.
>
> Are you interested in updating your patch?
>
> --
> Philip Martin
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 26 18:45:59 2002