Fossil SCM
Added the section "Fixing Forks" to www/branching.wiki, and added an explanatory paragraph about the intentionality of forking.
Commit
2686bad19a267fc0ddcefe0a5fdc718865aaf56427babc83c1f91fd9f78561f7
Parent
42bfe9362a1a708…
1 file changed
+18
-2
+18
-2
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -87,12 +87,12 @@ | ||
| 87 | 87 | check-in, which in turn selects which parent your next check-in will be |
| 88 | 88 | a child of. This situation means development on that branch can fork |
| 89 | 89 | into two independent lines of development, based solely on which branch |
| 90 | 90 | tip is newer at the time the next user starts his work on it. Because |
| 91 | 91 | of this, we strongly recommend that you do not intentionally create |
| 92 | -forks on branches with "--allow-fork" if that branch is used by many | |
| 93 | -people over a long period of time. (Prime example: trunk.) | |
| 92 | +forks on long-lived shared working branches with "--allow-fork". (Prime | |
| 93 | +example: trunk.) | |
| 94 | 94 | |
| 95 | 95 | Let us return to Figure 2. To resolve such situations before they can |
| 96 | 96 | become a real problem, Alice can use the <b>fossil merge</b> command to |
| 97 | 97 | merge Bob's changes into her local copy of check-in 3. Then she can |
| 98 | 98 | commit the results as check-in 5. This results in a DAG as shown in |
| @@ -147,10 +147,12 @@ | ||
| 147 | 147 | instead of <i>forking</i>: |
| 148 | 148 | |
| 149 | 149 | <blockquote> |
| 150 | 150 | <b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork. |
| 151 | 151 | </blockquote> |
| 152 | + | |
| 153 | +Forks *may* be intentional, but most of the time, they're accidental. | |
| 152 | 154 | |
| 153 | 155 | Figure 4 shows an example of a project where there are two branches, one |
| 154 | 156 | for development work and another for testing. |
| 155 | 157 | |
| 156 | 158 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| @@ -274,10 +276,24 @@ | ||
| 274 | 276 | |
| 275 | 277 | There's a common generalization of that case: you're a solo developer, |
| 276 | 278 | so that the problems with branching vs forking simply don't matter. In |
| 277 | 279 | that case, feel free to use "--allow-fork" as much as you like. |
| 278 | 280 | |
| 281 | + | |
| 282 | +<h2 id="fix">Fixing Forks</h2> | |
| 283 | + | |
| 284 | +If your local checkout is on a forked branch, you can usually fix a fork | |
| 285 | +automatically with: | |
| 286 | + | |
| 287 | +<pre> | |
| 288 | + $ fossil merge | |
| 289 | +</pre> | |
| 290 | + | |
| 291 | +Normally you need to pass arguments to <b>fossil merge</b> to tell it | |
| 292 | +what you want to merge into the current basis view of the repository, | |
| 293 | +but without arguments, the command seeks out and fixes forks. | |
| 294 | + | |
| 279 | 295 | |
| 280 | 296 | <h2 id="tags">Tags And Properties</h2> |
| 281 | 297 | |
| 282 | 298 | Tags and properties are used in Fossil to help express the intent, and |
| 283 | 299 | thus to distinguish between forks and branches. Figure 5 shows the |
| 284 | 300 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -87,12 +87,12 @@ | |
| 87 | check-in, which in turn selects which parent your next check-in will be |
| 88 | a child of. This situation means development on that branch can fork |
| 89 | into two independent lines of development, based solely on which branch |
| 90 | tip is newer at the time the next user starts his work on it. Because |
| 91 | of this, we strongly recommend that you do not intentionally create |
| 92 | forks on branches with "--allow-fork" if that branch is used by many |
| 93 | people over a long period of time. (Prime example: trunk.) |
| 94 | |
| 95 | Let us return to Figure 2. To resolve such situations before they can |
| 96 | become a real problem, Alice can use the <b>fossil merge</b> command to |
| 97 | merge Bob's changes into her local copy of check-in 3. Then she can |
| 98 | commit the results as check-in 5. This results in a DAG as shown in |
| @@ -147,10 +147,12 @@ | |
| 147 | instead of <i>forking</i>: |
| 148 | |
| 149 | <blockquote> |
| 150 | <b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork. |
| 151 | </blockquote> |
| 152 | |
| 153 | Figure 4 shows an example of a project where there are two branches, one |
| 154 | for development work and another for testing. |
| 155 | |
| 156 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| @@ -274,10 +276,24 @@ | |
| 274 | |
| 275 | There's a common generalization of that case: you're a solo developer, |
| 276 | so that the problems with branching vs forking simply don't matter. In |
| 277 | that case, feel free to use "--allow-fork" as much as you like. |
| 278 | |
| 279 | |
| 280 | <h2 id="tags">Tags And Properties</h2> |
| 281 | |
| 282 | Tags and properties are used in Fossil to help express the intent, and |
| 283 | thus to distinguish between forks and branches. Figure 5 shows the |
| 284 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -87,12 +87,12 @@ | |
| 87 | check-in, which in turn selects which parent your next check-in will be |
| 88 | a child of. This situation means development on that branch can fork |
| 89 | into two independent lines of development, based solely on which branch |
| 90 | tip is newer at the time the next user starts his work on it. Because |
| 91 | of this, we strongly recommend that you do not intentionally create |
| 92 | forks on long-lived shared working branches with "--allow-fork". (Prime |
| 93 | example: trunk.) |
| 94 | |
| 95 | Let us return to Figure 2. To resolve such situations before they can |
| 96 | become a real problem, Alice can use the <b>fossil merge</b> command to |
| 97 | merge Bob's changes into her local copy of check-in 3. Then she can |
| 98 | commit the results as check-in 5. This results in a DAG as shown in |
| @@ -147,10 +147,12 @@ | |
| 147 | instead of <i>forking</i>: |
| 148 | |
| 149 | <blockquote> |
| 150 | <b>Key Distinction:</b> A branch is a <i>named, intentional</i> fork. |
| 151 | </blockquote> |
| 152 | |
| 153 | Forks *may* be intentional, but most of the time, they're accidental. |
| 154 | |
| 155 | Figure 4 shows an example of a project where there are two branches, one |
| 156 | for development work and another for testing. |
| 157 | |
| 158 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| @@ -274,10 +276,24 @@ | |
| 276 | |
| 277 | There's a common generalization of that case: you're a solo developer, |
| 278 | so that the problems with branching vs forking simply don't matter. In |
| 279 | that case, feel free to use "--allow-fork" as much as you like. |
| 280 | |
| 281 | |
| 282 | <h2 id="fix">Fixing Forks</h2> |
| 283 | |
| 284 | If your local checkout is on a forked branch, you can usually fix a fork |
| 285 | automatically with: |
| 286 | |
| 287 | <pre> |
| 288 | $ fossil merge |
| 289 | </pre> |
| 290 | |
| 291 | Normally you need to pass arguments to <b>fossil merge</b> to tell it |
| 292 | what you want to merge into the current basis view of the repository, |
| 293 | but without arguments, the command seeks out and fixes forks. |
| 294 | |
| 295 | |
| 296 | <h2 id="tags">Tags And Properties</h2> |
| 297 | |
| 298 | Tags and properties are used in Fossil to help express the intent, and |
| 299 | thus to distinguish between forks and branches. Figure 5 shows the |
| 300 |