RFC: Initial git save format

[Robert C. Helling]

On 07 Mar 2014, at 01:20, Linus Torvalds <torvalds at linux-foundation.org> wrote:

Hi everyone,

just a few comments.

> - turn the current subsurface directory into a git repository
> (~/subsurface/ on Linux, ~/Library/Application Support/Subsurface on
> MacOS, and CSIDL_APPDATA/Subsurface/ on Windows)
> 


I hope you mean something like ~/.subsurface or even ~/.subsurfacerc . At least for me ~/subsurface is already a git repository and is my subsurface working directory (containing the source).


> […]

> *Eventually* we definitely want to have a way to do the network syncing part.
> 
> I do *not* believe that we want to have people doing "git pull/push"
> to sync to some repository in the cloud, but I do think that one of
> the big advantages of the git model is that it will make that syncing
> much easier. And we'll need some gui thing to set that up etc.
> 
> I think some of those interfaces will inevitably be outside of
> subsurface (ie setting up an account on github or whatever), but I
> suspect there's a few things we'd want to do.

You realise that some people already are dealing in a way with “network syncing part” without git: They have their default .xml in a Dropbox or similar. This might be a poor choice with respect to merging and privacy but it is dead simple and thus often enough sufficiently good. This we would break by “forcing” the new format upon users (not only directory wise but having some version control inside a Dropbox sounds like asking for trouble). I would therefore make the transition to the new format optional in the preferences (maybe offered by some dialog on start-up) and leave the possibility to have the default file in old xml format at least until the network sync part is solved (also GUI wise).

How do you see the network sync to be realised? Is every subsurface user supposed to run some sort of server reachable by ssh for their own? Are we suggesting to use github (which is free only if you make your repositories non-private) or are we going to run a Subsurface-cloud (i.e. hosting repositories ourselves)?

As a final remark: My experience with guiding non-programmers to use version control (be it git, subversion or whatever) works well as long as things are easy (I force my collaborators when writing physics papers to do this for example). But only until there is a merge conflict. Even if you show them how to resolve it when you show them how to use version control, they will have forgotten it when it happens (as it happens very rarely). And things get worse when these users try to fix it themselves (which in most cases means they manage to check in a version that still has conflict markers). In short, all I am saying, to make this work and not make people angry and have the opinion that your software is a piece of shit, we have to make sure, the enduser will never see a conflict that has to be resolved using a text editor rather than pressing one button or the other (basically saying “all theirs/all ours).

Best
Robert


--                                                                              
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO 
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics  
                      Scientific Coordinator                                   
                      Ludwig Maximilians Universitaet Muenchen, Dept. Physik    
print "Just another   Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339       
    stupid .sig\n";   http://www.atdotde.de