web commit by AlesandroDottiContra

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

diff --git a/doc/about_rcs_backends.mdwn b/doc/about_rcs_backends.mdwn
index 4aba78fc043232a0d539e657b693cbd812f9ab2a..1aafd4a8ee50ad412b9f0546c247c359f5c6a012 100644 (file)
--- a/doc/about_rcs_backends.mdwn
+++ b/doc/about_rcs_backends.mdwn
@@ -1,16 +1,16 @@
-## A few bits about the RCS backends
+# A few bits about the RCS backends

 
 

-### Terminology
+## Terminology

 
 ``web-edit'' means that a page is edited by using the web (CGI) interface
 as opposed to using a editor and the RCS interface.
 
 
 
 ``web-edit'' means that a page is edited by using the web (CGI) interface
 as opposed to using a editor and the RCS interface.
 
 

-### [[Subversion]]
+## [[Subversion]]

 
 Subversion was the first RCS to be supported by ikiwiki.
 
 
 Subversion was the first RCS to be supported by ikiwiki.
 

-#### How does it work internally?
+### How does it work internally?

 
 Master repository M.
 
 
 Master repository M.
 


@@ -22,15 +22,18 @@ HTML is generated from W.  rcs_update() will update from M to W.
 
 CGI operates on W.  rcs_commit() will commit from W to M.
 
 
 CGI operates on W.  rcs_commit() will commit from W to M.
 

+For all the gory details of how ikiwiki handles this behind the scenes,
+see [[commit-internals]].
+

 You browse and web-edit the wiki on W.
 
 
 You browse and web-edit the wiki on W.
 
 

-### [darcs](http://darcs.net/) (not yet included)
+## [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).
 
 
 Support for using darcs as a backend is being worked on by [Thomas
 Schwinge](mailto:tschwinge@gnu.org).
 

-#### How will it work internally?
+### How will it work internally?

 
 ``Master'' repository R1.
 
 
 ``Master'' repository R1.
 


@@ -45,29 +48,45 @@ There is a working copy of R1: R2.
 CGI operates on R2.  rcs_commit() will push from R2 to R1.
 
 You browse the wiki on R1 and web-edit it on R2.  This means for example
 CGI operates on R2.  rcs_commit() will push from R2 to R1.
 
 You browse the wiki on R1 and web-edit it on R2.  This means for example

-that R2 needs to be updated from R1 if you are going the web-edit a page,
+that R2 needs to be updated from R1 if you are going to web-edit a page,

 as the user otherwise might be irritated otherwise...
 
 How do changes get from R1 to R2?  Currently only internally in
 as the user otherwise might be irritated otherwise...
 
 How do changes get from R1 to R2?  Currently only internally in

-rcs_commit().  Is rcs_prepedit() suitable?
+rcs\_commit().  Is rcs\_prepedit() suitable?

 
 It follows that the HTML rendering and the CGI handling can be completely
 separated parts in ikiwiki.
 
 What repository should [[RecentChanges]] and [[History]] work on?  R1?
 
 
 It follows that the HTML rendering and the CGI handling can be completely
 separated parts in ikiwiki.
 
 What repository should [[RecentChanges]] and [[History]] work on?  R1?
 

-##### Rationale for doing it differently than in the Subversion case
+#### Rationale for doing it differently than in the Subversion case

 
 darcs is a distributed RCS, which means that every checkout of a
 repository is equal to the repository it was checked-out from.  There is
 no forced hierarchy.
 
 
 darcs is a distributed RCS, which means that every checkout of a
 repository is equal to the repository it was checked-out from.  There is
 no forced hierarchy.
 

-R1 is the nevertheless called the master repository.  It's used for
+R1 is nevertheless called the master repository.  It's used for

 collecting all the changes and publishing them: on the one hand via the
 rendered HTML and on the other via the standard darcs RCS interface.
 
 collecting all the changes and publishing them: on the one hand via the
 rendered HTML and on the other via the standard darcs RCS interface.
 

-R2, the repository where CGI operates on, is just a checkout of R1 and
+R2, the repository the CGI operates on, is just a checkout of R1 and

 doesn't really differ from the other checkouts that people will branch
 off from R1.
 
 (To be continued.)
 doesn't really differ from the other checkouts that people will branch
 off from R1.
 
 (To be continued.)

+
+
+## [[Git]]
+
+Regarding the Git support, Recai says:
+
+I have been testing it for the past few days and it seems satisfactory.  I
+haven't observed any race condition regarding the concurrent blog commits
+and it handles merge conflicts gracefully as far as I can see.
+
+As you may notice from the patch size, GIT support is not so trivial to
+implement (for me, at least).  Being a fairly fresh code base it has some
+bugs.  It also has some drawbacks (especially wrt merge which was the hard
+part).  GIT doesn't have a similar functionality like 'svn merge -rOLD:NEW
+FILE' (please see the relevant comment in mergepast for more details), so I
+had to invent an ugly hack just for the purpose.