Fossil SCM
Update to the Fossil-v-Git matrix.
Commit
a52287876c414dedf9e35e8af47b77dd6d461a89
Parent
630691456be6722…
1 file changed
+40
-29
+40
-29
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -19,11 +19,11 @@ | ||
| 19 | 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | 21 | <tr><td>File versioning only</td> |
| 22 | 22 | <td>Versioning, Tickets, Wiki, and Blog/News</td></tr> |
| 23 | 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | -<tr><td>Huge community</td><td>Road less traveled</td></tr> | |
| 24 | +<tr><td>Developer branches</td><td>Feature branches</td></tr> | |
| 25 | 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | 28 | <tr><td>Pile-of-files repository</td><td>Single file repository</td></tr> |
| 29 | 29 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| @@ -79,38 +79,49 @@ | ||
| 79 | 79 | The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | 80 | for multiple developers to work on a single branch and maintain |
| 81 | 81 | linear development on that branch and avoid needless forking |
| 82 | 82 | and merging. |
| 83 | 83 | |
| 84 | -<h3>3.3 Community</h3> | |
| 85 | - | |
| 86 | -Git has a huge user community. If following the herd and being | |
| 87 | -like everybody else is important to you, then you should choose Git. | |
| 88 | - | |
| 89 | -Fossil is clearly the "road less traveled": | |
| 90 | - | |
| 91 | -<blockquote> | |
| 92 | -Two roads diverged in a wood, and I —<br> | |
| 93 | -I took the one less traveled by,<br> | |
| 94 | -And that has made all the difference.<br> | |
| 95 | - | |
| 96 | -<small>- Robert Frost, <i>The Road Not Taken</i>, 1916</small> | |
| 97 | -</blockquote> | |
| 98 | -</i></blockquote> | |
| 99 | - | |
| 100 | -Among the advantages of Git's huge user community are that new team | |
| 101 | -members may already be familiar with Git's operation and hence can | |
| 102 | -bypass the VCS learning curve. Also, if you need an add-on tool or | |
| 103 | -script of some kind, a Google search will likely turn up a suitable | |
| 104 | -tool that you can just download and use. A huge community also means | |
| 105 | -that somebody else has likely already encountered and fixed the bugs | |
| 106 | -so that Git will work for you and your project as advertised. | |
| 107 | - | |
| 108 | -Among the advantages of the "road less traveled" is that your particular | |
| 109 | -project will be bigger percentage of the total user base, and is thus | |
| 110 | -more likely to receive personal attention from the Fossil maintainers | |
| 111 | -if you do encounter problems. | |
| 84 | +<h3>3.3 Branches</h3> | |
| 85 | + | |
| 86 | +Git (and especially GitHub) encourages a workflow where each developer | |
| 87 | +has his or her own branch or branches. Developers then send "pull requests" | |
| 88 | +to have their changes be merged into "official" branches by integrators. | |
| 89 | +For example, the Linux kernel team has a hierarchy of integrators with | |
| 90 | +Linus Torvalds at the root. Individual developers each have their own | |
| 91 | +private branches of the source tree into which they make their own changes. | |
| 92 | +They then encourage first-tier integrators to pull those changes. The | |
| 93 | +first-tier integrators merge together changes from multiple contributors | |
| 94 | +then try to get second-tier integrators to pull their branches. The | |
| 95 | +changes merge up the the hierarchy until (hopefully) they are pulled into | |
| 96 | +"Linus's branch", at which time they become part of the "official" Linux. | |
| 97 | + | |
| 98 | +In Git, each branch is "owned" by the person who creates it and works | |
| 99 | +on it. The owner might pull changes from others, but the owner is always | |
| 100 | +in control of the branch. Branches are developer-centric. | |
| 101 | + | |
| 102 | +Fossil, on the other hand, encourages a workflow where branches are | |
| 103 | +associated with features or releases, not individual developers. | |
| 104 | +All developers share all branches in common, and two | |
| 105 | +or more developers can and often do intersperse commits onto the same branch. | |
| 106 | +Branches do not belong to individuals. All branches are read/write | |
| 107 | +accessible to all developers at all times. There is no need | |
| 108 | +for integrators to merge together changes from various independent | |
| 109 | +developers. Instead, all of the developers work together cooperatively | |
| 110 | +and the changes stay integrated naturally. | |
| 111 | + | |
| 112 | +So to a first approximation, branches in Git are developer-centric whereas | |
| 113 | +branches in Fossil are feature-centric. | |
| 114 | + | |
| 115 | +The Git approach scales much better for large projects like the Linux | |
| 116 | +kernel with thousands of contributors who in many cases don't even know | |
| 117 | +each others names. The integrators serve a gatekeeper role to help keep | |
| 118 | +undesirable code out of the official Linux source tree. On the other hand, | |
| 119 | +not many projects are as big or as loosely organized as the Linux kernel. | |
| 120 | +Most project, have a small team of developers who all know each other | |
| 121 | +well and trust each other, and who enjoy working together collaboratively | |
| 122 | +without the overhead and hierarchy of integrators. | |
| 112 | 123 | |
| 113 | 124 | <h3>3.4 Complexity</h3> |
| 114 | 125 | |
| 115 | 126 | Git is a complex system. It can be tricky to use and requires a fair |
| 116 | 127 | amount of knowledge and experience to master. Fossil strives to be |
| 117 | 128 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -19,11 +19,11 @@ | |
| 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | <tr><td>File versioning only</td> |
| 22 | <td>Versioning, Tickets, Wiki, and Blog/News</td></tr> |
| 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | <tr><td>Huge community</td><td>Road less traveled</td></tr> |
| 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | <tr><td>Pile-of-files repository</td><td>Single file repository</td></tr> |
| 29 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| @@ -79,38 +79,49 @@ | |
| 79 | The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | for multiple developers to work on a single branch and maintain |
| 81 | linear development on that branch and avoid needless forking |
| 82 | and merging. |
| 83 | |
| 84 | <h3>3.3 Community</h3> |
| 85 | |
| 86 | Git has a huge user community. If following the herd and being |
| 87 | like everybody else is important to you, then you should choose Git. |
| 88 | |
| 89 | Fossil is clearly the "road less traveled": |
| 90 | |
| 91 | <blockquote> |
| 92 | Two roads diverged in a wood, and I —<br> |
| 93 | I took the one less traveled by,<br> |
| 94 | And that has made all the difference.<br> |
| 95 | |
| 96 | <small>- Robert Frost, <i>The Road Not Taken</i>, 1916</small> |
| 97 | </blockquote> |
| 98 | </i></blockquote> |
| 99 | |
| 100 | Among the advantages of Git's huge user community are that new team |
| 101 | members may already be familiar with Git's operation and hence can |
| 102 | bypass the VCS learning curve. Also, if you need an add-on tool or |
| 103 | script of some kind, a Google search will likely turn up a suitable |
| 104 | tool that you can just download and use. A huge community also means |
| 105 | that somebody else has likely already encountered and fixed the bugs |
| 106 | so that Git will work for you and your project as advertised. |
| 107 | |
| 108 | Among the advantages of the "road less traveled" is that your particular |
| 109 | project will be bigger percentage of the total user base, and is thus |
| 110 | more likely to receive personal attention from the Fossil maintainers |
| 111 | if you do encounter problems. |
| 112 | |
| 113 | <h3>3.4 Complexity</h3> |
| 114 | |
| 115 | Git is a complex system. It can be tricky to use and requires a fair |
| 116 | amount of knowledge and experience to master. Fossil strives to be |
| 117 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -19,11 +19,11 @@ | |
| 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | <tr><td>File versioning only</td> |
| 22 | <td>Versioning, Tickets, Wiki, and Blog/News</td></tr> |
| 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | <tr><td>Developer branches</td><td>Feature branches</td></tr> |
| 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | <tr><td>Pile-of-files repository</td><td>Single file repository</td></tr> |
| 29 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| @@ -79,38 +79,49 @@ | |
| 79 | The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | for multiple developers to work on a single branch and maintain |
| 81 | linear development on that branch and avoid needless forking |
| 82 | and merging. |
| 83 | |
| 84 | <h3>3.3 Branches</h3> |
| 85 | |
| 86 | Git (and especially GitHub) encourages a workflow where each developer |
| 87 | has his or her own branch or branches. Developers then send "pull requests" |
| 88 | to have their changes be merged into "official" branches by integrators. |
| 89 | For example, the Linux kernel team has a hierarchy of integrators with |
| 90 | Linus Torvalds at the root. Individual developers each have their own |
| 91 | private branches of the source tree into which they make their own changes. |
| 92 | They then encourage first-tier integrators to pull those changes. The |
| 93 | first-tier integrators merge together changes from multiple contributors |
| 94 | then try to get second-tier integrators to pull their branches. The |
| 95 | changes merge up the the hierarchy until (hopefully) they are pulled into |
| 96 | "Linus's branch", at which time they become part of the "official" Linux. |
| 97 | |
| 98 | In Git, each branch is "owned" by the person who creates it and works |
| 99 | on it. The owner might pull changes from others, but the owner is always |
| 100 | in control of the branch. Branches are developer-centric. |
| 101 | |
| 102 | Fossil, on the other hand, encourages a workflow where branches are |
| 103 | associated with features or releases, not individual developers. |
| 104 | All developers share all branches in common, and two |
| 105 | or more developers can and often do intersperse commits onto the same branch. |
| 106 | Branches do not belong to individuals. All branches are read/write |
| 107 | accessible to all developers at all times. There is no need |
| 108 | for integrators to merge together changes from various independent |
| 109 | developers. Instead, all of the developers work together cooperatively |
| 110 | and the changes stay integrated naturally. |
| 111 | |
| 112 | So to a first approximation, branches in Git are developer-centric whereas |
| 113 | branches in Fossil are feature-centric. |
| 114 | |
| 115 | The Git approach scales much better for large projects like the Linux |
| 116 | kernel with thousands of contributors who in many cases don't even know |
| 117 | each others names. The integrators serve a gatekeeper role to help keep |
| 118 | undesirable code out of the official Linux source tree. On the other hand, |
| 119 | not many projects are as big or as loosely organized as the Linux kernel. |
| 120 | Most project, have a small team of developers who all know each other |
| 121 | well and trust each other, and who enjoy working together collaboratively |
| 122 | without the overhead and hierarchy of integrators. |
| 123 | |
| 124 | <h3>3.4 Complexity</h3> |
| 125 | |
| 126 | Git is a complex system. It can be tricky to use and requires a fair |
| 127 | amount of knowledge and experience to master. Fossil strives to be |
| 128 |