Fossil SCM
c/--force/--allow-fork/
Commit
604a355811f04b022e9bd38fe1d24791ae882842
Parent
aafcf6c57b982e1…
1 file changed
+3
-3
+3
-3
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -63,13 +63,13 @@ | ||
| 63 | 63 | |
| 64 | 64 | But perhaps Bob is off-network when he does his commit, so he |
| 65 | 65 | has no way of knowing that Alice has already committed her changes. |
| 66 | 66 | Or, it could be that Bob has turned off "autosync" mode in Fossil. Or, |
| 67 | 67 | maybe Bob just doesn't want to merge in Alice's changes before he has |
| 68 | -saved his own, so he forces the commit to occur using the "--force" option | |
| 69 | -to the fossil <b>commit</b> command. For any of these reasons, two commits against | |
| 70 | -check-in 2 have occurred and now the DAG has two leaves. | |
| 68 | +saved his own, so he forces the commit to occur using the "--allow-fork" | |
| 69 | +option to the fossil <b>commit</b> command. For any of these reasons, | |
| 70 | +two commits against check-in 2 have occurred and now the DAG has two leaves. | |
| 71 | 71 | |
| 72 | 72 | So which version of the project is the "latest" in the sense of having |
| 73 | 73 | the most features and the most bug fixes? When there is more than |
| 74 | 74 | one leaf in the graph, you don't really know. So we like to have |
| 75 | 75 | graphs with a single leaf. |
| 76 | 76 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -63,13 +63,13 @@ | |
| 63 | |
| 64 | But perhaps Bob is off-network when he does his commit, so he |
| 65 | has no way of knowing that Alice has already committed her changes. |
| 66 | Or, it could be that Bob has turned off "autosync" mode in Fossil. Or, |
| 67 | maybe Bob just doesn't want to merge in Alice's changes before he has |
| 68 | saved his own, so he forces the commit to occur using the "--force" option |
| 69 | to the fossil <b>commit</b> command. For any of these reasons, two commits against |
| 70 | check-in 2 have occurred and now the DAG has two leaves. |
| 71 | |
| 72 | So which version of the project is the "latest" in the sense of having |
| 73 | the most features and the most bug fixes? When there is more than |
| 74 | one leaf in the graph, you don't really know. So we like to have |
| 75 | graphs with a single leaf. |
| 76 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -63,13 +63,13 @@ | |
| 63 | |
| 64 | But perhaps Bob is off-network when he does his commit, so he |
| 65 | has no way of knowing that Alice has already committed her changes. |
| 66 | Or, it could be that Bob has turned off "autosync" mode in Fossil. Or, |
| 67 | maybe Bob just doesn't want to merge in Alice's changes before he has |
| 68 | saved his own, so he forces the commit to occur using the "--allow-fork" |
| 69 | option to the fossil <b>commit</b> command. For any of these reasons, |
| 70 | two commits against check-in 2 have occurred and now the DAG has two leaves. |
| 71 | |
| 72 | So which version of the project is the "latest" in the sense of having |
| 73 | the most features and the most bug fixes? When there is more than |
| 74 | one leaf in the graph, you don't really know. So we like to have |
| 75 | graphs with a single leaf. |
| 76 |