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 <sussman@collab.net> writes:
> Greg Stein <gstein@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
Received on Sat Oct 21 14:36:48 2006