You browse and web-edit the wiki on W.
+W "belongs" to ikiwiki and should not be edited directly.
+
## [darcs](http://darcs.net/) (not yet included)
Support for using darcs as a backend is being worked on by [Thomas
-Schwinge](mailto:tschwinge@gnu.org).
+Schwinge](mailto:tschwinge@gnu.org), although development is on hold curretly.
+There is a patch in [[todo/darcs]].
### How will it work internally?
This approach might be applicable to other distributed VCSs as well, although they're not as oriented
towards transmitting changes with standalone patch bundles (often by email) as darcs is.
+> The mercurial plugin seems to just use one repo and edit it directly - is
+> there some reason that's okay there but not for darcs? I agree with tuomov
+> that having just the one repo would be preferable; the point of a dvcs is
+> that there's no difference between one repo and another. I've got a
+> darcs.pm based on mercurial.pm, that's almost usable... --bma
+
+>> IMHO it comes down to whatever works well for a given RCS. Seems like
+>> the darcs approach _could_ be done with most any distributed system, but
+>> it might be overkill for some (or all?) While there is the incomplete darcs
+>> plugin in [[todo/darcs]], if you submit one that's complete, I will
+>> probably accept it into ikiwiki.. --[[Joey]]
+
## [[Git]]
Regarding the Git support, Recai says:
FILE' (please see the relevant comment in mergepast for more details), so I
had to invent an ugly hack just for the purpose.
+By design, Git backend uses a "master-clone" repository pair approach in contrast
+to the single repository approach (here, _clone_ may be considered as the working
+copy of a fictious web user). Even though a single repository implementation is
+possible, it somewhat increases the code complexity of backend (I couldn't figure
+out a uniform method which doesn't depend on the prefered repository model, yet).
+By exploiting the fact that the master repo and _web user_'s repo (`srcdir`) are all
+on the same local machine, I suggest to create the latter with the "`git clone -l -s`"
+command to save disk space.
+
+Note that, as a rule of thumb, you should always put the rcs wrapper (`post-update`)
+into the master repository (`.git/hooks/`) as can be noticed in the Git wrappers of
+the sample [[ikiwiki.setup]].
+
## [[Mercurial]]
The Mercurial backend is still in a early phase, so it may not be mature
If you have any question or suggestion about the Mercurial backend
please refer to [Emanuele](http://nerd.ocracy.org/em/)
-## [[tla]]
\ No newline at end of file
+## [[tla]]
+
+## rcs
+
+There is a patch that needs a bit of work linked to from [[todo/rcs]].
+
+## [Monotone](http://monotone.ca/)
+
+There is a patch in [[bugs/Monotone_rcs_support]]. It works, but its conflict handling is a little ugly.
+
+In normal use, monotone has a local database as well as a workspace/working copy.
+In ikiwiki terms, the local database takes the role of the master repository, and
+the srcdir is the workspace. As all monotone workspaces point to a default
+database, there is no need to tell ikiwiki explicitly about the "master" database. It
+will know. (BTW - this is also true of subversion. It might be possible to simplify the svn config?)
+
+The patch currently supports normal committing and getting the history of the page.
+To understand the parallel commit approach, you need to understand monotone's
+approach to conflicts:
+
+Monotone allows multiple micro-branches in the database. There is a command,
+`mtn merge`, that takes the heads of all these branches and merges them back together
+(turning the tree of branches into a dag). Conflicts in monotone (at time of writing)
+need to be resolved interactively during this merge process.
+It is important to note that having multiple heads is not an error condition in a
+monotone database. This condition will occur in normal use. In this case
+'update' will choose a head if it can, or complain and tell the user to merge.
+
+For the ikiwiki plugin, the monotone ikiwiki plugin borrows some ideas from the svn ikiwiki plugin.
+On prepedit() we record the revision that this change is based on (I'll refer to this as the prepedit revision). When the web user
+saves the page, we check if that is still the current revision. If it is, then we commit.
+If it isn't then we check to see if there were any changes by anyone else to the file
+we're editing while we've been editing (a diff bewteen the prepedit revision and the current rev).
+If there were no changes to the file we're editing then we commit as normal.
+
+It is only if there have been parallel changes to the file we're trying to commit that
+things get hairy. In this case the current approach is to
+commit the web changes as a branch from the prepedit revision. This
+will leave the repository with multiple heads. At this point, all data is saved.
+The system then tries to merge the heads with a merger that will fail if it cannot
+resolve the conflict. If the merge succeeds then everything is ok.
+
+If that merge failed then there are conflicts. In this case, the current patch calls
+merge again with a merger that inserts conflict markers. It commits this new
+revision with conflict markers to the repository. It then returns the text to the
+user for cleanup. This is less neat than it could be, in that a conflict marked
+revision gets committed to the repository.
sipb-www / ikiwiki.git / blobdiff