old tags lost

[Lubomir I. Ivanov]

hello,

On 13 December 2013 20:35, Thomas 'Mike' Michlmayr <mike at cluon.priv.at> wrote:
> On Fri, Dec 13, 2013 at 07:10:24 -0800,
> Dirk Hohndel <dirk at hohndel.org> wrote:
> [...]
>> If you have a good idea of how this should work and how a non-technical
>> (and I mean seriously non-technical) user would interact with it, I'd be
>> interested to hear that.
>
> i'd make the user "not" interact with it. i'd change around what gets
> done behind the scene when the user interacts with the app as usual.
>
> my VCS experience is limited to RCS and a bit of SVN, so i'll try to
> explain it in my understanding of SVN.
>
> on first startup, make sure you have a (local) repository with an empty
> data file in it. when the user starts editing dives, flush the file to
> the repository at strategic places in the code.
> when the user saves (using cmd/ctrl-s), flush the file to disk and commit
> the changes.
>

i'm not sure that by 'local' you mean a remote i.e. a repository on
the subsurface website (1) or a local repository on the user pc (2).

both are very complicated to achieve:
1) massive amount of bandwidth and server meltdown if we attempt the
stunt to maintain a branch for each user that tires to push changes
via some sort of a protocol that connect to a shell and then invokes
git to commit changes for him. prone to hacks and massive amount of
*fun*.
2) local installation bundling of SCM (or like you say RCS) is a waste
of disk space and developer brain power investigating installation
procedures. git on windows as an example is not an easy toy to install
and it's 200 mb, as for example it may come bundled with MSYS
(msys-git).

> when the user quits the app, if there are uncommitted changes, ask him
> if he wants to save (commit) or not (rollback).
>
> if the app crashes, you can have three possible states:
>    * a corrupt file: revert to head from the repository
>    * a clean file: no action required
>    * a file with uncommited changes: ask the user if we wants to start
>         from last known good state (head) or last state before crashing
>
> i have no idea how to change all of this to git terms (i'd not use anything
> else today). and if the user has access to a remote git repository, we can
> allow him to specify this and give him a menu option to push out the changes.
>
> all of this is 100% transparent to the user, allows hackers to use all git
> magic on the local repo, and would give more crash resilience and protection
> from (stupid) changes.
>
> there are some additional complexities: subsurface currently supports
> multiple data files, but i think this could easily done within the same
> repository. the only thing that would no longer be permitted is to move
> files around outside of subsurface's control. on mac that's easy, store
> it in ~/Library. on linux in .subsurface. on windows it would be in the
> profile somewhere where there's normally no fs access.
>
> but maybe i'm totally underestimating the complexities.
>

i think the user should maintain his own version history, manually.
the same applies to backup-ing photos or valuable documents. if he's a
developer obviously much easier for him as he can use SCM.

as an alternative to sort the divelog backup issue is to maintain
version history in the log file itself with non-casual (read as "back
in time") linearity.

an example would be:
[current log]
[log -1]
[log -2]
[log -3]
[log -4]
...
[limit]

then we can provide the means to revert to [log -3] from the UI,
discarding say a corrupt [log -2] entry, becoming:

[current log]
[log -4]
...
[limit]

obviously this will inflate the logfile a lot and there won't be an
easy to go to [log -2] from [log -3] (i.e. forward in time).
again, not sure if this is a waste of dev. time.

lubomir
--