Re: [fossil-users] minor doc patch, .fos suggestion
On Fri, Feb 3, 2012 at 8:26 PM, frantisek holop min...@obiit.org wrote: hi there, reading through the documentation i thought some sentences would be easier to read with some minor changes, and i also removed end of line whitespace. the other item from the subject concerns the future change of '_FOSSIL_' to '.fos'. i am totally new on the list, so i am not familiar with the debate (if any happened) regarding this change, but the linguistic issue is that 'fos' in hungarian means a certain type of excrement.. i dont know if this is open to discussion, but if it were, i'd say '.fossil' would not be a good choice, as it looks like a repository without a name. '.fockout' would have it's own problems in english ;} Thank you. I was not aware of this. I'll try to figure out a backwards-compatible way to change that file name. so seeing that it's also part of fossil, also an sqlite db file, why not have something less mystical, bit more verbose (being hidden anyway), like '.checkout.fossil' or some such? in the worst case please keep _FOSSIL_ around for us hungarians :] -f Index: www/tech_overview.wiki == --- www/tech_overview.wiki +++ www/tech_overview.wiki @@ -6,11 +6,11 @@ h21.0 Introduction/h2 At its lowest level, a Fossil repository consists of an unordered set of immutable artifacts. You might think of these artifacts as files, since in many cases the artifacts exactly correspond to source code files -that are stored in the Fossil repository. But other control artifacts +that are stored in the Fossil repository. But other control artifacts are also included in the mix. These control artifacts define the relationships between artifacts - which files go together to form a particular version of the project, who checked in that version and when, what was the check-in comment, what wiki pages are included with the project, what are the edit histories of each wiki page, what bug reports or tickets are @@ -17,29 +17,27 @@ included, who contributed to the evolution of each ticket, and so forth, and so on. This low-level file format is called the global state of the repository, since this is the information that is synced to peer repositories using push and pull operations. The low-level file format is also called enduring since it is intended to last for many years. -The details of the low-level, enduring, global file format +The details of the low-level, enduring, global file format are [./fileformat.wiki | described separately]. This article is about how Fossil is currently implemented. Instead of dealing with vague abstractions of enduring file formats as the -[./fileformat.wiki | that other document] does, this article provides -some detail on how Fossil actually stores information on disk. +[./fileformat.wiki | other document] does, this article provides +some detail on how Fossil actually stores information on disk. h22.0 Three Databases/h2 -Fossil stores state information in +Fossil stores state information in [http://www.sqlite.org/ | SQLite] database files. SQLite keeps an entire relational database, including multiple tables and indices, in a single disk file. The SQLite library allows the database files to be efficiently queried and updated using the industry-standard -SQL language. And SQLite makes updates to these database files atomic, -even if a system crashes or power failure occurs in the middle of the -update, meaning that repository content is protected even during severe -malfunctions. +SQL language. SQLite updates are atomic, so even in the event of a system +crash or power failure the repository content is protected. Fossil uses three separate classes of SQLite databases: ol liThe configuration database @@ -48,11 +46,11 @@ /ol The configuration database is a one-per-user database that holds global configuration information used by Fossil. There is one repository database per project. The repository database is the -file that people are normally referring to when they say +file that people are normally referring to when they say a Fossil repository. The checkout database is found in the working checkout for a project and contains state information that is unique to that working checkout. Fossil does not always use all three database files. The web interface, @@ -134,11 +132,11 @@ instead of a dot) and is located in the directory specified by the LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. h32.2 Repository Databases/h3 -The repository database is the file that is commonly referred to as +The repository database is the file that is commonly referred to as the repository. This is because the repository database contains, among other things, the complete revision, ticket, and wiki history for a project. It is customary to name the repository
[fossil-users] minor doc patch, .fos suggestion
hi there, reading through the documentation i thought some sentences would be easier to read with some minor changes, and i also removed end of line whitespace. the other item from the subject concerns the future change of '_FOSSIL_' to '.fos'. i am totally new on the list, so i am not familiar with the debate (if any happened) regarding this change, but the linguistic issue is that 'fos' in hungarian means a certain type of excrement.. i dont know if this is open to discussion, but if it were, i'd say '.fossil' would not be a good choice, as it looks like a repository without a name. '.fockout' would have it's own problems in english ;} so seeing that it's also part of fossil, also an sqlite db file, why not have something less mystical, bit more verbose (being hidden anyway), like '.checkout.fossil' or some such? in the worst case please keep _FOSSIL_ around for us hungarians :] -f Index: www/tech_overview.wiki == --- www/tech_overview.wiki +++ www/tech_overview.wiki @@ -6,11 +6,11 @@ h21.0 Introduction/h2 At its lowest level, a Fossil repository consists of an unordered set of immutable artifacts. You might think of these artifacts as files, since in many cases the artifacts exactly correspond to source code files -that are stored in the Fossil repository. But other control artifacts +that are stored in the Fossil repository. But other control artifacts are also included in the mix. These control artifacts define the relationships between artifacts - which files go together to form a particular version of the project, who checked in that version and when, what was the check-in comment, what wiki pages are included with the project, what are the edit histories of each wiki page, what bug reports or tickets are @@ -17,29 +17,27 @@ included, who contributed to the evolution of each ticket, and so forth, and so on. This low-level file format is called the global state of the repository, since this is the information that is synced to peer repositories using push and pull operations. The low-level file format is also called enduring since it is intended to last for many years. -The details of the low-level, enduring, global file format +The details of the low-level, enduring, global file format are [./fileformat.wiki | described separately]. This article is about how Fossil is currently implemented. Instead of dealing with vague abstractions of enduring file formats as the -[./fileformat.wiki | that other document] does, this article provides -some detail on how Fossil actually stores information on disk. +[./fileformat.wiki | other document] does, this article provides +some detail on how Fossil actually stores information on disk. h22.0 Three Databases/h2 -Fossil stores state information in +Fossil stores state information in [http://www.sqlite.org/ | SQLite] database files. SQLite keeps an entire relational database, including multiple tables and indices, in a single disk file. The SQLite library allows the database files to be efficiently queried and updated using the industry-standard -SQL language. And SQLite makes updates to these database files atomic, -even if a system crashes or power failure occurs in the middle of the -update, meaning that repository content is protected even during severe -malfunctions. +SQL language. SQLite updates are atomic, so even in the event of a system +crash or power failure the repository content is protected. Fossil uses three separate classes of SQLite databases: ol liThe configuration database @@ -48,11 +46,11 @@ /ol The configuration database is a one-per-user database that holds global configuration information used by Fossil. There is one repository database per project. The repository database is the -file that people are normally referring to when they say +file that people are normally referring to when they say a Fossil repository. The checkout database is found in the working checkout for a project and contains state information that is unique to that working checkout. Fossil does not always use all three database files. The web interface, @@ -134,11 +132,11 @@ instead of a dot) and is located in the directory specified by the LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. h32.2 Repository Databases/h3 -The repository database is the file that is commonly referred to as +The repository database is the file that is commonly referred to as the repository. This is because the repository database contains, among other things, the complete revision, ticket, and wiki history for a project. It is customary to name the repository database after then name of the project, with a .fossil suffix. For example, the repository database for the self-hosting Fossil repository is called fossil.fossil @@ -145,11 +143,11 @@ and the repository database for SQLite is called sqlite.fossil.
