Re: svn commit: rev 1329 - trunk/subversion/svnadmin trunk/subversion/tests/clients/cmdline

On Tue, Feb 19, 2002 at 10:04:46PM -0600, Ben Collins-Sussman wrote:
>...
> But if I were a consciencous repository administrator, I would never
> execute such a line. What if some of those transactions were commits
> in progress? Or updates in progress?

Agreed.

However, I *do* like the change. In general, I don't want all the
information from the previous incarnation of the command.

> What I want is a command that is in between; it doesn't print the
> whole txn tree, but it gives me *more* than just the txn name. I'd
> want one txn per line, but divided into columns:
>
>
> txn: 866 username: sussman created: 25-Feb-2002
> txn: 901 username: cmpilato created: 02-Apr-2001
> txn: 998 username: foo created: 03-May-2000
>
> Then I could write a script to parse the fields, and say, remove all
> transactions that are older than 2 weeks. Or remove all transactions
> created by an employee who no longer works with the company...

Ooh! Neat.

> Do you think we can have a 'middle' mode?

Add --quiet for the shortest form, middle form is the default, and --verbose
is the long format.

> Or maybe all this repository adminstration should be happening via the
> client, over the RA vtable. :-)

Actually, that is quite doable. It is a PROPFIND against the activity
collection. In mod_dav_svn, that collection is a PRIVATE resource type,
where the info->restype==DAV_SVN_RESTYPE_ACT_COLLECTION.

Removing a transaction is just a DELETE on the activities found under that
collection.

We'd use DAV:displayname for the short name (over DAV, they use UUIDs),
DAV:creator-displayname for the author, DAV:creationdate for when the txn
was created, and possibly DAV:getlastmodified for when the txn was last
touched (the different times could be important for, say, the commit
approval stuff which uses delayed commits).

Most of the svnadmin commands can be modeled (even "create" to some extent;
definitely if we enable a multi-repository apache config option). The *real*
question is what to do on the client side. How many new commands will be
needed? Do they all go into the same 'svn' client? (I think so) Do we list
the admin commands with all the others, or do they get classified as 'admin'
commands, and we only show them with 'svn help --verbose' ? etc etc

Personally, I think getting rid of most of the svnadmin commands is Right.
My only real issue is whether we should do it Right for 1.0, or stick with
svnadmin.

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