IIUC: you: fossil clone http://sqlite.org:8080 fossils/sqlite.fsl; cd project_dir; fossil open ~/project_dir/sqlite.fsl; fossil server
Each of your our co-conspirators: fossil clone http://your.machine.address:8080 fossils/sqlite.fsl; cd project_dir; fossil open ~/fossils/sqlite.fsl You will: fossil set autosync 0 (because unlikely drh is going to let you push your changes to canonical repo) Your co-conspirators will set autosync to 1 (to sync with your repo auto-magically). You will use the UI to give (eg) developer privileges to the folks that cloned from you, so they can re-push their work to your copy of the repo. Hack, hack. fossil sync, fossil pull, fossil push where necessary. Maybe two peers will sync explicitly between themselves if they're working on something that requires it... What am I missing? On May 30, 2014 9:42 PM, "Abilio Marques" <amarq...@smartappsla.com> wrote: > Hi, > > Let's say I want to do this setup: > Clone sqlite repo on a local server > Then clone the server into several machines, with the users pushing changes > > Then, someday, I will want to update my sqlite "base" code. > > In git, one would first fork the code from another repo, add a second > remote: > git remote add upstream > > then proceed to work as usual. Then do a: > git fetch upstream > > and even a merge: > git merge upstream/master > > > Any recomendation on how to perform something like this, for example, with > the sqlite code? > > > Thanks, > > > PS: just in case https://help.github.com/articles/fork-a-repo > https://help.github.com/articles/fork-a-repo > > _______________________________________________ > 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
