Appropriate use of revision properties?

[Andy Levy <an...@gmail.com>]

One of the (many) things we want to track with our usage of Subversion
is not only who changed what and when, but for what internal
change-tracking ticket #.  I realize that there are issue tracking
systems that integrate with svn, but that's not really an option here.
 I'm envisioning the following workflow:

Issue is logged in ticket system & assigned ticket #1234
Issue is assiged to developer
Developer makes requisite changes
Developer sets a rev prop called "Ticket" and sets a value of "1234"
Developer commits change to svn

Yes, I could use branches or tags, but this may make bundling fixes
for a number of tickets into one release cumbersome (with or without
merging every time).

My thinking is that by doing this, we can more easily query subversion
logs later to determine what changes were made for ticket 1234.  The
alternate would be to have a standard commit message format and
require everyone to use it; however, that would require parsing every
commit message to find the ticket number I'm looking for.

Where would I find this revprop reported later?  I'm currently using a
tweaked svn2cl (originally written by Arthur de Jong) to generate an
HTML changelog from the output of svn log --xml --verbose - will
revprops be included in that output?

Am I way off course here?  How do other developers/teams manage
tracking like this?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Appropriate use of revision properties?

[Paul Koning <pk...@equallogic.com>]

>>>>> "Bart" == Bart Robinson <lo...@pobox.com> writes:

 Bart> On 2006-1-12 Ryan Schmidt <su...@ryandesign.com>
 Bart> wrote:
 >> > My thinking is that by doing this, we can more easily query
 >> subversion > logs later to determine what changes were made for
 >> ticket 1234.  The > alternate would be to have a standard commit
 >> message format and > require everyone to use it; however, that
 >> would require parsing every > commit message to find the ticket
 >> number I'm looking for.
 >> 
 >> As far as I know, most people put that kind of stuff into their
 >> commit message according to a particular format. For example, we
 >> require all bug numbers to begin with a hash mark (e.g. "#1234")
 >> so that it could be automatically parsed out by a tool, should we
 >> at some point get the desire to write one.

 Bart> We do the same ("BugId: 1234,1236" at the beginning of a line
 Bart> for easy extraction, the post commit hook appends to the
 Bart> bugzilla entry).  I think having to manually tie the bug to the
 Bart> changeset is a pain, much easier to just put it in your commit
 Bart> message.

Same here, except that the format isn't particularly tightly
controlled.  I added a simple tweak to ViewVC to find bug ID
references (if halfway sanely formatted) and turn them into
hyperlinks.  No hooks needed, which means it works fine with old
revision messages (even from CVS) -- so long as the string has
something vaguely like "bug 1234" in it anywhere, it'll get hooked to
bugzilla. 

	  paul


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Appropriate use of revision properties?

[Bart Robinson <lo...@pobox.com>]

On 2006-1-12 Ryan Schmidt <su...@ryandesign.com> wrote:
 > > My thinking is that by doing this, we can more easily query subversion
 > > logs later to determine what changes were made for ticket 1234.  The
 > > alternate would be to have a standard commit message format and
 > > require everyone to use it; however, that would require parsing every
 > > commit message to find the ticket number I'm looking for.
 > 
 > As far as I know, most people put that kind of stuff into their  
 > commit message according to a particular format. For example, we  
 > require all bug numbers to begin with a hash mark (e.g. "#1234") so  
 > that it could be automatically parsed out by a tool, should we at  
 > some point get the desire to write one.

We do the same ("BugId: 1234,1236" at the beginning of a line
for easy extraction, the post commit hook appends to the
bugzilla entry).  I think having to manually tie the bug to the
changeset is a pain, much easier to just put it in your commit
message.

The ability to easily go back and edit the svn:log revprop makes
it simple to go put bugid: tags in if someone forgets (we put
them at the beginning of a line for easy extraction).

However, Subversion doesn't currently have log message templates
so you either have to hack the code (what I did) or have
thorough user-education and enforcement about what fields to add
to commit messages.  I plan to help fix the log templates thing
since we use them heavily.  svn issue 1973 tracks the templates
feature.

 > I believe some of the web-based repository viewers import information  
 > about each revision into their own database whenever the commit takes  
 > place, via a post-commit hook. You could use one of those tools, or  
 > write your own, such that you build up your own database which could  
 > then contain anything you like, including all revision properties.  
 > Then you could query your database for that information.

Hey that's a good idea.  viewvc does the database thing and it
would be pretty straightforward to customize it to store the
issue-id from the commit message.  Then you could do queries
like "what bugs were fixed on this branch", or "what branches
had fixes related to bugid 1234" (although for us that info is
already in the bug report, just spread around in the comments).

-- bart

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Appropriate use of revision properties?

[Ryan Schmidt <su...@ryandesign.com>]

On Jan 11, 2006, at 18:57, Andy Levy wrote:

> I'm envisioning the following workflow:
>
> Issue is logged in ticket system & assigned ticket #1234
> Issue is assiged to developer
> Developer makes requisite changes
> Developer sets a rev prop called "Ticket" and sets a value of "1234"
> Developer commits change to svn
>
> Yes, I could use branches or tags, but this may make bundling fixes
> for a number of tickets into one release cumbersome (with or without
> merging every time).

I don't see how tags can be used to fix bugs. A tag is supposed to be  
a snapshot of the trunk (or a branch) at a particular point in time,  
never again to be changed.

A branch could be used. If the bug fix takes more than a short while  
to fix, and it requires several commits to do, and the intermediate  
commits would break the project in a way that would inconvenience the  
other developers, then it would make sense to branch off first, fix  
the problem in the branch, then merge the changes in the branch back  
into the trunk. That would be a "feature branch," or, if you like, a  
"bug-fix branch."

I don't see how such a branch would make a release any more or less  
difficult. If you fix the problem in the trunk initially, or merge  
the fix there from another branch, it still ends up on the trunk, and  
you can still cut a release from it. The branch strategy just takes a  
bit more effort on the developer's part; whether that effort is well- 
spent there or not needs to be decided separately for each issue.


> My thinking is that by doing this, we can more easily query subversion
> logs later to determine what changes were made for ticket 1234.  The
> alternate would be to have a standard commit message format and
> require everyone to use it; however, that would require parsing every
> commit message to find the ticket number I'm looking for.

As far as I know, most people put that kind of stuff into their  
commit message according to a particular format. For example, we  
require all bug numbers to begin with a hash mark (e.g. "#1234") so  
that it could be automatically parsed out by a tool, should we at  
some point get the desire to write one.


> Where would I find this revprop reported later?  I'm currently using a
> tweaked svn2cl (originally written by Arthur de Jong) to generate an
> HTML changelog from the output of svn log --xml --verbose - will
> revprops be included in that output?

That's the problem -- you won't find it later. If you committed  
revision 34 and attached custom revprop my:bugid=1234, then the only  
way you will discover this is if you specifically ask Subversion to  
give you the properties in revision 34. There is no mechanism by  
which you could conduct a search to find all revisions where a  
certain property equals a certain value.

I believe some of the web-based repository viewers import information  
about each revision into their own database whenever the commit takes  
place, via a post-commit hook. You could use one of those tools, or  
write your own, such that you build up your own database which could  
then contain anything you like, including all revision properties.  
Then you could query your database for that information.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org