svn propset -r

sussman@tigris.org writes:

> Author: sussman
> Date: 2002-09-27 00:05:20 -0500 (Fri, 27 Sep 2002)
> New Revision: 3240
>
> Infrastructure for setting revision properties from client.

So now we have two use-cases for 'svn propset':

usage: 1. propset PROPNAME [PROPVAL | -F VALFILE] [WC_TARGETS]
       2. propset PROPNAME [PROPVAL | -F VALFILE] -r REV [URL]

First usage creates a versioned, local propchange in working copy.
Second usage creates an unversioned, remote propchange on repos revision.

The -r is basically the key to making propset behave one way or
another. Also notice the optional URL in the second case; this means
you can tweak a repository prop without having a working copy. If you
do have a working copy, then the URL arg can be dropped, and URL of
'.' is used.

Because these propchanges are unversioned, they can be potentially
very destructive -- the old value is lost forever. Thus this new
feature is INACTIVE by default; unlike other hook scripts, you can't
change a revision prop until the repository administrator actually
goes and creates a 'pre-revprop-change' hook.

Here's what's missing:

  1. no ra_dav yet, just ra_local. I'll fix that tomorrow.

  2. the pre-revprop-change hook needs to accept the proposed binary
     propvalue from stdin. It would be great if somebody could look
     at hooks.c:run_hook_cmd() and make that happen. (For now, my test
     hook script is just a dumb old "exit 0".)

  3. in the long run, we need to be able to run propget, proplist, and
     propedit with the -r option as well.

Heck, I just realized that we have *no* way of doing a proplist on a
revision right now -- even svnadmin and svnlook won't do that. They
only show the specific revision props 'svn:log', 'svn:date', and
'svn:author'. Yeesh.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 27 07:23:05 2002