Merge branch 'master' into cvs
Joey Hess
commit
fc2bd0afe1
|
|
@ -65,3 +65,32 @@ Could you please enlighten me. It should be possible seeing for example this sit
|
||||||
Thanks in advance,
|
Thanks in advance,
|
||||||
|
|
||||||
--[[PaulePanter]]
|
--[[PaulePanter]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Current Working Notes
|
||||||
|
|
||||||
|
I've spent a little time getting this working and I wanted to share my notes on this, for those that come after me.
|
||||||
|
|
||||||
|
### My Setup
|
||||||
|
|
||||||
|
- Debian Lenny
|
||||||
|
|
||||||
|
- Gitosis (hand compiled, for no good reason, but it's the same version as in the repository)
|
||||||
|
|
||||||
|
- Ikiwiki 3.12 installed using packages from Sid
|
||||||
|
|
||||||
|
### What Works
|
||||||
|
|
||||||
|
- Everything needs to be chowned git:git (or gitosis:gitosis) by whatever gitosis runs with. This includes:
|
||||||
|
- the bare repository (as always)
|
||||||
|
- the srcdir
|
||||||
|
- the destdir
|
||||||
|
|
||||||
|
- Ikiwiki needs to run in gitosis' group (eg. git in my case, but probably gitosis in yours)
|
||||||
|
|
||||||
|
- ikiwiki.cgi needs be set with the wrapper mode 6755.
|
||||||
|
|
||||||
|
-- [[tychoish]]
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,8 +5,8 @@
|
||||||
This plugin allows ikiwiki to use [[!wikipedia desc="CVS" Concurrent Versions System]] as an [[rcs]].
|
This plugin allows ikiwiki to use [[!wikipedia desc="CVS" Concurrent Versions System]] as an [[rcs]].
|
||||||
|
|
||||||
### Usage
|
### Usage
|
||||||
7. Install [cvsps](http://www.cobite.com/cvsps/), [[!cpan IPC::Cmd]],
|
7. Install [cvsps](http://www.cobite.com/cvsps/), [[!cpan
|
||||||
[[!cpan String::ShellQuote]], [[!cpan File::ReadBackwards]], and
|
File::ReadBackwards]], and
|
||||||
[cvsweb](http://www.freebsd.org/projects/cvsweb.html) or the like.
|
[cvsweb](http://www.freebsd.org/projects/cvsweb.html) or the like.
|
||||||
7. Adjust CVS-related parameters in your setup file.
|
7. Adjust CVS-related parameters in your setup file.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -93,3 +93,35 @@ the "cvs add <directory>" call and avoid doing anything in that case?
|
||||||
>>> if a configured post-commit hook is missing, and it seems fine,
|
>>> if a configured post-commit hook is missing, and it seems fine,
|
||||||
>>> probably also thanks to IPC::Cmd.
|
>>> probably also thanks to IPC::Cmd.
|
||||||
>>> --[[schmonz]]
|
>>> --[[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.
|
||||||
|
|
||||||
|
> Thanks for reading carefully. I've tested your suggestions and
|
||||||
|
> applied them on my branch. --[[schmonz]]
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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'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]]
|
||||||
|
|
|
||||||
126
doc/sandbox.mdwn
126
doc/sandbox.mdwn
|
|
@ -1,39 +1,7 @@
|
||||||
This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]).
|
This is the [[SandBox]], a page anyone can edit to try out ikiwiki (version [[!version ]]).
|
||||||
|
|
||||||
----
|
|
||||||
2009/7/13 Monday Blue...\\
|
|
||||||
While working on [[http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199|[97] Phpbb 與 Dokuwiki 之間的往來]] (External Link to //http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199// not working?), surf Internet for Wikis supporting //Creole V1.0//, found this site.
|
|
||||||
|
|
||||||
* I thought that creole markup is used by ikiwiki...
|
|
||||||
* Thought about using //SVN/CVS// server, however with different idea
|
|
||||||
* Kinda curious why **Tcl** does not show her face in this Wiki arena
|
|
||||||
* It looks like that I was wrong, from Wikipedia Creole page it mention that ikiwiki is also adopting Creole markup.
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
Guten Morgen aus Deutschland. Wir mögen Umläuter (ich weiß, der Plural ist falsch, aber dafür hat er einen). Die sind heutzutage kein Ärgernis mehr.
|
|
||||||
|
|
||||||
&#x263a; becomes ☺
|
|
||||||
|
|
||||||
<script>alert("If this pops, ikiwiki is not cross site scripting safe."); /* Fortunately, this does not work. */</script>
|
|
||||||
|
|
||||||
---
|
|
||||||
I try to have a discussion page !!!
|
|
||||||
----
|
|
||||||
|
|
||||||
Testing OpenID some more..
|
|
||||||
|
|
||||||
test more test
|
|
||||||
[[中文显示]]
|
|
||||||
|
|
||||||
Here's a paragraph.
|
Here's a paragraph.
|
||||||
|
|
||||||
The following code block is pre-formatted:
|
|
||||||
|
|
||||||
Testing what
|
|
||||||
pre-formatted code blocks
|
|
||||||
look like.
|
|
||||||
|
|
||||||
Here's another one with *emphasised* text.
|
Here's another one with *emphasised* text.
|
||||||
|
|
||||||
# Header
|
# Header
|
||||||
|
|
@ -59,10 +27,6 @@ Numbered list
|
||||||
1. And another..
|
1. And another..
|
||||||
1. foo
|
1. foo
|
||||||
2. bar
|
2. bar
|
||||||
3. baz
|
|
||||||
4. qux
|
|
||||||
5. quux
|
|
||||||
6. wibble
|
|
||||||
|
|
||||||
Bulleted list
|
Bulleted list
|
||||||
|
|
||||||
|
|
@ -71,9 +35,6 @@ Bulleted list
|
||||||
* item
|
* item
|
||||||
* one
|
* one
|
||||||
* two
|
* two
|
||||||
* three
|
|
||||||
* four
|
|
||||||
* five
|
|
||||||
|
|
||||||
----
|
----
|
||||||
|
|
||||||
|
|
@ -82,102 +43,15 @@ Bulleted list
|
||||||
|
|
||||||
----
|
----
|
||||||
|
|
||||||
The haiku will change after every save, mind you.
|
|
||||||
|
|
||||||
## Different sorts of links:
|
## Different sorts of links:
|
||||||
|
|
||||||
* [[Features]]
|
* [[Features]]
|
||||||
* [[different_name_for_a_WikiLink|ikiwiki/WikiLink]]
|
* [[different_name_for_a_WikiLink|ikiwiki/WikiLink]]
|
||||||
* <http://www.gnu.org/>
|
* <http://www.gnu.org/>
|
||||||
* [GNU](http://www.gnu.org/)
|
* [GNU](http://www.gnu.org/)
|
||||||
* [Email](mailto:noone@invalid)
|
|
||||||
* [](http://ikiwiki.info)
|
|
||||||
* <a href="http://www.google.com/">plain old html link</a>
|
|
||||||
* [[foo]]
|
|
||||||
|
|
||||||
-----
|
-----
|
||||||
|
|
||||||
This SandBox is also a [[blog]]!
|
This SandBox is also a [[blog]]!
|
||||||
|
|
||||||
[[!inline pages="sandbox/* and !*/Discussion" rootpage="sandbox" show="4" archive="yes"]]
|
[[!inline pages="sandbox/* and !*/Discussion" rootpage="sandbox" show="4" archive="yes"]]
|
||||||
|
|
||||||
--------
|
|
||||||
|
|
||||||
This gives an example of inline code: `tar | netcat` is a nice way to transfer bulk files over the net
|
|
||||||
|
|
||||||
But, of course, rsync is better.
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
Let's see what happens... ~~
|
|
||||||
|
|
||||||
#中文标题一
|
|
||||||
##中文标题二
|
|
||||||
###中文标题三
|
|
||||||
...
|
|
||||||
######中文标题六
|
|
||||||
|
|
||||||
###正文:
|
|
||||||
|
|
||||||
君不见，黄河之水天上来，奔流到海不复回。
|
|
||||||
|
|
||||||
君不见，高堂明镜悲白发，朝如青丝暮成雪。
|
|
||||||
|
|
||||||
人生得意须尽欢，莫使金樽空对月。
|
|
||||||
|
|
||||||
天生我材必有用，千金散尽还复来。
|
|
||||||
|
|
||||||
###列表：
|
|
||||||
|
|
||||||
* 天空
|
|
||||||
|
|
||||||
1. 蓝色的
|
|
||||||
2. 好高啊
|
|
||||||
|
|
||||||
* 海洋
|
|
||||||
|
|
||||||
1. 有鱼
|
|
||||||
|
|
||||||
* 鲸鱼
|
|
||||||
* 鲨鱼
|
|
||||||
|
|
||||||
|
|
||||||
* 大地
|
|
||||||
|
|
||||||
###链接：
|
|
||||||
|
|
||||||
[谷歌](http://www.google.com)
|
|
||||||
|
|
||||||
###引用：
|
|
||||||
|
|
||||||
> 一级引用
|
|
||||||
>
|
|
||||||
> 一级引用
|
|
||||||
>
|
|
||||||
> > 二级引用
|
|
||||||
>
|
|
||||||
>> 没有空格也可以
|
|
||||||
>>> 三级引用
|
|
||||||
>
|
|
||||||
> 回到一级引用
|
|
||||||
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
|
|
||||||
testing
|
|
||||||
|
|
||||||
--
|
|
||||||
[[!toc levels=2]]
|
|
||||||
|
|
||||||
[[Mamma Mia]]
|
|
||||||
|
|
||||||
----
|
|
||||||
|
|
||||||
[[!format c """
|
|
||||||
void main () {
|
|
||||||
printf("hello, world!");
|
|
||||||
}
|
|
||||||
"""]]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
This is a testing Blag-Entry.
|
|
||||||
/me loves blagging.
|
|
||||||
|
|
||||||
* Entry one
|
|
||||||
* entry two
|
|
||||||
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
Just a test page ...
|
|
||||||
|
|
||||||
... to see what happens.
|
|
||||||
|
|
@ -1,25 +0,0 @@
|
||||||
!!!Heading Three
|
|
||||||
|
|
||||||
Itemized
|
|
||||||
* list
|
|
||||||
* of
|
|
||||||
* things
|
|
||||||
|
|
||||||
or not
|
|
||||||
1. mom
|
|
||||||
1. hi
|
|
||||||
1. there
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
!!!Heading Three
|
|
||||||
|
|
||||||
Itemized
|
|
||||||
* list
|
|
||||||
* of
|
|
||||||
* things
|
|
||||||
|
|
||||||
or not
|
|
||||||
1. mom
|
|
||||||
1. hi
|
|
||||||
1. there
|
|
||||||
|
|
@ -1,31 +0,0 @@
|
||||||
<math xmlns="http://www.w3.org/1998/Math/MathML">
|
|
||||||
<mrow>
|
|
||||||
<msup>
|
|
||||||
<mfenced open="(" close=")">
|
|
||||||
<mrow>
|
|
||||||
<mi>a</mi>
|
|
||||||
<mo>+</mo>
|
|
||||||
|
|
||||||
<mi>b</mi>
|
|
||||||
</mrow>
|
|
||||||
</mfenced>
|
|
||||||
<mn>2</mn>
|
|
||||||
</msup>
|
|
||||||
<mo>-</mo>
|
|
||||||
<msub>
|
|
||||||
|
|
||||||
<mfenced open="{" close="}">
|
|
||||||
<mrow>
|
|
||||||
<mi>x</mi>
|
|
||||||
<mo>+</mo>
|
|
||||||
<mi>y</mi>
|
|
||||||
</mrow>
|
|
||||||
</mfenced>
|
|
||||||
|
|
||||||
<mi>i</mi>
|
|
||||||
</msub>
|
|
||||||
</mrow>
|
|
||||||
</math>
|
|
||||||
<br>
|
|
||||||
test <b>test</b><abbr title="test">T.</abbr> <h1>test</h1>
|
|
||||||
<a href="https://bugzilla.mozilla.org">øđ</a>
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
what happens?
|
|
||||||
|
|
@ -1,2 +0,0 @@
|
||||||
[[!teximg code="E = - \frac{Z^2 \cdot \mu \cdot e^4}{32\pi^2 \epsilon_0^2 \hbar^2 n^2}" ]]
|
|
||||||
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
# Title with $\TeX$
|
|
||||||
|
|
||||||
* How about some math?
|
|
||||||
* $\frac{1}{2} = \frac{3}{6}$
|
|
||||||
|
|
||||||
and teximg? [[!teximg code="\frac{1}{2}"]]
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
foo?
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
This just a test, but I am impressed.
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
I recall testing this too, but I'm not sure where the test went. Let's try again. -- [[users/Jon]]
|
|
||||||
|
|
||||||
Context: [[todo/discussion_page_as_blog/discussion/castle]]
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
I like this idea of using the blog feature to handle comments. Let's see how it works.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
wibble
|
|
||||||
|
|
@ -1,6 +0,0 @@
|
||||||
normally a sandbow doesn't have a discussion page
|
|
||||||
but it's a sandbox
|
|
||||||
|
|
||||||
-
|
|
||||||
little light
|
|
||||||
ikiwiki looks great
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
a test blog in the ikiwiki sandbox!
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Foobaka bakfoo.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
hehe hohoho
|
|
||||||
|
|
@ -1,5 +0,0 @@
|
||||||
##Why?
|
|
||||||
* Because I can do things like this
|
|
||||||
* Because I can use my favourite SCM, as the rest of my project elements (that's the only reason I complain about Trac...)
|
|
||||||
* Because the perfect tool does not exist, but custommizing very simple approaches like this I can build my own
|
|
||||||
* Because I'm just adding a new topic to see how diff works
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Perhaps
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
testing my openid provider @ www.steve.org.uk
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
this is test two, being pushed by [[tips/untrusted_git_push]].
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
Testing nested inlines:
|
|
||||||
|
|
||||||
[[!inline pages="sandbox/test_nested_inlines/* and !sandbox/test_nested_inlines/*/*" feeds="no"]]
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
I tried to make a page called **testπ** and it didn't work. So this is a page called **test pi**.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
hi mom!
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
Test page content.
|
|
||||||
|
|
@ -1,3 +0,0 @@
|
||||||
# Test subpage
|
|
||||||
|
|
||||||
This is a test subpage. Isn't that special?
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
I am very impressed.
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
~를 어떻게 할까~
|
|
||||||
|
|
@ -1,2 +0,0 @@
|
||||||
|
|
||||||
Wow test
|
|
||||||
|
|
@ -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!!!
|
||||||
|
|
@ -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.).
|
||||||
|
|
@ -1,5 +1,10 @@
|
||||||
I'm [tycho](http://www.tychoish.com/).
|
I'm Sam Kleinman ([tychoish](http://www.tychoish.com/)), and I use ikiwiki.
|
||||||
|
|
||||||
I use ikiwiki *a lot* on my local machine to organize thoughts, stage writing projects, and collect information. It's a great thing for me. Someday I'll probably get around to using it to powersome sort of collaborative fiction project. Someday.
|
I used to use ikiwiki a bunch, in a purely local setup, for various projects and personal note taking of various kinds. I've since switched to using [orgmode](http://www.orgmode.org) and a number of just regular old git repositories with some textfiles in them, which seems to work just as well for my particular use case.
|
||||||
|
|
||||||
Talk to you soon.
|
Currently, I'm using ikiwiki on the [cyborg institute wiki](http://www.cyborginstitute.com/wiki/) and I'm working on helping someone develop a collaborative fiction project at the [critical futures wiki](http://www.criticalfutures.com/wiki/)... and I'm thinking about other projects, but nothing that exists enough to mention here.
|
||||||
|
|
||||||
|
I hang out in #ikiwiki on oftc, and I'm working on getting some of my templates in order to share with you all. Soon. For sure.
|
||||||
|
|
||||||
|
Cheers,
|
||||||
|
tychoish
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue