Fossil

Check-in [73911668]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More expansion on the discussion of creating branches in Fossil, especially in the second-form commands, which were incomplete in the prior version.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 739116689328d03bb93b1af125175a1ff5931c725cdffed31eb1856f0697a77c
User & Date: wyoung 2019-06-19 17:58:34
Context
2019-06-19
17:59
Fixed a command in the previoius checkin check-in: d5e1e113 user: wyoung tags: trunk
17:58
More expansion on the discussion of creating branches in Fossil, especially in the second-form commands, which were incomplete in the prior version. check-in: 73911668 user: wyoung tags: trunk
17:41
Added the key distinction ("A branch is a named, intentional fork") to www/branching.wiki and added info on actually creating branches. check-in: 1e0cf467 user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198



199
200
201
202
203
204
205










206
207
208





209
210
211
212
213
214
215
concerned, there is no difference.  The distinction is in the intent.
In Figure 2, the fact that check-in 2 has multiple children is an
accident that stems from concurrent development.  In Figure 4, giving
check-in 2 multiple children is a deliberate act.  So, to a good
approximation, we define forking to be by accident and branching to
be by intent.  Apart from that, they are the same.

Fossil offers two primary ways to create branches (a.k.a. named,
intentional forks):

<pre>
    $ fossil ci --branch my-new-branch-name
    $ fossil branch new my-new-branch-name trunk
</pre>

The first option is the one we recommend for most cases: it creates a
branch as part of a checkin using the current branch as its basis. 




(Keep in mind that trunk is just another branch in Fossil. It is simply
the default branch name for the first checkin and every checkin made as
one of its direct descendants.)

The second command above is more complicated.  Also, it creates the
branch in advance of actual need, which makes it a violation of the










[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|YAGNI
Principle]. We recommend that you wait until you actually need the
branch and create it using the first command above.







<h2 id="forking">Justifications For Forking</h2>

The primary cases where forking is justified are all when it is done purely
in software in order to avoid losing information:








|
|


|
<


|
|
>
>
>

<
<
|

|
|
>
>
>
>
>
>
>
>
>
>



>
>
>
>
>







182
183
184
185
186
187
188
189
190
191
192
193

194
195
196
197
198
199
200
201


202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
concerned, there is no difference.  The distinction is in the intent.
In Figure 2, the fact that check-in 2 has multiple children is an
accident that stems from concurrent development.  In Figure 4, giving
check-in 2 multiple children is a deliberate act.  So, to a good
approximation, we define forking to be by accident and branching to
be by intent.  Apart from that, they are the same.

Fossil offers two primary ways to create named, intentional forks
a.k.a. branches. First:

<pre>
    $ fossil commit --branch my-new-branch-name

</pre>

This is the method we recommend for most cases: it creates a branch as
part of a checkin using the current branch as its basis. After the
checkin, your local working directory is switched to that branch, so
that further checkins occur on that branch as well, as children of the
last checkin on that branch.



The second, more complicated option is:

<pre>
    $ fossil branch new my-new-branch-name trunk
    $ fossil update new my-new-branch-name
    $ fossil commit
</pre>

Not only is the first command longer, you must give the second command
before creating any checkins, because until you do, your local working
directory remains on the same branch it was on at the time you issued
the command.

In addition to those problems, the second method is a violation of the
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it|YAGNI
Principle]. We recommend that you wait until you actually need the
branch and create it using the first command above.

(Keep in mind that trunk is just another branch in Fossil. It is simply
the default branch name for the first checkin and every checkin made as
one of its direct descendants. It is special only in that it is Fossil's
default when it has no better idea of which branch you mean.)


<h2 id="forking">Justifications For Forking</h2>

The primary cases where forking is justified are all when it is done purely
in software in order to avoid losing information: