Re: Setting Revision Properties before Commit

On 6/21/05, Mark Phippard <MarkP@softlanding.com> wrote:>
> There already is an open issue for this:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=1976

Thanks, I checked for "revision property", "revision properties", and
even just "properties". This was under "rev-props".

A UI? There is already a UI for setting revision properties:

$ propset PROPNAME --revprop -r REV [PROPVAL | -F VALFILE] [URL]

The problem is that the "-r" parameter is mandatory. If the UI made it
optional, and simply assumed to set it on the next commit transaction,
we'd be fine. Of course, someone could accidently forget the option,
and not realize they were setting the revision parameter for the wrong
revision. Maybe something like this:

$ propset PROPNAME --revprop [-r REV | --oncommit] [PROPVAL | -F
VALFILE] [URL]

Of course, the proplist, propdel, and propedit commands must also
incorporate these changes.

I don't really see a need to set this on a commit (which is the UI
everyone is talking about). If there was a way to set it on the
command line, client GUIs could incorporate it or users could write
their own commit shell scripts. After all, regular properties can't be
set on commits.

The only concession I see is allowing autoproperties to set rev-props
just like it can set regular properties.

Apparently, you can already set the rev-props for the next commit
transaction via the Subverison bindings and the SVNLOOK command can
verify these properties (which means you can test for them in
pre-commit hooks)

It appears the feature is 90% there right now.

> Whether there are revision properties or not, this always going to be an
> issue. The Subclipse and TortoiseSVN projects got together and defined a
> standard "spec" that any Subversion client can easily implement to
> integrate with issue trackers.
>
> http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt

A lot of this doesn't really deal with the bug number itself, but how
the bug number is formatted (in order to find it in the svn log), and
setting up the integration between the client and bugtracking system
via properties in the parent folder.

I'm not too crazy about some of this stuff. If a user creates new
sub-folders, the bugtraq information is not there. Fortunately, my
hook can force the user to create the properties needed for these new
folders.

> If this revision property feature were implemented, we would likely
> enhavce the spec to also include setting a property. However, until there
> is some mechanism for querying revision properties, using log messages
> will likely remain the best place for this information.

Yup, that's another feature that's sort of missing: Querying
Subversion information via properties.

In a sense, the log is currently printing out a select set of revision
properties. Right now it prints out in this format:

<revision> | svn:author | svn:date | <# of lines in svn:log>
svn:log

How difficult would it be to have a "long" format for the "svn log".
Something that would print each and every revision property and it's
value in this format?

<revision> - <revproperty> = <revpropValue>.

Then the log would look something like this

$ svn log --long
------------------------------------------------------------------------
r183 - svn:author = weintraub
r183 - svn:date = 2005-06-10 16:26:23 -0400 (Fri, 10 Jun 2005)
r183 - svn:comment = Tell Subversion to ignore file "control-file"
         Moved control-file to control-file.template
r183 - bugtraq:id = 458
------------------------------------------------------------------------
r182 - svn:author = weintraub
r182 - svn:date = 2005-06-10 16:21:40 -0400 (Fri, 10 Jun 2005)
r182 - svn:comment = Finishing up unit testing of access.pl
r182 - target_rel = REV2.3
r182 - bugtraq:id = 459
------------------------------------------------------------------------

That would make the "svn log" fairly easy to parse via a grep command
or internally by any program. Without too much work, you could even
extend the syntax to only list the properties I'm interested in:

$ svn log --long --revprops svn:author,svn:date,bugtraq:id

Going beyond that to more general queries would be much more difficult
(show me all revisions where the bugtraq:id is between 1000 and 1200,
or were committed between June 1, 2005 and June 14, 2005). However, if
you can output the revision properties in this long format, you can
find exactly what you're looking for anyway. The only problem is the
amount of data that is being transmitted from the server to the
client.

Of course, this doesn't help with non-revision properties. It would be
nice to be able to find all files with a particular property set, but
that isn't as important as doing it for the revision-properties.

--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org