X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/5cd32c2eeeafc5e9f3feae7983fc48a9711462a3..26b20b4cd6dc4d371579091ecd6406c7a87c10e5:/doc/commit-internals.mdwn diff --git a/doc/commit-internals.mdwn b/doc/commit-internals.mdwn new file mode 100644 index 000000000..3a464ffbf --- /dev/null +++ b/doc/commit-internals.mdwn @@ -0,0 +1,20 @@ +Saving this irc transcript here, since it's a fairly in-depth discussion of +how ikiwiki handles commits, locking, etc, and avoids some races while +doing so. + + What happens if I edit a page and in the underground a new version is installed into the svn repository? + The revision when I started editing was saved, right? + what happens, exactly is: + 1. the new version that was committed first get into svn, and ikiwiki updates its WC to have the new version + 2. When you save your edit, ikiwiki detects a conflict. + 3. It uses svn merge to try to resolve it; if it's resolved it adds your changes transparently + 4. If the conflict needs manual resolution, it displays the page with conflict markers in the editor for you to resolve + Ok. + Note that in step 2, it detects the conflict by using svn info to get the current Revision of the page in the WC, and compares that to a revision that is stored when you start to edit the page + that's why rcs_prepedit exists, to get that revision info + But isn't there a race condition? + well, there is locking going on too + ikiwiki won't update the WC in step 1. if another instance of itself is getting the Revision info + Is that lockwiki()? + yeah + note that when it gets the current Revision info of a page during its conflict detection, svn could have changed the page in the repo, and the WC not been updated yet due to the lock, but this isn't a race since the commit will then fail due to a regular svn conflict and the conflict detction will still work.