Fossil SCM
Further refinements to the Fossil-versus-Git document.
Commit
8f4d5314ae4f0f6c0c902f7897092a8fa4ae3593
Parent
71f71034945b2a5…
1 file changed
+52
-31
+52
-31
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -42,37 +42,46 @@ | ||
| 42 | 42 | These additional capabilities are available for Git as 3rd-party |
| 43 | 43 | user-installed add-ons, but with Fossil they are integrated into |
| 44 | 44 | the design. One way to describe Fossil is that it is |
| 45 | 45 | "[https://github.com/ | github]-in-a-box". |
| 46 | 46 | |
| 47 | -<h3>3.2 Sharing Model</h3> | |
| 48 | - | |
| 49 | -Git supports a sharded source tree, whereas Fossil wants all all | |
| 50 | -syncing repositories to carry all information. Git allows individual | |
| 51 | -developers to maintain multiple branches on their local repository | |
| 52 | -and then selectively push only one or two branches to higher level | |
| 53 | -developers. Fossil also allows private local branches, but Fossil | |
| 54 | -tends to encourage sharing everything, not just one or two select | |
| 55 | -branches. The Git model works best for large projects, like the | |
| 56 | -Linux kernel, since Linus doesn't really want to see a thousand | |
| 47 | +<h3>3.2 Sharding versus Replicating</h3> | |
| 48 | + | |
| 49 | +Git makes it easy for each repository in a project to hold a subset of | |
| 50 | +the branches for that project. In fact, it is entirely possible and not | |
| 51 | +uncommon for no repository in the project to hold all the different code | |
| 52 | +versions for a project. Instead the information is distributed. | |
| 53 | +Individual developers have one or more private branches. A hierarchy | |
| 54 | +of integrators merge changes from individual developers into collaborative | |
| 55 | +branches, until all the changes are merged together at the top-level master | |
| 56 | +branch. And all of this can be accomplished without having to have all the | |
| 57 | +code in any one repository. Developers or groups of developers can share | |
| 58 | +only those branches that they want to share and keep other branchs of the | |
| 59 | +project private. This is analogous to sharding an a distributed database. | |
| 60 | + | |
| 61 | +Fossil allows private branches, but its default mode is to share everything. | |
| 62 | +And so in a Fossil project, all respositories tend to contain all of the | |
| 63 | +content at all times. This is analogous to replication in a | |
| 64 | +distributed database. | |
| 65 | + | |
| 66 | +The Git model works best for large projects, like the | |
| 67 | +Linux kernel for which Git was designed. | |
| 68 | +Linus Torvalds does not need or want to see a thousand | |
| 57 | 69 | different branches, one for each contributor. Git allows intermediary |
| 58 | 70 | "gate-keepers" to merge changes from multiple lower-level developers |
| 59 | 71 | into a single branch and only present Linus with a handful of branches |
| 60 | -at a time. Fossil encourages a tight-knit, smaller, and more closely | |
| 61 | -cooperating developer community where all participants share all | |
| 62 | -of their code all of the time. | |
| 63 | - | |
| 64 | -The prototypical Git development model is that each developer maintains | |
| 65 | -their own branch and the various changes from each developer are later | |
| 66 | -merged into a master branch by an integrator. The prototypical Fossil | |
| 67 | -development model is that multiple developers collaborate on the same | |
| 68 | -branch at the same time. | |
| 69 | - | |
| 70 | -So in other words, Git promotes a model where individual developers | |
| 71 | -keep a subset of the branches of a project (sharding) whereas Fossil | |
| 72 | -promotes every developer having a complete copy of all branches | |
| 73 | -(replicating). | |
| 72 | +at a time. Git encourages a programming model where each developer | |
| 73 | +works in his or her own branch and then merges changes up the hierarchy | |
| 74 | +until they reach the master branch. | |
| 75 | + | |
| 76 | +Fossil is designed for smaller and non-hierarchical teams where all | |
| 77 | +developers are operating directly on the master branch, or at most one | |
| 78 | +a small number of well defined branches. | |
| 79 | +The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy | |
| 80 | +for multiple developers to work on a single branch and maintain a | |
| 81 | +linear line of development on that branch without needless forking | |
| 82 | +and merging. | |
| 74 | 83 | |
| 75 | 84 | <h3>3.3 Community</h3> |
| 76 | 85 | |
| 77 | 86 | Git has a huge user community. If following the herd and being |
| 78 | 87 | like everybody else is important to you, then you should choose Git. |
| @@ -92,16 +101,16 @@ | ||
| 92 | 101 | members may already be familiar with Git's operation and hence can |
| 93 | 102 | bypass the VCS learning curve. Also, if you need an add-on tool or |
| 94 | 103 | script of some kind, a Google search will likely turn up a suitable |
| 95 | 104 | tool that you can just download and use. A huge community also means |
| 96 | 105 | that somebody else has likely already encountered and fixed the bugs |
| 97 | -so that for you the product will work as advertised. | |
| 106 | +so that Git will work for you and your project as advertised. | |
| 98 | 107 | |
| 99 | 108 | Among the advantages of the "road less traveled" is that your particular |
| 100 | 109 | project will be bigger percentage of the total user base, and is thus |
| 101 | -more likely to receive attention from the DVCS maintainers if you do | |
| 102 | -encounter problems. | |
| 110 | +more likely to receive personal attention from the Fossil maintainers | |
| 111 | +if you do encounter problems. | |
| 103 | 112 | |
| 104 | 113 | <h3>3.4 Complexity</h3> |
| 105 | 114 | |
| 106 | 115 | Git is a complex system. It can be tricky to use and requires a fair |
| 107 | 116 | amount of knowledge and experience to master. Fossil strives to be |
| @@ -122,11 +131,23 @@ | ||
| 122 | 131 | |
| 123 | 132 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 124 | 133 | require little thinking about how to operating it. Reports from the |
| 125 | 134 | field indicate that Fossil is mostly successful at this effort. |
| 126 | 135 | |
| 127 | -<h3>3.5 Implementation Strategy</h3> | |
| 136 | +<h3>3.5 Web Interface</h3> | |
| 137 | + | |
| 138 | +Git has a web interface, but it requires a fair amount of setup and an | |
| 139 | +external web server. Fossil comes with a fully functional | |
| 140 | +[./webui.wiki | built-in web-server] | |
| 141 | +and a really simple mechanism (the "<tt>fossil ui</tt>" command) to | |
| 142 | +automatically start the web server and bring up a web browser to navigate | |
| 143 | +it. The web interface for Fossil is not only easier to set up, it is also | |
| 144 | +more powerful and easier to use. The web interface to Fossil is a practical | |
| 145 | +replacement to the 3rd-party "GUI Tools" that users often employ to operate | |
| 146 | +Git. | |
| 147 | + | |
| 148 | +<h3>3.6 Implementation Strategy</h3> | |
| 128 | 149 | |
| 129 | 150 | Git consists of a collection of many little programs. Git needs to be |
| 130 | 151 | "installed" using some kind of installer or package tool. Git can be |
| 131 | 152 | tricky to install and get working, especially for users without |
| 132 | 153 | administrative privileges. |
| @@ -138,11 +159,11 @@ | ||
| 138 | 159 | |
| 139 | 160 | Fossil is designed to be trivial to install, uninstall, and upgrade so |
| 140 | 161 | that developers can spend more time working on their own projects and |
| 141 | 162 | much less time configuring their version control system. |
| 142 | 163 | |
| 143 | -<h3>3.6 Repository Storage</h3> | |
| 164 | +<h3>3.7 Repository Storage</h3> | |
| 144 | 165 | |
| 145 | 166 | A Git repository is a "pile-of-files" in the ".git" directory at the |
| 146 | 167 | root of the working checkout. There is a one-to-one correspondence |
| 147 | 168 | between repositories and working checkouts. A power-loss or system crash |
| 148 | 169 | in the middle of Git operation can damage or corrupt the Git repository. |
| @@ -151,11 +172,11 @@ | ||
| 151 | 172 | repository can serve multiple simultaneous working checkouts. |
| 152 | 173 | A Fossil repository is an SQLite database, so it highly resistant |
| 153 | 174 | to damage from a power-loss or system crash - incomplete transactions |
| 154 | 175 | are simply rolled back after the system reboots. |
| 155 | 176 | |
| 156 | -<h3>3.7 Audit Trail</h3> | |
| 177 | +<h3>3.8 Audit Trail</h3> | |
| 157 | 178 | |
| 158 | 179 | Git features the "rebase" command which can be used to change the |
| 159 | 180 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 160 | 181 | a complex sequence of check-ins to make their intent easier for others |
| 161 | 182 | to understand. From another point of view, rebase can be used to |
| @@ -169,14 +190,14 @@ | ||
| 169 | 190 | by entering a correction, with an explanation of why the correction is |
| 170 | 191 | needed. This can make the history of a project messy, but it also |
| 171 | 192 | makes it more honest. The lack of a "rebase" function is considered |
| 172 | 193 | a feature of Fossil, not a bug. |
| 173 | 194 | |
| 174 | -<h3>3.8 License</h3> | |
| 195 | +<h3>3.9 License</h3> | |
| 175 | 196 | |
| 176 | 197 | Both Git and Fossil are open-source. Git is under |
| 177 | 198 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 178 | 199 | under the |
| 179 | 200 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 180 | 201 | The difference should not be of a concern to most users. However, |
| 181 | 202 | some corporate lawyers have objections to using GPL products and |
| 182 | 203 | are more comfortable with a BSD-style license. |
| 183 | 204 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -42,37 +42,46 @@ | |
| 42 | These additional capabilities are available for Git as 3rd-party |
| 43 | user-installed add-ons, but with Fossil they are integrated into |
| 44 | the design. One way to describe Fossil is that it is |
| 45 | "[https://github.com/ | github]-in-a-box". |
| 46 | |
| 47 | <h3>3.2 Sharing Model</h3> |
| 48 | |
| 49 | Git supports a sharded source tree, whereas Fossil wants all all |
| 50 | syncing repositories to carry all information. Git allows individual |
| 51 | developers to maintain multiple branches on their local repository |
| 52 | and then selectively push only one or two branches to higher level |
| 53 | developers. Fossil also allows private local branches, but Fossil |
| 54 | tends to encourage sharing everything, not just one or two select |
| 55 | branches. The Git model works best for large projects, like the |
| 56 | Linux kernel, since Linus doesn't really want to see a thousand |
| 57 | different branches, one for each contributor. Git allows intermediary |
| 58 | "gate-keepers" to merge changes from multiple lower-level developers |
| 59 | into a single branch and only present Linus with a handful of branches |
| 60 | at a time. Fossil encourages a tight-knit, smaller, and more closely |
| 61 | cooperating developer community where all participants share all |
| 62 | of their code all of the time. |
| 63 | |
| 64 | The prototypical Git development model is that each developer maintains |
| 65 | their own branch and the various changes from each developer are later |
| 66 | merged into a master branch by an integrator. The prototypical Fossil |
| 67 | development model is that multiple developers collaborate on the same |
| 68 | branch at the same time. |
| 69 | |
| 70 | So in other words, Git promotes a model where individual developers |
| 71 | keep a subset of the branches of a project (sharding) whereas Fossil |
| 72 | promotes every developer having a complete copy of all branches |
| 73 | (replicating). |
| 74 | |
| 75 | <h3>3.3 Community</h3> |
| 76 | |
| 77 | Git has a huge user community. If following the herd and being |
| 78 | like everybody else is important to you, then you should choose Git. |
| @@ -92,16 +101,16 @@ | |
| 92 | members may already be familiar with Git's operation and hence can |
| 93 | bypass the VCS learning curve. Also, if you need an add-on tool or |
| 94 | script of some kind, a Google search will likely turn up a suitable |
| 95 | tool that you can just download and use. A huge community also means |
| 96 | that somebody else has likely already encountered and fixed the bugs |
| 97 | so that for you the product will work as advertised. |
| 98 | |
| 99 | Among the advantages of the "road less traveled" is that your particular |
| 100 | project will be bigger percentage of the total user base, and is thus |
| 101 | more likely to receive attention from the DVCS maintainers if you do |
| 102 | encounter problems. |
| 103 | |
| 104 | <h3>3.4 Complexity</h3> |
| 105 | |
| 106 | Git is a complex system. It can be tricky to use and requires a fair |
| 107 | amount of knowledge and experience to master. Fossil strives to be |
| @@ -122,11 +131,23 @@ | |
| 122 | |
| 123 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 124 | require little thinking about how to operating it. Reports from the |
| 125 | field indicate that Fossil is mostly successful at this effort. |
| 126 | |
| 127 | <h3>3.5 Implementation Strategy</h3> |
| 128 | |
| 129 | Git consists of a collection of many little programs. Git needs to be |
| 130 | "installed" using some kind of installer or package tool. Git can be |
| 131 | tricky to install and get working, especially for users without |
| 132 | administrative privileges. |
| @@ -138,11 +159,11 @@ | |
| 138 | |
| 139 | Fossil is designed to be trivial to install, uninstall, and upgrade so |
| 140 | that developers can spend more time working on their own projects and |
| 141 | much less time configuring their version control system. |
| 142 | |
| 143 | <h3>3.6 Repository Storage</h3> |
| 144 | |
| 145 | A Git repository is a "pile-of-files" in the ".git" directory at the |
| 146 | root of the working checkout. There is a one-to-one correspondence |
| 147 | between repositories and working checkouts. A power-loss or system crash |
| 148 | in the middle of Git operation can damage or corrupt the Git repository. |
| @@ -151,11 +172,11 @@ | |
| 151 | repository can serve multiple simultaneous working checkouts. |
| 152 | A Fossil repository is an SQLite database, so it highly resistant |
| 153 | to damage from a power-loss or system crash - incomplete transactions |
| 154 | are simply rolled back after the system reboots. |
| 155 | |
| 156 | <h3>3.7 Audit Trail</h3> |
| 157 | |
| 158 | Git features the "rebase" command which can be used to change the |
| 159 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 160 | a complex sequence of check-ins to make their intent easier for others |
| 161 | to understand. From another point of view, rebase can be used to |
| @@ -169,14 +190,14 @@ | |
| 169 | by entering a correction, with an explanation of why the correction is |
| 170 | needed. This can make the history of a project messy, but it also |
| 171 | makes it more honest. The lack of a "rebase" function is considered |
| 172 | a feature of Fossil, not a bug. |
| 173 | |
| 174 | <h3>3.8 License</h3> |
| 175 | |
| 176 | Both Git and Fossil are open-source. Git is under |
| 177 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 178 | under the |
| 179 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 180 | The difference should not be of a concern to most users. However, |
| 181 | some corporate lawyers have objections to using GPL products and |
| 182 | are more comfortable with a BSD-style license. |
| 183 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -42,37 +42,46 @@ | |
| 42 | These additional capabilities are available for Git as 3rd-party |
| 43 | user-installed add-ons, but with Fossil they are integrated into |
| 44 | the design. One way to describe Fossil is that it is |
| 45 | "[https://github.com/ | github]-in-a-box". |
| 46 | |
| 47 | <h3>3.2 Sharding versus Replicating</h3> |
| 48 | |
| 49 | Git makes it easy for each repository in a project to hold a subset of |
| 50 | the branches for that project. In fact, it is entirely possible and not |
| 51 | uncommon for no repository in the project to hold all the different code |
| 52 | versions for a project. Instead the information is distributed. |
| 53 | Individual developers have one or more private branches. A hierarchy |
| 54 | of integrators merge changes from individual developers into collaborative |
| 55 | branches, until all the changes are merged together at the top-level master |
| 56 | branch. And all of this can be accomplished without having to have all the |
| 57 | code in any one repository. Developers or groups of developers can share |
| 58 | only those branches that they want to share and keep other branchs of the |
| 59 | project private. This is analogous to sharding an a distributed database. |
| 60 | |
| 61 | Fossil allows private branches, but its default mode is to share everything. |
| 62 | And so in a Fossil project, all respositories tend to contain all of the |
| 63 | content at all times. This is analogous to replication in a |
| 64 | distributed database. |
| 65 | |
| 66 | The Git model works best for large projects, like the |
| 67 | Linux kernel for which Git was designed. |
| 68 | Linus Torvalds does not need or want to see a thousand |
| 69 | different branches, one for each contributor. Git allows intermediary |
| 70 | "gate-keepers" to merge changes from multiple lower-level developers |
| 71 | into a single branch and only present Linus with a handful of branches |
| 72 | at a time. Git encourages a programming model where each developer |
| 73 | works in his or her own branch and then merges changes up the hierarchy |
| 74 | until they reach the master branch. |
| 75 | |
| 76 | Fossil is designed for smaller and non-hierarchical teams where all |
| 77 | developers are operating directly on the master branch, or at most one |
| 78 | a small number of well defined branches. |
| 79 | The [concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 80 | for multiple developers to work on a single branch and maintain a |
| 81 | linear line of development on that branch without 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. |
| @@ -92,16 +101,16 @@ | |
| 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 |
| @@ -122,11 +131,23 @@ | |
| 131 | |
| 132 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 133 | require little thinking about how to operating it. Reports from the |
| 134 | field indicate that Fossil is mostly successful at this effort. |
| 135 | |
| 136 | <h3>3.5 Web Interface</h3> |
| 137 | |
| 138 | Git has a web interface, but it requires a fair amount of setup and an |
| 139 | external web server. Fossil comes with a fully functional |
| 140 | [./webui.wiki | built-in web-server] |
| 141 | and a really simple mechanism (the "<tt>fossil ui</tt>" command) to |
| 142 | automatically start the web server and bring up a web browser to navigate |
| 143 | it. The web interface for Fossil is not only easier to set up, it is also |
| 144 | more powerful and easier to use. The web interface to Fossil is a practical |
| 145 | replacement to the 3rd-party "GUI Tools" that users often employ to operate |
| 146 | Git. |
| 147 | |
| 148 | <h3>3.6 Implementation Strategy</h3> |
| 149 | |
| 150 | Git consists of a collection of many little programs. Git needs to be |
| 151 | "installed" using some kind of installer or package tool. Git can be |
| 152 | tricky to install and get working, especially for users without |
| 153 | administrative privileges. |
| @@ -138,11 +159,11 @@ | |
| 159 | |
| 160 | Fossil is designed to be trivial to install, uninstall, and upgrade so |
| 161 | that developers can spend more time working on their own projects and |
| 162 | much less time configuring their version control system. |
| 163 | |
| 164 | <h3>3.7 Repository Storage</h3> |
| 165 | |
| 166 | A Git repository is a "pile-of-files" in the ".git" directory at the |
| 167 | root of the working checkout. There is a one-to-one correspondence |
| 168 | between repositories and working checkouts. A power-loss or system crash |
| 169 | in the middle of Git operation can damage or corrupt the Git repository. |
| @@ -151,11 +172,11 @@ | |
| 172 | repository can serve multiple simultaneous working checkouts. |
| 173 | A Fossil repository is an SQLite database, so it highly resistant |
| 174 | to damage from a power-loss or system crash - incomplete transactions |
| 175 | are simply rolled back after the system reboots. |
| 176 | |
| 177 | <h3>3.8 Audit Trail</h3> |
| 178 | |
| 179 | Git features the "rebase" command which can be used to change the |
| 180 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 181 | a complex sequence of check-ins to make their intent easier for others |
| 182 | to understand. From another point of view, rebase can be used to |
| @@ -169,14 +190,14 @@ | |
| 190 | by entering a correction, with an explanation of why the correction is |
| 191 | needed. This can make the history of a project messy, but it also |
| 192 | makes it more honest. The lack of a "rebase" function is considered |
| 193 | a feature of Fossil, not a bug. |
| 194 | |
| 195 | <h3>3.9 License</h3> |
| 196 | |
| 197 | Both Git and Fossil are open-source. Git is under |
| 198 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 199 | under the |
| 200 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 201 | The difference should not be of a concern to most users. However, |
| 202 | some corporate lawyers have objections to using GPL products and |
| 203 | are more comfortable with a BSD-style license. |
| 204 |