Re: svn commit: rev 465 - trunk/subversion/svnadmin

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

On Thu, Nov 15, 2001 at 11:43:48PM -0600, sussman@tigris.org wrote:
> Author: sussman
> Date: 2001-11-16 05:43 GMT
> New Revision: 465
> 
> Added:
>    trunk/subversion/svnadmin/shell.c
>    trunk/subversion/svnadmin/svnadmin.h
> Modified:
>    trunk/subversion/svnadmin/main.c
> Log:
> 
> Okay, I've been secretly sitting on this for over a week, just a
> little experiment.  Thought I'd commit it for everyone's amusement.
> :-)
> 
> Try this with a local repository:  'svnadmin shell repos', and then
> type 'help'.
> 
> * svnadmin.h:  new header file.  contains #includes that were in main.c.

Header files which "include the world" suck. We threw out that concept in
the early stages of SVN development.

> * main.c:      move #includes to svnadmin.h;  add new "shell" subcommand.
> * shell.c:     implement a simple, exploratory shell.

I don't like this. This "fun little hack" is going to grow into a full scale
app when we're not looking. "Just one more feature". A year later, and we've
completely reimplemented what cadaver does for us today.

In the interest of moving to more client-side administration, and away from
server-side "operate on a local FS", I'd say let's *not* include
functionality like this. Let's depend on standard WebDAV tools for exploring
the repository.

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

Re: svn commit: rev 465 - trunk/subversion/svnadmin

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

Karl Fogel <kf...@newton.ch.collab.net> writes:

> Which is fine; we make such trade-offs every day.  But as long as
> `svnadmin' is a bare bones, just-the-facts-ma'am kind of tool, I
> wouldn't want to see us spending any significant time making major
> interface improvements to it.

Amen.  I certainly didn't mean to throw out so much heat and smoke
over this.  I was just scratching a tiny itch -- I certainly don't
plan to spend any more time touching svnadmin.  Consider the issue
dead.  :-)




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: rev 465 - trunk/subversion/svnadmin

[Karl Fogel <kf...@newton.ch.collab.net>]

Ah, okay, see the distinction now.  Svnadmin isn't a tool for doing
the sorts of administrative tasks that users might want to do, it's
for checking on the health of one's repository, removing dead
transactions, that sort of thing... (?)

The distinction is real, but the problem arises in trying to place the
dividing line.  Eventually, one has to wonder if there should be such
a line at all.

For example, we can use `svnadmin' right now to change log messages.
Great.  No user would ever want to do *that*, right?  :-)

Of course they would.  The only reason it's in a server-side tool is
that it was easier for us to put it there.  It's not that we really
think it should be runnable only on the server, it's that there isn't
time to make it work any other way.

Which is fine; we make such trade-offs every day.  But as long as
`svnadmin' is a bare bones, just-the-facts-ma'am kind of tool, I
wouldn't want to see us spending any significant time making major
interface improvements to it.  That effort would be better devoted to
removing entirely the restriction that it be run server side, and
making that functionality available via the client (over RA) instead.

Not proposing that that be a high priority now, although it should
eventually.  But let's not spend too much time on svnadmin except to
add new & necessary functionality.  The tool is a placeholder.

-K

Ben Collins-Sussman <su...@collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
> 
> > > * shell.c:     implement a simple, exploratory shell.
> > 
> > I don't like this. This "fun little hack" is going to grow into a full scale
> > app when we're not looking. "Just one more feature". A year later, and we've
> > completely reimplemented what cadaver does for us today.
> 
> I don't see how this is related to cadaver -- or webdav -- at all.
> It's solving a completely different problem.
> 
> No webdav tool in the world is going to natively speak libsvn_fs's
> API.  The point of svnadmin is that it allows an administrator to
> inspect the health of a repository -- by examining
> *Subversion-specific* detalis such as node-rev-ids, created-revisions,
> or possibly dead transactions.  It has nothing to do with dav, and
> it's certainly not meant for "general users".
> 
> (For example, when we were debugging merge bugs and such, 'svnadmin'
> was great.  We could compare node-rev-ids resulting from our commits,
> and get an idea of what was going on.  It was a great supplement to
> gdb.  The only point of the hack was that it's easier to look at data
> from a shell, instead of printing out entire trees.)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: rev 465 - trunk/subversion/svnadmin

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

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

> > * shell.c:     implement a simple, exploratory shell.
> 
> I don't like this. This "fun little hack" is going to grow into a full scale
> app when we're not looking. "Just one more feature". A year later, and we've
> completely reimplemented what cadaver does for us today.

I don't see how this is related to cadaver -- or webdav -- at all.
It's solving a completely different problem.

No webdav tool in the world is going to natively speak libsvn_fs's
API.  The point of svnadmin is that it allows an administrator to
inspect the health of a repository -- by examining
*Subversion-specific* detalis such as node-rev-ids, created-revisions,
or possibly dead transactions.  It has nothing to do with dav, and
it's certainly not meant for "general users".

(For example, when we were debugging merge bugs and such, 'svnadmin'
was great.  We could compare node-rev-ids resulting from our commits,
and get an idea of what was going on.  It was a great supplement to
gdb.  The only point of the hack was that it's easier to look at data
from a shell, instead of printing out entire trees.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: rev 465 - trunk/subversion/svnadmin

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

Karl Fogel <kf...@newton.ch.collab.net> writes:

> > In the interest of moving to more client-side administration, and
> > away from server-side "operate on a local FS", I'd say let's *not*
> > include functionality like this. Let's depend on standard WebDAV
> > tools for exploring the repository.
> 
> +1 on favoring client side administration; the current `svnadmin'
> program exists mainly because we needed it to debug our filesystem
> while the rest of Subversion was still under development :-) And of
> course it's always easier to write something to operate on local disk
> data than to run over a network.  But that doesn't mean it's a great
> user tool.
> 
> Server administration can happen through other WebDAV tools, and
> through new commands added to the Subversion client[s]... and a little
> overlap never hurt anyone. :-)

