zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

David,

First have a look at the "Version Control" plugin in zim. It in fact
already has some support to deal with Mercurial, Git and Bazaar. We simply
call them as separate commands, no need to use integrated libraries.

>From that you would want functions to push and pull revisions. This can be
done by defining a few scripts in the "Tools" -> "Custom tool" menu.

Agreed these tools already take care of merging, so 90% of the time there
should be no issue. However if there is a merging conflict, the user should
stop editing and first fix the conflict before pushing new revisions. This
may be straightforward for technical users, but is not convenient.

This is were the idea on conflict resolution comes in. This feature would
allow to have to versions of the page and commit both (as separate files)
to the repository. That way you can keep editing and post-pone the merging
conflict to a next cyclus. It is inspired by the way conflicting versions
of a data object can co-exist in couchdb.

So from the steps you describe, this only covers the final step - the
version control integration is already in a large part available.

Hope this clarifies,

Jaap




On Thu, Oct 10, 2013 at 10: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
>
>