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
