Merge branch 'master' of git://github.com/joeyh/ikiwiki

19 files changed, 158 insertions, 24 deletions

diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
index 5e842ca7f..ad0f506f2 100644
--- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
+++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn
@@ -66,8 +66,6 @@ Patch:
 
 >>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]]
 
-[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]]
-
 > [[merged|done]] --[[Joey]] 
 
 Patch:
diff --git a/doc/git.mdwn b/doc/git.mdwn
index 008f109df..16af30584 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -49,6 +49,7 @@ into [[Joey]]'s working tree. This is recommended. :-)
 * [[chrysn]] `git://github.com/github076986099/ikiwiki.git`
 * [[simonraven]] `git://github.com/kjikaqawej/ikiwiki-simon.git`
 * [[schmonz]] `git://github.com/schmonz/ikiwiki.git`
+* [[will]] `http://www.cse.unsw.edu.au/~willu/ikiwiki.git`
 
 ## branches
 
diff --git a/doc/news/version_3.1415926.mdwn b/doc/news/version_3.1415926.mdwn
index c914c83cd..d31812c8e 100644
--- a/doc/news/version_3.1415926.mdwn
+++ b/doc/news/version_3.1415926.mdwn
@@ -50,4 +50,4 @@ ikiwiki 3.1415926 released with [[!toggle text="these changes"]]
      larger in either dimension.
  * [ Josh Triplett ]
    * teximg: Replace the insufficient blacklist with the built-in security
-     mechanisms of TeX."""]]
\ No newline at end of file
+     mechanisms of TeX. ([[!cve CVE-2009-2944]])"""]]
diff --git a/doc/plugins/contrib/cvs/discussion.mdwn b/doc/plugins/contrib/cvs/discussion.mdwn
index e142452d0..b5f03ac6f 100644
--- a/doc/plugins/contrib/cvs/discussion.mdwn
+++ b/doc/plugins/contrib/cvs/discussion.mdwn
@@ -93,3 +93,32 @@ the "cvs add <directory>" call and avoid doing anything in that case?
 >>> if a configured post-commit hook is missing, and it seems fine,
 >>> probably also thanks to IPC::Cmd.
 >>> --[[schmonz]]
