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.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 > > -- 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
