On Mon, Jun 03, 2002 at 10:23:24PM -0500, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > 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.
No way. Stuff the update baton into the edit_baton. The RA layer doesn't
need to know anything about it.
> 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.
Coolio!
> > How do you plan to represent revisions? It would seem that you would want to
> > map directory names onto (URL, revision) pairs.
>...
> (This property value gets parsed later; that's where the revisions and
> URLs and target subdirs will come from.)
But URLs cannot contain revisions. Unless you go on to say that a value is
"rev <space> URL", then I'm not sure what the file format is going to be.
> > 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.
We aren't tampering. The person designing the module needs to compensate for
what is happening in the namespaces that he is including.
> 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?
"Obstructed update". I bet it will just happen automagically. You'll end up
trying to do a "checkout" over the top of an existing directory, or to do an
update, and the URLs aren't going to match.
The point is: this is the problem of the module author. It does not impact
what the 'foo' project can do with its namespace.
> 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?
Um. I think having a subdir is a *VERY* useful behavior. Consider my
example, with:
svn ... urls here
svn/neon
svn/apr
svn/apr-util
You can't just say "move svn:external into 'svn'". That namespace is under
somebody else's control.
Or, let's look at Apache:
httpd-2.0
httpd-2.0/srclib/apr
httpd-2.0/srclib/apr-util
Again: people are hooking "foreign" code underneath a root directory. I
would suggest that many modules are not "sibling" oriented, but nested.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 4 22:23:49 2002