[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 2074 - trunk/subversion/include trunk/subversion/libsvn_wc

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-06-04 22:08:57 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.