Fossil

Check-in [007c32bdfd]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Documented the 'l' F-card permission and added a minor clarification regarding F-card UUID values for removed files.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 007c32bdfd677111a55f4a54299f5014d4a27f90
User & Date: stephan 2014-02-24 18:38:48.100
Context
2014-02-26
08:58
Cherry-pick [http://www.sqlite.org/src/info/4043d87979|4043d87979], [http://www.sqlite.org/src/info/953cdd6ada|953cdd6ada] and [http://www.sqlite.org/src/info/23001a85cd|23001a85cd]: Ensure that _FILE_OFFSET_BITS and related macros are defined before any #include, for QNX. Meant for testing this change in SQLite in combination with the mingw4x fixes: [http://www.sqlite.org/src/timeline?r=mingw4x] check-in: 782c3bd265 user: jan.nijtmans tags: trunk
2014-02-25
13:31
Follow-up to [8ab08d32c7]: Fossil still doesn't handle the extended path prefix on win32 ('\\?\') right, mainly in checking paths. e.g.: "fossil add //\?/C:/Localdata/workspace/fossil/foo.c". Fossil cannot know that this path is correct. Solution: Strip the extended path prefix in file_simplify_name(), and only add it back when needed. Latest "winhttp.c" changes could be reverted with this change when compiling with MSVC or MinGW-w64 (as the repository path after simplicifation doesn't contain '?' any more), but when using MinGW the command-line handling cannot be thrusted. check-in: ce4afc891c user: jan.nijtmans tags: extended-path-prefix
2014-02-24
18:38
Documented the 'l' F-card permission and added a minor clarification regarding F-card UUID values for removed files. check-in: 007c32bdfd user: stephan tags: trunk
10:56
Speedup "fossil extras" and other commands which traverse the local filesystem. See: [http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg14697.html]. Thanks to Samuel Debionne for the suggestion. check-in: 3fbdaa243d user: jan.nijtmans tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/fileformat.wiki.
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

155
156
157

158
159
160
161
162
163
164
165
166
167
168
169
170

<blockquote>
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br>
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i>
</blockquote>

A manifest has zero or more F-cards.  Each F-card identifies a file
that is part of the check-in.  There are one, two, three, or four arguments.
The first argument
is the pathname of the file in the check-in relative to the root
of the project file hierarchy.  No ".." or "." directories are allowed
within the filename.  Space characters are escaped as in C-card
comment text.  Backslash characters and newlines are not allowed
within filenames.  The directory separator character is a forward
slash (ASCII 0x2F).  The second argument to the F-card is the
full 40-character lower-case hexadecimal SHA1 hash of the content
artifact.  The second argument is required for baseline manifests
but is optional for delta manifests.  When the second argument to the
F-card is omitted, it means that the file has been deleted relative

to the baseline.  The optional 3rd argument defines any special access 
permissions associated with the file.  The only special code currently
defined is "x" which means that the file is executable.  All files are

always readable and writable.  This can be expressed by "w" permission
if desired but is optional.  The file format might be extended with
new permission letters in the future.
The optional 4th argument is the name of the same file as it existed in
the parent check-in.  If the name of the file is unchanged from its
parent, then the 4th argument is omitted.

A manifest has zero or one N-cards.  The N-card specifies the mimetype for the
text in the comment of the C-card.  If the N-card is omitted, a default mimetype
is used.

A manifest has zero or one P-cards.  Most manifests have one P-card.
The P-card has a varying number of arguments that







|
<
|
|
|
|
|
|
|
|
|
|
>
|
|
|
>
|
|
<
|
|
|







136
137
138
139
140
141
142
143

144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160

161
162
163
164
165
166
167
168
169
170

<blockquote>
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br>
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i>
</blockquote>

A manifest has zero or more F-cards.  Each F-card identifies a file
that is part of the check-in.  There are one, two, three, or four

arguments.  The first argument is the pathname of the file in the
check-in relative to the root of the project file hierarchy.  No ".."
or "." directories are allowed within the filename.  Space characters
are escaped as in C-card comment text.  Backslash characters and
newlines are not allowed within filenames.  The directory separator
character is a forward slash (ASCII 0x2F).  The second argument to the
F-card is the full 40-character lower-case hexadecimal SHA1 hash of
the content artifact.  The second argument is required for baseline
manifests but is optional for delta manifests.  When the second
argument to the F-card is omitted, it means that the file has been
deleted relative to the baseline (files removed in baseline manifests
versions are <em>not</em> added as F-cards). The optional 3rd argument
defines any special access permissions associated with the file.  This
can be defined as "x" to mean that the file is executable or "l"
(small letter ell) to mean a symlink.  All files are always readable
and writable.  This can be expressed by "w" permission if desired but
is optional.  The file format might be extended with new permission

letters in the future.  The optional 4th argument is the name of the
same file as it existed in the parent check-in.  If the name of the
file is unchanged from its parent, then the 4th argument is omitted.

A manifest has zero or one N-cards.  The N-card specifies the mimetype for the
text in the comment of the C-card.  If the N-card is omitted, a default mimetype
is used.

A manifest has zero or one P-cards.  Most manifests have one P-card.
The P-card has a varying number of arguments that