[pmwiki-devel] Subversion PageStore Design

[Kathryn Andersen]

On Tue, Nov 13, 2007 at 06:43:32AM -0500, Stirling Westrup wrote:
> Kathryn Andersen wrote:
[snip]
> > A few questions remain, however.
> > 
> > - 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.

So far as I understand, svn diffs require one to know the
revision-number that one is diffing between -- how would one get the
whole diff-history of a particular file?  Would one have to do a svn log
to find all the revision numbers, and then do all the diffs?
 
> > - When would one do updates?
> > - When would one do commits?
> 
> In order to have diffs created whenever pmwiki would have created them, we
> would need to do an update and commit on every single page save. I don't think
> this would usually be a problem though, as it would have one of two effects:
> 
> A) There had been no remote changes to the wiki since the last update/commit
> cycle, so it would just work.

Yep.
 
> B) Since there had been no local changes since the last update/commit cycle
> (assuming all changes are going through the wiki),

Big assumption, if one allows for detached operation.

> any new updates for pages
> other than the currently edited page would simply succeed. The currently
> edited page may end up in conflict, in which case we use the same conflict
> resolution method already in pmwiki (which was borrowed from tools like diff
> and svn in the first place).
 
> 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'm not sure how to resolve
> that, other than have a way to mark a page as 'in conflict' in the pagestore,
> and have the next person who looks at it deal with it in some way. I can
> imagine some scenarios like:
> 
> A) Display all versions (serially, or with change marks or something) and hope
> the next editor cleans up the mess.
> B) Display the last non-conflicted version, but somehow visually flag the page
> as conflicted. The next editor is required the resolve the mess.
> 
> I'd have to do some research into SVK to see what other possible problems we
> could run into.
 
> > - How would one know what repository to make commits to?
> 
> I'd want to make use of the fact that SVN stores the repository name in the
> hidden directories it creates when it manages files. If you try to make a
> pagestore in a directory that is already under SVN control, it just uses the
> same repository, I would think.

Yes, that's what I thought, but I was concerned about the initial setup
of SVN control.
 
> For other cases, we would want there to be an optional extra parameter to the
> new pagestore command, just as the current one takes a directory name. I
> imagine we'd also have a config variable called something like $SVNRepository
> to pass when we create new directories and such.

I'm not sure I'd want to have an external config variable, since that
assumes that there's only one repository being used, and there might not
be -- it just seems like an unneccessary limitation.
Having the extra parameter to the pagestore command makes more sense.
 
> > - 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.
 
> > The "when would one do commits?" question has a number of
> > ramifications, including conflict resolution, and whether or not one
> > could operate "detached" on a laptop (as someone suggested in the thread
> > on the pmwiki list).  I can see a number of problems arising.
> > 
> > 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.
> 
> Yup. I think this is the way to go. The standard conflict resolution system
> should work fine.
 
> > However, this doesn't allow work to be done detached on a laptop.
> > So maybe there would have to be some sort of global option which could
> > be turned on to disable commits while that person is working detached,
> > and then they would have to commit by hand when they were attached
> > again.
> 
> If one wants to do detached work on a laptop, then I can think of several
> possibilities:
> 
> A) Use SVK instead of SVN, as it has the concept of detached commits to a
> local version of the repository.

The advantage of this is, yes, we have the same "all saves are commits"
thing which deals with version history well.
 
> B) The detached flag you mentioned. We would probably need to supply some sort
> of automatic update system for resynchronizing though, and it could get hairy.
> There is also a question of where we would store the diffs and metadata if we
> aren't going through a repository in this mode. PmWiki won't really work if we
> don't have things like title, author, etc stored SOMEWHERE. We'd pretty much
> be forced to go back to the old pagestore method when in detached mode.

That sounds messy. 8-(
 
> C) Insist on there being a laptop repository of its own, and provide some
> mechanism for a repository-to-repository merge.

Which is just SVK under another guise.
 
> > Likewise, "when would one do updates?" could have some conflict problems
> > -- does one do an update just before one reads a page?  After one does a
> > write?  Both?
> 
> 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.
 
> 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).

I'm not familiar with that.
 
> This latter system would mean that if you have one site where all your editors
> work, and another copy which everyone else is reading, they would tend to stay
> in synch.

That would be a good thing.

Kathryn Andersen
-- 
 _--_|\     | Kathryn Andersen	<http://www.katspace.com>
/      \    | 
\_.--.*/    | GenFicCrit mailing list <http://www.katspace.com/gen_fic_crit/>
      v     | 
------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere
Maranatha!  |	-> Earth -> Sol -> Milky Way Galaxy -> Universe