278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
|
for us to integrate all at once.
[https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy]
put it well in his book on software project management,
<i>[https://www.amazon.com/dp/0735623198/|Dynamics of Software
Development]</i>: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware
of a guy in a room]."</p></li>
<li><p><b>Branch names sync:</b> Unlike in Git, branch names are not
purely local labels. They sync along with everything else, so
everyone sees the same set of branch names.</p></li>
<li><p><b>Private branches are rare:</b>
[/doc/trunk/www/private.wiki|Private branches exist in Fossil], but
they're normally used to handle rare exception cases, whereas in
many Git projects, they're part of the straight-line development
process.</p></li>
|
|
|
|
>
>
>
>
|
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
|
for us to integrate all at once.
[https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy]
put it well in his book on software project management,
<i>[https://www.amazon.com/dp/0735623198/|Dynamics of Software
Development]</i>: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware
of a guy in a room]."</p></li>
<li><p><b>Branch names sync:</b> Unlike in Git, branch names in
Fossil are not purely local labels. They sync along with everything
else, so everyone sees the same set of branch names. Fossil's design
choice here is a direct reflection of the Linux vs. SQLite project
outlook: SQLite's developers collaborate closely on a single
conherent project, whereas Linux's developers go off on tangents and
occasionally sync changes up with each other.</p></li>
<li><p><b>Private branches are rare:</b>
[/doc/trunk/www/private.wiki|Private branches exist in Fossil], but
they're normally used to handle rare exception cases, whereas in
many Git projects, they're part of the straight-line development
process.</p></li>
|
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
|
[/help?cmd=timeline|timeline] is generally easier and more clear than
those available in Git front-ends. It is why Fossil is immune from
Git's "detached head state." It's why Git has the cryptic <tt>@~</tt>
notation meaning "the parent of HEAD" (what Fossil simply
[./checkin_names.wiki|calls "prev"]) but there is no way to ask Git
for the child of the current checkin, as with "next" in Fossil.
* <b>Named branches</b>
Branches in Fossil have persistent names that are propagated
to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull].
All developers see the same name on the same branch. Git, in contrast,
uses only local branch names, so developers working on the
same project can (and frequently do) use a different name for the
same branch.
* <b>The [/help?cmd=all|fossil all] command</b>
Fossil keeps track of all repositories and check-outs and allows
operations over all of them with a single command. For example, in
Fossil is possible to request a pull of all repositories on a laptop
from their respective servers, prior to taking the laptop off network.
Or it is possible to do "fossil all changes" to see if there are any
|
<
<
<
<
<
<
<
<
<
|
537
538
539
540
541
542
543
544
545
546
547
548
549
550
|
[/help?cmd=timeline|timeline] is generally easier and more clear than
those available in Git front-ends. It is why Fossil is immune from
Git's "detached head state." It's why Git has the cryptic <tt>@~</tt>
notation meaning "the parent of HEAD" (what Fossil simply
[./checkin_names.wiki|calls "prev"]) but there is no way to ask Git
for the child of the current checkin, as with "next" in Fossil.
* <b>The [/help?cmd=all|fossil all] command</b>
Fossil keeps track of all repositories and check-outs and allows
operations over all of them with a single command. For example, in
Fossil is possible to request a pull of all repositories on a laptop
from their respective servers, prior to taking the laptop off network.
Or it is possible to do "fossil all changes" to see if there are any
|