RFC: Initial git save format

[Dirk Hohndel]

On Fri, 2014-03-07 at 13:03 -0800, Linus Torvalds wrote:
> On Fri, Mar 7, 2014 at 12:45 PM, Robert C. Helling <helling at atdotde.de> wrote:
> >
> >
> > 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).
> 
> I actually did mean "~/subsurface".

I always thought that was an odd choice :-)

> We already treat that directory specially, and look up the "$USER.xml"
> file there by default.
> 
> That said, I agree that it's likely a bad idea. In your case, if you
> ever do "git clean", for example, that will remove your xml file.
> 
> > You realise that some people already are dealing in a way with “network syncing part” without git:
> 
> That's fine. You can continue to do that, you'd just use "export as
> xml" instead. Or, if the special subsurface user branch never gets
> created, the git logic would never trigger anyway by default - even if
> it's a git repository.

So I spent some more time thinking about this earlier this morning but
hadn't gotten around to write it all down. There may still be flaws in
the logic, but let's give this a try

Subsurface is in one of two 'states'. XML-state or git-state.

New user, doesn't have any configuration -> git-state
Existing user, has an XML file set as Default file -> XML-state
Preference setting that allows user to overwrite and set the state
(clearly not called that... something like "use Subsurface's data
storage engine or always write XML files?"

In XML-state it behaves exactly as it does today.

In git-state the "filename" is actually a directory name and in that
directory we create a git repository with the branch named after the
user. It might be possible to overwrite the branch name in advanced
preferences. Subsurface can still "Export to XML" and of course open /
read / import XML files. Just the default Save / Save As now creates git
repositories instead.

I am thinking that in XML mode we might want to change the menu entries
to read "Save XML" and "Save XML As..." or something.

As for merging? I think we can never allow the user to see a merge
conflict. Simply keep both sides and create a new dive. Or if that isn't
possible, keep the change with the later time stamp.

What is still unsolved in my mind is the UI we provide for people to
take advantage of the version control. My guess is that we need some
form of 'step by step rollback' or something along those lines.

What is also still unsolved is the network solution. My expectation was
that we tell people to get accounts "somewhere" and point to that
repository. Bitbucket for example allows free private git repositories.
But I'm not sure about the UI here. The backend side would check for
access to the remote repository, sync the local repository, then
read/write the local repository and sync back to the remote repository.
I think every write (save) to the local repository should trigger an
attempt to sync remotely.

/D