On Wed, Oct 2, 2013 at 10:22 AM, Stephan Beal <sgb...@googlemail.com> wrote:
Ignoring the complication of having to parse/grok the content (it's a minor
> complication, granted, but parsing text is always at least a slight
> annoyance), there's another problem: DVCS. i edit the field, then you close
> the ticket in your copy before i sync my changes to the blocker list. So
> we've now got a closed ticket with open blockers. i don't see how that
> could be made to work (meaning "automatically enforced") 100% reliably in a
> DVCS.
>
It seems to me that the most immediately obvious solution would involve the
synching process.
Let's say there's a central repository R and two users M and N who have
cloned R (to make R(M) and R(N)). R contains bugs B1 and B2.
(1) M modifies R(M) to make B2 blocked by B1. Bug B1 is not affected in
any way (other than perhaps to say that it blocks B2, e.g. a metadata
change).
(2) N modifies R(N) to close B2 (presumably making changes to code, etc, or
possibly closing it as WillNotFix, NotABug, WorksForMe, CannotReplicate,
etc without code changes). Bug B1 is not affected in any way.
(3) M pushes R(M) to repository R to create R' -- R' is now a duplicate of
R(M) and therefore says bug B2 is blocked by B1.
(4) N pushes R(N) to repository R'. During the push, it is noticed that
R(N) says bug B2 is closed while R' says it is open and blocked by B1 (and
that A specified the block), which is open both in R' and R(N). N should
be notified of this as it is something which cannot be automatically
resolved by fossil, and given an opportunity to specify what to do.
(Alternatively, if it is deemed permissible to close bugs as WillNotFix,
etc without closing their blockers, then those changes could be synched in
both directions -- the close synched from R(N) to R' and the block synched
from R' to R(N). N should probably still be notified if this happens, in
case they wish to review and perhaps change their decision to close B2
given the new information available.)
How is this different from synching other things, such as code etc, where
multiple people might make incompatible changes to the same object which
require human intervention to resolve?
> I didn't expect it to be a "rocket" feature but exactly a client-side
>> customization others {may/may not} find useful.
>>
>
> i don't deny that, i'm just thinking more in terms of "ratio of code to
> users," and so far you're the only(?) one who's expressed an interest in
> blockers.
>
That's a fair consideration, whether or not implementing this is worth the
cost (both of implementation and ongoing maintenance).
OTOH, isn't this a feature available in most modern pro-grade bug
trackers? (Admittedly, most of them probably do not use distributed
databases in the same way that fossil does but instead are intrinsically
centralized.) Is it possible there are potential users who are dissuaded
from using fossil because of lack of an advertised capability to specify
blocking bugs, and because it does not exist they never attempt to use
fossil in the first place and their interest in blockers never becomes
visible to the devs for fossil? That sounds like a chicken and egg -type
problem to me.
This isn't to say implementation of blocking bugs *should* be done, of
course, but just that merely because it's never come up before does not
mean there would not be interest in it or use of it if it *were*
implemented.
Hope this is of some use, interest. Thanks for your time. Be well.
Joseph
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
