On Sun, Jan 15, 2012 at 17:12, Fernando Perez <fperez.net@gmail.com> wrote:
> On Sun, Jan 15, 2012 at 2:23 PM, Brian Granger <ellisonbg@gmail.com> wrote:
>>>> If saves can be performed across network failures, I would like to
>> take the time to think carefully about how we want to solve the
>> version control/autosave issues. It may be that we end up with some
>> sort of autosave that is done in the manner proposed here, but we may
>> find a paradigm that works better. These are exactly the types of
>> things that we could discuss at PyCon.
>>>> I also agree that we really want to avoid cluttering the working dir
>> of the notebook.
>> The other issue here is that we need to start to think about how a
>> full multiuser notebook would affect these things. Because the
>> existing notebook uses different notebook_id's each time the server is
>> started, some kinds of things are difficult. We may need to start
>> persisting information to a db so that we can track information across
>> server runs. This would enable us to save the autosaved versions in
>> the IPYTHONDIR somewhere and refer to them across server runs. Moving
>> in the direction of a multiuser notebook would force us to think about
>> these things.
>> We should certainly try to find a solution that's solid for the long
> run, but I think there are two criteria that are important:
>> - autosaving should work absent a 'real' version control system. The
> answer to data loss prevention in the notebook should not be 'install
> git/mercurial'.
Certainly, though it's quite appropriate that it be significantly
diminished in its functionality. A crude autosave backup should be
fairly straightforward to implement, and if we can't require git, we
will need two implementations anyway.
>> - it should be very simple and easy for normal users to figure out, so
> I'd strongly prefer a solution that doesn't go to the IPYTHONDIR or
> depend on additional functionality like a database: since this is
> about preventing data loss, simplicity and robustness should be
> paramount. For instance, a user could be working on a directory which
> they put on a usb stick, and if there's a problem with the notebook,
> they should be able to find the autosave files right there, not inside
> their IPYTHONDIR which they may not even know about.
I disagree only in that I think the user should not have to look at
the filesystem *at all*. It should be handled by the notebook server.
Remember that it is not a safe assumption that users even have access
to the filesystem other than through the notebook itself. In some
capacity, the notebook server should say "I have some unsaved edits in
backup file(s), what would you like me to do?". There's a bit of a
decision to make on when exactly that should appear (on first view of
the notebook list, or only on request of the individual notebook, or
only when 'view my current backups' is explicitly requested etc.).
As usual, part of this is based on the tension between the notebook as
a webapp and the notebook as a desktop application that happens to run
in a browser.
>> Basically, the scenario in my mind is that someone is working at 3am
> on a project and for some reason the nb crashes. They should be able
> to find their data quickly, without having to know anything else about
> how IPython organizes things internally or in a database.
Indeed, and they must also be able to do this when using a remote
notebook server running on a machine they do not control.
>> So I'm +1 for going next to the working files and auto-cleaned up,
> though making them be .foo_autosave.ipynb would be totally fine with
> me, to prevent cluttering the directory during a live session.
>> There's no major rush to do this right away, but it seems like we're
> slowly converging on a reasonable design that eventually we can
> implement. We can keep on mulling the interaction of this with the
> rest of the system to make sure we don't paint ourselves into a
> corner, obviously.
>> Cheers,
>> f