On 6/21/05, Mark Phippard <MarkP@softlanding.com> wrote:
> David Weintraub <qazwart@gmail.com> wrote on 06/21/2005 01:08:45 PM:
>
> > 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 --nextcommit REV [PROPVAL | -F VALFILE] [URL]
>
> 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.
There really shouldn't be a problem with errors if the syntax used the
"--nextcommit" command line parameter. You couldn't accidently set the
wrong revision parameter in this case.
I haven't had time to really play around with it, but I was already
informed that the bindings for setting properties on the next commit
transaction is already there. I could write my own Perl script to do
this even though the "svn propset" command can't.
I also don't see why it is a problem of "forcing" the GUI clients to
run two commands. That is, if they don't use the bindings, but instead
run the commands from the Subversion client. If they were setting
regular file properties, they'd be doing the same thing.
> > > 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.
Yes, but only if you checked out the parent folder! I find myself
creating subfolders, then creating a new working directory from that
folder. If the parent folder that contains the neede properties isn't
checked out, the commit comments are wrong, and the integrated bug
tracking system doesn't work.
The document mentions that you should have the developers always
checking out from the trunk to make sure it will work.
> > > 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.
Implementing a query language is always difficult. I figured that if
the "svn log" printed the information in an easily parsible format,
you could quickly find what you're looking for -- even without a query
language. If this could be implemented in Subversion 1.3 without a
query language or Subversion 4.x with a query language, I'd go for the
earlier release.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 21 22:53:42 2005