zim-wiki team mailing list archive

[Andrew Buchan <andyhasit@xxxxxxxxx>]

David,

I like the efficiency of working with Zim, but wouldn't necessarily say
it's the best for a highly collaborative environment with non-techie
people, especially if they will potentially have to deal with source
control issues (commit, push, pull etc...).

Even if you manage to automate the whole source control quite seamlessly,
there's still a chance it will come to the surface. At which point you will
be asked to explain why you chose a solution that involves gluing together
a desktop app + source control instead of using one of the many web-based
wikis which handles most of what you need out of the box.

Having said that, we do use small Zim wikis inside software projects,
keeping the zim files in a directory which is under Mercurial source
control along with the rest of the source code. This works fairly well
thanks to Mercurial's ability to merge modified files, but you do have to
do manual merges and at least understand what's going with regards to
source control, and you occasionally get a Kdiff window thrown at you.
We did experience funny issues with the tree-view in the user interface,
and found it was best to exclude the index.db and state.conf files from
source control. Zim complained a lot less when these were kept locally, and
if funny things happen you can always wipe those files and Zim will rebuild
them.

Here's what part of the .hgignore file looks like (our wikis are in a dir
called "Doc") should this be of any use to you:

syntax: glob
Doc/.zim/**

With regards to automating push and pulls, a cheap hack you can do is to
force users to use a custom shortcut to open Zim, which fires of any hg
commands you need before actually opening Zim. You could surely write a
small python script which does all the the push/pull/warn and then runs Zim
if everything is OK (it could even wait for Zim process to end and do
commits at the end, but I'd think carefully about that).

This may be enough for you to trial the whole proof of concept, and see
what kind of issues you may come up against, before you invest serious time
into making the solution work.

All the best,

Andrew.




On Thu, Oct 10, 2013 at 9:16 PM, David Verelst <david.verelst@xxxxxxxxx>wrote:

> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~zim-wiki
> Post to     : zim-wiki@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~zim-wiki
> More help   : https://help.launchpad.net/ListHelp
>
>