David Weintraub wrote:
>> well, with subversion, usually, you create a branche to fix a bug,
and then,
>> all commits to this branch have something to do with the bug.
>> (you can retrive them very easily, import the changes (almost) where you
>> want, etc.)
>
> Actually, most site where I've used Subversion fix the bug directly on
> the trunk (or whatever active release branch). This is much in line
> with current thinking of forcing users to share their changes with
> each other and is one of the major complaints with distributed
> systems.
>
> <http://blog.red-bean.com/sussman/?p=20>
unfortunately.
(note that it's maybe also due to the fact that for both cvs and
perforce user,
create a branch is a heavy procedure).
>> In addition, the notion of bug (managed or not by a third party tools)
>> imply that you specify, with a commit, some information (identification)
>> about the related bug. This can be 'commit in a specific branch'
(dedicated to the bug), but
>> more frequently,
>> you (also) give such identification through the commit log (like:
BUG-1234)
>> With such convention, looking for every commits having "BUG-1234")
in their
>> log message is easy.
>
> Of course, you can put your comments in the log, but then:
>
> You have to have your users agree to first put the bug number in the
> comments and agree to use the correct format. Then, you have to
> produce the log, search the log, and then determine that the comment
> in the log is in fact fixing that bug and not in a reference of a
> previous bug. For example, "This change fixes BUG-3400 which was
> created when some doofus 'fixed' BUG-3323". I want to make sure that I
> know this isn't a fix for BUG-3323, but for BUG-3400.
well... it's true that some 'rules' must be established... but with the
possibility
to verify the commit with a pre-commit hook, it's possible to reject lot of
badly formatted message.
In addition, some clients (like TortoiseSvn) give the possibility to:
(i) provide pre-formatted log messages (template)
(ii) reserve/use specific fields for the bug-tracking (entering the
related bug-ids)
Looking, from the log, for commits relative to a specific bug is then
really easy, as said by some other.
>> hum... personnaly, I will be really disappointed if subversion will
"offer"
>> such kind of "feature"
>> (deeply integrated, of course; having a "package" subversion+trac (for
>> example) is perfectly acceptable)
>
> Of course, defect tracking systems do integrate with Subversion and
> other defect tracking systems, but most of the time, the integration
> is one way: You can query the changes via the defect tracking system,
> but you can't query tickets too easily through subversion. (That might
> be a bit different for Trac since it apparently uses the Subversion
> repository, but I've never used Trac, so I can't say for certain).
well, it's the same. If you want to have high-level information about
the defects, you should use the defect tracking system.
> What the Perforce Job system allows you to do is to do the integration
> both ways: You can query your source changes via the defect tracking
> system, and you can query your defect tracking tickets via the source
> control system. For example, imagine if my last release was change
> set 3283, and now my next release will be change set 3904. From
> Perforce, I can quickly build a set of release notes showing all
> tickets worked on, their description, and who worked on them. And,
> because it is done from my version control side, I can usually find
> discrepancies in my defect tracking system where wrong information was
> entered.
>
I still don't see why this should absolutely(ideally) be done from
subversion (command-line),
but you can relatively easily do that from the tracking system, if the
simple grep on the
commit log don't fit your requirement (well, having a list of bug
*fixed* [#] between
two specific revisions is not totally trivial with track, because of how
*trac* (and not subversion)
is designed, but you can easily have something approaching, if you look
at the bug fixed
between x day/weeks/months ago and now).
For me, the conclusion is still that everything needed to use subversion
integrated with a decent bug
tracking system is already available (in subversion); but I admit that
there are some lacks in the
actually available bug-tracking clients [at least those that I know]...
even if, as said,
trac+a post-commit hook, let you do almost all that you want.
(cf
http://trac.edgewall.org/wiki/TracFaq#can-trac-automatically-update-a-ticket-when-i-commit-a-changeset)
regards,
flo
[#]
which, if you work with branches, open the question of when should you
considere that
a defect is fixed: when the proper code is inserted on a dedicated
branch, when this branch
is integrated in the active release, or when the release is done... etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-26 09:10:26 CEST