Fossil SCM
Remove obsolete files
Commit
1f498a6ef26bb8145039656b287487e4f2823096
Parent
8d4c5642777c351…
5 files changed
-190
-126
-66
-69
-198
D
ci_cvs.txt
-190
| --- a/ci_cvs.txt | ||
| +++ b/ci_cvs.txt | ||
| @@ -1,192 +0,0 @@ | ||
| 1 | -=============================================================================== | |
| 2 | - | |
| 3 | -First experimental codes ... | |
| 4 | - | |
| 5 | -tools/import-cvs.tcl | |
| 6 | -tools/lib/rcsparser.tcl | |
| 7 | - | |
| 8 | -No actual import, right now only working on getting csets right. The | |
| 9 | -code uses CVSROOT/history as foundation, and augments that with data | |
| 10 | -from the individual RCS files (commit messages). | |
| 11 | - | |
| 12 | -Statistics of a run ... | |
| 13 | - 3516 csets. | |
| 14 | - | |
| 15 | - 1545 breaks on user change | |
| 16 | - 558 breaks on file duplicate | |
| 17 | - 13 breaks on branch/trunk change | |
| 18 | - 1402 breaks on commit message change | |
| 19 | - | |
| 20 | -Time statistics ... | |
| 21 | - 3297 were processed in <= 1 seconds (93.77%) | |
| 22 | - 217 were processed in between 2 seconds and 14 minutes. | |
| 23 | - 1 was processed in ~41 minutes | |
| 24 | - 1 was processed in ~22 hours | |
| 25 | - | |
| 26 | -Time fuzz - Differences between csets range from 0 seconds to 66 | |
| 27 | -days. Needs stats analysis to see if there is an obvious break. Even | |
| 28 | -so the times within csets and between csets overlap a great deal, | |
| 29 | -making time a bad criterium for cset separation, IMHO. | |
| 30 | - | |
| 31 | -Leaving that topic, back to the current cset separator ... | |
| 32 | - | |
| 33 | -It has a problem: | |
| 34 | - The history file is not starting at the root! | |
| 35 | - | |
| 36 | -Examples: | |
| 37 | - The first three changesets are | |
| 38 | - | |
| 39 | - =============================/user | |
| 40 | - M {Wed Nov 22 09:28:49 AM PST 2000} ericm 1.4 tcllib/modules/ftpd/ChangeLog | |
| 41 | - M {Wed Nov 22 09:28:49 AM PST 2000} ericm 1.7 tcllib/modules/ftpd/ftpd.tcl | |
| 42 | - files: 2 | |
| 43 | - delta: 0 | |
| 44 | - range: 0 seconds | |
| 45 | - =============================/cmsg | |
| 46 | - M {Wed Nov 29 02:14:33 PM PST 2000} ericm 1.3 tcllib/aclocal.m4 | |
| 47 | - files: 1 | |
| 48 | - delta: | |
| 49 | - range: 0 seconds | |
| 50 | - =============================/cmsg | |
| 51 | - M {Sun Feb 04 12:28:35 AM PST 2001} ericm 1.9 tcllib/modules/mime/ChangeLog | |
| 52 | - M {Sun Feb 04 12:28:35 AM PST 2001} ericm 1.12 tcllib/modules/mime/mime.tcl | |
| 53 | - files: 2 | |
| 54 | - delta: 0 | |
| 55 | - range: 0 seconds | |
| 56 | - | |
| 57 | -All csets modify files which already have several revisions. We have | |
| 58 | -no csets from before that in the history, but these csets are in the | |
| 59 | -RCS files. | |
| 60 | - | |
| 61 | -I wonder, is SF maybe removing old entries from the history when it | |
| 62 | -grows too large ? | |
| 63 | - | |
| 64 | -This also affects incremental import ... I cannot assume that the | |
| 65 | -history always grows. It may shrink ... I cannot keep an offset, will | |
| 66 | -have to record the time of the last entry, or even the full entry | |
| 67 | -processed last, to allow me to skip ahead to anything not known yet. | |
| 68 | - | |
| 69 | -I might have to try to implement the algorithm outlined below, | |
| 70 | -matching the revision trees of the individual RCS files to each other | |
| 71 | -to form the global tree of revisions. Maybe we can use the history to | |
| 72 | -help in the matchup, for the parts where we do have it. | |
| 73 | - | |
| 74 | -Wait. This might be easier ... Take the delta information from the RCS | |
| 75 | -files and generate a fake history ... Actually, this might even allow | |
| 76 | -us to create a total history ... No, not quite, the merge entries the | |
| 77 | -actual history may contain will be missing. These we can mix in from | |
| 78 | -the actual history, as much as we have. | |
| 79 | - | |
| 80 | -Still, lets try that, a fake history, and then run this script on it | |
| 81 | -to see if/where are differences. | |
| 82 | - | |
| 83 | -=============================================================================== | |
| 84 | - | |
| 85 | - | |
| 86 | -Notes about CVS import, regarding CVS. | |
| 87 | - | |
| 88 | -- Problem: CVS does not really track changesets, but only individual | |
| 89 | - revisions of files. To recover changesets it is necessary to look at | |
| 90 | - author, branch, timestamp information, and the commit messages. Even | |
| 91 | - so this is only heuristic, not foolproof. | |
| 92 | - | |
| 93 | - Existing tool: cvsps. | |
| 94 | - | |
| 95 | - Processes the output of 'cvs log' to recover changesets. Problem: | |
| 96 | - Sees only a linear list of revisions, does not see branchpoints, | |
| 97 | - etc. Cannot use the tree structure to help in making the decisions. | |
| 98 | - | |
| 99 | -- Problem: CVS does not track merge-points at all. Recovery through | |
| 100 | - heuristics is brittle at best, looking for keywords in commit | |
| 101 | - messages which might indicate that a branch was merged with some | |
| 102 | - other. | |
| 103 | - | |
| 104 | - | |
| 105 | -Ideas regarding an algorithm to recover changesets. | |
| 106 | - | |
| 107 | -Key feature: Uses the per-file revision trees to help in uncovering | |
| 108 | -the underlying changesets and global revision tree G. | |
| 109 | - | |
| 110 | -The per-file revision tree for a file X is in essence the global | |
| 111 | -revision tree with all nodes not pertaining to X removed from it. In | |
| 112 | -the reverse this allows us to built up the global revision tree from | |
| 113 | -the per-file trees by matching nodes to each other and extending. | |
| 114 | - | |
| 115 | -Start with the per file revision tree of a single file as initial | |
| 116 | -approximation of the global tree. All nodes of this tree refer to the | |
| 117 | -revision of the file belonging to it, and through that the file | |
| 118 | -itself. At each step the global tree contains the nodes for a finite | |
| 119 | -set of files, and all nodes in the tree refer to revisions of all | |
| 120 | -files in the set, making the mapping total. | |
| 121 | - | |
| 122 | -To add a file X to the tree take the per-file revision tree R and | |
| 123 | -performs the following actions: | |
| 124 | - | |
| 125 | -- For each node N in R use the tuple <author, branch, commit message> | |
| 126 | - to identify a set of nodes in G which may match N. Use the timestamp | |
| 127 | - to locate the node nearest in time. | |
| 128 | - | |
| 129 | -- This process will leave nodes in N unmapped. If there are unmapped | |
| 130 | - nodes which have no neighbouring mapped nodes we have to | |
| 131 | - abort. | |
| 132 | - | |
| 133 | - Otherwise take the nodes which have mapped neighbours. Trace the | |
| 134 | - edges and see which of these nodes are connected in the local | |
| 135 | - tree. Then look at the identified neighbours and trace their | |
| 136 | - connections. | |
| 137 | - | |
| 138 | - If two global nodes have a direct connection, but a multi-edge | |
| 139 | - connection in the local tree insert global nodes mapping to the | |
| 140 | - local nodes and map them together. This expands the global tree to | |
| 141 | - hold the revisions added by the new file. | |
| 142 | - | |
| 143 | - Otherwise, both sides have multi-edge connections then abort. This | |
| 144 | - looks like a merge of two different branches, but there are no such | |
| 145 | - in CVS ... Wait ... sort the nodes over time and fit the new nodes | |
| 146 | - in between the other nodes, per the timestamps. We have overlapping | |
| 147 | - / alternating changes to one file and others. | |
| 148 | - | |
| 149 | - A last possibility is that a node is only connected to a mapped | |
| 150 | - parent. This may be a new branch, or again an alternating change on | |
| 151 | - the given line. Symbols on the revisions will help to map this. | |
| 152 | - | |
| 153 | -- We now have an extended global tree which incorporates the revisions | |
| 154 | - of the new file. However new nodes will refer only to the new file, | |
| 155 | - and old nodes may not refer to the new file. This has to be fixed, | |
| 156 | - as all nodes have to refer to all files. | |
| 157 | - | |
| 158 | - Run over the tree and look at each parent/child pair. If a file is | |
| 159 | - not referenced in the child, but the parent, then copy a reference | |
| 160 | - to the file revision on the parent forward to the child. This | |
| 161 | - signals that the file did not change in the given revision. | |
| 162 | - | |
| 163 | -- After all files have been integrated in this manner we have global | |
| 164 | - revision tree capturing all changesets, including the unchanged | |
| 165 | - files per changeset. | |
| 166 | - | |
| 167 | - | |
| 168 | -This algorithm has to be refined to also take Attic/ files into | |
| 169 | -account. | |
| 170 | - | |
| -------------------------------------------------------------------------- | ||
| 171 | - | |
| 172 | -Two archive files mapping to the same user file. How are they | |
| 173 | -interleaved ? | |
| 174 | - | |
| 175 | -(a) sqlite/src/os_unix.h,v | |
| 176 | -(b) sqlite/src/Attic/os_unix.h,v | |
| 177 | - | |
| 178 | -Problem: Max version of (a) is 1.9 | |
| 179 | - Max version of (b) is 1.11 | |
| 180 | - cvs co 1.10 -> no longer in the repository. | |
| 181 | - | |
| 182 | -This seems to indicate that the non-Attic file is relevant. | |
| 183 | - | |
| --------------------------------------------------------------------------- | ||
| 184 | - | |
| 185 | -tcllib - more problems - tklib/pie.tcl,v - | |
| 186 | - | |
| 187 | -invalid change text in | |
| 188 | -/home/aku/Projects/Tcl/Fossil/Devel/Examples/cvs-tcllib/tklib/modules/tkpiechart/pie.tcl,v | |
| 189 | - | |
| 190 | -Possibly braces ? |
| --- a/ci_cvs.txt | |
| +++ b/ci_cvs.txt | |
| @@ -1,192 +0,0 @@ | |
| 1 | =============================================================================== |
| 2 | |
| 3 | First experimental codes ... |
| 4 | |
| 5 | tools/import-cvs.tcl |
| 6 | tools/lib/rcsparser.tcl |
| 7 | |
| 8 | No actual import, right now only working on getting csets right. The |
| 9 | code uses CVSROOT/history as foundation, and augments that with data |
| 10 | from the individual RCS files (commit messages). |
| 11 | |
| 12 | Statistics of a run ... |
| 13 | 3516 csets. |
| 14 | |
| 15 | 1545 breaks on user change |
| 16 | 558 breaks on file duplicate |
| 17 | 13 breaks on branch/trunk change |
| 18 | 1402 breaks on commit message change |
| 19 | |
| 20 | Time statistics ... |
| 21 | 3297 were processed in <= 1 seconds (93.77%) |
| 22 | 217 were processed in between 2 seconds and 14 minutes. |
| 23 | 1 was processed in ~41 minutes |
| 24 | 1 was processed in ~22 hours |
| 25 | |
| 26 | Time fuzz - Differences between csets range from 0 seconds to 66 |
| 27 | days. Needs stats analysis to see if there is an obvious break. Even |
| 28 | so the times within csets and between csets overlap a great deal, |
| 29 | making time a bad criterium for cset separation, IMHO. |
| 30 | |
| 31 | Leaving that topic, back to the current cset separator ... |
| 32 | |
| 33 | It has a problem: |
| 34 | The history file is not starting at the root! |
| 35 | |
| 36 | Examples: |
| 37 | The first three changesets are |
| 38 | |
| 39 | =============================/user |
| 40 | M {Wed Nov 22 09:28:49 AM PST 2000} ericm 1.4 tcllib/modules/ftpd/ChangeLog |
| 41 | M {Wed Nov 22 09:28:49 AM PST 2000} ericm 1.7 tcllib/modules/ftpd/ftpd.tcl |
| 42 | files: 2 |
| 43 | delta: 0 |
| 44 | range: 0 seconds |
| 45 | =============================/cmsg |
| 46 | M {Wed Nov 29 02:14:33 PM PST 2000} ericm 1.3 tcllib/aclocal.m4 |
| 47 | files: 1 |
| 48 | delta: |
| 49 | range: 0 seconds |
| 50 | =============================/cmsg |
| 51 | M {Sun Feb 04 12:28:35 AM PST 2001} ericm 1.9 tcllib/modules/mime/ChangeLog |
| 52 | M {Sun Feb 04 12:28:35 AM PST 2001} ericm 1.12 tcllib/modules/mime/mime.tcl |
| 53 | files: 2 |
| 54 | delta: 0 |
| 55 | range: 0 seconds |
| 56 | |
| 57 | All csets modify files which already have several revisions. We have |
| 58 | no csets from before that in the history, but these csets are in the |
| 59 | RCS files. |
| 60 | |
| 61 | I wonder, is SF maybe removing old entries from the history when it |
| 62 | grows too large ? |
| 63 | |
| 64 | This also affects incremental import ... I cannot assume that the |
| 65 | history always grows. It may shrink ... I cannot keep an offset, will |
| 66 | have to record the time of the last entry, or even the full entry |
| 67 | processed last, to allow me to skip ahead to anything not known yet. |
| 68 | |
| 69 | I might have to try to implement the algorithm outlined below, |
| 70 | matching the revision trees of the individual RCS files to each other |
| 71 | to form the global tree of revisions. Maybe we can use the history to |
| 72 | help in the matchup, for the parts where we do have it. |
| 73 | |
| 74 | Wait. This might be easier ... Take the delta information from the RCS |
| 75 | files and generate a fake history ... Actually, this might even allow |
| 76 | us to create a total history ... No, not quite, the merge entries the |
| 77 | actual history may contain will be missing. These we can mix in from |
| 78 | the actual history, as much as we have. |
| 79 | |
| 80 | Still, lets try that, a fake history, and then run this script on it |
| 81 | to see if/where are differences. |
| 82 | |
| 83 | =============================================================================== |
| 84 | |
| 85 | |
| 86 | Notes about CVS import, regarding CVS. |
| 87 | |
| 88 | - Problem: CVS does not really track changesets, but only individual |
| 89 | revisions of files. To recover changesets it is necessary to look at |
| 90 | author, branch, timestamp information, and the commit messages. Even |
| 91 | so this is only heuristic, not foolproof. |
| 92 | |
| 93 | Existing tool: cvsps. |
| 94 | |
| 95 | Processes the output of 'cvs log' to recover changesets. Problem: |
| 96 | Sees only a linear list of revisions, does not see branchpoints, |
| 97 | etc. Cannot use the tree structure to help in making the decisions. |
| 98 | |
| 99 | - Problem: CVS does not track merge-points at all. Recovery through |
| 100 | heuristics is brittle at best, looking for keywords in commit |
| 101 | messages which might indicate that a branch was merged with some |
| 102 | other. |
| 103 | |
| 104 | |
| 105 | Ideas regarding an algorithm to recover changesets. |
| 106 | |
| 107 | Key feature: Uses the per-file revision trees to help in uncovering |
| 108 | the underlying changesets and global revision tree G. |
| 109 | |
| 110 | The per-file revision tree for a file X is in essence the global |
| 111 | revision tree with all nodes not pertaining to X removed from it. In |
| 112 | the reverse this allows us to built up the global revision tree from |
| 113 | the per-file trees by matching nodes to each other and extending. |
| 114 | |
| 115 | Start with the per file revision tree of a single file as initial |
| 116 | approximation of the global tree. All nodes of this tree refer to the |
| 117 | revision of the file belonging to it, and through that the file |
| 118 | itself. At each step the global tree contains the nodes for a finite |
| 119 | set of files, and all nodes in the tree refer to revisions of all |
| 120 | files in the set, making the mapping total. |
| 121 | |
| 122 | To add a file X to the tree take the per-file revision tree R and |
| 123 | performs the following actions: |
| 124 | |
| 125 | - For each node N in R use the tuple <author, branch, commit message> |
| 126 | to identify a set of nodes in G which may match N. Use the timestamp |
| 127 | to locate the node nearest in time. |
| 128 | |
| 129 | - This process will leave nodes in N unmapped. If there are unmapped |
| 130 | nodes which have no neighbouring mapped nodes we have to |
| 131 | abort. |
| 132 | |
| 133 | Otherwise take the nodes which have mapped neighbours. Trace the |
| 134 | edges and see which of these nodes are connected in the local |
| 135 | tree. Then look at the identified neighbours and trace their |
| 136 | connections. |
| 137 | |
| 138 | If two global nodes have a direct connection, but a multi-edge |
| 139 | connection in the local tree insert global nodes mapping to the |
| 140 | local nodes and map them together. This expands the global tree to |
| 141 | hold the revisions added by the new file. |
| 142 | |
| 143 | Otherwise, both sides have multi-edge connections then abort. This |
| 144 | looks like a merge of two different branches, but there are no such |
| 145 | in CVS ... Wait ... sort the nodes over time and fit the new nodes |
| 146 | in between the other nodes, per the timestamps. We have overlapping |
| 147 | / alternating changes to one file and others. |
| 148 | |
| 149 | A last possibility is that a node is only connected to a mapped |
| 150 | parent. This may be a new branch, or again an alternating change on |
| 151 | the given line. Symbols on the revisions will help to map this. |
| 152 | |
| 153 | - We now have an extended global tree which incorporates the revisions |
| 154 | of the new file. However new nodes will refer only to the new file, |
| 155 | and old nodes may not refer to the new file. This has to be fixed, |
| 156 | as all nodes have to refer to all files. |
| 157 | |
| 158 | Run over the tree and look at each parent/child pair. If a file is |
| 159 | not referenced in the child, but the parent, then copy a reference |
| 160 | to the file revision on the parent forward to the child. This |
| 161 | signals that the file did not change in the given revision. |
| 162 | |
| 163 | - After all files have been integrated in this manner we have global |
| 164 | revision tree capturing all changesets, including the unchanged |
| 165 | files per changeset. |
| 166 | |
| 167 | |
| 168 | This algorithm has to be refined to also take Attic/ files into |
| 169 | account. |
| 170 | |
| -------------------------------------------------------------------------- | |
| 171 | |
| 172 | Two archive files mapping to the same user file. How are they |
| 173 | interleaved ? |
| 174 | |
| 175 | (a) sqlite/src/os_unix.h,v |
| 176 | (b) sqlite/src/Attic/os_unix.h,v |
| 177 | |
| 178 | Problem: Max version of (a) is 1.9 |
| 179 | Max version of (b) is 1.11 |
| 180 | cvs co 1.10 -> no longer in the repository. |
| 181 | |
| 182 | This seems to indicate that the non-Attic file is relevant. |
| 183 | |
| --------------------------------------------------------------------------- | |
| 184 | |
| 185 | tcllib - more problems - tklib/pie.tcl,v - |
| 186 | |
| 187 | invalid change text in |
| 188 | /home/aku/Projects/Tcl/Fossil/Devel/Examples/cvs-tcllib/tklib/modules/tkpiechart/pie.tcl,v |
| 189 | |
| 190 | Possibly braces ? |
| --- a/ci_cvs.txt | |
| +++ b/ci_cvs.txt | |
| @@ -1,192 +0,0 @@ | |
| -------------------------------------------------------------------------- | |
| --------------------------------------------------------------------------- | |
D
ci_fossil.txt
-126
| --- a/ci_fossil.txt | ||
| +++ b/ci_fossil.txt | ||
| @@ -1,127 +0,0 @@ | ||
| 1 | - | |
| 2 | -To perform CVS imports for fossil we need at least the ability to | |
| 3 | -parse CVS files, i.e. RCS files, with slight differences. | |
| 4 | - | |
| 5 | -For the general architecture of the import facility we have two major | |
| 6 | -paths to choose between. | |
| 7 | - | |
| 8 | -One is to use an external tool which processes a cvs repository and | |
| 9 | -drives fossil through its CLI to insert the found changesets. | |
| 10 | - | |
| 11 | -The other is to integrate the whole facility into the fossil binary | |
| 12 | -itself. | |
| 13 | - | |
| 14 | -I dislike the second choice. It may be faster, as the implementation | |
| 15 | -can use all internal functionality of fossil to perform the import, | |
| 16 | -however it will also bloat the binary with functionality not needed | |
| 17 | -most of the time. Which becomes especially obvious if more importers | |
| 18 | -are to be written, like for monotone, bazaar, mercurial, bitkeeper, | |
| 19 | -git, SVN, Arc, etc. Keeping all this out of the core fossil binary is | |
| 20 | -IMHO more beneficial in the long term, also from a maintenance point | |
| 21 | -of view. The tools can evolve separately. Especially important for CVS | |
| 22 | -as it will have to deal with lots of broken repositories, all | |
| 23 | -different. | |
| 24 | - | |
| 25 | -However, nothing speaks against looking for common parts in all | |
| 26 | -possible import tools, and having these in the fossil core, as a | |
| 27 | -general backend all importer may use. Something like that has already | |
| 28 | -been proposed: The deconstruct|reconstruct methods. For us, actually | |
| 29 | -only reconstruct is important. Taking an unordered collection of files | |
| 30 | -(data, and manifests) it generates a proper fossil repository. With | |
| 31 | -that method implemented all import tools only have to generate the | |
| 32 | -necessary collection and then leave the main work of filling the | |
| 33 | -database to fossil itself. | |
| 34 | - | |
| 35 | -The disadvantage of this method is however that it will gobble up a | |
| 36 | -lot of temporary space in the filesystem to hold all unique revisions | |
| 37 | -of all files in their expanded form. | |
| 38 | - | |
| 39 | -It might be worthwhile to consider an extension of 'reconstruct' which | |
| 40 | -is able to incrementally add a set of files to an existing fossil | |
| 41 | -repository already containing revisions. In that case the import tool | |
| 42 | -can be changed to incrementally generate the collection for a | |
| 43 | -particular revision, import it, and iterate over all revisions in the | |
| 44 | -origin repository. This is of course also dependent on the origin | |
| 45 | -repository itself, how well it supports such incremental export. | |
| 46 | - | |
| 47 | -This also leads to a possible method for performing the import using | |
| 48 | -only existing functionality ('reconstruct' has not been implemented | |
| 49 | -yet). Instead generating an unordered collection for each revision | |
| 50 | -generate a properly setup workspace, simply commit it. This will | |
| 51 | -require use of rm, add and update methods as well, to remove old and | |
| 52 | -enter new files, and point the fossil repository to the correct parent | |
| 53 | -revision from the new revision is derived. | |
| 54 | - | |
| 55 | -The relative efficiency (in time) of these incremental methods versus | |
| 56 | -importing a complete collection of files encoding the entire origin | |
| 57 | -repository however is not clear. | |
| 58 | - | |
| ----------------------------------- | ||
| 59 | - | |
| 60 | -reconstruct | |
| 61 | - | |
| 62 | -The core logic for handling content is in the file "content.c", in | |
| 63 | -particular the functions 'content_put' and 'content_deltify'. One of | |
| 64 | -the main users of these functions is in the file "checkin.c", see the | |
| 65 | -function 'commit_cmd'. | |
| 66 | - | |
| 67 | -The logic is clear. The new modified files are simply stored without | |
| 68 | -delta-compression, using 'content_put'. And should fosssil have an id | |
| 69 | -for the _previous_ revision of the committed file it uses | |
| 70 | -'content_deltify' to convert the already stored data for that revision | |
| 71 | -into a delta with the just stored new revision as origin. | |
| 72 | - | |
| 73 | -In other words, fossil produces reverse deltas, with leaf revisions | |
| 74 | -stored just zip-compressed (plain) and older revisions using both zip- | |
| 75 | -and delta-compression. | |
| 76 | - | |
| 77 | -Of note is that the underlying logic in 'content_deltify' gives up on | |
| 78 | -delta compression if the involved files are either not large enough, | |
| 79 | -or if the achieved compression factor was not high enough. In that | |
| 80 | -case the old revision of the file is left plain. | |
| 81 | - | |
| 82 | -The scheme can thus be called a 'truncated reverse delta'. | |
| 83 | - | |
| 84 | -The manifest is created and committed after the modified files. It | |
| 85 | -uses the same logic as for the regular files. The new leaf is stored | |
| 86 | -plain, and storage of the parent manifest is modified to be a delta | |
| 87 | -with the current as origin. | |
| 88 | - | |
| 89 | -Further note that for a checkin of a merge result oonly the primary | |
| 90 | -parent is modified in that way. The secondary parent, the one merged | |
| 91 | -into the current revision is not touched. I.e. from the storage layer | |
| 92 | -point of view this revision is still a leaf and the data is kept | |
| 93 | -stored plain, not delta-compressed. | |
| 94 | - | |
| 95 | - | |
| 96 | - | |
| 97 | -Now the "reconstruct" can be done like so: | |
| 98 | - | |
| 99 | -- Scan the files in the indicated directory, and look for a manifest. | |
| 100 | - | |
| 101 | -- When the manifest has been found parse its contents and follow the | |
| 102 | - chain of parent links to locate the root manifest (no parent). | |
| 103 | - | |
| 104 | -- Import the files referenced by the root manifest, then the manifest | |
| 105 | - itself. This can be done using a modified form of the 'commit_cmd' | |
| 106 | - which does not have to construct a manifest on its own from vfile, | |
| 107 | - vmerge, etc. | |
| 108 | - | |
| 109 | -- After that recursively apply the import of the previous step to the | |
| 110 | - children of the root, and so on. | |
| 111 | - | |
| 112 | -For an incremental "reconstruct" the collection of files would not be | |
| 113 | -a single tree with a root, but a forest, and the roots to look for are | |
| 114 | -not manifests without parent, but with a parent which is already | |
| 115 | -present in the repository. After one such root has been found and | |
| 116 | -processed the unprocessed files have to be searched further for more | |
| 117 | -roots, and only if no such are found anymore will the remaining files | |
| 118 | -be considered as superfluous. | |
| 119 | - | |
| 120 | -We can use the functions in "manifest.c" for the parsing and following | |
| 121 | -the parental chain. | |
| 122 | - | |
| 123 | -Hm. But we have no direct child information. So the above algorithm | |
| 124 | -has to be modified, we have to scan all manifests before we start | |
| 125 | -importing, and we have to create a reverse index, from manifest to | |
| 126 | -children so that we can perform the import from root to leaves. |
| --- a/ci_fossil.txt | |
| +++ b/ci_fossil.txt | |
| @@ -1,127 +0,0 @@ | |
| 1 | |
| 2 | To perform CVS imports for fossil we need at least the ability to |
| 3 | parse CVS files, i.e. RCS files, with slight differences. |
| 4 | |
| 5 | For the general architecture of the import facility we have two major |
| 6 | paths to choose between. |
| 7 | |
| 8 | One is to use an external tool which processes a cvs repository and |
| 9 | drives fossil through its CLI to insert the found changesets. |
| 10 | |
| 11 | The other is to integrate the whole facility into the fossil binary |
| 12 | itself. |
| 13 | |
| 14 | I dislike the second choice. It may be faster, as the implementation |
| 15 | can use all internal functionality of fossil to perform the import, |
| 16 | however it will also bloat the binary with functionality not needed |
| 17 | most of the time. Which becomes especially obvious if more importers |
| 18 | are to be written, like for monotone, bazaar, mercurial, bitkeeper, |
| 19 | git, SVN, Arc, etc. Keeping all this out of the core fossil binary is |
| 20 | IMHO more beneficial in the long term, also from a maintenance point |
| 21 | of view. The tools can evolve separately. Especially important for CVS |
| 22 | as it will have to deal with lots of broken repositories, all |
| 23 | different. |
| 24 | |
| 25 | However, nothing speaks against looking for common parts in all |
| 26 | possible import tools, and having these in the fossil core, as a |
| 27 | general backend all importer may use. Something like that has already |
| 28 | been proposed: The deconstruct|reconstruct methods. For us, actually |
| 29 | only reconstruct is important. Taking an unordered collection of files |
| 30 | (data, and manifests) it generates a proper fossil repository. With |
| 31 | that method implemented all import tools only have to generate the |
| 32 | necessary collection and then leave the main work of filling the |
| 33 | database to fossil itself. |
| 34 | |
| 35 | The disadvantage of this method is however that it will gobble up a |
| 36 | lot of temporary space in the filesystem to hold all unique revisions |
| 37 | of all files in their expanded form. |
| 38 | |
| 39 | It might be worthwhile to consider an extension of 'reconstruct' which |
| 40 | is able to incrementally add a set of files to an existing fossil |
| 41 | repository already containing revisions. In that case the import tool |
| 42 | can be changed to incrementally generate the collection for a |
| 43 | particular revision, import it, and iterate over all revisions in the |
| 44 | origin repository. This is of course also dependent on the origin |
| 45 | repository itself, how well it supports such incremental export. |
| 46 | |
| 47 | This also leads to a possible method for performing the import using |
| 48 | only existing functionality ('reconstruct' has not been implemented |
| 49 | yet). Instead generating an unordered collection for each revision |
| 50 | generate a properly setup workspace, simply commit it. This will |
| 51 | require use of rm, add and update methods as well, to remove old and |
| 52 | enter new files, and point the fossil repository to the correct parent |
| 53 | revision from the new revision is derived. |
| 54 | |
| 55 | The relative efficiency (in time) of these incremental methods versus |
| 56 | importing a complete collection of files encoding the entire origin |
| 57 | repository however is not clear. |
| 58 | |
| ----------------------------------- | |
| 59 | |
| 60 | reconstruct |
| 61 | |
| 62 | The core logic for handling content is in the file "content.c", in |
| 63 | particular the functions 'content_put' and 'content_deltify'. One of |
| 64 | the main users of these functions is in the file "checkin.c", see the |
| 65 | function 'commit_cmd'. |
| 66 | |
| 67 | The logic is clear. The new modified files are simply stored without |
| 68 | delta-compression, using 'content_put'. And should fosssil have an id |
| 69 | for the _previous_ revision of the committed file it uses |
| 70 | 'content_deltify' to convert the already stored data for that revision |
| 71 | into a delta with the just stored new revision as origin. |
| 72 | |
| 73 | In other words, fossil produces reverse deltas, with leaf revisions |
| 74 | stored just zip-compressed (plain) and older revisions using both zip- |
| 75 | and delta-compression. |
| 76 | |
| 77 | Of note is that the underlying logic in 'content_deltify' gives up on |
| 78 | delta compression if the involved files are either not large enough, |
| 79 | or if the achieved compression factor was not high enough. In that |
| 80 | case the old revision of the file is left plain. |
| 81 | |
| 82 | The scheme can thus be called a 'truncated reverse delta'. |
| 83 | |
| 84 | The manifest is created and committed after the modified files. It |
| 85 | uses the same logic as for the regular files. The new leaf is stored |
| 86 | plain, and storage of the parent manifest is modified to be a delta |
| 87 | with the current as origin. |
| 88 | |
| 89 | Further note that for a checkin of a merge result oonly the primary |
| 90 | parent is modified in that way. The secondary parent, the one merged |
| 91 | into the current revision is not touched. I.e. from the storage layer |
| 92 | point of view this revision is still a leaf and the data is kept |
| 93 | stored plain, not delta-compressed. |
| 94 | |
| 95 | |
| 96 | |
| 97 | Now the "reconstruct" can be done like so: |
| 98 | |
| 99 | - Scan the files in the indicated directory, and look for a manifest. |
| 100 | |
| 101 | - When the manifest has been found parse its contents and follow the |
| 102 | chain of parent links to locate the root manifest (no parent). |
| 103 | |
| 104 | - Import the files referenced by the root manifest, then the manifest |
| 105 | itself. This can be done using a modified form of the 'commit_cmd' |
| 106 | which does not have to construct a manifest on its own from vfile, |
| 107 | vmerge, etc. |
| 108 | |
| 109 | - After that recursively apply the import of the previous step to the |
| 110 | children of the root, and so on. |
| 111 | |
| 112 | For an incremental "reconstruct" the collection of files would not be |
| 113 | a single tree with a root, but a forest, and the roots to look for are |
| 114 | not manifests without parent, but with a parent which is already |
| 115 | present in the repository. After one such root has been found and |
| 116 | processed the unprocessed files have to be searched further for more |
| 117 | roots, and only if no such are found anymore will the remaining files |
| 118 | be considered as superfluous. |
| 119 | |
| 120 | We can use the functions in "manifest.c" for the parsing and following |
| 121 | the parental chain. |
| 122 | |
| 123 | Hm. But we have no direct child information. So the above algorithm |
| 124 | has to be modified, we have to scan all manifests before we start |
| 125 | importing, and we have to create a reverse index, from manifest to |
| 126 | children so that we can perform the import from root to leaves. |
| --- a/ci_fossil.txt | |
| +++ b/ci_fossil.txt | |
| @@ -1,127 +0,0 @@ | |
| ----------------------------------- | |
D
cvs2fossil.txt
-66
| --- a/cvs2fossil.txt | ||
| +++ b/cvs2fossil.txt | ||
| @@ -1,66 +0,0 @@ | ||
| 1 | - | |
| 2 | -Known problems and areas to work on | |
| 3 | -=================================== | |
| 4 | - | |
| 5 | -* Not yet able to handle the specification of multiple projects | |
| 6 | - for one CVS repository. I.e. I can, for example, import all of | |
| 7 | - tcllib, or a single subproject of tcllib, like tklib, but not | |
| 8 | - multiple sub-projects in one go. | |
| 9 | - | |
| 10 | -* Consider to rework the breaker- and sort-passes so that they | |
| 11 | - do not need all changesets as objects in memory. | |
| 12 | - | |
| 13 | - Current memory consumption after all changesets are loaded: | |
| 14 | - | |
| 15 | - bwidget 6971627 6.6 | |
| 16 | - cvs-memchan 4634049 4.4 | |
| 17 | - cvs-sqlite 45674501 43.6 | |
| 18 | - cvs-trf 8781289 8.4 | |
| 19 | - faqs 2835116 2.7 | |
| 20 | - libtommath 4405066 4.2 | |
| 21 | - mclistbox 3350190 3.2 | |
| 22 | - newclock 5020460 4.8 | |
| 23 | - oocore 4064574 3.9 | |
| 24 | - sampleextension 4729932 4.5 | |
| 25 | - tclapps 8482135 8.1 | |
| 26 | - tclbench 4116887 3.9 | |
| 27 | - tcl_bignum 2545192 2.4 | |
| 28 | - tclconfig 4105042 3.9 | |
| 29 | - tcllib 31707688 30.2 | |
| 30 | - tcltutorial 3512048 3.3 | |
| 31 | - tcl 109926382 104.8 | |
| 32 | - thread 8953139 8.5 | |
| 33 | - tklib 13935220 13.3 | |
| 34 | - tk 66149870 63.1 | |
| 35 | - widget 2625609 2.5 | |
| 36 | - | |
| 37 | -* Look at the dependencies on external packages and consider | |
| 38 | - which of them can be moved into the importer, either as a | |
| 39 | - simple utility command, or wholesale. | |
| 40 | - | |
| 41 | - struct::list | |
| 42 | - assign, map, reverse, filter | |
| 43 | - | |
| 44 | - Very few and self-contained commands. | |
| 45 | - | |
| 46 | - struct::set | |
| 47 | - size, empty, contains, add, include, exclude, | |
| 48 | - intersect, subsetof | |
| 49 | - | |
| 50 | - Most of the core commands. | |
| 51 | - | |
| 52 | - fileutil | |
| 53 | - cat, appendToFile, writeFile, | |
| 54 | - tempfile, stripPath, test | |
| 55 | - | |
| 56 | - fileutil::traverse | |
| 57 | - In toto | |
| 58 | - | |
| 59 | - struct::graph | |
| 60 | - In toto | |
| 61 | - | |
| 62 | - snit | |
| 63 | - In toto | |
| 64 | - | |
| 65 | - sqlite3 | |
| 66 | - In toto |
| --- a/cvs2fossil.txt | |
| +++ b/cvs2fossil.txt | |
| @@ -1,66 +0,0 @@ | |
| 1 | |
| 2 | Known problems and areas to work on |
| 3 | =================================== |
| 4 | |
| 5 | * Not yet able to handle the specification of multiple projects |
| 6 | for one CVS repository. I.e. I can, for example, import all of |
| 7 | tcllib, or a single subproject of tcllib, like tklib, but not |
| 8 | multiple sub-projects in one go. |
| 9 | |
| 10 | * Consider to rework the breaker- and sort-passes so that they |
| 11 | do not need all changesets as objects in memory. |
| 12 | |
| 13 | Current memory consumption after all changesets are loaded: |
| 14 | |
| 15 | bwidget 6971627 6.6 |
| 16 | cvs-memchan 4634049 4.4 |
| 17 | cvs-sqlite 45674501 43.6 |
| 18 | cvs-trf 8781289 8.4 |
| 19 | faqs 2835116 2.7 |
| 20 | libtommath 4405066 4.2 |
| 21 | mclistbox 3350190 3.2 |
| 22 | newclock 5020460 4.8 |
| 23 | oocore 4064574 3.9 |
| 24 | sampleextension 4729932 4.5 |
| 25 | tclapps 8482135 8.1 |
| 26 | tclbench 4116887 3.9 |
| 27 | tcl_bignum 2545192 2.4 |
| 28 | tclconfig 4105042 3.9 |
| 29 | tcllib 31707688 30.2 |
| 30 | tcltutorial 3512048 3.3 |
| 31 | tcl 109926382 104.8 |
| 32 | thread 8953139 8.5 |
| 33 | tklib 13935220 13.3 |
| 34 | tk 66149870 63.1 |
| 35 | widget 2625609 2.5 |
| 36 | |
| 37 | * Look at the dependencies on external packages and consider |
| 38 | which of them can be moved into the importer, either as a |
| 39 | simple utility command, or wholesale. |
| 40 | |
| 41 | struct::list |
| 42 | assign, map, reverse, filter |
| 43 | |
| 44 | Very few and self-contained commands. |
| 45 | |
| 46 | struct::set |
| 47 | size, empty, contains, add, include, exclude, |
| 48 | intersect, subsetof |
| 49 | |
| 50 | Most of the core commands. |
| 51 | |
| 52 | fileutil |
| 53 | cat, appendToFile, writeFile, |
| 54 | tempfile, stripPath, test |
| 55 | |
| 56 | fileutil::traverse |
| 57 | In toto |
| 58 | |
| 59 | struct::graph |
| 60 | In toto |
| 61 | |
| 62 | snit |
| 63 | In toto |
| 64 | |
| 65 | sqlite3 |
| 66 | In toto |
| --- a/cvs2fossil.txt | |
| +++ b/cvs2fossil.txt | |
| @@ -1,66 +0,0 @@ | |
D
kktodo.wiki
-69
| --- a/kktodo.wiki | ||
| +++ b/kktodo.wiki | ||
| @@ -1,69 +0,0 @@ | ||
| 1 | -<h3>kkinnell</h3> | |
| 2 | - | |
| 3 | -.plan -- <i>Fossil, the DG</i> Bwahahahaha! The cover art could be an <i>homo erectus</i> skull lying on some COBOL code... | |
| 4 | - | |
| 5 | - 1. Command line interface reference docs | |
| 6 | - <ul> | |
| 7 | - <li> <font color="#bb4466">Finish initial pages.</font></li> | |
| 8 | - <li> Start on tech-spec (serious, not "chatty") reference pages.</li> | |
| 9 | - <li> Edit, edit, edit.</li> | |
| 10 | - </ul> | |
| 11 | - | |
| 12 | - 2. Support docs | |
| 13 | - <ul> | |
| 14 | - <li>Basic explanation of Distributed SCM.</i> | |
| 15 | - <li>Tutorial | |
| 16 | - <ul> | |
| 17 | - <li>Silly source. Start with existing dir struct.</li> | |
| 18 | - <li>Repository. Creatiing and populating.</li> | |
| 19 | - <li>Where? Local, Intranet, Internet.</li> | |
| 20 | - <li>Who? Project size defined by size of code base versus | |
| 21 | - number of developers. Size matters.</li> | |
| 22 | - <li>How? | |
| 23 | - <ul> | |
| 24 | - <li>Open, close, commit, checkout, update, merge.</li> | |
| 25 | - </ul> | |
| 26 | - </li> | |
| 27 | - <li>Hmmm. Experimenting.</li> | |
| 28 | - <ul> | |
| 29 | - <li>The road less travelled, or where'd that | |
| 30 | - fork come from?</li> | |
| 31 | - </ul> | |
| 32 | - <li>Oops! Going back in time.</li> | |
| 33 | - <ul> | |
| 34 | - <li>Versions</li> | |
| 35 | - <ul> | |
| 36 | - <li>What <i>is</i> a version?</li> | |
| 37 | - <li>Is it a "version" or a "tag"?</li> | |
| 38 | - <li>DSCM redux: Revisionist versioning.</li> | |
| 39 | - </ul> | |
| 40 | - </ul> | |
| 41 | - </ul> | |
| 42 | - </li> | |
| 43 | - <li>Basic explanation of <i>merge</i>. | |
| 44 | - <ol> | |
| 45 | - <li>Leaves, branches and baselines: We want a shrubbery!</li> | |
| 46 | - <li><i>update</i> merges vs. <i>merge</i> merges. | |
| 47 | - All merges are equal, but some are more equal than others.</li> | |
| 48 | - </ol> | |
| 49 | - </li> | |
| 50 | - </ul> | |
| 51 | - | |
| 52 | - 3. Configuration | |
| 53 | - | |
| 54 | - 42. General | |
| 55 | - <ul> | |
| 56 | - <li>Co-ordinate style and tone with drh, other devs. (documentation | |
| 57 | - standard? yuck.)</li> | |
| 58 | - </ul> | |
| 59 | - | |
| 60 | - * Tips & tricks. | |
| 61 | - | |
| 62 | - * <b>Fossil</b> and <b>Sqlite</b> | |
| 63 | - <ul> | |
| 64 | - <li>Get a word in for Mrinal Kant's | |
| 65 | - <a href="http://code.google.com/p/sqlite-manager/">SQLite Manager</a> | |
| 66 | - XUL app. Great tool.</li> | |
| 67 | - </ul> | |
| 68 | - | |
| 69 | - * Th (code groveling [and code groveling {and code groveling ... } ... ] ... ) |
| --- a/kktodo.wiki | |
| +++ b/kktodo.wiki | |
| @@ -1,69 +0,0 @@ | |
| 1 | <h3>kkinnell</h3> |
| 2 | |
| 3 | .plan -- <i>Fossil, the DG</i> Bwahahahaha! The cover art could be an <i>homo erectus</i> skull lying on some COBOL code... |
| 4 | |
| 5 | 1. Command line interface reference docs |
| 6 | <ul> |
| 7 | <li> <font color="#bb4466">Finish initial pages.</font></li> |
| 8 | <li> Start on tech-spec (serious, not "chatty") reference pages.</li> |
| 9 | <li> Edit, edit, edit.</li> |
| 10 | </ul> |
| 11 | |
| 12 | 2. Support docs |
| 13 | <ul> |
| 14 | <li>Basic explanation of Distributed SCM.</i> |
| 15 | <li>Tutorial |
| 16 | <ul> |
| 17 | <li>Silly source. Start with existing dir struct.</li> |
| 18 | <li>Repository. Creatiing and populating.</li> |
| 19 | <li>Where? Local, Intranet, Internet.</li> |
| 20 | <li>Who? Project size defined by size of code base versus |
| 21 | number of developers. Size matters.</li> |
| 22 | <li>How? |
| 23 | <ul> |
| 24 | <li>Open, close, commit, checkout, update, merge.</li> |
| 25 | </ul> |
| 26 | </li> |
| 27 | <li>Hmmm. Experimenting.</li> |
| 28 | <ul> |
| 29 | <li>The road less travelled, or where'd that |
| 30 | fork come from?</li> |
| 31 | </ul> |
| 32 | <li>Oops! Going back in time.</li> |
| 33 | <ul> |
| 34 | <li>Versions</li> |
| 35 | <ul> |
| 36 | <li>What <i>is</i> a version?</li> |
| 37 | <li>Is it a "version" or a "tag"?</li> |
| 38 | <li>DSCM redux: Revisionist versioning.</li> |
| 39 | </ul> |
| 40 | </ul> |
| 41 | </ul> |
| 42 | </li> |
| 43 | <li>Basic explanation of <i>merge</i>. |
| 44 | <ol> |
| 45 | <li>Leaves, branches and baselines: We want a shrubbery!</li> |
| 46 | <li><i>update</i> merges vs. <i>merge</i> merges. |
| 47 | All merges are equal, but some are more equal than others.</li> |
| 48 | </ol> |
| 49 | </li> |
| 50 | </ul> |
| 51 | |
| 52 | 3. Configuration |
| 53 | |
| 54 | 42. General |
| 55 | <ul> |
| 56 | <li>Co-ordinate style and tone with drh, other devs. (documentation |
| 57 | standard? yuck.)</li> |
| 58 | </ul> |
| 59 | |
| 60 | * Tips & tricks. |
| 61 | |
| 62 | * <b>Fossil</b> and <b>Sqlite</b> |
| 63 | <ul> |
| 64 | <li>Get a word in for Mrinal Kant's |
| 65 | <a href="http://code.google.com/p/sqlite-manager/">SQLite Manager</a> |
| 66 | XUL app. Great tool.</li> |
| 67 | </ul> |
| 68 | |
| 69 | * Th (code groveling [and code groveling {and code groveling ... } ... ] ... ) |
| --- a/kktodo.wiki | |
| +++ b/kktodo.wiki | |
| @@ -1,69 +0,0 @@ | |
D
rse-notes.txt
-198
| --- a/rse-notes.txt | ||
| +++ b/rse-notes.txt | ||
| @@ -1,198 +0,0 @@ | ||
| 1 | -From: "Ralf S. Engelschall" | |
| 2 | -Date: October 18, 2008 1:40:53 PM EDT | |
| 3 | -To: [email protected] | |
| 4 | -Subject: Some Fossil Feedback | |
| 5 | - | |
| 6 | -I've today looked at your Fossil project (latest version from your | |
| 7 | -repository). That's a _really_ interesting and very promising DVCS. | |
| 8 | -While I looked around and tested it, I stumbled over some issues I want | |
| 9 | -to share with you: | |
| 10 | - | |
| 11 | -o No tarball | |
| 12 | - | |
| 13 | - You currently still do not provide any tarballs of the Fossil sources. | |
| 14 | - Sure, you are still hacking wild on the code and one can on-the-fly | |
| 15 | - fetch a ZIP archive, but that's a manual process. For packagers (like | |
| 16 | - me in the OpenPKG project) this is very nasty and just means that | |
| 17 | - Fossil will usually still not be packaged. As a result it will be not | |
| 18 | - spreaded as much as possible and this way you still do not get as much | |
| 19 | - as possible feedback. Hence, I recommend that you let daily snapshot | |
| 20 | - tarballs (or ZIP files) be rolled. This would be great. | |
| 21 | - | |
| 22 | -o UUID | |
| 23 | - | |
| 24 | - Under http://www.fossil-scm.org/index.html/doc/tip/www/concepts.wiki | |
| 25 | - you describe the concepts and you clearly name the artifact ID a | |
| 26 | - "UUID" and even say that this is a "Universally Unique Identifier". | |
| 27 | - Unfortunately, a UUID is a 128-bit entity standardized by the ISO | |
| 28 | - (under ISO/IEC 11578:1996) and IETF (under RFC-4122) and hence it is | |
| 29 | - *VERY MUCH* confusing and unclean that your 160-bit SHA1-based ID is | |
| 30 | - called "UUID" in Fossil. | |
| 31 | - | |
| 32 | - I *STRONGLY* recommend you to either use real UUIDs (128-bit | |
| 33 | - entities, where a UUID of version 5 even is SHA1-based!) or you name | |
| 34 | - your 160-bit SHA1 entities differently (perhaps AID for "Artifact | |
| 35 | - Identifier"?). | |
| 36 | - | |
| 37 | -o "fossil cgi <script>" | |
| 38 | - | |
| 39 | - Currently we have only "fossil cgi <script>" where <script> contains | |
| 40 | - "repository: <file>". This is a neat idea and should be kept. But | |
| 41 | - this way one cannot easily host multiple repositories over this | |
| 42 | - CGI interface without creating such a script for every individual | |
| 43 | - repository. | |
| 44 | - | |
| 45 | - Perhaps a "fossil cgi --repository <file>" would help here, as this | |
| 46 | - way one can use a generic CGI script which first figures out the | |
| 47 | - name <name> of the individual project and then runs "fossil cgi | |
| 48 | - --repository /path/to/repositories/<name>.db". But perhaps I'm just | |
| 49 | - overlooking something and this is already possible... | |
| 50 | - | |
| 51 | -o "fossil db <operation>" | |
| 52 | - | |
| 53 | - In Monotone DVCS we have a "mtn db" command for the low-level SQLite | |
| 54 | - database manipulations. For instance a "mtn --db=<monotone-repository> | |
| 55 | - db dump" is more or less equal to a "sqlite3 <monotone-repository> | |
| 56 | - .dump". A "mtn --db=<monotone-repository> db exec '<SQL>'" is equal | |
| 57 | - "echo '<SQL>' | sqlite3 <monotone-repository>", etc. The point is | |
| 58 | - that the DVCS user usually has no SQLite CLI at hand but as the DVCS | |
| 59 | - already contains more or less the complete SQLite it is very useful to | |
| 60 | - also include the SQLite CLI functionality and wire it into the DVCS | |
| 61 | - CLI via a "db" command. | |
| 62 | - | |
| 63 | -o "fossil version" | |
| 64 | - | |
| 65 | - Mostly all VCS I know if either support a command "version" or a | |
| 66 | - command-line option "--version" or most of the time even both. Please | |
| 67 | - output the "This is fossil version [9e80dc66cf] 2008-10-18 13:03:36" | |
| 68 | - there (at least additionally) instead of at the end of "fossil help". | |
| 69 | - | |
| 70 | -o "--port" vs. "-port" | |
| 71 | - | |
| 72 | - In the "fossil help server" there is "--port" while under | |
| 73 | - http://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki there | |
| 74 | - is "-port". I personally like GNU-long-style options "--xxxx" more | |
| 75 | - than the CC-style options "-xxx". But anyway, independent which one is | |
| 76 | - correct (well, perhaps both even work) only one should be documented | |
| 77 | - to avoid confusion. | |
| 78 | - | |
| 79 | -o User creation on the CLI | |
| 80 | - | |
| 81 | - There is "fossil user new ?USERNAME?" which interactively prompts | |
| 82 | - for the capabilities and the password -- even from the TTY and not | |
| 83 | - from STDIN. One needs "fossil user new ?USERNAME? ?CAPABILITIES? | |
| 84 | - ?PASSWORD?" to be able to create a repository in batch without having | |
| 85 | - to hack the user into the "user" table via the SQLite CLI. Similar: | |
| 86 | - the "fossil user password USERNAME" should be actually "fossil user | |
| 87 | - password USERNAME ?PASSWORD?", please. | |
| 88 | - | |
| 89 | -o "-R <repository" | |
| 90 | - | |
| 91 | - There is the "-R" option for specifiying the repository. But it is | |
| 92 | - a sub-command option and not a global option. And on "fossil ui" or | |
| 93 | - "fossil server" it even is an argument and not an option. This is | |
| 94 | - confusing. Every time one has to figure out how to set the repository | |
| 95 | - on the CLI. Monotone simply uses a *global* option "--db" and that's | |
| 96 | - it. So, I recommend that Fossil also uses a single global option | |
| 97 | - "--repository"/"-R" instead of a command-specific option. Sure, not | |
| 98 | - all commands might require a repository, but IMHO it is better to | |
| 99 | - ignore the global option there than having to figure out every time | |
| 100 | - how the repository has to be specified. | |
| 101 | - | |
| 102 | -o Setup pages | |
| 103 | - | |
| 104 | - When hitting "Apply changes" on any setup page, one keeps staying on | |
| 105 | - this page. Sure, that's what an "apply" button usually is about. But | |
| 106 | - I at least would have liked to see a button (either instead of the | |
| 107 | - "apply changes" or at least in addition) which applies the changes and | |
| 108 | - goes back to the setup main page (from where one usually come). | |
| 109 | - | |
| 110 | -o _FOSSIL_ | |
| 111 | - | |
| 112 | - Very nice idea to use another SQLite database for the _FOSSIL_ | |
| 113 | - control file. BUT: Why "_FOSSIL_"? CVS's "CVS" directory was ugly for | |
| 114 | - decades. Today we have ".svn", ".git", ".hg" and "_MTN"/".mtn" to get | |
| 115 | - rid of those ugly control files or directories of the DVCS! Sure, | |
| 116 | - dot-files are disliked by Windows people. But that's no problem, one | |
| 117 | - can accept "_XXX" in addition to ".XXX" easily, of course. | |
| 118 | - | |
| 119 | - So, I really would like to see the file "_FOSSIL_" to be renamed | |
| 120 | - to ".fossil" under Unix and "_fossil" under Windows or (if the | |
| 121 | - upper-case is important to you) ".FOSSIL" and "_FOSSIL". But to see | |
| 122 | - an ugly "_FOSSIL_" at the top of every source tree is really rather | |
| 123 | - boring for Unix people! | |
| 124 | - | |
| 125 | -o "fossil open", "fossil checkout", "fossil update". | |
| 126 | - | |
| 127 | - I'm personally confused that "fossil open" is what "checkout" does in | |
| 128 | - other DVCS and that "checkout" is just a variant of "update". Hmmm... | |
| 129 | - for me it looks at least one should be eleminated to reduce confusion. | |
| 130 | - The difference between checkout and update could become an option of | |
| 131 | - a single option. And the remaining to perhaps better should be either | |
| 132 | - "open" + "update" or "checkout" + "update". Well, perhaps I'm still | |
| 133 | - not understanding Fossil enough. But I can only tell that I got rather | |
| 134 | - confused. | |
| 135 | - | |
| 136 | -o "fossil commit" | |
| 137 | - | |
| 138 | - There is "fossil commit" but no short-hand "fossil ci". But there | |
| 139 | - is "fossil status" and even just "fossil st" which clearly shows | |
| 140 | - that Fossil allows abbreviations or at least prefix-matching on the | |
| 141 | - commands. Sure, "ci" is not a prefix of "commit" but mostly all VCS | |
| 142 | - support the good old RCS/CVS "ci" and similar aliases. So I recommend | |
| 143 | - that Fossil does not only alias matching, but also provides aliases: | |
| 144 | - "ci" for "commit", "co" for "checkout", "log" for "timeline", etc. | |
| 145 | - Sorry, having to type the long "fossil commit" every time is too long | |
| 146 | - for us Unix hackers ;-) | |
| 147 | - | |
| 148 | - Additionally, Fossil seems to use GnuPG when installed and --nosign is | |
| 149 | - not specified. Hmm... two questions arise here for me: 1. should the | |
| 150 | - use of a cryptographically strong signature really be just _optional_ | |
| 151 | - (Monotone for instance RSA signs every commit) and 2. is GnuPG here | |
| 152 | - really the right tool (Monotone does a plain RSA signing and is even | |
| 153 | - able to leverage a running SSH agent for the operation -- something | |
| 154 | - which is very cool both under Unix with "ssh-agent" and under Windows | |
| 155 | - with "pagent"). OTOH, GnuPG 2.x supports a gpg-agent, so this might be | |
| 156 | - no longer a big issue. But Fossil should document this a little bit | |
| 157 | - futher: how to create the necessary GnuPG key, how to setup gpg-agent, | |
| 158 | - etc. | |
| 159 | - | |
| 160 | -o "fossil diff" | |
| 161 | - | |
| 162 | - There is "Usage: fossil diff|gdiff ?-i? ?-r REVISION? FILE...". Two | |
| 163 | - questions arise: Why do I have to specify a "FILE"? I would expect | |
| 164 | - that a simple "fossil diff" recursively shows a "diff" of all changed | |
| 165 | - files in the source tree. Additionally, how does one do a diff between | |
| 166 | - two particular revisions (one seems to be not able to specifiy "-r" | |
| 167 | - twice). | |
| 168 | - | |
| 169 | -o "manifest" / "manifest.uuid" | |
| 170 | - | |
| 171 | - Above I was already bothered by the _FOSSIL_ file, but now that I | |
| 172 | - played with Fossil I see that "manifest" and "manifest.uuid" files | |
| 173 | - showed up in my source tree. Why is this not implicitly in the | |
| 174 | - database and instead externally represented in the source tree. | |
| 175 | - Hmmm... then I recommend that you use a .fossil *DIRECTORY*, place | |
| 176 | - the control file into .fossil/control (or whatever) and the manifest | |
| 177 | - stuff into .fossil/manifest and .fossil/manifest.uuid. But please do | |
| 178 | - not clutter the top-level of the source three with control data of the | |
| 179 | - DVCS. | |
| 180 | - | |
| 181 | -o "fossil mv" | |
| 182 | - | |
| 183 | - There is "fossil add" and "fossil rm", but no "fossil mv". Hopefully | |
| 184 | - this doesn't mean a file move is an "add" and a "remove" bundle, as | |
| 185 | - this way Fossil would have trouble to know that the file was renamed | |
| 186 | - and hence the full history tracking of a file seems to be broken. | |
| 187 | - | |
| 188 | -o "fossil changes" vs. "fossil status" | |
| 189 | - | |
| 190 | - Finally, I got confused by the "fossil changes" and "fossil status" | |
| 191 | - commands. "fossil status" seems to be a super-set of "fossil changes". | |
| 192 | - Looks a little bit less orthogonal than necessary. I would remove | |
| 193 | - "fossil changes" or at least do not show the file details on "fossil | |
| 194 | - status". | |
| 195 | - | |
| 196 | -Yours, | |
| 197 | - Ralf S. Engelschall | |
| 198 | - |
| --- a/rse-notes.txt | |
| +++ b/rse-notes.txt | |
| @@ -1,198 +0,0 @@ | |
| 1 | From: "Ralf S. Engelschall" |
| 2 | Date: October 18, 2008 1:40:53 PM EDT |
| 3 | To: [email protected] |
| 4 | Subject: Some Fossil Feedback |
| 5 | |
| 6 | I've today looked at your Fossil project (latest version from your |
| 7 | repository). That's a _really_ interesting and very promising DVCS. |
| 8 | While I looked around and tested it, I stumbled over some issues I want |
| 9 | to share with you: |
| 10 | |
| 11 | o No tarball |
| 12 | |
| 13 | You currently still do not provide any tarballs of the Fossil sources. |
| 14 | Sure, you are still hacking wild on the code and one can on-the-fly |
| 15 | fetch a ZIP archive, but that's a manual process. For packagers (like |
| 16 | me in the OpenPKG project) this is very nasty and just means that |
| 17 | Fossil will usually still not be packaged. As a result it will be not |
| 18 | spreaded as much as possible and this way you still do not get as much |
| 19 | as possible feedback. Hence, I recommend that you let daily snapshot |
| 20 | tarballs (or ZIP files) be rolled. This would be great. |
| 21 | |
| 22 | o UUID |
| 23 | |
| 24 | Under http://www.fossil-scm.org/index.html/doc/tip/www/concepts.wiki |
| 25 | you describe the concepts and you clearly name the artifact ID a |
| 26 | "UUID" and even say that this is a "Universally Unique Identifier". |
| 27 | Unfortunately, a UUID is a 128-bit entity standardized by the ISO |
| 28 | (under ISO/IEC 11578:1996) and IETF (under RFC-4122) and hence it is |
| 29 | *VERY MUCH* confusing and unclean that your 160-bit SHA1-based ID is |
| 30 | called "UUID" in Fossil. |
| 31 | |
| 32 | I *STRONGLY* recommend you to either use real UUIDs (128-bit |
| 33 | entities, where a UUID of version 5 even is SHA1-based!) or you name |
| 34 | your 160-bit SHA1 entities differently (perhaps AID for "Artifact |
| 35 | Identifier"?). |
| 36 | |
| 37 | o "fossil cgi <script>" |
| 38 | |
| 39 | Currently we have only "fossil cgi <script>" where <script> contains |
| 40 | "repository: <file>". This is a neat idea and should be kept. But |
| 41 | this way one cannot easily host multiple repositories over this |
| 42 | CGI interface without creating such a script for every individual |
| 43 | repository. |
| 44 | |
| 45 | Perhaps a "fossil cgi --repository <file>" would help here, as this |
| 46 | way one can use a generic CGI script which first figures out the |
| 47 | name <name> of the individual project and then runs "fossil cgi |
| 48 | --repository /path/to/repositories/<name>.db". But perhaps I'm just |
| 49 | overlooking something and this is already possible... |
| 50 | |
| 51 | o "fossil db <operation>" |
| 52 | |
| 53 | In Monotone DVCS we have a "mtn db" command for the low-level SQLite |
| 54 | database manipulations. For instance a "mtn --db=<monotone-repository> |
| 55 | db dump" is more or less equal to a "sqlite3 <monotone-repository> |
| 56 | .dump". A "mtn --db=<monotone-repository> db exec '<SQL>'" is equal |
| 57 | "echo '<SQL>' | sqlite3 <monotone-repository>", etc. The point is |
| 58 | that the DVCS user usually has no SQLite CLI at hand but as the DVCS |
| 59 | already contains more or less the complete SQLite it is very useful to |
| 60 | also include the SQLite CLI functionality and wire it into the DVCS |
| 61 | CLI via a "db" command. |
| 62 | |
| 63 | o "fossil version" |
| 64 | |
| 65 | Mostly all VCS I know if either support a command "version" or a |
| 66 | command-line option "--version" or most of the time even both. Please |
| 67 | output the "This is fossil version [9e80dc66cf] 2008-10-18 13:03:36" |
| 68 | there (at least additionally) instead of at the end of "fossil help". |
| 69 | |
| 70 | o "--port" vs. "-port" |
| 71 | |
| 72 | In the "fossil help server" there is "--port" while under |
| 73 | http://www.fossil-scm.org/index.html/doc/tip/www/quickstart.wiki there |
| 74 | is "-port". I personally like GNU-long-style options "--xxxx" more |
| 75 | than the CC-style options "-xxx". But anyway, independent which one is |
| 76 | correct (well, perhaps both even work) only one should be documented |
| 77 | to avoid confusion. |
| 78 | |
| 79 | o User creation on the CLI |
| 80 | |
| 81 | There is "fossil user new ?USERNAME?" which interactively prompts |
| 82 | for the capabilities and the password -- even from the TTY and not |
| 83 | from STDIN. One needs "fossil user new ?USERNAME? ?CAPABILITIES? |
| 84 | ?PASSWORD?" to be able to create a repository in batch without having |
| 85 | to hack the user into the "user" table via the SQLite CLI. Similar: |
| 86 | the "fossil user password USERNAME" should be actually "fossil user |
| 87 | password USERNAME ?PASSWORD?", please. |
| 88 | |
| 89 | o "-R <repository" |
| 90 | |
| 91 | There is the "-R" option for specifiying the repository. But it is |
| 92 | a sub-command option and not a global option. And on "fossil ui" or |
| 93 | "fossil server" it even is an argument and not an option. This is |
| 94 | confusing. Every time one has to figure out how to set the repository |
| 95 | on the CLI. Monotone simply uses a *global* option "--db" and that's |
| 96 | it. So, I recommend that Fossil also uses a single global option |
| 97 | "--repository"/"-R" instead of a command-specific option. Sure, not |
| 98 | all commands might require a repository, but IMHO it is better to |
| 99 | ignore the global option there than having to figure out every time |
| 100 | how the repository has to be specified. |
| 101 | |
| 102 | o Setup pages |
| 103 | |
| 104 | When hitting "Apply changes" on any setup page, one keeps staying on |
| 105 | this page. Sure, that's what an "apply" button usually is about. But |
| 106 | I at least would have liked to see a button (either instead of the |
| 107 | "apply changes" or at least in addition) which applies the changes and |
| 108 | goes back to the setup main page (from where one usually come). |
| 109 | |
| 110 | o _FOSSIL_ |
| 111 | |
| 112 | Very nice idea to use another SQLite database for the _FOSSIL_ |
| 113 | control file. BUT: Why "_FOSSIL_"? CVS's "CVS" directory was ugly for |
| 114 | decades. Today we have ".svn", ".git", ".hg" and "_MTN"/".mtn" to get |
| 115 | rid of those ugly control files or directories of the DVCS! Sure, |
| 116 | dot-files are disliked by Windows people. But that's no problem, one |
| 117 | can accept "_XXX" in addition to ".XXX" easily, of course. |
| 118 | |
| 119 | So, I really would like to see the file "_FOSSIL_" to be renamed |
| 120 | to ".fossil" under Unix and "_fossil" under Windows or (if the |
| 121 | upper-case is important to you) ".FOSSIL" and "_FOSSIL". But to see |
| 122 | an ugly "_FOSSIL_" at the top of every source tree is really rather |
| 123 | boring for Unix people! |
| 124 | |
| 125 | o "fossil open", "fossil checkout", "fossil update". |
| 126 | |
| 127 | I'm personally confused that "fossil open" is what "checkout" does in |
| 128 | other DVCS and that "checkout" is just a variant of "update". Hmmm... |
| 129 | for me it looks at least one should be eleminated to reduce confusion. |
| 130 | The difference between checkout and update could become an option of |
| 131 | a single option. And the remaining to perhaps better should be either |
| 132 | "open" + "update" or "checkout" + "update". Well, perhaps I'm still |
| 133 | not understanding Fossil enough. But I can only tell that I got rather |
| 134 | confused. |
| 135 | |
| 136 | o "fossil commit" |
| 137 | |
| 138 | There is "fossil commit" but no short-hand "fossil ci". But there |
| 139 | is "fossil status" and even just "fossil st" which clearly shows |
| 140 | that Fossil allows abbreviations or at least prefix-matching on the |
| 141 | commands. Sure, "ci" is not a prefix of "commit" but mostly all VCS |
| 142 | support the good old RCS/CVS "ci" and similar aliases. So I recommend |
| 143 | that Fossil does not only alias matching, but also provides aliases: |
| 144 | "ci" for "commit", "co" for "checkout", "log" for "timeline", etc. |
| 145 | Sorry, having to type the long "fossil commit" every time is too long |
| 146 | for us Unix hackers ;-) |
| 147 | |
| 148 | Additionally, Fossil seems to use GnuPG when installed and --nosign is |
| 149 | not specified. Hmm... two questions arise here for me: 1. should the |
| 150 | use of a cryptographically strong signature really be just _optional_ |
| 151 | (Monotone for instance RSA signs every commit) and 2. is GnuPG here |
| 152 | really the right tool (Monotone does a plain RSA signing and is even |
| 153 | able to leverage a running SSH agent for the operation -- something |
| 154 | which is very cool both under Unix with "ssh-agent" and under Windows |
| 155 | with "pagent"). OTOH, GnuPG 2.x supports a gpg-agent, so this might be |
| 156 | no longer a big issue. But Fossil should document this a little bit |
| 157 | futher: how to create the necessary GnuPG key, how to setup gpg-agent, |
| 158 | etc. |
| 159 | |
| 160 | o "fossil diff" |
| 161 | |
| 162 | There is "Usage: fossil diff|gdiff ?-i? ?-r REVISION? FILE...". Two |
| 163 | questions arise: Why do I have to specify a "FILE"? I would expect |
| 164 | that a simple "fossil diff" recursively shows a "diff" of all changed |
| 165 | files in the source tree. Additionally, how does one do a diff between |
| 166 | two particular revisions (one seems to be not able to specifiy "-r" |
| 167 | twice). |
| 168 | |
| 169 | o "manifest" / "manifest.uuid" |
| 170 | |
| 171 | Above I was already bothered by the _FOSSIL_ file, but now that I |
| 172 | played with Fossil I see that "manifest" and "manifest.uuid" files |
| 173 | showed up in my source tree. Why is this not implicitly in the |
| 174 | database and instead externally represented in the source tree. |
| 175 | Hmmm... then I recommend that you use a .fossil *DIRECTORY*, place |
| 176 | the control file into .fossil/control (or whatever) and the manifest |
| 177 | stuff into .fossil/manifest and .fossil/manifest.uuid. But please do |
| 178 | not clutter the top-level of the source three with control data of the |
| 179 | DVCS. |
| 180 | |
| 181 | o "fossil mv" |
| 182 | |
| 183 | There is "fossil add" and "fossil rm", but no "fossil mv". Hopefully |
| 184 | this doesn't mean a file move is an "add" and a "remove" bundle, as |
| 185 | this way Fossil would have trouble to know that the file was renamed |
| 186 | and hence the full history tracking of a file seems to be broken. |
| 187 | |
| 188 | o "fossil changes" vs. "fossil status" |
| 189 | |
| 190 | Finally, I got confused by the "fossil changes" and "fossil status" |
| 191 | commands. "fossil status" seems to be a super-set of "fossil changes". |
| 192 | Looks a little bit less orthogonal than necessary. I would remove |
| 193 | "fossil changes" or at least do not show the file details on "fossil |
| 194 | status". |
| 195 | |
| 196 | Yours, |
| 197 | Ralf S. Engelschall |
| 198 |
| --- a/rse-notes.txt | |
| +++ b/rse-notes.txt | |
| @@ -1,198 +0,0 @@ | |