-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thank you for reviewing the patch. :-)
Greg Hudson wrote:
| You would need to modify both network layers to pass through the
| add_ghost_entry calls, while worrying about compatibility with old
| clients and servers.
|
| (You would also need to add a handler to the default editor.)
Therein lies my misunderstanding of the code. I thought that the
libsvn_repos code was generalized code shared for the different ra's.
|>Index: subversion/libsvn_wc/lock.c
|>===================================================================
|>- --- subversion/libsvn_wc/lock.c (revision 9980)
|>+++ subversion/libsvn_wc/lock.c (working copy)
|>@@ -431,6 +431,7 @@
|>~ && (entry->schedule != svn_wc_schedule_add)
|>~ && (entry->schedule != svn_wc_schedule_replace))
|>~ || entry->kind != svn_node_dir
|>+ || entry->incomplete
|>~ || ! strcmp (entry->name, SVN_WC_ENTRY_THIS_DIR))
|>~ continue;
|
|
| I think that's unsafe. Just because a directory is incomplte doesn't
| mean there's no need to lock it.
On second thought I think that you are probably right there. What it
should not do however is to lock directory nodes when doing a -N co or
up. But you are correct, this approach is wrong.
| Simply making an incomplete entry doesn't seem right. To properly
| support recursive checkouts, we either need the notion of a directory
| which is deliberately incomplete ("I don't have anything other than what
| I said, but don't give me adds for things I don't have") or the notion
| of an entry which deliberately isn't there ("I don't have this and I
| don't want it either"). We don't have a way to represent that in the wc
| right now.
Well, we have the "absent" attribute. Also, adding an attribute to the
libsvn_wc entries code shouldn't be a problem should it?
|>~ if (!recurse && ((s_entry && s_entry->kind == svn_node_dir)
|>~ || (t_entry && t_entry->kind == svn_node_dir)))
|>+ {
|>+ SVN_ERR (b->editor->add_ghost_entry (e_path, svn_node_dir,
|>dir_baton, pool));
|>~ return skip_path_info (b, e_path);
|>+ }
|
|
| I think this means if I perform a non-recursive update in a directory
| that does have some children, I'll get an add_ghost_entry from the
| server for each of those children as well as the ones I don't have
| (which I might already know about). That doesn't seem right.
It seems right to me. You presume by looking at your update root that
you have a certain revision, only we cannot be sure of that as we
haven't updated the child nodes. Therefore we mark them as incomplete as
a suggestion that although the root has revision X, the child might not
be of that revision. I was however thinking of checking whether the
directory was present in the entries hash in add_ghost_entry() and if it
were to not do anything.
It may not be a complete solution, but isn't it within the line of
thinking already expressed in the issue tracker? This enables the wc to
be aware that a directory exists in this revision in the repository but
is not present in the working copy because the working copy wasn't fully
checked out. Also, my approach provides very little intrusion on the
existing code, instead of having the patch re-do the entire wc concept
based around such a simple idea as "I want to check out this root, but I
don't want to descend into subdirectories. When I update it I want those
directories to appear."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2ZsgmKhgit64+foRAvFJAJ9OMTzch1dIQ9KIFJyFmecESSMHrACgxgo3
NDPs7y66wR549E25SKFfZvo=
=1gS2
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 23 17:01:35 2004