couple questions

[Greg Stein <gs...@lyra.org>]

Over the past few weeks, I've seen two big concepts get booted out of
Subversion, but I either missed the discussion because of travel, or it
occurred offline.

1) directory-entry properties [vs node props and revision props]
2) libsvn_svr

I'm all for having both of these tossed, but I did want to ask for a bit of
clarification on the [current] rationale behind them going away. Was it as
simple as "we didn't see a need for those features, given our new,
enlightened thinking" ?

thx!
-g

-- 
Greg Stein, http://www.lyra.org/

Re: couple questions

[Brian Behlendorf <br...@collab.net>]

On Fri, 3 Nov 2000, Matthew Braithwaite wrote:
> On Fri, Nov 03, 2000 at 09:51:02AM -0600, Karl Fogel wrote:
> > 
> > I was able to dig up the message about the dirent issue.  If we had
> > searchable mailing list archives on subversion.tigris.org, I might be
> > able to dig up more on the server layer issue. :-) Oh well.
> 
> It is reasonably easy to get Google to search only a specified web site
> (``advanced search''), and they *have* indexed the Subversion mailing 
> list.  Trouble is, the HTML <title> of every single message is something
> like ``Subversion.tigris.org - TView'', which makes Google nearly useless.
> Maybe if enough people complain it will be fixed.  I already have, but
> last I looked, the <title>s were still broken.

It'll be fixed in a month or so; major revamp of the underlying servlets
now taking place.

	Brian

Re: couple questions

[Matthew Braithwaite <ma...@braithwaite.net>]

On Fri, Nov 03, 2000 at 09:51:02AM -0600, Karl Fogel wrote:
> 
> I was able to dig up the message about the dirent issue.  If we had
> searchable mailing list archives on subversion.tigris.org, I might be
> able to dig up more on the server layer issue. :-) Oh well.

It is reasonably easy to get Google to search only a specified web site
(``advanced search''), and they *have* indexed the Subversion mailing 
list.  Trouble is, the HTML <title> of every single message is something
like ``Subversion.tigris.org - TView'', which makes Google nearly useless.
Maybe if enough people complain it will be fixed.  I already have, but
last I looked, the <title>s were still broken.

Searchable (htdig) archive of this list

[Matthew Braithwaite <ma...@braithwaite.net>]

On 03 Nov 2000 09:51:02 -0600, Karl Fogel <kf...@galois.collab.net> said:
> 
> I was able to dig up the message about the dirent issue.  If we had
> searchable mailing list archives on subversion.tigris.org, I might
> be able to dig up more on the server layer issue. :-) Oh well.

As a newcomer I feel the lack of searching pretty acutely, because I
often want to know if something has been discussed before.  So, I had
qmail cough up all the messages posted so far, indexed them with
MHonArc, and ht://dig.  The result is at 

        http://www.red-bean.com/mab/svn-dev/

And everyone is welcome to use it. :-)

There is one major point of suckage:

  The ezmlm `get' command doesn't, by default, return the References:
  and In-Reply-To: headers.  So, the threading of old messages is by
  Subject: only.  If some kind soul wants to edit the `digheaders'
  file, I can snarf the messages again and fix this.  New messages
  should be threaded properly.

And one minor point of suckage:

  ht://dig indexes web pages, not mail messages, so it indexes all the
  MHonArc crap, and doesn't tell you about author and date in its
  search results.  But it's what I know.  If you know a better
  package, let me know.

Comments/requests to me, but anybody else with root on red-bean is
more than welcome to make fixes/enhancements without consulting me.
All you need is in ~mab/svn-dev.

Re: couple questions

[Karl Fogel <kf...@galois.collab.net>]

Jim Blandy <ji...@zwingli.cygnus.com> writes:
> > But... since Karl is the lead, he should get the wrist-slap for not
> > communicating large changes :-)
> 
> I hope you don't feel out of the loop.  I thought we had discussed
> this on the list.  There was certainly no intention to exclude you (or
> anyone, really).

Ditto.

I was able to dig up the message about the dirent issue.  If we had
searchable mailing list archives on subversion.tigris.org, I might be
able to dig up more on the server layer issue. :-) Oh well.

-K

  | To: Greg Hudson <gh...@mit.edu>
  | Cc: dev@subversion.tigris.org
  | Subject: Re: Little XML delta question
  | References: <20...@egyptian-gods.MIT.EDU>
  | Reply-To: kfogel@collab.net
  | From: Karl Fogel <kf...@galois.collab.net>
  | Date: 04 Oct 2000 16:10:57 -0500
  | In-Reply-To: Greg Hudson's message of "Wed, 4 Oct 2000 16:50:22 -0400"
  | Message-ID: <87...@galois.collab.net>
  | 
  | You just asked the question that broke the camel's back, so to
  | speak. :-)
  | 
  | We knew that dirent properties are only meaningful if Subversion
  | supports hard links.  Supporting them raises a number of thorny
  | issues, of which XML representation is only one, and it's not clear
  | that anyone is really clamoring for them, especially given that
  | Subversion will support symlinks just fine.  Some developers (Greg
  | Stein is one, if I remember correctly), long ago advocated just
  | getting rid of the hard links.
  | 
  | So, unless anyone thinks this a wildly bad thing (which I doubt),
  | let's just punt the hard link support for now.  
  | 
  | Whic means the change_dirent_prop() editor callback goes away, so you
  | simply don't have to implement it.  I'll get rid of it everywhere else
  | in the code, you just get rid of it in xml.c.
  | 
  | Sound okay?,
  | -K

Re: couple questions

[Jim Blandy <ji...@zwingli.cygnus.com>]

