On Sun, Oct 6, 2013 at 9:55 PM, Joseph R. Justice <jayare...@gmail.com>wrote:
> 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
