After reviewing this proposal again I'm still worried about direct
multi-user usage. Locking single files seems doable, but I see
problems e.g. when you move a file and want to update links in X other
files. Would you need to lock all these files before proceeding ? If
so, lot of code needs to be t
I've made a simple lock mechanism. I believe this lock mechanism should
work both on Windows and Linux (I've only tested on Linux and only on a
local filesystem). I'll test it in windows and shared filesystems later.
2012/3/1 Jaap Karssenberg
> On Thu, Mar 1, 2012 at 11:01 AM, João Santos wrot
On Thu, Mar 1, 2012 at 11:01 AM, João Santos wrote:
> Wouldn't this module: http://packages.python.org/lockfile/lockfile.htmldo the
> job?
>
Afraid not. This module will do locking between multiple processes on the
same system, but it is not suitable for .e.g. multiple systems accessing
the sam
Wouldn't this module: http://packages.python.org/lockfile/lockfile.html do
the job?
As for stale lock files the easiest way to solve it is to allow the user to
override them, but having a timeout value would not be a bad idea.
2012/3/1 Jaap Karssenberg
> On Thu, Mar 1, 2012 at 10:35 AM, João San
On Thu, Mar 1, 2012 at 10:35 AM, João Santos wrote:
> I think the easiest way to implement this is by doing the following:
>
> 1 - User A opens a page. A lock file with a unique ID is created;
> 2 - User B tries to open the same page, it opens read only with a message
> saying that file is being
I think the easiest way to implement this is by doing the following:
1 - User A opens a page. A lock file with a unique ID is created;
2 - User B tries to open the same page, it opens read only with a message
saying that file is being edited and giving the user the option to override
(this allows
On Thu, Mar 1, 2012 at 3:47 AM, wrote:
> I am of the opinion that just like version control, Zim is best served by
> hooking into third-party best of breed tools for specialized functions like
> this. DokuWiki for example tries to do this, but I would turn it off if I
> could, as I keep my DW sou
On Thu, 2012-03-01 at 09:17 +, João Santos wrote:
> Either way, ideally, zim should support simultaneous access to the
> files, for example in a NFS or SMB shared filesystem.
Yupp, that what it all boils down to.
--
Svenn
___
Mailing list: https
Either way, ideally, zim should support simultaneous access to the files,
for example in a NFS or SMB shared filesystem.
2012/3/1 Svenn Bjerkem
> On Thu, 2012-03-01 at 08:02 +, João Santos wrote:
> > The problem with unison is that it is no longer actively developed.
> > And beside that a
On Thu, 2012-03-01 at 08:02 +, João Santos wrote:
> The problem with unison is that it is no longer actively developed.
> And beside that an automatic syncing method would probably be better
> for the average user.
Well, git is also not automatically updating, but SparkleShare
developers put i
The problem with unison is that it is no longer actively developed. And
beside that an automatic syncing method would probably be better for the
average user.
Com os melhores cumprimentos,
João Miguel Cardoso Santos
2012/3/1
> I am of the opinion that just like version control, Zim is best se
I am of the opinion that just like version control, Zim is best served by
hooking into third-party best of breed tools for specialized functions like
this. DokuWiki for example tries to do this, but I would turn it off if I
could, as I keep my DW source files in VCS. If the bzr hook functionality
w
SparkleShare is nice with zim. I notice that due to the frequent
saving in zim, there is a rush of updates being pushed to the git
server. The problem is, as Jaap notes, that if a page changes behind
the scene while somebody is editing a page, there will be a conflict.
--
Svenn
_
Alright, I'm gonna strike when the iron is hot. Both my Python knowledge
and my time is limited to do this myself, but I definitely want this
feature. As a project manager and an open source believer, I see many
opportunities for Zim to become a main tool for small project teams.
So, I want to
Btw. just so you guys are aware, there is a 100,- euro bounty open on
resolving conflicts. This draft is targetting a generic mechanism to show
and resolve conflicts in zim - regardless of the backend (dropbox, bazaar,
...). So far nobody has notified me that they are working on this, so open
for t
Hi,
Together with a friend I'm sharing a Zim notebook for a private project.
We share the notebook via Dropbox. We did toggle the shared notebook
setting.
It is working, but we have to be careful. We are aware about the pitfall
that we can not change the same page at the same time.
However,
I believe the use of DVCS is the best way to use zim as a long-term
wiki. Maybe we should define how it would work; I'm interested in
upgrading the DVCS plugin in this direction.
Damien
On 02/29/2012 05:57 PM, Greg Warner wrote:
Or maybe something like a shared dropbox folder would work. I'm
Or maybe something like a shared dropbox folder would work. I'm not sure
how it does conflict resolution, but it's probably better than nothing and
might be more user friendly than a VCS.
On Wed, Feb 29, 2012 at 9:55 AM, Jaap Karssenberg <
jaap.karssenb...@gmail.com> wrote:
> On Wed, Feb 29, 201
On Wed, Feb 29, 2012 at 5:32 PM, Ulf Bro wrote:
> Is it possible to leave all files on a server, for example on a samba
> server in Linux, and have more people working with it at the same time?
> One person can read what another has written just like in Wikipedia?
>
> Those who have a Windows cli
Is it possible to leave all files on a server, for example on a samba
server in Linux, and have more people working with it at the same time?
One person can read what another has written just like in Wikipedia?
Those who have a Windows client have their Zim running there and those
who have a Linux
20 matches
Mail list logo
