Karl Fogel <kfogel@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
Received on Sat Oct 21 14:36:48 2006