Re: [fossil-users] working with open source code

2014-05-31 Thread Andy Bradford 
Thus said Abilio Marques on Sat, 31 May 2014 00:12:00 -0430:

 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

Are they committing changes to trunk?

 Then, someday, I will want to update my sqlite base code.

Again, are we talking about trunk or is your ``base'' code maintained in
a local branch (I say local because  I don't mean private, but rather, a
branch  that exists  in your  local server  clone but  will not  push to
sqlite proper).

Andy
-- 
TAI64 timestamp: 4000538a1c64


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] working with open source code

2014-05-30 Thread Abilio Marques 
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

Re: [fossil-users] working with open source code

2014-05-30 Thread B Harder 
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