xcfit 0.9.0 → 1.0.0

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/RestfulPackets/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-	<saveId>1235142473765</saveId>
-	<ticketId>-2501072354251645696</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/RestfulSuiteXmlFormat/content.txt

@@ -1,31 +0,0 @@
-The format for a suite is similar to the format for a test as shown in <UserGuide.RestfulTests.  The big difference is that the majority of the content for each test result is replaced by a link to the appropriate page history.  This keeps the suite response very small, and allows the user to obtain all the detail they need by issuing a page history request.
-{{{
-<testResults>
-	<rootPath>SuiteAcceptanceTests</rootPath>
-	<result>
-		<relativePageName>SuiteWidgetTests.TestBrokenWikiWordLink</relativePageName>
-                <tags>critical,slow</tags>
-		<counts>
-			<right>24</right>
-			<wrong>0</wrong>
-			<ignores>0</ignores>
-			<exceptions>0</exceptions>
-		</counts>
-		<runTimeInMillis>
-			1022
-		</runTimeInMillis>
-                <pageHistoryLink>FitNesse.SuiteAcceptanceTests.SuiteWidgetTests.SuiteWidgetTests.TestBrokenWikiWordLink?pageHistory&resultDate=20090820&format=xml</pageHistoryLink>
-	</result>
-	...
-
-	<finalCounts>
-		<right>182</right>
-		<wrong>0</wrong>
-		<ignores>0</ignores>
-		<exceptions>0</exceptions>
-	</finalCounts>
-	<totalRunTimeInMillis>
-		6234
-	</totalRunTimeInMillis>
-</testResults>
-}}}

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/RestfulSuiteXmlFormat/properties.xml

@@ -1,11 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit>true</Edit>
-	<Files>true</Files>
-	<Properties>true</Properties>
-	<RecentChanges>true</RecentChanges>
-	<Refactor>true</Refactor>
-	<Search>true</Search>
-	<Versions>true</Versions>
-	<WhereUsed>true</WhereUsed>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/RssFeed/content.txt

