[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Stein <gstein_at_lyra.org>
Date: 2002-02-20 22:22:36 CET

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?


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

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


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
Received on Sat Oct 21 14:37:09 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.