David Weintraub <qazwart@gmail.com> wrote on 06/21/2005 01:08:45 PM:
> 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:
I would be pretty surprised if a feature like that were ever implemented.
It seems like there is a lot of room for error and it also forces a GUI to
have to run this command as part of the commit UI and process (assuming
the goal is to integrate these properties into the commit dialog). I
think making the properties a part of the commit makes more sense.
> 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.
That might be overstating it a bit. SVNLOOK operates on the transactions
in the repository directly, this feature would require the commit protocol
being able to supply the properties as part of the transaction. It is
possible, even likely, that the current protocols would have to be
modified.
> > 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.
Yes, it is all about allowing a Subversion client to provide a nice GUI
for collection the bug number as part of the commit and then later
allowing the history UI to provide links to the bug tracking system. Of
course it is also about standardizing the format of the log message so
that it is easier to write hooks that validate and/or extract the bug
ID's. This last part would obviously be much simpler if there were
revision properties.
> 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.
The spec calls for the GUI to search up the WC hierarchy to find the
properties. In many cases this means you only need to set the properties
on the top most folder. Obviously if your app is such that any folder
could be checked out as a top-level folder, then you would have to set the
props everywhere.
> > 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
GUI's would also need the underlyign API's to allow retrieving this
information just as easily (and quickly) as the "built-in" revision
properties. That way I could just add a bug ID column to my GUI history
viewer as I have already for the author and date.
> 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.
What I would like to be able to do is ask Subversion for all revisions
where the bug number is X. Then a bug tracking tool does not even need to
store this information in its own system. It could just ask Subversion
for the info on the fly.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 21 19:35:53 2005