link to format_escape

[git.ikiwiki.info.git] / doc / about_rcs_backends.mdwn

diff --git a/doc/about_rcs_backends.mdwn b/doc/about_rcs_backends.mdwn
index c92d377843154bce0f9b3f3a267e7dcd433514ff..7af4a952e1f770fa3dd6ffb1f19f95eb13e67e4b 100644 (file)
--- a/doc/about_rcs_backends.mdwn
+++ b/doc/about_rcs_backends.mdwn
@@ -184,13 +184,11 @@ There is a patch that needs a bit of work linked to from [[todo/rcs]].
 
 ## [Monotone](http://monotone.ca/)
 
 
 ## [Monotone](http://monotone.ca/)
 

-There is an unfinished patch in [[bugs/Monotone_rcs_support]].
-

 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
 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?)
+will know.

 
 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
 
 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


@@ -210,36 +208,16 @@ saves the page, we check if that is still the current revision.  If it is, then
 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.
 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.

-All of this should work with the current patch.

 
 It is only if there have been parallel changes to the file we're trying to commit that
 
 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 (implemented but untested) approach is to
+things get hairy.  In this case the current approach is to

 commit the web changes as a branch from the prepedit revision.  This
 commit the web changes as a branch from the prepedit revision.  This

-will leave the repository with multiple heads.  At this stage, all data is saved, but there
-is no way to resolve the potential conflict using the web interface.
-
-In the specific case of a branch caused by a web edit, it may be possible to 
-make monotone use the current web interface.  This may be possible because we
-know that merging between the two revisions we have (the new branch
-and the prepedit revision) involves at most one conflicted file.
-We could use `mtn explicit_merge` to merge the revisions.  If that
-succeeds without conflicts then good.  If that fails, then we could
-use a special lua merge hook to spit out the conflict marked file
-and hand it back to the web interface and then abort the merge.  At the same time, we'd have
-to modify the 'prepedit' data to include both parents so that when
-the user saves again we know we're in this case.
-
-If you get a commit and your prepedit data includes two revids then
-we form a commit manually using the automate interface - same way
-we currently build the micro-branch.  However, while conflicts were being resolved,
-someone could have come
-along and introduced *another* one.  So after forming this merge revision,
-you need to go back and check to see if the workspace revision has changed
-and possibly go through the whole process again.  The repeats until you're
-merged.
-
-The end result of all of this is a system that can resolve all web conflicts without race
-conditions. (And because of the way monotone works it saves all data, including
-both sides of the merge, before the merge.  You can go back later and check that
-the merge was reasonable.)  It still doesn't provide a web-based way of merging multiple
-heads that come in through non-web interaction with monotone.
+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.