emded revision control in Python application?

[duncan smith]

On 22/06/12 21:34, Emile van Sebille wrote:
> On 6/22/2012 11:19 AM duncan smith said...
>> On 22/06/12 17:42, Emile van Sebille wrote:
>>> On 6/22/2012 8:58 AM duncan smith said...
>>>> Hello,
>>>> I have an application that would benefit from collaborative working.
>>>> Over time users construct a "data environment" which is a number of
>>>> files in JSON format contained in a few directories
>
> So, will the users modify their local environment and you'd push the
> revisions to a known location for redistribution?

Yes. My rough idea is that each time a user opens the application it 
will connect to a server and download the current data environment (or 
preferably just the changes made since the application was last 
connected). Thus the user can start with an up to date environment. As 
the application is used to make changes to the data environment any 
changes are uploaded to the server for immediate redistribution to other 
connected application instances.

Part of the application involves the construction of directed acyclic 
graphs. If I add an edge to a graph I want anyone else editing the same 
graph to be able to see the edge in something approaching real time so 
that cycles are avoided. (Being able to lock the file so that only one 
user can edit it concurrently might be another solution to this specific 
issue.)

How might peer-to-peer
> work? How would you know which peers get the change, or would all peers
> get the change?
>

All peers. I'm not sure about the peer to peer thing though. It would be 
better if the user could be guaranteed that the environment they see is 
current, rather than having changes residing on someone else's machine 
that happens to be switched off. I suppose the alternative must be that 
the information is sat on a server somewhere.

> I've been working with rpyc (in as much spare time as I can manage) on
> some similar sounding issues and am now settling on a central system
> which provides convenient administration and potential relaying or
> pulling. See http://rpyc.sourceforge.net/
>
> I just tested my in-process development status and find 64 remote
> machines up and 5 non-responsive which in my case are likely machines
> that are not yet configured properly. As this has been on the back
> burner the past two months I'm pleased with how it's fared in the face
> of neglect.
>
> At least with rpyc (which does have a low learning curve) you'll be
> fully in python.
>

Yes, it looks very interesting. Cheers.

Duncan