Fossil SCM

Remove control characters from rse-notes.txt.

drh 2008-10-24 14:03 trunk
Commit 9a482dd7011db01220b6889573f6646ead5db593
Parent e8c4f69c50ecbe4…
1 file changed +138 -138
~ rse-notes.txt
M rse-notes.txt
+138 -138
--- rse-notes.txt
+++ rse-notes.txt
@@ -8,191 +8,191 @@
88
 While I looked around and tested it, I stumbled over some issues I want
99
 to share with you:
1010
1111
 o No tarball
1212
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.
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.
2121
2222
 o UUID
2323
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"?).
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"?).
3636
3737
 o "fossil cgi <script>"
3838
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...
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...
5050
5151
 o "fossil db <operation>"
5252
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.
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.
6262
6363
 o "fossil version"
6464
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".
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".
6969
7070
 o "--port" vs. "-port"
7171
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.
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.
7878
7979
 o User creation on the CLI
8080
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.
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.
8888
8989
 o "-R <repository"
9090
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.
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.
101101
102102
 o Setup pages
103103
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).
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).
109109
110110
 o _FOSSIL_
111111
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!
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!
124124
125125
 o "fossil open", "fossil checkout", "fossil update".
126126
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.
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.
135135
136136
 o "fossil commit"
137137
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.
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.
159159
160160
 o "fossil diff"
161161
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).
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).
168168
169169
 o "manifest" / "manifest.uuid"
170170
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.
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.
180180
181181
 o "fossil mv"
182182
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.
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.
187187
188188
 o "fossil changes" vs. "fossil status"
189189
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".
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".
195195
196196
 Yours,
197
-                                      Ralf S. Engelschall
197
+ Ralf S. Engelschall
198198
199199
--- rse-notes.txt
+++ rse-notes.txt
@@ -8,191 +8,191 @@
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
199
--- rse-notes.txt
+++ rse-notes.txt
@@ -8,191 +8,191 @@
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
199

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button