@@ -1,19 +0,0 @@
-!img-r http://www.reallysimplesyndication.com/mainResponderResources/userlandIcons/xmlCoffeeMug
-!c !2 FitNesse supports RSS 2.0
-
-The RSS URL has the simple form:
- * ''!-http://[myWikiAddress]/[somePage]?responder=rss-!''
-
-This will send you a list of all the recent changes for ''[somePage]'' and all pages below.  If you omit ''[somePage]'' then you'll get a list of all the recent changes in the whole wiki.
-
-There is one caveat.  Without help FitNesse doesn't know how to build fully qulified URL to it's pages.  This will result in bad links in the RSS feed.  You can help out by defining the '''RSS_PREFIX''' variable.  Here's how:
- 1 Goto the root page of your FitNesse site
-  * use the '''root''' keyword in the URL.  !-http://localhost/root-!
- 2 Click the '''edit''' button (or add ?edit to the end of the URL)
- 3 Define the '''RSS_PREFIX''' variable.
-  * !-!define RSS_PREFIX {http://www.mysite.com/}-!
-
-
-Example:{{{http://fitnesse.org/FitNesse?responder=rss}}}
-
-!note !meta Make sure your !-RecentChanges-! page is well formed.  If it's corrupted, then the RSS feed responder can crash.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/RssFeed/properties.xml

@@ -1,13 +0,0 @@
-<?xml version="1.0"?>
-<properties>
-	<Edit/>
-	<Files/>
-	<Help/>
-	<Normal/>
-	<Properties/>
-	<RecentChanges/>
-	<Refactor/>
-	<Suites/>
-	<Versions/>
-	<WhereUsed/>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/TestHistoryXml/content.txt

@@ -1,13 +0,0 @@
-{{{
-<TestHistory>
-  <Page>
-    <Name>FitNesse.SuiteAcceptanceTests</Name>
-    <PageHistoryLink>FitNesse.SuiteAcceptanceTests?pageHistory&format=xml</PageHistoryLink>
-    <Pass>16</Pass>
-    <Fail>1</Fail>
-    <MinDate>Tue Jun 23 14:49:49 CDT 2009</MinDate>
-    <MaxDate>Tue Jul 07 13:08:07 CDT 2009</MaxDate>
-  </Page>
-...
-</TestHistory>
-}}}

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/content.txt

@@ -1,128 +0,0 @@
-!-FitNesse-! is a web application, therefore all of it's functions can be accessed by passing it URLs.  The structure of !-FitNesse-! urls is very simple.
-
- * !style_code(http://)''host''!style_code(:)''port''!style_code(/)''resource''!style_code(?)''responder''!style_code(&)''inputs''
-   * The ''host'' and ''port'' specify the location of the !-FitNesse-! server.
-   * ''resource'' is usually the name of the !-FitNesse-! wiki page being referenced.  Sometimes it refers to a path below the ''files'' section.  It is not used in all urls.
-   * ''responder'' is the name of the operation to be performed.  This is typically something like !style_code(?edit) to edit a page, or !style_code(?properties) to bring up the properties dialog.  A responder corresponds roughly to a servlet.
-   * ''inputs'' is the list of parameters to the operation.  As in all URL query strings these are name-value pairs and will be things like !style_code(&format=xml) or !style_code(&dontCreatePage).
- * A wiki page can be fetched by leaving the query string blank as in !style_code(http://myHost:myPort/MyWikiPage).
- * A responder can be specified by using the ''responder'' input as in: !style_code(http://myHost:myPort/MyWikiPage?responder=edit) instead of !style_code(http://myHost:myPort/MyWikiPage?edit).  The former is ''proper'', but the latter has become so idiomatic that it will not be deprecated any time soon.
- * The files section of the wiki can be accessed by using the word ''files'' followed by a directory path as in !style_code(http://myHost:myPort/files/images/bob.gif)
- * The root page can be accessed by using the word ''root'' instead of the ''page'' as in !style_code(http://myHost:myPort/root)
-
-!2 Responders
-| !meta name | !meta inputs | !meta description |
-| addChild | | Creates a new child page beneath the selected page |
-| | pageName | The name of the page to be created. |
-| | pageContent | The contents of the new page. |
-| | pageTemplate | If present must point to a valid wiki page. The new page will have the same properties as the referred page. |
-| | pageType | If present must be {Test, Suite, Static} and sets the page type accordingly.  Otherwise page type is set based on the name of the page as usual. This option does nothing if the ''pageTemplate'' option is set. |
-| compareHistory | | Generates a report comparing two test results. |
-| | TestResult_''yyyyMMddHHmmss_rr_ww_ii_xx''.xml | One of the files to be compared.  Always two there are. |
-| createDir | | Create a new directory in the ''files'' section.  The directory will be created below the ''resource'' |
-| | dirname | The name of the directory to create |
-| deletePage | | Deletes the specified page. |
-| | confirmed=yes | Bypasses the confirmation screen. |
-| deleteFile | | Deletes a file in the ''files'' section.  The ''resource'' is the directory in which the file exists. |
-| | filename | the name of the file to be deleted. |
-| edit | | returns the edit screen for a wiki page.  The ''save'' button invokes the ''saveData'' responder. |
-| | redirectToReferer | instructs the ''edit'' responder to pass the ''redirect'' input to the ''saveData'' responder.  The input is constructed from the ''Referer'' header and the ''redirectAction'' input and has the form ''referer''?''action''. |
-| | redirectAction=action | see above. |
-| | nonExistent | Causes the ''edit'' responder to load the edit window with default page contents and changes some message from ''edit'' to ''create'' |
-| executeSearchProperties | | Returns a list of pages that match the search criteria |
-| | pageType | a list of page types to include in the search {Normal, Test, Suite} or the word "Any" |
-| | Suites | a comma seperated list of tags (as used by the ''suite'' responder) to include in the search |
-| | Action | a list of actions !-{Edit, Versions,Properties, Refactor, WhereUsed, RecentChanges, Files, Search}-! or the word "Any" to include in the search |
-| | !-ExcludeSetUp-! | Exclude setup pages from the search. |
-| | !-ExcludeTearDown-! | Exclude teardown pages from the search. |
-| | !-ExcludeObsolete-! | Exclude pages with the "skipped" attribute selected from the search. |
-| files | | Displays a directory in the ''files'' section.  The ''resource'' is the directory to be displayed. |
-| getPage | | View the selected page |
-| | dontCreatePage | if present, will prevent the responder from attempting to create a page if it doesn't exist. |
-| | ''key''=''value'' | If present creates a markup variable with ''key'' as name & ''value'' as value.  ''key'' and ''value'' can be any string values.  Multiple pairs can be specified.  | 
-| import | | Imports a page hierarchy from a foreign !-FitNesse-! |
-| | remoteUsername | The user name to log in as (optional) |
-| | remotePassword | The password to use (optional) |
-| | remoteUrl | The url to the complete pathname of the parent page to be imported. |
-| | autoUpdate | If present, will cause a re-import of changed pages whenever a test is run. |
-| importAndView | | imports (if necessary) and views the selected page. |
-| movePage | | moves the selected page below a different parent. |
-| | newLocation | The full path name of the page that will be the new parent. |
-| names | | Displays a list of the pages at the current level.  If no page name is supplied, then the list is all the pages at the top level.  Otherwise it is the list of direct children (not grandchildren) of the supplied page. |
-| | format=json | returns the list as a JSON array |
-| | Recursive | prints also child, grand-child, ... pages |
-| | !-LeafOnly-! | in combination with the "Recursive" option prints only leaf pages that don't have further children |
-| | !-ShowTags-! | prints the tags associated with a page in []-brackets, e.g., [hello][world] |
-| | !-ShowChildCount-! | adds the count of children to each page name after a space. |
-| new | | Like ''edit'', but used for new pages. |
-| | pageTemplate | Define a page to use as a template for the to be created page  |
-| | pageType | If present must be {Test, Suite, Static} and sets the page type accordingly.  Otherwise page type is set based on the name of the page as usual. This option does nothing if the ''pageTemplate'' option is set. |
-| packet | | Returns a json packet containing all the tables on the page.  See: [[!-RestfulPackets-!][<UserGuide.AdministeringFitNesse.RestfulServices.RestfulPackets]] |
-| | jsonp=function | Wraps the json packet into a function call for JSONP, see: [[!-RestfulPackets-!][<UserGuide.AdministeringFitNesse.RestfulServices.RestfulPackets]] |
-| pageData | | Returns the raw wiki-text of the page. |
-| pageHistory | | Displays the test history of the specified page. |
-| | resultDate | if present the date (yyyyMMddHHmmss) of the test to show, or the word "latest".  Otherwise show a list of all dates for this page. | |
-| | format=xml | Returns an XML report.  See: >PageHistoryXml and [[!-RestfulTests-!][<UserGuide.WritingAcceptanceTests.RestfulTests]] |
-| properties | | Displays the properties form for the selected page. |
-| | format=json | shows the properties in JSON format   See >JsonProperties |
-| purgeHistory | | Purges old test history files |
-| | days | The number of days of history to preserve |
-| raw | | returns the raw wiki-text of the selected page |
-| refactor | | Displays the refactoring screen. |
-| renameFile | | Renames a file in the ''files'' section.  The ''resource'' is the directory that contains the file. |
-| | filename | the file to be renamed. |
-| | newName | the new name of the file. |
-| renamePage | | Renames the selected page. |
-| | newName | The new name for the page.  Must be a simple wiki word without any dots.  You can't use this responder to move a page! |
-| rollback | | Rollback the page to the selected version. |
-| | version | The version identifier of the version to rollback to.  See: ''viewVersion'' |
-| rss | | Returns an rss feed for the current page and all it's children.  See [[!-RssFeed-!][<UserGuide.AdministeringFitNesse.RestfulServices.RssFeed]] |
-| saveData | | Saves the data for a wiki page.  Usually called by the ''edit'' responder.  Usually invoked as a POST.  If the ''ticketId'' and ''saveTime'' suggest that a merge is needed, this responder will return the merge form without doing a save. |
-| | pageContent | The content to be saved into the page. |
-| | editTime | The time (in milliseconds) that the page was fetched for this edit.  Used to determine whether or not a merge is needed.  (Optional) |
-| | ticketId | A random number associated with the edit session.  Used to determine whether or not a merge is needed.  (Optional) |
-| | redirect | The URL to redirect to after the page is saved. |
-| saveProperties | | Saves the properties for the selected page.  Usually called from the ''properties'' responder.  Usually called as a POST. |
-| | pageType | Must be one of: {Normal, Test, Suite}, sets the page type. |
-| | ''attribute'' | Must be one of: !-{Edit, Versions,Properties, Refactor, WhereUsed, RecentChanges, Files, Search, Prune}-! These are booleans.  If present they will be set.  If absent they will be reset. |
-| | Suites | a comma seperated list of tags used by the ''suite'' responder. |
-| | !-HelpText-! | The help text that can show up in TOC listings. |
-| search | | Searches for pages that match the query.  Returns an HTML table of results found. |
-| | searchString | The string to search for.  This is a string, not a regular expression. |
-| | searchType | May be "title" or "content".  If "title" then searches for pages whose names contain the ''searchString'', otherwise searches for pages whose content contains the ''searchString''. |
-| searchForm | | Returns the search form that allows users to specify a search. |
-| shutdown | | Shuts !-FitNesse-! down. |
-| stoptest | | Stops running tests. |
-| | id | If present, is the process id of the test to stop.  Otherwise stops ''all'' running tests. |
-| suite | | Runs a suite of tests.  The tests run are all those below the wiki page that are marked as tests.  Returns a suite report. |
-| | format=xml | See >RestfulSuiteXmlFormat |
-| | format=junit | Produces simple jUnit XML format|
-| | debug | See test |
-| | remote_debug | See test | |
-| | suiteFilter | A comma separated list of tags.  If present only tests that one or more of these tags will be run. |
-| | excludeSuiteFilter | a comma separated list of tags.  If present only test that DO NOT have any of these tags will be run. |
-| | firstTest | if present, only tests whose full path names are lexigraphically greater (later in alphabetical order) will be run.  This is of questionable use since tests are not guaranteed to be run in any particular order. |
-| | nohistory | Do not generate test history files when running the suite.  Don't use this with format=xml since xml reports depend upon history. |
-| | includehtml | If format=xml then this will cause the XML to contain a 'content' tag that holds the HTML of the tested page.  Beware, this can lead to !-OutOfMemory-! errors for large suites. |
-| | ''key''=''value'' | If present creates a markup variable with ''key'' as name & ''value'' as value.  ''key'' and ''value'' can be any string values.  Multiple pairs can be specified.| 
-| symlink | | Creates a symbolic link between pages in the same !-FitNesse-! |
-| | removal | If present is the name of a symbolic link to be removed. |
-| | rename | If present is the name of a symbolic link to be renamed. |
-| | newname | The new name of the symbolic link being renamed. |
-| | linkName | If present is the name of a new symbolic link to be added to the page named by the ''resource''. |
-| | linkPath | The path that the link refers to. |
-| test | | runs a test on the specified page, returns result in html |
-| | format=xml | Returns results in XML.  See [[!-RestfulTests-!][<UserGuide.WritingAcceptanceTests.RestfulTests]] |
-| | debug | (Only works for Java fixtures.) Attempts to run the test in the same JVM that !-FitNesse-! is running in.  Allows you to attach a debugger to your fixtures before you run the test. | |
-| | remote_debug | Causes the REMOTE_DEBUG_COMMAND and REMOTE_DEBUG_RUNNER variables to be used in place of COMMAND_PATTERN and TEST_RUNNER when creating the command to execute the test.  See [[!-CustomizingTestExecution-!][<UserGuide.WritingAcceptanceTests.CustomizingTestExecution]] for defaults |
-| | ''key''=''value'' | If present creates a markup variable with ''key'' as name & ''value'' as value.  ''key'' and ''value'' can be any string values.  Multiple pairs can be specified.  | 
-| testHistory | | Displays the current test history below the selected page, or all history if no page is selected. |
-| | format=xml | Returns an XML report of test history. See >TestHistoryXml |
-| upload | | Upload a new file into the files section.  The ''resource'' is the directory into which the new file will be stored. |
-| | file | An object of type !style_code(fitnesse.http.UploadedFile) |
-| versions | | Returns the form that shows the saved versions of the wiki page |
-| viewVersion | | Shows the selected version of the wiki page. |
-| | version | The version identifier.  The version identifier is just the name of the zip file (without the .zip) that holds the version.  The format of this file name is (generally) ''user''-''id''-''yyyyMMddHHmmss'' where user might not be present. |
-| whereUsed | | Returns a list of pages that contains references (links) to the selected page |
-
- * ''nochunk''  can be added to many urls to turn off chunking.  This is most useful for test and suite urls when writing programs to parse the output.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/RestfulServices/properties.xml

@@ -1,10 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-<saveId>1234653714415</saveId>
-<ticketId>2484226534369622367</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SecurityDescription/SpnegoAuthentication/content.txt

@@ -1,31 +0,0 @@
-!2 How to enable for Kerberos/Active Directory
-!note Not tested as part of the normal build.  Use at your own risk.
-
-Enable this plugin by editing !style_code(plugins.properties) and adding the line:
-!style_code(!-Authenticator = fitnesse.authentication.NegotiateAuthenticator-!)
-
-If using Kerberos on Unix, create a !style_code(jaas-krb5.conf) file with these contents:
-{{{
-com.sun.security.jgss.accept  {
-       com.sun.security.auth.module.Krb5LoginModule required
-       storeKey=true
-       isInitiator=false
-       principal="HTTP/your.web.server@YOUR.REALM"
-       useKeyTab=true
-       keyTab="/path/to/your/http.keytab"
-       ;
-    };
-}}}
-Next, define these system properties when running the FitNesse server:
-
-{{{
--Djavax.security.auth.useSubjectCredsOnly=false
--Djava.security.auth.login.config=/path/to/jaas-krb5.conf
--Dsun.security.krb5.debug=true
-}}}
-You can remove the !style_code(krb5.debug) property later, when you know it's working.
-
-{{{
- * @author David Leonard Released into the Public domain, 2009. No warranty:
- *         Provided as-is.
-}}}

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SecurityDescription/SpnegoAuthentication/properties.xml

@@ -1,8 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SecurityDescription/content.txt

@@ -1,28 +0,0 @@
-!3 Security Overview
-Pages can be marked with three levels of security:
-
-|''secure-read''|Only authenticated users can read the page|
-|''secure-write''|Only authenticated users can write the page.|
-|''secure-test''|Only authenticated users can test the page.|
-
-These levels are not hierarchical.  secure-write does not imply secure-read.  Indeed, the three are completely independent flags that you can set on any page.
-
-!3 Setting Security
-You set the security of a page by going to it's properties and clicking on the appropriate checkboxes. If none of the checkboxes are checked, then the page is completely insecure and anybody can do anything to it.  This is the default.
-
-!3 Security Inheritance
-Pages inherit their security from their parent pages.  If a parent page has ''secure-read'' then all its children will be protected from reading, even though they don't have ''secure-read'' set themselves.  There is no way to relax security in child pages.  Where security is concerned, the parents rule.
-
-!3 Details
- * If a unauthenticated user attempts to display a page that has ''secure-read'' set, he will be prompted for his username and password.  If he survives this authentication then he will be redirected to the requested page.
- * If an unauthenticated user attempts to write a page that has ''secure-write'' set, he will be authenticated before the write is allowed to take place.
- * If an unauthenticated user attempts to test a page that has ''secure-test'' set, he will be authenticated before the test is allowed to take place.  This works the same for both tests and suites.
- * A user must be authenticated to do any kind of refactoring.
- * A user must be authenticated to change the properties of a page.
- * A user must be authenticated to inspect or change the /files directory structure.  However, unauthenticated readers can read files from the /files directory.
- * Searching, [[!-WhereUsed-!][<UserGuide.FitNesseWiki.WhereUsed]], Sisterhood, and other queries of that kind are not secure and do not require authentication.
-
-!3 Authentication
-The users and their passwords are supplied to FitNesse by using the -a as one of the CommandLineArguments.
-!3 SPNEGO/GSSAPI Authentication
-See >SpnegoAuthentication

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SecurityDescription/properties.xml

@@ -1,6 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<RecentChanges/>
-<WhereUsed/>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SourceCodeControl/content.txt

@@ -1,33 +0,0 @@
-It is relatively simple to marry !-FitNesse-! to your source code control system. By default FitNesse is using a Zip-file based version control mechanism. As soon as a page is updated, a backup is made of the current version and the new version is put into place. Closely tied to the version controller is the .RecentChanges page. This page can be consulted to see who change what.
-
-The most basic implementation is the !-SimpleFileVersionsController-!. It just stores the content. This class is used as a basis for the !-ZipFileVersionsController-! and [[!-Git versions controller-!][https://github.com/amolenaar/fitnesse-git-plugin]].
-
-!2 Description of !-fitnesse.wiki.fs.VersionsController-!
-To create a version controller 3 things are important:
-
- 1 The pages should be stored in a File system. The filesystem based wiki page is currently the only supported page type (but you're free to create your own)
- 1 You'll need to implement the !-fitnesse.wiki.fs.VersionsController-! interface.
- 1 To support recent changes you'll have to provide a class that implements the !-fitnesse.wiki.RecentChanges-! interface.
-
-The !-VersionsController-! interface is quite straightforward. All the relevant information is provided through the !-fitnesse.wiki.fs.FileVersion-! interface. This interface provides the file name, content, author and time information.
-
-The !-VersionsController-! interface consists of the following methods:
-
-{{{  VersionInfo makeVersion(FileVersion... fileVersion) throws IOException;}}}Create a new version/revision. This is typically called then a page is saved. Each !-FileVersion-! contains infomation about the file that is to be saved, the author and the content. Time information is usually less important. It might be that the author information is taken from the first file version provided (since all changes are to be saved as one commit anyway). Note that, since files are saved in directories, the directories are not mentioned as files-to-be-saved. It's up to the versions controller to take care of this.
-
-{{{  FileVersion[] getRevisionData(String revision, File... files);}}}Get a specific version of the files requested, given a revision indentifier. The label is either a property also provided by the !-VersionInfo-! object (typically name) or null, denoting the most recent version.
-
-{{{  Collection<? extends VersionInfo> history(File... files);}}}Obtain the history of a page. The history is as big as the depth set by setHistoryDepth(int) (see below).
-
-{{{  void addDirectory(FileVersion... files) throws IOException;}}}Create a new (versioned) directory. This operation is called from the http://files/ handlers.
-
-{{{  void rename(FileVersion fileVersion, File originalFile) throws IOException;}}}Rename a versioned file. This operation is called from the http://files/ handlers.
-
-{{{  void delete(FileVersion... files);}}}Delete the page. The author has to be set to the user performing the delete operation.
-
-{{{  void setHistoryDepth(int historyDepth);}}}Configure the depth for which versions need to be stored (in case of zip files) or the history depth for which changes are fetched (see history() above)
-
-!2 What happened to !-CmSystem-!?
-In older versions the convention was to create a !-CmSystem-! class: a class that fulfilled the !-CmSystem-! protocol. Although this appeared to work fine on paper the real world version had some downsides. For one it was not in control with the saving of the content, now the !-VersionsController-! is in charge of this. Also the protocol was quite cumbersome and it involved Java introspection logic to get it working. Why does your wiki page have to "know" about version control anyway...
-
-The !-VersionsController-! solution will be more solid can be made to provide generic solutions towards version control in FitNesse.

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/SourceCodeControl/properties.xml

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<Help>Hook up FitNesse to your source code management tooling</Help>
-<RecentChanges/>
-<Search/>
-<Static/>
-<WhereUsed/>
-<saveId>1232134793876</saveId>
-<ticketId>-8719944065822967118</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/StartingAndStoppingFitNesse/content.txt

@@ -1,29 +0,0 @@
-!2 Starting FitNesse
-To start Fitnesse, invoke the fitnesse-standalone.jar file like this:
-
-!style_code(java -jar fitnesse-standalone.jar)
-This will start a wiki server listening on port 80.  You can modify this and other options using a CommandLineArguments.
-
-See PasswordFile for a description of how to set up per user authentication.
-
-!2 Running Rest Commands using the -c option.
-See RestfulServices
-
-!2 Stopping FitNesse
-Pressing ''ctrl-c'' generally works well for development use.  However, it's not sufficient for automated control.
-
-There are now ''stop.bat'' and ''stop.sh'' scripts to stop a running server. Invoke them with the same '''-p port_number''' option used to start the server.
-
-Both scripts run java with a class to stop FitNesse. You can invoke this class directly, as well:{{{Usage: java fitnesse.Shutdown [-pa]
-        -h <hostname> {localhost}
-        -p <port number> {80}
-        -c <username> <password> Supply user credentials.  Use when FitNesse has authentication activated.
-}}}This command will send an HTTP request to the designated server.  If the server is using authentication then the '''-c''' option should be used with appropriate username and password.
-
-Alternatively you may manually type a URL to shutdown a server. http://hostname:port/?responder=shutdown
-
-!2 Running from JUnit
-see [[!-RunningFromJunit-!][<UserGuide.WritingAcceptanceTests.RunningFromJunit]]
-
-!2 Running from Maven
-see [[!-RunningFromMaven-!][<UserGuide.WritingAcceptanceTests.RunningFromMaven]]

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/StartingAndStoppingFitNesse/properties.xml

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<properties>
-<Files/>
-<Help>The details of starting and stopping the FitNesse wiki/web server.</Help>
-<Normal/>
-<RecentChanges/>
-<Static/>
-<WhereUsed/>
-<saveId>1213818998677</saveId>
-<ticketId>5252078302071996298</ticketId>
-</properties>

data/XCFitDemo/FitNesseRoot/FitNesse/UserGuide/AdministeringFitNesse/WikiTheming/content.txt

@@ -1,53 +0,0 @@
-(new since April 2012)
-
-As of April 2012, !-FitNesse-! has a new layout. There are a few reasons for making this (incompatible) change:
-
- * !-FitNesse-! had quite a techie edge to it. The menu items were not well structured and some pages looked messy (like Search)
- * Web standards have evolved, so should !-FitNesse-!
- * Lots of markup was generated directly from java code, now [[Velocity][http://velocity.apache.org]] is performing the rendering
- * !-FitNesse-! was not easy to customize
- * The web interface looked old fashioned. Having a fresh look and feel appeals to people (yes it does)
- * !-FitNesse-! style related files (css, javascript, templates) were put in !-FitNesseRoot-!. This is not desired since it mixes application files with user data (with pages)
-
-So here you are, in your new !-FitNesse-!, with a look and feel you're not accustomed to. How to deal with that?
-
-!2 Theming to the rescue
-One of the benefits you'll have from the new layout is that the page L&F is easier to change. !-FitNesse-! comes with a few styles built-in:
-
- * ''fitnesse_straight'' - the default style
- * ''fitnesse_mint'' - a classy style
- * ''fitnesse_topnav'' - a minimalistic style
- * ''bootstrap'' - uses [[Twitter Bootstrap][http://twitter.github.com/bootstrap]] as a basis for its styling
-
-For all styles the HTML remains the same. The default style can be configured through ''plugins.properties'', !-FitNesse-!'s settings file (this is where you also configure custom symbols). Add the line
-
-{{{
-Theme=fitnesse_mint
-}}}(re)start !-FitNesse-! and the style will have completely changed.
-
-Apart from the layout style, fitnesse loads a few stylesheets by default: ''fitnesse_pages.css'' and ''fitnesse_wiki.css''. Both files serve the boilerplate for pages (like the properties page) and the wiki text.
-
-!2 Rolling your own
-FitNesse still has the ability to support custom user styling. In [[!-FitNesseRoot/files/fitnesse-!][/files/fitnesse]] you can place your own files. Stylesheets go in a ''css'' directory, Javascript in ''javascript'' and images are filed in the ''images'' folder (note: those directories are not present by default, you'll have to create them by hand).
-
-Now say you want to create your own style, named ''my-style''. You'll need to create a stylesheet ''!-FitNesseRoot/files/fitnesse/css/my-style.css-!'' and an optional Javascript file ''!-FitNesseRoot/files/fitnesse/javascript/my-style.js-!''.
-
-The stylesheet can contain just your own styling or a combination of existing styles with your own additions on top of it.
-
-To reuse one of the existing styles as an entry point, create a custom css file and import the base style you like to use, e.g.:
-
-{{{
-@import url(fitnesse_straight.css); 
-}}}Now you can simply add custom elements to it.
-
-!3 Create a theme based on Bootstrap
-The Bootstrap theme took a slightly different route. It's using a subfolder for it's resources. The skeleton.vm template  ([[files/fitnesse/bootstrap/templates/skeleton.vm][http://files/fitnesse/bootstrap/templates/skeleton.vm]]) contains the general markup and layout. It also contains references to the other resources used. You can find the resources used to compile the bootstrap style (lesscss templates) in fitnesse.jar: fitnesse/resources/bootstrap/less. Use those as a basis for the custom theme. There are a few more template files that are overwritten by the bootstrap theme. If the theme needs to be reusable, refer (''#parse'') the the bootstrap templates for a start and add your own customisations along the way.
-
-!2 Packaging themes
-It's also possible to distribute themes in jar files (for example if you want to support a corporate theme for all your !-FitNesse-! projects). For that, package the css and javascript in a jar file, like this:
-
- * fitnesse/resources/css/my-style.css
- * fitnesse/resources/javascript/my-style.js
- * fitnesse/resources/images/some-image.png
-
-Add the jar file to your classpath and define the style (''my-style'') in your ''plugins.properties''.