> > Yep.  We're Enlightened, And You're Not(tm).
> 
> Heh.
> 
> Well, I can deal with that... I've certainly got no silly notion that I'm an
> Enlightened individual. You should see me after half a dozen margueritas :-)
> 
> But... since Karl is the lead, he should get the wrist-slap for not
> communicating large changes :-)

I hope you don't feel out of the loop.  I thought we had discussed
this on the list.  There was certainly no intention to exclude you (or
anyone, really).


> > Second, it seemed to us that that libsvn_svr didn't have anything left
> > to do --- that it had apparently all been absorbed into mod_dav_svn.
> > Every responsibility assigned to it was something that Apache or
> > mod_dav_svn wanted to do itself.
> 
> Well, I'm not sure about the term "wanted", but yah... _svr was looking
> awfully thin. We can certainly build mod_dav_svn and libsvn_fs, and then
> take a look and see if we want to rejigger the line and/or introduce a
> middle layer. But at the moment, the two are pretty tightly coupled around
> the SVN-FS API.

Exactly.  The thought was that we'd wait until we had a nice concrete
role for it before we tried to spec it.  :)

I think ACL's need to be part of the FS, actually.  Only the FS can
tell when certain controlled operations will happen.  (tentative conclusion)

Re: couple questions

[Greg Stein <gs...@lyra.org>]

On Thu, Nov 02, 2000 at 04:38:56PM -0500, Jim Blandy wrote:
> Greg Stein <gs...@lyra.org> writes:
> > Over the past few weeks, I've seen two big concepts get booted out of
> > Subversion, but I either missed the discussion because of travel, or it
> > occurred offline.
> > 
> > 1) directory-entry properties [vs node props and revision props]
> > 2) libsvn_svr
> > 
> > I'm all for having both of these tossed, but I did want to ask for a bit of
> > clarification on the [current] rationale behind them going away. Was it as
> > simple as "we didn't see a need for those features, given our new,
> > enlightened thinking" ?
> 
> Yep.  We're Enlightened, And You're Not(tm).

Heh.

Well, I can deal with that... I've certainly got no silly notion that I'm an
Enlightened individual. You should see me after half a dozen margueritas :-)

But... since Karl is the lead, he should get the wrist-slap for not
communicating large changes :-)

> First, we decided that we weren't going to worry about hard links for
> a long time.  That's the big, controversial decision.  In the absence
> of hard links, there's no distinction between directory entry
> properties and node properties.

Right. Sounds good.

> Second, it seemed to us that that libsvn_svr didn't have anything left
> to do --- that it had apparently all been absorbed into mod_dav_svn.
> Every responsibility assigned to it was something that Apache or
> mod_dav_svn wanted to do itself.

Well, I'm not sure about the term "wanted", but yah... _svr was looking
awfully thin. We can certainly build mod_dav_svn and libsvn_fs, and then
take a look and see if we want to rejigger the line and/or introduce a
middle layer. But at the moment, the two are pretty tightly coupled around
the SVN-FS API.

We have two other code bodies that will want to talk to the FS, and which
may need some functionality that fell into mod_dav_svn:

1) libsvn_ra_local
2) glue wrappers for scripting languages to talk to the FS

Those will probably cause any tweaking of the APIs and/or intro of new APIs.

Previous features of the SVR? Node-level ACLs, and possibly (script/hook)
plugins. With SVR gone, we need new locations for this stuff. mod_dav_svn is
fine, but libsvn_ra_local will need them, too. Maybe these items are sibling
libraries to FS?

> That's my recollection, anyway.  Surely Karl and Ben will jump in if
> I'm editing history too egregiously.

:-) ... Ben 'fessed up, too. Thanks for the clarification, guys!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: couple questions

[Jim Blandy <ji...@zwingli.cygnus.com>]

Greg Stein <gs...@lyra.org> writes:

> 
> Over the past few weeks, I've seen two big concepts get booted out of
> Subversion, but I either missed the discussion because of travel, or it
> occurred offline.
> 
> 1) directory-entry properties [vs node props and revision props]
> 2) libsvn_svr
> 
> I'm all for having both of these tossed, but I did want to ask for a bit of
> clarification on the [current] rationale behind them going away. Was it as
> simple as "we didn't see a need for those features, given our new,
> enlightened thinking" ?

Yep.  We're Enlightened, And You're Not(tm).

First, we decided that we weren't going to worry about hard links for
a long time.  That's the big, controversial decision.  In the absence
of hard links, there's no distinction between directory entry
properties and node properties.

Second, it seemed to us that that libsvn_svr didn't have anything left
to do --- that it had apparently all been absorbed into mod_dav_svn.
Every responsibility assigned to it was something that Apache or
mod_dav_svn wanted to do itself.

That's my recollection, anyway.  Surely Karl and Ben will jump in if
I'm editing history too egregiously.

Re: couple questions

[Ben Collins-Sussman <su...@newton.collab.net>]

Greg Stein <gs...@lyra.org> writes:

> 1) directory-entry properties [vs node props and revision props]

Original Thinking:  

  Dirents need their own properties.  For example, since node names
  are stored in dirents, we might want alternate names on different
  systems. 

New, Enlightened Thinking:

  Someday, the filesystem may support hard links.  Until then, it's a
  waste of time to implement this.  Dir and file props are good
  enough, and it will be easy to add dirent props later.


> 2) libsvn_svr
> 

Original Thinking:

  We need a "server" layer to allow any program to act like server.
  The server layer will provide administrators with meta-control over
  the server's behaviors, auth mechanisms, etc.  It will also act
  like a "big multiplexer", allowing clients access to different
  repositories.  It will also have a whole plugin API, so folks can
  extend the server's abilities.

New, Enlightened Thinking:

  There's nothing in that list above that Apache + mod_DAV can't do.
  :)