|
dddc58d…
|
drh
|
1 |
<title>Child Projects</title> |
|
dddc58d…
|
drh
|
2 |
|
|
dddc58d…
|
drh
|
3 |
<h2>Background</h2> |
|
dddc58d…
|
drh
|
4 |
|
|
dddc58d…
|
drh
|
5 |
The default behavior of Fossil is to share everything (all check-ins, |
|
dddc58d…
|
drh
|
6 |
tickets, wiki, etc) between all clients and all servers. Such a policy |
|
085bfae…
|
drh
|
7 |
helps to promote a cohesive design for a cathedral-style project run |
|
dddc58d…
|
drh
|
8 |
by a small cliche of developers - the sort of project for which Fossil |
|
dddc58d…
|
drh
|
9 |
was designed. |
|
dddc58d…
|
drh
|
10 |
|
|
dddc58d…
|
drh
|
11 |
But sometimes it is desirable to branch off a side project that does not |
|
dddc58d…
|
drh
|
12 |
sync back to the master but does continue to track changes in the master. |
|
dddc58d…
|
drh
|
13 |
For example, the master project might be an open-source project like |
|
dddc58d…
|
drh
|
14 |
[https://www.sqlite.org/|SQLite] and a team might want to do a proprietary |
|
dddc58d…
|
drh
|
15 |
closed-source enhancement to that master project in a separate repository. |
|
dddc58d…
|
drh
|
16 |
All changes in the master project should flow forward into the derived |
|
dddc58d…
|
drh
|
17 |
project, but care must be taken to prevent proprietary content from the |
|
dddc58d…
|
drh
|
18 |
derived project from leaking back into the master. |
|
dddc58d…
|
drh
|
19 |
|
|
dddc58d…
|
drh
|
20 |
<h2>Child Projects</h2> |
|
dddc58d…
|
drh
|
21 |
|
|
dddc58d…
|
drh
|
22 |
A scenario such as the above can be accomplished in Fossil by creating |
|
dddc58d…
|
drh
|
23 |
a child project. The child project is able to freely pull from the parent, |
|
dddc58d…
|
drh
|
24 |
but the parent cannot push or pull from the child nor is the child able to |
|
dddc58d…
|
drh
|
25 |
push to the parent. Content flows from parent to child only, and then only |
|
dddc58d…
|
drh
|
26 |
at the request of the child. |
|
dddc58d…
|
drh
|
27 |
|
|
dddc58d…
|
drh
|
28 |
<h2>Creating a Child Project</h2> |
|
dddc58d…
|
drh
|
29 |
|
|
dddc58d…
|
drh
|
30 |
To create a new child project, first clone the parent. Then make manual |
|
dddc58d…
|
drh
|
31 |
SQL changes to the child repository as follows: |
|
dddc58d…
|
drh
|
32 |
|
|
8a1ba49…
|
wyoung
|
33 |
<verbatim> |
|
dddc58d…
|
drh
|
34 |
UPDATE config SET name='parent-project-code' WHERE name='project-code'; |
|
dddc58d…
|
drh
|
35 |
UPDATE config SET name='parent-project-name' WHERE name='project-name'; |
|
dddc58d…
|
drh
|
36 |
INSERT INTO config(name,value) |
|
dddc58d…
|
drh
|
37 |
VALUES('project-code',lower(hex(randomblob(20)))); |
|
dddc58d…
|
drh
|
38 |
INSERT INTO config(name,value) |
|
dddc58d…
|
drh
|
39 |
VALUES('project-name','CHILD-PROJECT-NAME'); |
|
8a1ba49…
|
wyoung
|
40 |
</verbatim> |
|
dddc58d…
|
drh
|
41 |
|
|
f47b705…
|
jan.nijtmans
|
42 |
Modify the CHILD-PROJECT-NAME in the last statement to be the name of |
|
dddc58d…
|
drh
|
43 |
the child project, of course. |
|
dddc58d…
|
drh
|
44 |
|
|
dddc58d…
|
drh
|
45 |
The repository is now a separate project, independent from its parent. |
|
dddc58d…
|
drh
|
46 |
Clone the new project to the developers as needed. |
|
dddc58d…
|
drh
|
47 |
|
|
dddc58d…
|
drh
|
48 |
The child project and the parent project will not normally be able to sync |
|
dddc58d…
|
drh
|
49 |
with one another, since they are now separate projects with distinct |
|
dddc58d…
|
drh
|
50 |
project codes. However, if the |
|
f47b705…
|
jan.nijtmans
|
51 |
"--from-parent-project" command-line option is provided to the |
|
c64f28d…
|
drh
|
52 |
"[/help/pull|fossil pull]" command in the child, and the URL of |
|
dddc58d…
|
drh
|
53 |
parent repository is also provided on the command-line, then updates to |
|
dddc58d…
|
drh
|
54 |
the parent project that occurred after the child was created will be added |
|
dddc58d…
|
drh
|
55 |
to the child repository. Thus, by periodically doing a |
|
dddc58d…
|
drh
|
56 |
pull --from-parent-project, the child project is able to stay up to date |
|
dddc58d…
|
drh
|
57 |
with all the latest changes in the parent. |