Hi Andrew, Thanks for sharing your experience and advice. Actually, there might be more issues luring under the surface: for some tight control over access rights of certain notes might be an issue. However, what I like about the Zim format is that it is also easily available and searchable in an off line mode. With colleagues going out on meetings and conferences while taking notes, this might not always be straight forward to solve with an online wiki. Convincing our central IT department of running such a Wiki which can be approached from the outside world is another non trivial internal political issue. How well such a collaborative notebook would scale in a 30 person group is a very good question. I am not even sure I will have the chance the figure it out :-) Some people find it sufficient to either have no shared meeting reports at all or simple throw around Word documents over the mail and/or shared network drive.
I agree with the simple proof of concept idea, and you are probably right that it would be very difficult to make this process work without ever resolving diff conflicts of any kind. Although that might not always work nicely, I do think/hope you could make some less strict merging rules compared to code: a bunch of notes do not always have a strict order. If a bunch of bullets get interchanged with another group committed by another user, that doesn't necesarly need to end in a merging conflict. It just requires someone to re-organize the document if the automated merger doesn't get it right. That is a lot more simple and straight forward compared to dealing with n-way diffs for non tech users. You could flag pages that have been merged using some "creative" rules and warn users that certain sections (that are highlighted for instance) need verification. I think the goal should be to abstract away the git/hg/bzr pulling/pushing and merging conflicts and present them as simple to be reviewed edits in the Zim notebook (I think this point is also mentioned on the bounty page on resolving merge conflicts). In that way merge conflicts might require several simple iterations (by possibly multiple users) before they are fully solved. Thanks again for your pointers. Best regards, David On 13 October 2013 15:54, Andrew Buchan <[email protected]> wrote: > 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 <[email protected]>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 : [email protected] >> Unsubscribe : https://launchpad.net/~zim-wiki >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : [email protected] Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
