[pmwiki-devel] Subversion PageStore Design

Patrick R. Michaud pmichaud at pobox.com
Wed Nov 14 15:06:43 CST 2007


Just a few thoughts and reactions...

On Wed, Nov 14, 2007 at 08:24:28AM +1100, Kathryn Andersen wrote:
> On Tue, Nov 13, 2007 at 06:43:32AM -0500, Stirling Westrup wrote:
> > Kathryn Andersen wrote:
> > > - How would one do diffs for "history" pages?  I'm not quite clear how
> > >   pmwiki does that stuff, I haven't looked.
> > 
> > Currently pmwiki stores diffs inside the page as attributes. We would want to
> > use the SVN diff functions instead, as this is one of the main reasons to move
> > to an SVN pagestore.
> 
> Oh yes, I realize that one would be using svn diffs, I just wasn't sure
> how one would convert that into something that could be used by PmWiki
> history pages.

One would likely want to change the code for ?action=diff so that
instead of showing a history of changes it provides an interface
to view changes between any pair of versions of a page.  This has
been commonly requested, and it wouldn't be too difficult to
extend PageStore to have an interface for this for existing pages
(which the subversion PageStore could override for a subversion
repository).

> > With SVK, I worry that there might be far more hairy scenarios, in which two
> > different and conflicting distributed changes have occurred to the same file,
> > which we only find out about when we do an update.
> 
> Well, how does SVK itself deal with conflicts?

I don't know about SVK, but svn deals with conflicts pretty
much the same way that PmWiki does now -- by highlighting the
conflicts in the current file and requiring them to be resolved
and re-committed.  (PmWiki's simultaneous edit capability is
modeled after the conflict resolution available in cvs and svn.)

But I'm not sure how one would handle this in an offline context,
such as what svk does.  Perhaps the suggestion of simply leaving 
the conflict in place and allowing the next editor to resolve it 
is the best here.

> > > - How would one deal with creating/committing new directories 
> > > (for wiki page formats which have pages in separate directories 
> > > for example).
> > 
> > This seems very straight forward. Maybe I'm not seeing the problem you are
> > anticipating. Can you explain?
> 
> I guess I'm just betraying that I'm not familiar with what PmWiki itself
> does when it needs to create new directories.

PageStore objects don't have to be tied to directory structures,
so a svn-based pagestore is free to organize files in the PageStore
however it wishes.  (The whole point of PageStore is to make the
underlying storage mechanism somewhat transparent.)

PmWiki provides a mkdirp() function that can be used to automatically
create new directories and make sure they have appropriate permissions.
Of course, a svn-based PageStore would also have to make sure that
any newly created directories are added and committed to the repository.

> > > A. Commits are done immediately after writing and updating properties.
> > > However, this isn't an atomic action, so how do you prevent someone else
> > > overwriting your file before you do the commit?  I suppose the standard
> > > pmwiki conflict-resolution would do for that.

PmWiki uses transaction-based locking for its operations, so if
one instance is performing an update operation of some sort,
then no others are allowed to proceed until the first one has
finished its transaction.

In other words, having two people overwrite the same file isn't
normally an issue.

> > I think one does an update just before a write, and just before showing the
> > contents of a page for editing. If everyone is going through the same
> > repository, and there is reasonable amounts of editing happening in both
> > places, this should be sufficient.
> 
> I was considering it would make more sense to do an update just before a
> read, to make sure that all pages were up to date when one needed to
> find the actual content of them.

Sounds expensive to do this for every read, or even for every
invocation of PmWiki.

> > Otherwise, I suggest we have some method of determining if any changes have
> > taken place in the repository since the last local update, and do an update
> > after displaying a page (as part of the PmWiki shutdown system, like the way
> > Notify works).

This also sounds expensive.  To my mind, "determine if any changes
have taken place in the repository" involves establishing a connection
to the repository server over a (possibly slow) network.  If you're
running a site that is getting thousands of requests, that's an
awful lot of extra network activity.

Pm



More information about the pmwiki-devel mailing list