On 3/30/13, Stephan Beal <sgb...@googlemail.com> wrote: > > Fossil _repos_ are indeed intended to be used by relatively few people at a > time. Fossil is designed for small, relatively tight-knit teams. It does > not directly support deep hierarchies of developers like git does.
>From my limited experience with git, a few years ago, git does 2 things that require extra effort to do in Fossil: 1. Changes from "below" do not automatically propogate. This allows (requires) adevelopper to inspect/integrate received changed before sending them "up". 2. A developper can receive changes from his/her subordinates in to a named branch. That is, the subordinate's trunk is pulled/pushed in to the receiver's repo as a named branch. The receiver then explicitly diffs/merges/integrates the received changes in to his/her trunk (or other branch) #2 could be handled by the subordinate developpers only commiting changes to named branches instead of the trunk. Working using named branches is a good idea, anyway, so this is not much of a burden. As for #1, as long as the subordinates are only commiting to named branches, if those branches are tagged privated, then they won't be automatically propogated. Question: If I push my non-private, named banch to another developper, can he/she tag it private in his/her repo, or will my pushes override the private tag on "my" branch in his/her repo? Also, I forget, can pushes/pulls to trunk be blocked while allowing to named branches? _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users