So, if I understand correctly:

You guys are proposing that we either augment the SVN client (or write
a new client) that truly transports the libsvn_fs API over a network?
Sends node-rev-ids or created-revs back and forth?  Allows
administrators to remove dead transactions?  These are fs-specific
concepts that don't exist in the dav model.

If you do this -- well, I hate to say it, this sounds like a new ra_
layer to me.  Wouldn't such a project effectively eliminate the need
for ra_dav itself!?

I reiterate: I didn't give 'svnadmin' any new features; I just made
one of its existing features more usable (namely, the printing of
trees.)  Any newfound fears of "too much server-side administration"
were just as valid a week ago as they are today -- a shell-mode
doesn't change anything.

My feeling is: svnadmin is necessary, and only does svn-specific
things that cadaver & friends cannot do.  Specifically, svnadmin
prints out detailed fs-data.  It's only write operations are to change
log messages, remove dead txns, deltify/undeltify revisions, create a
repository, and recover db.  Of these things, only the first item
should be done by a cilent app.  Anything else is a waste of time,
IMO.  Typical (remote) users don't normally create repositories,
undeltify revisions, or search for dead txns -- so why kill ourselves
to make them happen over a network?  'svnadmin' is for administrators,
and thus it makes sense to assume that the admin has direct local
access to a repository.

Really, I'm trying to address an issue that has been worrying me for a
long time.  Despite CVS's shortcomings, there is a great feeling of
"administrator comfort" in knowing that a CVS repository is all plain
text.  Deep down, I have a feeling that a lot of admins are going to
freak when the see that their SVN repository is binary-only.
'svnadmin' can help by at least providing the *illusion* that the
repository is more hackable and accessible than it really is.  That
was my subconsicous motivation for tweaking the UI.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: rev 465 - trunk/subversion/svnadmin

[Karl Fogel <kf...@newton.ch.collab.net>]

Greg Stein <gs...@lyra.org> writes:
> I don't like this. This "fun little hack" is going to grow into a full scale
> app when we're not looking. "Just one more feature". A year later, and we've
> completely reimplemented what cadaver does for us today.
> 
> In the interest of moving to more client-side administration, and away from
> server-side "operate on a local FS", I'd say let's *not* include
> functionality like this. Let's depend on standard WebDAV tools for exploring
> the repository.

+1 on favoring client side administration; the current `svnadmin'
program exists mainly because we needed it to debug our filesystem
while the rest of Subversion was still under development :-) And of
course it's always easier to write something to operate on local disk
data than to run over a network.  But that doesn't mean it's a great
user tool.

Server administration can happen through other WebDAV tools, and
through new commands added to the Subversion client[s]... and a little
overlap never hurt anyone. :-)

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org