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
Received on Thu Jan 12 00:07:51 2006