On 2012-07-30 10:41, Natacha Porté wrote:
Hello,
I don't want to look impatient, and I personally hate to be
constantly
reminded about something that hasn't actually left my mind, so I'm a
bit
reluctant to send e-mails like this one. All my apologies if I'm
doing
it wrong.
So my point is only to remind you all that I'm still committed to
make
the fossil-in-markdown thing going forward, and I'm eagerly waiting
any
instructions on what to do about it next.
Currently the code is in a new branch off a clone of the official
fossil
repository, available at
http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown
There is also a live demo (dedicated repository served using a fossil
compiled off this branch) at
http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd
What is done:
+ complete and seamless integration of the markdown engine into
fossil
(e.g. using fossil blobs as dynamic buffers),
+ support of markdown embedded documentation (.markdown and .mkd
extensions), using current fossil style,
+ regular merge of latest changes from trunk.
What remains to do:
+ review my code to ensure it meets fossil level of quality,
+ format it using fossil code style if needed,
+ any other code change that comes up during the review.
I'm still willing to perform any maintenance needed on the markdown
library code and/or the glue between it and fossil, for as long as I
can. I would also gladly handle any knowledge-transfer needed to
prevent
myself from being a single point of failure in the maintenance of
that
code.
Thanks for your interest,
Natacha Porté
Are we going to move all the wikipages to markdown? I converted the
attached file to markdown it wasn't to difficult with
bit of sed, awk and pandoc.
What do you see as an advantage of markdown compared to the current
wiki syntax?
--
Rene
add
---
The often used `add` command is how you tell **fossil** to include a
(usually new) file in the repository.
**fossil** is designed to manage artifacts whose role is being "source"
for something, most probably software program code or other text. One
can imagine all kinds of ways to let fossil know just what constitutes a
source; the simplest and most direct way it *actually* finds out is when
you give it the ` fossil add path ` command.
It's reasonable to think of the [`import`](./cmd_import.wiki) and
[`clone`](./cmd_clone.wiki) commands as very high-powered versions of
the `add` command that are combined with system level file movement and
networking functions. Not particularly accurate, but reasonable.
Typing `fossil add myfile` causes fossil to put *myfile* into the
repository at the next `commit`provided you issue it from within the
source tree, of course.
By contrast, `fossil add mydirectory` will add ***all*** of the files in
*mydirectory*, and all of its sub-directories. In other words, adding a
directory will recursively add all of the directory's file system
descendants to the repository. This was an oft-requested feature,
recently implemented. It is very flexible. Only when you add a directory
do you get the recursive behavior. If you are globbing a subset of
files, you won't get the recursion.
Realize that the repository is not changed by the `add` command, but by
the `commit` command. `add` *myfile* tells **fossil** to "mark" *myfile*
as part of the repository. Only commands which actually manipulate the
content of the repository can physically put source artifacts into (or
remove them from) the repository.
Just to keep things symmetric, there are also commands that can
manipulate the repository without affecting the checked-out sources (see
[fossil pull](./cmd_pull.wiki), for instance.)
It's worthwhile reiterating that **fossil** is storing the content of
source artifacts and the names of the artifacts in their "native
habitat", a sequence of "temporal slices" (aka "versions") of the state
of the whole system, and a set of unique identifiers. When you add a
file to a repository, the *path* to the file is a part of the *name* of
the file. There is a mis-match between the file system's idea of a
directory (a file containing pointers to files) and fossil's idea (a
substring of the name of the artifact.) The names of the artifacts
specify their relative locations because of the way the file system
interprets them. If you don't keep this in mind, you may fool yourself
into thinking **fossil** somehow "stores directories." It doesn't, and
believing it does will eventually confuse you.
See also: [fossil rm](./cmd_rm.wiki), [fossil
import](./cmd_import.wiki), [fossil clone](./cmd_clone.wiki), [fossil
commit](./cmd_commit.wiki), [fossil pull](./cmd_pull.wiki), [fossil
setting](./cmd_settings.wiki) (async), [Reference](./reference.wiki)
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
