Re: [fossil-users] Ticket system -- blockers
On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice jayare...@gmail.comwrote: 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. This would be a fundamental change to the design and philosophy of Fossil. You are asking that push operations become atomic (either all artifacts are pushed or else none are) and that the push can only succeed if certain constraints are satisfied. As currently designed, Fossil does push operations incrementally. And a push never fails due to constraints. The current model is that a repository is an unordered bag of blobs (called artifacts). A push from A to B merely causes all artifacts held by A to be copied into B if they are not already there. The push logic does not know or care about the content of the individual artifacts. There are no constraints that prevent certain artifacts from being pushed from A to B based on content. If A has push permission, then A can push any artifact it wants, whenever it wants, and it can push multiple artifacts in any order that it wants. The push and pull logic never examines the content of an artifact. Push and pull are just transport. Like TCP/IP, that merely moves information from one place to another without regard to the meaning of that information, push and pull just move artifacts from one repository to another with the objective that both repositories end up holding all artifacts. Now, you could in theory change the philosophy of Fossil so that push and pull did examine the content of artifacts as they moved over the wire, and rejected artifacts that violated constraints. But to do so would seriously complicate matters, both for the implementation and for the user. Suppose you had a case where repositories A and B held incompatible artifacts, artifacts that caused constraint violations. A could not push to B without violating a constraint so the push would fail. But if pushing from A to B violated a constraint, so would pulling from B back to A. The user of A is therefore stuck. He cannot pull without resolving the constraint. He cannot resolve the constraint without knowing what the constraint is. And he cannot find out what the constraint is without doing a pull. Stalemate. So maybe you add some logic to deal with this first-level constraint violation and prevent stalemate. I think you would quickly run into lower-level and more subtle kinds of stalemates, though. I fear that such a design would quickly devolve into playing whack-a-mole with constraints. 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? Push and pull never create conflicts. Conflicts only occur during a merge operation, which is something that only occurs in a local checkout. A push or a pull might create a new branch or fork in the code, but it never creates a conflict. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
Applying constraints as receiver end filtering could be very useful and I think it could fit the sync model if not needed blobs were not necessarily dropped but a record was kept so that they wouldn't be sync'd and they are kept out of the list of blobs. Essentially something similar to what the shun mechanism does now. I think features like the ticket blocking and pulling only a specific branch could be implemented on top of such a mechanism with the caveat that all data was being sync'd at least once. I.e. this would add control and management power to fossil but it would not be a bandwidth saving mechanism. Consider an autoshun mechanism that for example suppresses blobs based on branch name. To make it work this blob suppression mechanism would not remove blobs on rebuild. Could this work? On Mon, Oct 7, 2013 at 12:43 AM, Richard Hipp d...@sqlite.org wrote: On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice jayare...@gmail.comwrote: 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. This would be a fundamental change to the design and philosophy of Fossil. You are asking that push operations become atomic (either all artifacts are pushed or else none are) and that the push can only succeed if certain constraints are satisfied. As currently designed, Fossil does push operations incrementally. And a push never fails due to constraints. The current model is that a repository is an unordered bag of blobs (called artifacts). A push from A to B merely causes all artifacts held by A to be copied into B if they are not already there. The push logic does not know or care about the content of the individual artifacts. There are no constraints that prevent certain artifacts from being pushed from A to B based on content. If A has push permission, then A can push any artifact it wants, whenever it wants, and it can push multiple artifacts in any order that it wants. The push and pull logic never examines the content of an artifact. Push and pull are just transport. Like TCP/IP, that merely moves information from one place to another without regard to the meaning of that information, push and pull just move artifacts from one repository to another with the objective that both repositories end up holding all artifacts. Now, you could in theory change the philosophy of Fossil so that push and pull did examine the content of artifacts as they moved over the wire, and rejected artifacts that violated constraints. But to do so would seriously complicate matters, both for the implementation and for the user. Suppose you had a case where repositories A and B held incompatible artifacts, artifacts that caused constraint violations. A could not push to B without violating a constraint so the push would fail. But if pushing from A to B violated a constraint, so would pulling from B back to A. The user of A is therefore stuck. He cannot pull without resolving the constraint. He cannot resolve the constraint without knowing what the constraint is. And he cannot find out what the constraint is without doing a pull. Stalemate. So maybe you add some logic to deal with this first-level constraint violation and prevent stalemate. I think you would quickly run into lower-level and more subtle kinds of stalemates, though. I fear that such a design would quickly devolve into playing whack-a-mole with constraints. 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? Push and pull never create conflicts. Conflicts only occur during a merge operation, which is something that only occurs in a local checkout. A push or a pull might create a new branch or fork in the code, but it never creates a conflict. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Mon, Oct 7, 2013 at 11:31 AM, Matt Welland estifo...@gmail.com wrote: Applying constraints as receiver end filtering could be very useful and I think it could fit the sync model if not needed blobs were not necessarily dropped but a record was kept so that they wouldn't be sync'd and they are kept out of the list of blobs. Essentially something similar to what the shun mechanism does now. In theory, such ticket filtering could be done, but I don't know if there is an easy to find the artifacts making up a specific ticket. From what I have read, the ticket table holds the most recent field values and their respective timestamps so processing artifacts is only done when new ones arrive or a rebuild is done. Unless the ticket table also has a field for a list of the artifacts for each ticket, finding the artifacts required to detect restricted sequences of field value changes would be a very intensive operation. But, even if such checking could be added, there could still be pending ticket changes from an offline contributor. So far, the distributed ticketing system I know of is Fossil. It's distributed nature is going to introduce problems you won't see in a system that requires a connection to a central repository for operation. In an office situation where your team always has access to the main repository and you have auto-sync enabled, then Fossil will effectively work like a non-distributed system. But the main advantage of a distributed system like Fossil is to enable (mostly) normal operation in situations where one or more team members needs to get work done without constant access to the main repository. This could arise from having a geographically dispersed team or from the need to send someone to, for example, an outside testing facility. Where I work, our process is that we don't close or resolve tickets until the actions to date have been reviewed - and their affect on related tickets. That way, everyone knows before the ticket gets resolved or closed. (In theory, push/pull could be done via email. For small changes, this could be practical. Once libfossil is far enough along, maybe I will look into implementing an app to do that, at least for ticket updates. But even then, there will be significant lag in updates.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 3:51 PM, Jacek Cała jacek.c...@gmail.com wrote: ...For those interested I report changes to the ticket table (below) and view and edit pages (attached source). A remaining issue is that as there're no hard db constraints on blockers there seems to be no way to verify that the blocker to be added is actually a valid ticket uuid. Basically, user can add any text as a blocker. Any real blocking support has to be integrated with the system as a whole, from the human processes to the software (but primarily the human processes). What does a block actually block? Does it block a release (fossil doesn't know what a release is), does it cause work to be reprioritized (also something fossil knows nothing about), or does it have some other effect? My point being only that i don't think there's anything Fossil can reasonably know/do in regards to a blocker except for what you've already done: CREATE TABLE ticket( ... comment TEXT, blockers TEXT ); IMO that doesn't really belong in the default ticket schema system because... (and i know this is going to sound somewhat lame!)... it's never been a pressing issue before (in 6 years of use). It may have been brought up a time or two (i don't recall, but i also don't immediately recall whether or not i've already eaten today :/). If it's added, i'm pretty sure it will be ignored by 99% of users, in which case leaving it as an optional client-side customization seem more practical to me. But of course that's just my personal opinion and not some sort of official statement :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
in the field (possibly without commas, or a mixture). 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. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist. Cheers, Jacek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
Jacek, I just started using fossil. It is heartening to see there are so many people contributing. I haven't run into that need yet, but it doesn't mean i won't. Thanks for putting this out there. I will know where to find it if that need arises. Krister On Wed, Oct 2, 2013 at 9:31 AM, Jacek Cała jacek.c...@gmail.com wrote: in the field (possibly without commas, or a mixture). 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. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist. Cheers, Jacek ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 10:31 AM, Jacek Cała jacek.c...@gmail.com wrote: in the field (possibly without commas, or a mixture). 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. Fair enough, it's just that having indicators that something is blocking my ticket may still be useful -- at least to me. Clearly, I'd sync my repo before trying to resolve any blockers but at least I know they exist Having a list of any related tickets is useful. Your implementation is impressive and good. My own was just an extra field with a text area in the ticket edit page - though I did actually render links on the ticket view page. I might use a simplified version of yours. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket system -- blockers
On Wed, Oct 2, 2013 at 10:47 AM, Stephan Beal sgb...@googlemail.com wrote: Most just don't generate as much noise as i do, so you haven't seen them yet in your short time here ;). Noise? I'd say you have a very high signal-to-noise ratio. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
