zim-wiki team mailing list archive

[David Verelst <david.verelst@xxxxxxxxx>]

Dear all,

I am considering to use Zim as a tool for collaborative management of
meeting reports (as a starting point) at my working place (a university
department in Denmark). Because I really like Zim (long time user) and care
about open source, I thought to try to implement support for this in Zim.
At this time I don't have any funding for this project, so I will just try
to kick this off in my own time.

I've been playing around with Etherpad, but although it is very nice as an
collaborative editor an sich, you can not use it to manage a whole bunch of
pads transparently. That's where I think Zim really shines: organizing rich
notes. My gut feeling indicates that it might be "more easy" (whatever that
means) to implement a collaborative Zim notebook using Git (to start with),
compared to creating a nice note organizer for Etherpads on par with Zim's
feature set. I am also way more comfortable with Python compared to all the
shiny webtech that drives Etherpad.

I've been browsing through the mailing list, and found possibly two threads
related to this issue:
* [Zim-wiki] Multi user? https://lists.launchpad.net/zim-wiki/msg01600.html
* [Zim-wiki] Time Stamped Text (TST) plugin
https://lists.launchpad.net/zim-wiki/msg02453.html (on a side note, what is
de status of this project?)
* not the mailinglist but the wiki: Support Resolving Conflicts (
http://www.zim-wiki.org/wiki/doku.php?id=resolving_syncing_conflicts)

How I understand the "Support Resolving Conflicts" wiki page is that
collaborators are working on the same notebook stored on a network drive.
What if each collaborator has its own notebook, and pushes/fetches the
changes to/from a remote repository? In that way you wouldn't need to worry
about how to name and save jointly edited files. Conflict resolution takes
places when pushing/pulling changes to/from the remote repository. I would
assume the challenges here would be to:
* sensible automation of committing to the local repository, and have
manual commit button (which already exists). Too many commits for some
simple changes might be overkill.
* make a very robust automatic merging scheme (there are probably existing
tools available for this)
* possibly merge contributions from more than 2 authors into one document
* automate fetching and pulling from and to the remote repository, and also
add manual fetch/pull buttons

I would assume that from the manual conflict resolution point of view it
doesn't matter whether you are trying to merge commits from a remote
Git/Bzr/Hg branch or to different versions of a file on a network drive. It
think there could even be room for both implementation strategies.

In this context using Mercurial and Git comes very natural, since the
former is written in Python (so no need to parse commands to/from a shell)
and the latter has Python bindings (
https://github.com/gitpython-developers/GitPython). I don't now how that
works with Bzr, is bzr-gtk something similar (
http://wiki.bazaar.canonical.com/bzr-gtk)?

The advantage of using a Git/Bzr/Hg with a remote repository is that you
don't need to be online all the time. Maybe you are working on some notes
on the plane and want to share those changes when back connected or at the
office.

Any pointers, comments, hints or tips alike?

Since this is my first message on this list, I would like to explicitly
share my appreciations to Jaap and the other contributors for creating and
maintaining Zim!

Best regards,
David