Fossil SCM
More expansion on the discussion of creating branches in Fossil, especially in the second-form commands, which were incomplete in the prior version.
Commit
739116689328d03bb93b1af125175a1ff5931c725cdffed31eb1856f0697a77c
Parent
1e0cf46762168ab…
1 file changed
+27
-12
+27
-12
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -184,30 +184,45 @@ | ||
| 184 | 184 | accident that stems from concurrent development. In Figure 4, giving |
| 185 | 185 | check-in 2 multiple children is a deliberate act. So, to a good |
| 186 | 186 | approximation, we define forking to be by accident and branching to |
| 187 | 187 | be by intent. Apart from that, they are the same. |
| 188 | 188 | |
| 189 | -Fossil offers two primary ways to create branches (a.k.a. named, | |
| 190 | -intentional forks): | |
| 189 | +Fossil offers two primary ways to create named, intentional forks | |
| 190 | +a.k.a. branches. First: | |
| 191 | + | |
| 192 | +<pre> | |
| 193 | + $ fossil commit --branch my-new-branch-name | |
| 194 | +</pre> | |
| 195 | + | |
| 196 | +This is the method we recommend for most cases: it creates a branch as | |
| 197 | +part of a checkin using the current branch as its basis. After the | |
| 198 | +checkin, your local working directory is switched to that branch, so | |
| 199 | +that further checkins occur on that branch as well, as children of the | |
| 200 | +last checkin on that branch. | |
| 201 | + | |
| 202 | +The second, more complicated option is: | |
| 191 | 203 | |
| 192 | 204 | <pre> |
| 193 | - $ fossil ci --branch my-new-branch-name | |
| 194 | 205 | $ fossil branch new my-new-branch-name trunk |
| 206 | + $ fossil update new my-new-branch-name | |
| 207 | + $ fossil commit | |
| 195 | 208 | </pre> |
| 196 | 209 | |
| 197 | -The first option is the one we recommend for most cases: it creates a | |
| 198 | -branch as part of a checkin using the current branch as its basis. | |
| 199 | - | |
| 200 | -(Keep in mind that trunk is just another branch in Fossil. It is simply | |
| 201 | -the default branch name for the first checkin and every checkin made as | |
| 202 | -one of its direct descendants.) | |
| 203 | - | |
| 204 | -The second command above is more complicated. Also, it creates the | |
| 205 | -branch in advance of actual need, which makes it a violation of the | |
| 210 | +Not only is the first command longer, you must give the second command | |
| 211 | +before creating any checkins, because until you do, your local working | |
| 212 | +directory remains on the same branch it was on at the time you issued | |
| 213 | +the command. | |
| 214 | + | |
| 215 | +In addition to those problems, the second method is a violation of the | |
| 206 | 216 | [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|YAGNI |
| 207 | 217 | Principle]. We recommend that you wait until you actually need the |
| 208 | 218 | branch and create it using the first command above. |
| 219 | + | |
| 220 | +(Keep in mind that trunk is just another branch in Fossil. It is simply | |
| 221 | +the default branch name for the first checkin and every checkin made as | |
| 222 | +one of its direct descendants. It is special only in that it is Fossil's | |
| 223 | +default when it has no better idea of which branch you mean.) | |
| 209 | 224 | |
| 210 | 225 | |
| 211 | 226 | <h2 id="forking">Justifications For Forking</h2> |
| 212 | 227 | |
| 213 | 228 | The primary cases where forking is justified are all when it is done purely |
| 214 | 229 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -184,30 +184,45 @@ | |
| 184 | accident that stems from concurrent development. In Figure 4, giving |
| 185 | check-in 2 multiple children is a deliberate act. So, to a good |
| 186 | approximation, we define forking to be by accident and branching to |
| 187 | be by intent. Apart from that, they are the same. |
| 188 | |
| 189 | Fossil offers two primary ways to create branches (a.k.a. named, |
| 190 | intentional forks): |
| 191 | |
| 192 | <pre> |
| 193 | $ fossil ci --branch my-new-branch-name |
| 194 | $ fossil branch new my-new-branch-name trunk |
| 195 | </pre> |
| 196 | |
| 197 | The first option is the one we recommend for most cases: it creates a |
| 198 | branch as part of a checkin using the current branch as its basis. |
| 199 | |
| 200 | (Keep in mind that trunk is just another branch in Fossil. It is simply |
| 201 | the default branch name for the first checkin and every checkin made as |
| 202 | one of its direct descendants.) |
| 203 | |
| 204 | The second command above is more complicated. Also, it creates the |
| 205 | branch in advance of actual need, which makes it a violation of the |
| 206 | [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|YAGNI |
| 207 | Principle]. We recommend that you wait until you actually need the |
| 208 | branch and create it using the first command above. |
| 209 | |
| 210 | |
| 211 | <h2 id="forking">Justifications For Forking</h2> |
| 212 | |
| 213 | The primary cases where forking is justified are all when it is done purely |
| 214 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -184,30 +184,45 @@ | |
| 184 | accident that stems from concurrent development. In Figure 4, giving |
| 185 | check-in 2 multiple children is a deliberate act. So, to a good |
| 186 | approximation, we define forking to be by accident and branching to |
| 187 | be by intent. Apart from that, they are the same. |
| 188 | |
| 189 | Fossil offers two primary ways to create named, intentional forks |
| 190 | a.k.a. branches. First: |
| 191 | |
| 192 | <pre> |
| 193 | $ fossil commit --branch my-new-branch-name |
| 194 | </pre> |
| 195 | |
| 196 | This is the method we recommend for most cases: it creates a branch as |
| 197 | part of a checkin using the current branch as its basis. After the |
| 198 | checkin, your local working directory is switched to that branch, so |
| 199 | that further checkins occur on that branch as well, as children of the |
| 200 | last checkin on that branch. |
| 201 | |
| 202 | The second, more complicated option is: |
| 203 | |
| 204 | <pre> |
| 205 | $ fossil branch new my-new-branch-name trunk |
| 206 | $ fossil update new my-new-branch-name |
| 207 | $ fossil commit |
| 208 | </pre> |
| 209 | |
| 210 | Not only is the first command longer, you must give the second command |
| 211 | before creating any checkins, because until you do, your local working |
| 212 | directory remains on the same branch it was on at the time you issued |
| 213 | the command. |
| 214 | |
| 215 | In addition to those problems, the second method is a violation of the |
| 216 | [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|YAGNI |
| 217 | Principle]. We recommend that you wait until you actually need the |
| 218 | branch and create it using the first command above. |
| 219 | |
| 220 | (Keep in mind that trunk is just another branch in Fossil. It is simply |
| 221 | the default branch name for the first checkin and every checkin made as |
| 222 | one of its direct descendants. It is special only in that it is Fossil's |
| 223 | default when it has no better idea of which branch you mean.) |
| 224 | |
| 225 | |
| 226 | <h2 id="forking">Justifications For Forking</h2> |
| 227 | |
| 228 | The primary cases where forking is justified are all when it is done purely |
| 229 |