Fossil SCM
Grammar and clarity tweaks to fossil-v-git.wiki
Commit
2cfd125640100112f89ac614e246037cffb00f0594657ce7ab5910fb58c17be4
Parent
3510ca72aff7fa7…
1 file changed
+8
-8
+8
-8
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -114,14 +114,14 @@ | ||
| 114 | 114 | the design. One way to describe Fossil is that it is |
| 115 | 115 | "[https://github.com/ | GitHub]-in-a-box." |
| 116 | 116 | |
| 117 | 117 | Fossil can do operations over all local repo clones and check-out |
| 118 | 118 | directories with a single command. For example, Fossil lets you say |
| 119 | -<tt>fossil all pull</tt> on a laptop prior to taking it off the network | |
| 119 | +<tt>fossil all sync</tt> on a laptop prior to taking it off the network | |
| 120 | 120 | hosting those repos. You can sync up to all of the private repos on your |
| 121 | 121 | company network plus those public Internet-hosted repos you use. Whether |
| 122 | -going out for a working lunch or on a transoceanic an airplane trip, one | |
| 122 | +going out for a working lunch or on a transoceanic airplane trip, one | |
| 123 | 123 | command gets you in sync. This works with several other Fossil |
| 124 | 124 | sub-commands, such as <tt>fossil all changes</tt> to get a list of files |
| 125 | 125 | that you forgot to commit prior to the end of your working day, across |
| 126 | 126 | all repos. |
| 127 | 127 | |
| @@ -258,11 +258,11 @@ | ||
| 258 | 258 | are looking at some historical check-in then you cannot ask "What came |
| 259 | 259 | next?" or "What are the children of this check-in?" |
| 260 | 260 | |
| 261 | 261 | Fossil, on the other hand, parses essential information about check-ins |
| 262 | 262 | (parents, children, committers, comments, files changed, etc.) into a |
| 263 | -relational database that can be easily queried using concise SQL | |
| 263 | +relational database that can easily be queried using concise SQL | |
| 264 | 264 | statements to find both ancestors and descendants of a check-in. This is |
| 265 | 265 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 266 | 266 | other data in a NoSQL block chain structured data store, but that's backed |
| 267 | 267 | by a set of relational lookup tables for quick indexing into that |
| 268 | 268 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| @@ -759,13 +759,13 @@ | ||
| 759 | 759 | |
| 760 | 760 | Fossil cannot sensibly work that way because of its default-enabled |
| 761 | 761 | autosync feature. Instead of jumping straight to the commit step, Fossil |
| 762 | 762 | applies the proposed merge to the local working directory only, |
| 763 | 763 | requiring a separate check-in step before the change is committed to the |
| 764 | -repository blockchain. This gives you a chance to test the change, | |
| 765 | -whether manually, or by running your software's automatic tests, or | |
| 766 | -both. | |
| 764 | +repository blockchain. This gives you a chance to test the change first, | |
| 765 | +either manually or by running your software's automatic tests. (Ideally, | |
| 766 | +both!) | |
| 767 | 767 | |
| 768 | 768 | Another difference is that because Fossil requires an explicit commit |
| 769 | 769 | for a merge, it makes you give an explicit commit <i>message</i> for |
| 770 | 770 | each merge, whereas Git writes that commit message itself by default |
| 771 | 771 | unless you give the optional <tt>--edit</tt> flag to override it. |
| @@ -805,11 +805,11 @@ | ||
| 805 | 805 | brief online help for <tt>[/help?cmd=merge | fossil merge]</tt> is |
| 806 | 806 | currently 41 lines long, to which you want to add the 600 lines of |
| 807 | 807 | [./branching.wiki | the branching document]. The equivalent |
| 808 | 808 | documentation in Git is the aggregation of the man pages for the above |
| 809 | 809 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 810 | -(e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get | |
| 810 | +(e.g. Git's <tt>--edit</tt> and <tt>--no-commit</tt> options get | |
| 811 | 811 | described three times, each time differently.) Fossil's |
| 812 | 812 | documentation is not only more concise, it gives a nice split of brief |
| 813 | 813 | online help and full online documentation. |
| 814 | 814 | |
| 815 | 815 | |
| @@ -855,11 +855,11 @@ | ||
| 855 | 855 | weakening the case for continuing to use SHA-1. |
| 856 | 856 | |
| 857 | 857 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 858 | 858 | Git and Fossil blockchains isn't clear, but you want to have your repositories |
| 859 | 859 | moved over to a stronger hash algorithm before someone figures out how |
| 860 | -to make use of the weaknesses in the old one. Fossil had this covered | |
| 860 | +to make use of the weaknesses in the old one. Fossil has had this covered | |
| 861 | 861 | for years now, so that the solution is now almost universally deployed. |
| 862 | 862 | |
| 863 | 863 | <hr/> |
| 864 | 864 | |
| 865 | 865 | <h3>Asides and Digressions</h3> |
| 866 | 866 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -114,14 +114,14 @@ | |
| 114 | the design. One way to describe Fossil is that it is |
| 115 | "[https://github.com/ | GitHub]-in-a-box." |
| 116 | |
| 117 | Fossil can do operations over all local repo clones and check-out |
| 118 | directories with a single command. For example, Fossil lets you say |
| 119 | <tt>fossil all pull</tt> on a laptop prior to taking it off the network |
| 120 | hosting those repos. You can sync up to all of the private repos on your |
| 121 | company network plus those public Internet-hosted repos you use. Whether |
| 122 | going out for a working lunch or on a transoceanic an airplane trip, one |
| 123 | command gets you in sync. This works with several other Fossil |
| 124 | sub-commands, such as <tt>fossil all changes</tt> to get a list of files |
| 125 | that you forgot to commit prior to the end of your working day, across |
| 126 | all repos. |
| 127 | |
| @@ -258,11 +258,11 @@ | |
| 258 | are looking at some historical check-in then you cannot ask "What came |
| 259 | next?" or "What are the children of this check-in?" |
| 260 | |
| 261 | Fossil, on the other hand, parses essential information about check-ins |
| 262 | (parents, children, committers, comments, files changed, etc.) into a |
| 263 | relational database that can be easily queried using concise SQL |
| 264 | statements to find both ancestors and descendants of a check-in. This is |
| 265 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 266 | other data in a NoSQL block chain structured data store, but that's backed |
| 267 | by a set of relational lookup tables for quick indexing into that |
| 268 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| @@ -759,13 +759,13 @@ | |
| 759 | |
| 760 | Fossil cannot sensibly work that way because of its default-enabled |
| 761 | autosync feature. Instead of jumping straight to the commit step, Fossil |
| 762 | applies the proposed merge to the local working directory only, |
| 763 | requiring a separate check-in step before the change is committed to the |
| 764 | repository blockchain. This gives you a chance to test the change, |
| 765 | whether manually, or by running your software's automatic tests, or |
| 766 | both. |
| 767 | |
| 768 | Another difference is that because Fossil requires an explicit commit |
| 769 | for a merge, it makes you give an explicit commit <i>message</i> for |
| 770 | each merge, whereas Git writes that commit message itself by default |
| 771 | unless you give the optional <tt>--edit</tt> flag to override it. |
| @@ -805,11 +805,11 @@ | |
| 805 | brief online help for <tt>[/help?cmd=merge | fossil merge]</tt> is |
| 806 | currently 41 lines long, to which you want to add the 600 lines of |
| 807 | [./branching.wiki | the branching document]. The equivalent |
| 808 | documentation in Git is the aggregation of the man pages for the above |
| 809 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 810 | (e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get |
| 811 | described three times, each time differently.) Fossil's |
| 812 | documentation is not only more concise, it gives a nice split of brief |
| 813 | online help and full online documentation. |
| 814 | |
| 815 | |
| @@ -855,11 +855,11 @@ | |
| 855 | weakening the case for continuing to use SHA-1. |
| 856 | |
| 857 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 858 | Git and Fossil blockchains isn't clear, but you want to have your repositories |
| 859 | moved over to a stronger hash algorithm before someone figures out how |
| 860 | to make use of the weaknesses in the old one. Fossil had this covered |
| 861 | for years now, so that the solution is now almost universally deployed. |
| 862 | |
| 863 | <hr/> |
| 864 | |
| 865 | <h3>Asides and Digressions</h3> |
| 866 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -114,14 +114,14 @@ | |
| 114 | the design. One way to describe Fossil is that it is |
| 115 | "[https://github.com/ | GitHub]-in-a-box." |
| 116 | |
| 117 | Fossil can do operations over all local repo clones and check-out |
| 118 | directories with a single command. For example, Fossil lets you say |
| 119 | <tt>fossil all sync</tt> on a laptop prior to taking it off the network |
| 120 | hosting those repos. You can sync up to all of the private repos on your |
| 121 | company network plus those public Internet-hosted repos you use. Whether |
| 122 | going out for a working lunch or on a transoceanic airplane trip, one |
| 123 | command gets you in sync. This works with several other Fossil |
| 124 | sub-commands, such as <tt>fossil all changes</tt> to get a list of files |
| 125 | that you forgot to commit prior to the end of your working day, across |
| 126 | all repos. |
| 127 | |
| @@ -258,11 +258,11 @@ | |
| 258 | are looking at some historical check-in then you cannot ask "What came |
| 259 | next?" or "What are the children of this check-in?" |
| 260 | |
| 261 | Fossil, on the other hand, parses essential information about check-ins |
| 262 | (parents, children, committers, comments, files changed, etc.) into a |
| 263 | relational database that can easily be queried using concise SQL |
| 264 | statements to find both ancestors and descendants of a check-in. This is |
| 265 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 266 | other data in a NoSQL block chain structured data store, but that's backed |
| 267 | by a set of relational lookup tables for quick indexing into that |
| 268 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| @@ -759,13 +759,13 @@ | |
| 759 | |
| 760 | Fossil cannot sensibly work that way because of its default-enabled |
| 761 | autosync feature. Instead of jumping straight to the commit step, Fossil |
| 762 | applies the proposed merge to the local working directory only, |
| 763 | requiring a separate check-in step before the change is committed to the |
| 764 | repository blockchain. This gives you a chance to test the change first, |
| 765 | either manually or by running your software's automatic tests. (Ideally, |
| 766 | both!) |
| 767 | |
| 768 | Another difference is that because Fossil requires an explicit commit |
| 769 | for a merge, it makes you give an explicit commit <i>message</i> for |
| 770 | each merge, whereas Git writes that commit message itself by default |
| 771 | unless you give the optional <tt>--edit</tt> flag to override it. |
| @@ -805,11 +805,11 @@ | |
| 805 | brief online help for <tt>[/help?cmd=merge | fossil merge]</tt> is |
| 806 | currently 41 lines long, to which you want to add the 600 lines of |
| 807 | [./branching.wiki | the branching document]. The equivalent |
| 808 | documentation in Git is the aggregation of the man pages for the above |
| 809 | three commands, which is over 1000 lines, much of it mutually redundant. |
| 810 | (e.g. Git's <tt>--edit</tt> and <tt>--no-commit</tt> options get |
| 811 | described three times, each time differently.) Fossil's |
| 812 | documentation is not only more concise, it gives a nice split of brief |
| 813 | online help and full online documentation. |
| 814 | |
| 815 | |
| @@ -855,11 +855,11 @@ | |
| 855 | weakening the case for continuing to use SHA-1. |
| 856 | |
| 857 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 858 | Git and Fossil blockchains isn't clear, but you want to have your repositories |
| 859 | moved over to a stronger hash algorithm before someone figures out how |
| 860 | to make use of the weaknesses in the old one. Fossil has had this covered |
| 861 | for years now, so that the solution is now almost universally deployed. |
| 862 | |
| 863 | <hr/> |
| 864 | |
| 865 | <h3>Asides and Digressions</h3> |
| 866 |