+
+----
+
+
+Further review.. --[[Joey]] 
+
+I don't understand what `cvs_shquote_commit` is
+trying to do with the test message, but it seems
+highly likely to be insecure; I never trust anything 
+that relies on safely quoting user input passed to the shell. 
+
+(As an aside, `shell_quote` can die on certian inputs.)
+
+Seems to me that, if `IPC::Cmd` exposes input to the shell
+(which I have not verified but its docs don't specify; a bad sign)
+you chose the wrong tool and ended up doing down the wrong
+route, dragging in shell quoting problems and fixes. Since you
+chose to use `IPC::Cmd`	just because you wanted to shut
+up CVS stderr, my suggestion would be to use plain `system`
+to run the command, with stderr temporarily sent to /dev/null:
+
+	open(my $savederr, ">&STDERR");
+	open(STDERR, ">", "/dev/null");
+	my $ret=system("cvs", "-Q", @_);
+	open(STDERR, ">$savederr");
+
+`cvs_runcvs` should not take an array reference. It's
+usual for this type of function to take a list of parameters
+to pass to the command.
diff --git a/doc/plugins/contrib/mailbox/discussion.mdwn b/doc/plugins/contrib/mailbox/discussion.mdwn
index 00fb0c05f..9520fdd70 100644
--- a/doc/plugins/contrib/mailbox/discussion.mdwn
+++ b/doc/plugins/contrib/mailbox/discussion.mdwn
@@ -3,3 +3,6 @@
 For some reason, `git fetch` from http://pivot.cs.unb.ca/git/ikimailbox.git/ didn't work very smoothly for me: it hung, and I had to restart it 3 times before the download was complete.
 
 I'm writing this just to let you know that there might be some problems with such connections to your http-server. --Ivan Z.
+> I can't replicate this (two months later!)
+> I can suggest trying the git:// url for download if you can.
+> Also, if you really want to get my attention, send me email   [[DavidBremner]]
diff --git a/doc/plugins/mdwn.mdwn b/doc/plugins/mdwn.mdwn
index 6ad1fb229..ce1b6097a 100644
--- a/doc/plugins/mdwn.mdwn
+++ b/doc/plugins/mdwn.mdwn
@@ -12,9 +12,9 @@ this plugin. The [original version of
 markdown](http://daringfireball.net/projects/markdown/) can be used, or the
 [[!cpan Text::Markdown]] perl module.
 
-[[!cpan Text::Markdown]] also includes a markdown variant called
-[multimarkdown](http://fletcherpenney.net/MultiMarkdown/), which supports
-tables, footnotes, and other new features. Multimarkdown is not enabled by
-default, but can be turned on via the `multimarkdown` option in the setup
-file. Note that multimarkdown's metadata and wikilinks features are
-disabled when it's used with ikiwiki.
+[[!cpan Text::MultiMarkdown]] can be used in order to use tables, footnotes,
+and other new features from the markdown variant called
+[multimarkdown](http://fletcherpenney.net/MultiMarkdown/). Multimarkdown is
+not enabled by default, but can be turned on via the `multimarkdown` option
+in the setup file. Note that multimarkdown's metadata and wikilinks
+features are disabled when it's used with ikiwiki.
diff --git a/doc/sandbox/test2.mdwn b/doc/sandbox/test2.mdwn
new file mode 100644
index 000000000..3e50e68f3
--- /dev/null
+++ b/doc/sandbox/test2.mdwn
@@ -0,0 +1 @@
+this is test two, being pushed by [[tips/untrusted_git_push]].
diff --git a/doc/security.mdwn b/doc/security.mdwn
index 200ae29e2..3924186c2 100644
--- a/doc/security.mdwn
+++ b/doc/security.mdwn
@@ -426,4 +426,4 @@ bypassed and used to read arbitrary files. This was fixed by
 enabling TeX configuration options that disallow unsafe TeX commands.
 The fix was released on 30 Aug 2009 in version 3.1415926, and was
 backported to stable in version 2.53.4. If you use the teximg plugin,
-I recommend upgrading.
+I recommend upgrading. ([[!cve CVE-2009-2944]])
diff --git a/doc/tips/ikiwiki_as_a_requirements_management_tool.mdwn b/doc/tips/ikiwiki_as_a_requirements_management_tool.mdwn
new file mode 100644
index 000000000..6bef2619e
--- /dev/null
+++ b/doc/tips/ikiwiki_as_a_requirements_management_tool.mdwn
@@ -0,0 +1,95 @@
+[[!template id=note text="**Table of contents** [[!toc ]]"]]
+
+Introduction
+------------
+At work textual requirements and traceability are daily use terms, often used as contracts with clients or among stakeholders, but at the moment the only way we specify requirements is via a word processor, and traceability is managed manually (ouch!) unless we use a commercial UML (Unified Modeling Language) tool that handles office files, an also allows traceability from design, code and test artifacts. But functionality of that tool is less than basic for requirements.
+
+We are considering the use of a specific requirements management tool, but the problem and something that gets me really frustrated is the extremely expensive price of the licenses of the "de facto" commercial tools we should use. One floating license for both tools (requirements management and modeling) can go beyond $20,000. Of course we can purchase cheaper ones, but I'm tired of this licensing nightmare of worrying about how many licenses are being used, praying not to exceed the limit or restarting a dead license server. We pay companies to not trust us. Taking a look at the FLOSS world doesn't seem to add any reasonable alternative.
+
+These are the raw high level features of the tool I'd like to use:
+
+ * Requirements edition
+ * Requirements attributes edition
+ * Traceability: edition, coverage analysis and navigation
+ * External traceability: from requirements in one document/module to requirements in other one (eg: software requirements tracing to system requirements). Note: a set of requirements will be called "module" hereafter in this page.
+ * Requirements identifiers management
+ * Requirements history and diff/blame
+ * Team work
+ * Easy integration with other software lifecycle tools: modeling (eg. BOUML), project management (eg. Trac)
+ * Support for other formats such as HTML, office...
+ * Filtering and searching
+ * Export facilities to create standards compliant documentation.
+
+Initial idea was to develop a simple web solution using XHTML files. These files would be created in a web broser with existing WYSIWIM editors and store all the stuff in Subversion. All requirements would be stored at the same level (no hierarchies among requirements of the same module) and atomically accessible via a simple web browser. No server side programming would be needed to read requirements. Also special XHTML files (let's call it "views") would be necessary to group requirements hierarchically in a requirements document fashion, using xinclude.
+
+When I first played with ikiwiki I was so happy that many of the ideas I worked on were already in use in this marvelous piece of software, specially the decision to use well-known RCS software to manage history instead of reinventing the wheel, opening also one interesting feature: off-line edition. Other similarity was the absence of special processing for read-only navigation.
+
+So, let's now take all the features above and describe how to make them real using ikiwiki and some simple conventions. Some features would need new functionality and improvement, I'd really appreciate additional ideas on how to better get to the point.
+
+Requirements edition
+--------------------
+Suppose that all requirements would reside under a concrete folder. We will call it "reqs", and under "reqs" we add as folders as requirements modules we want to use for a system called "foo" (eg. "foo_sss" for system requirements, "foo_srs" for software requirements...). Index file for each document shall be a page summarizing the module: number of requirements, basic coverage information... Other similar pages under the "views" folder could be used in order to have different sets of requirements including additional stuff: introduction, document identification, etc... The rest of the files - actually requirements - shall be markdown files. So editing a requirement would be as simple as adding a page to the wiki.
+
+To create the summary and views, just [[ikiwiki/directive/inline]] and [[ikiwiki/directive/pagecount]] directives could provide nice pages. The uncomfortable part is having to use many [[pagespecs|ikiwiki/PageSpec]] to create the whole views, but it actually shoud work. One possible workaround would be an external tool to handle this and create directives automatically or graphically.
+
+Requirements attributes
+-----------------------
+There are lots of useful data to associate to a requirement. Eg:
+
+ * If it is traceable or not
+ * Its criticality level
+ * Its priority
+ * If it is funtional or not
+ 
+How to implement this? Using [[ikiwiki/directive/meta]] could be a solution, not tried yet, I'd rather keep requirements content alone. Storing this information in SVN it is easy, although ikiwiki does not provide a way to do it it would imply really little effort. The requirement in itself is the content of the file; attributes are stored as key-value pairs in the file's properties. AFAIK this is a feature available only in SVN, although git has something similar (gitattributes) although path based, but anyway whichever RCS is used, a ".properties" file could be created always when a requirement file is created.
+
+Traceability: edition, coverage analysis and navigation
+--------------------------------------------------------
+This is the most important feature of a requirements engineering tool. How to do this with ikiwiki? There are some ways, from extremely simple ones to more sophisticated:
+
+ * One simple solution: Links. Just link from one requirement to another one to create a traceable directional connection
+ * One harder: file attributes (see section about requirements just above)
+
+For coverage analysis , using [[ikiwiki/directive/pagecount]] is the perfect solution to summarize and show covered and uncovered requirements. We could add several pages per module - probably using template pages-  with ready made coverage analysis reports... Wow!!! [[ikiwiki/directive/linkmap]] directive can show traceability information graphically.
+
+Navigating among requirements needs... Nothing!!! Just follow the links of referring pages that ikiwiki adds by default.
+
+External traceability
+---------------------
+Being just different folders under the wiki, external traceability is as easy as internal.
+
+Requirements identifiers management
+-----------------------------------
+Another useful convention: requirement identifier shall be the name of the requirements file. In ikiwiki page title is the same as requirement Id. No trouble, it works. I personally prefer to keep title as page title and create a short auto-increasing numeric codes with prefixes and/or suffixes as file name (eg. SRS_FOO_0001, SSS_FOO_002), hope to have somethig running soon.
+
+Requirements history and diff/blame
+-----------------------------------
+Out of the box! And really much more useful than average diffing components of requirement management tools. There are plenty online front ends to use and for offline work tools like meld are awesome.
+
+Team work
+---------
+Also no need to do anything, RCS software does it all. Also for experienced users merging and conflict solving can provide much more practical solutions (most requirements management tools work blocking).
+
+Easy integration with other software lifecycle tools
+----------------------------------------------------
+Modeling tools: as a general rule, store model elements in the most atomic parts: classes, enums, actors, use cases... and use again file attributes to store traceability information. Other way is transforming files representing these atomic model parts in independent mdwn files under, for example, a "mdl" folder
+
+Trac integration is so simple... As simple as any PM tool that acceses the same RCS as ikiwiki does. Diffing, blaming, even navigating directly to ikiwiki generated pages. Integration of a ticketing system will give awesome power to all the team.
+
+Support for other formats
+-------------------------
+Out of the box, at least for wiki and mathematical formats, and creating additional ones shouldn't be so difficult.
+
+Filtering and searching
+-----------------------
+Look that box in the top right corner?
+
+Export facilities
+-----------------
+Views with custom styles and html conversion tools would be enough for most purposes.
+
+That's all!
+
+One funny thing: our "de facto future" requirements management tool, after years of research included some years ago a really nice feature: a Discussion tag per each requirement... See this in ikiwiki? Again out of the box!!!
+
+Comments are really welcome!!!
diff --git a/doc/tips/ikiwiki_as_a_requirements_management_tool/discussion.mdwn b/doc/tips/ikiwiki_as_a_requirements_management_tool/discussion.mdwn
new file mode 100644
index 000000000..94f0f8b4b
--- /dev/null
+++ b/doc/tips/ikiwiki_as_a_requirements_management_tool/discussion.mdwn
@@ -0,0 +1,18 @@
+How about using tags/links to associate attributes with requirements?
+This could be as simple as adding a link, fo e.g. :
+
+  * If it is traceable or not
+    + \[[attributes/traceable]]
+    + \[[attributes/untraceable]]
+  * Its criticality level
+    + \[[attributes/level/critical]]
+    + \[[attributes/level/important]]
+    + etc.
+  * Its priority
+    + \[[attributes/priority/low]]
+    + \[[attributes/priority/high]]
+  * If it is functional or not
+    + \[[attributes/functional]]
+    + \[[attributes/non-functional]]
+
+You just have to create pages for each attribute you want and then pagespec could be used to filter requirements by attributes. I think something similar is used to trac bug with ikiwiki (linking to a \[[done]] page, etc.).
diff --git a/doc/tips/upgrade_to_3.0.mdwn b/doc/tips/upgrade_to_3.0.mdwn
index d22813bf2..05b6d6fbd 100644
--- a/doc/tips/upgrade_to_3.0.mdwn
+++ b/doc/tips/upgrade_to_3.0.mdwn
@@ -45,7 +45,7 @@ contain the above, then run `ikiwiki-transition prefix_directives your.setup`
 ## GlobLists
 
 In 3.0, the old "GlobList" syntax for [[PageSpecs|ikiwiki/PageSpec]] is no
-longer supported. A GlobList contains multiple term, but does not separate
+longer supported. A GlobList contains multiple terms, but does not separate
 them with "and" or "or":
 
 	sandbox !*/Discussion
diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn
index 11b5fbcae..2a9fc4a0a 100644
--- a/doc/todo/backlinks_result_is_lossy.mdwn
+++ b/doc/todo/backlinks_result_is_lossy.mdwn
@@ -1,5 +1,4 @@
 [[!tag patch patch/core]]
-[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]
 
 IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a
 lossy transformation (to get it in the form that page templates want), making
diff --git a/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn
index 1d24fd385..29c017c5d 100644
--- a/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn
+++ b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn
@@ -1,4 +1,3 @@
-[[!template id=gitbranch branch=smcv/gitignore author="[[smcv]]"]]
 [[!tag patch]]
 
 The recent merge of the po branch didn't come with a .gitignore.
diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn
index bbde04f83..85bb4ff5a 100644
--- a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn
+++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn
@@ -1,5 +1,3 @@
-[[!template id=gitbranch branch=smcv/ready/inline-pagenames author="[[smcv]]"]]
-
 A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds
 the following parameter to the [[ikiwiki/directive/inline]] directive:
 
diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn
index 91e184c29..6f6284303 100644
--- a/doc/todo/optimize_simple_dependencies.mdwn
+++ b/doc/todo/optimize_simple_dependencies.mdwn
@@ -1,5 +1,3 @@
-[[!template id=gitbranch branch=smcv/ready/depends-exact author="[[smcv]]"]]
-
 I'm still trying to optimize ikiwiki for a site using
 [[plugins/contrib/album]], and checking which pages depend on which pages
 is still taking too long. Here's another go at fixing that, using [[Will]]'s
diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn
index fd15d6a42..33f9258fd 100644
--- a/doc/todo/pagestats_among_a_subset_of_pages.mdwn
+++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn
@@ -1,5 +1,4 @@
 [[!tag patch plugins/pagestats]]
-[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]
 
 My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that
 to provide pagestats for links from a subset of pages. From the docs included
diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn
index 4b4e267f0..728ab8994 100644
--- a/doc/todo/should_optimise_pagespecs.mdwn
+++ b/doc/todo/should_optimise_pagespecs.mdwn
@@ -79,8 +79,6 @@ I can think about reducung the size of my wiki source and making it available on
 > 
 > --[[Joey]]
 
-[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]]
-
 >> I've been looking at optimizing ikiwiki for a site using
 >> [[plugins/contrib/album]] (which produces a lot of pages) and it seems
 >> that checking which pages depend on which pages does take a significant
@@ -100,8 +98,6 @@ I can think about reducung the size of my wiki source and making it available on
 >>>> I haven't actually deleted it), because the "or" operation is now done in
 >>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]]
 
-[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]]
-
 >>>>> I've now added a patch to the end of that branch that deletes
 >>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in
 >>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support
diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn
index dfc2766cc..cf3e69487 100644
--- a/doc/todo/source_link.mdwn
+++ b/doc/todo/source_link.mdwn
@@ -11,8 +11,6 @@ All of this code is licensed under the GPLv2+. -- [[Will]]
 > by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does?
 > --[[smcv]]
 
-[[!template id=gitbranch branch=smcv/ready/getsource
-  author="[[Will]]/[[smcv]]"]]
 [[done]]
 
 >> I've applied the patch below in a git branch, fixed my earlier criticism,
diff --git a/doc/users/Will.mdwn b/doc/users/Will.mdwn
index 9c46edc69..043203dc3 100644
--- a/doc/users/Will.mdwn
+++ b/doc/users/Will.mdwn
@@ -4,6 +4,8 @@ Lately I've been using Ikiwiki for other things and seem to be scratching a few
 
 I generally use my [[ikiwiki/openid]] login when editing here: <http://www.cse.unsw.edu.au/~willu/>
 
+I have a git repository for some of my IkiWiki code: <http://www.cse.unsw.edu.au/~willu/ikiwiki.git>.
+
 Generic License Grant
 -----------------