-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Nelson wrote: > Alex Willmer wrote: >> On Tue, Nov 9, 2010 at 9:39 PM, Chris Nelson >> <[email protected]> wrote: >>> How is no_cycle different from parent_child? I imagine parent_child >>> has more than no_cycle. It's only just occurred to me that cycles >>> have to be detected along all possible links. For example, A has a >>> child B which blocks C which blocks A. >> no_cycle checks that the graph is acyclic like you say, preventing a >> single link type forming a loop e.g. A depends on B depends on C >> depends on A. parent_child in addition checks that a single link type >> forms a tree - namely that a ticket may have many children, but at >> most one parent. > > That makes sense. But is preventing "single link type" loops sufficient? It > seems that my example could be a concern.
I feel like a collection of logic is needed here, what leads to a two-stepped approach: a) collect and somehow combine logic for every single relation type that makes loop conditions possible «strong» links like 'parent-child' or 'sibling' could be part of a loop, while «weak» ones like 'relative' would not be concerned. b) do a one-pass check with an algorithm respecting that combination of possible loop paths However, I don't know, if especially the combined logic could be done in terms of 'doable within months, not years'. Steffen Hoffmann (hasienda) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkzcUPoACgkQ31DJeiZFuHcn+wCeJ/aPv0APFNi2afQql7tPoMXO nGMAljRE0VjplWCLc84/cf7OB4Oqdo4= =+hFU -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
