also, sometimes a single ticket requires multiple checkins over time
to arrive at a fix.
rw
from my mobile 434.851.1612
On Mar 14, 2010, at 12:53 PM, Jeremy Cowgar jer...@cowgar.com wrote:
On 3/13/2010 7:32 PM, Jacek Cała wrote:
fossil commit -t ticket_id -m comment [-r resolution_type]
[...@ramon] Hmmm, yes and no.
fossil ticket...
would give more versatility but again it would require two steps instead of
one.
[...@ronald] Yes, if you need multiple checkins this option would require
another parameter, like '-s status'
[...@ron] This might be a little hassle when there is
On 3/13/2010 7:32 PM, Jacek Cała wrote:
fossil commit -t ticket_id -m comment [-r resolution_type]
I like the idea. Only one problem, as I see it though. Maybe discussion
can bring about it's resolution. Maybe it's just a change of my
workflow, don't know. I'll get a few minor bug's submitted
On Sun, Mar 14, 2010 at 12:53:09PM -0400, Jeremy Cowgar wrote:
On 3/13/2010 7:32 PM, Jacek Cała wrote:
fossil commit -t ticket_id -m comment [-r resolution_type]
I like the idea. Only one problem, as I see it though. Maybe discussion
can bring about it's resolution. Maybe it's just a
On Sunday 14 March 2010 18:53:09 Jeremy Cowgar wrote:
* Fixed [384938]. Blah Blah Blah
* Fixed [2939283]. Blah Blah Blah.
Does everyone do the same or does everyone fix one bug per commit?
I try to make one checkin per fix (I'm a fan of checking in often as a means or
cheap
Hi All,
What do you think about the following feature?
The case is very common, I suppose. Let's have an issue reported by a
tester/user as a ticket. When a developer resolves the issue they would like
to commit changes that are related to the ticket describing this issue.
AFAIK in fossil
On Sunday 14 March 2010 02:32:32 Jacek Cała wrote:
Wouldn't be useful if this common case is simplified to only a single
operation: commit which closes a related ticket e.g. using a command like:
fossil commit -t ticket_id -m comment [-r resolution_type]
Yeah, I can see where that would be
7 matches
Mail list logo
