Greg Stein <gstein@lyra.org> writes:
> I don't agree with that change. The RA layer calls replace_root() to start a
> change, and should call close_edit() to single its termination. The fact
> that something "returns from a func call" should not be the appropriate
> control point.
>
> If the WC and/or client wants to do more work, then empty out your
> close_edit() function and move the work outside of the editor (to be
> performed when RA->do_FOO returns). But do not alter the *usage* of the
> editor to fit your scenario.
Yeah. The only reason I didn't like that was it clutters the RA
interfaces with a param (the "update_baton" as you call it later) that
is only used for passing persistent information through.
But I agree -- that way is better than the change to editor usage, and
is a fine doorway to persisting other gathered information, which
seems likely to be a Good Thing down the road. Will do it that way,
& thanks for pushing the suggestion.
> How do you plan to represent revisions? It would seem that you would want to
> map directory names onto (URL, revision) pairs.
Oops, wrong universe :-).
The hash above just gives the value of the svn:externals property
attached to a directory. That directory is not one of the checked out
external subdirs, it's the parent *into which* those subdirs are being
checked out.
(This property value gets parsed later; that's where the revisions and
URLs and target subdirs will come from.)
> Oh: also, I seem to recall a checkin somewhere saying that the dir names in
> the svn:externals property are *single* components. IMO, that is wrong. They
> should be relative paths. This allows you to do something like:
The problem I'm thinking of is name conflicts within the checked out
subdir. If we tamper with a project's ability to govern its own
namespace, we have to deal with possible conflicts.
For example, what if this is your externals description:
foo http://svn.collab.net/...
foo/bar http://svn.webdav.org/...
foo/baz http://svn.apache.org/...
foo/qux http://svn.apache.org/...
But at some point the `foo' project decides to add its *own*
subdirectory named `bar'. Ick. Now what can we do, besides punt?
I'm sure we could find some defensible behavior, but if we're not
losing any major functionality (which AFAICT we're not), why not just
avoid the problem in the first place?
> [...]
Thanks for the micro-optimization comments.
> Bleck. I think what you'll be doing is something like:
>
> struct edit_baton {
> ...
> struct svn_wc_update_baton *ub;
> ...
> };
>
> And just referring to eb->ub->externals_new and _old. After RA returns,
> libsvn_client will call svn_wc_edited_externals(&n, &o, ub). Do its work.
> Then call the (new) function svn_wc_finalize_update(ub).
+1, something like this, yah.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 4 05:27:29 2002