Saving should increment last_modified. Renaming should not. Noticed
because incrementing last_modified on rename results in a scary error
message from the frontend.
The test actually passes on my VM (Win 7),
but not on Jenkins (Server 2012).
I haven't figured out how to identify the subset of Windows systems where it won't work,
but since the problem appears to be in the test,
not the tested code, skipping on Windows seems the right way to go.
- Adds a `GenericCheckpointMixin` as a helper for implementing the two
boundary-traversing Checkpoint API methods, `create_checkpoint` and
`restore_checkpoint`.
- `GenericFileCheckpointManager` is implemented as a subclass of
`FileCheckpointManager` using `GenericCheckpointMixin`. Note that
this is the safe subtyping relationship because of method
signature *contra*variance: `FileCheckpointManager` accepts
`FileContentsManager` in its method signatures type, whereas
`GenericFileCheckpointManager` accepts any `ContentsManager`.
- Moved Checkpoint-related classes to their own files.
On `create_checkpoint` and `restore_checkpoint`, pass a path and a
`ContentsManager` to `CheckpointManager` instead of an already-loaded
model.
The `CheckpointManager` base class provides a correct implementation of
these methods that's generic across any ContentsManager, but subclasses
are free to specialize when the storage backend of `ContentsManager` is
shared.
- Add a `CheckpointManager` base class and infrastructure for creating a
`checkpoint_manager` instance attribute on `ContentsManager`.
- Provide default implementations of `delete` and `rename` in the base
`ContentsManager` class. `ContentsManager` subclasses are now
required to implement `delete_file` and `rename_file`. These methods
no longer need to manage checkpoints.
- Move checkpoint-related functionality from `FileContentsManager` to a
dedicated `FileCheckpointManager` subclass.
- Move shared filesystem interaction logic into `FileManagerMixin`
used by both `FileContentsManager` and `FileCheckpointManager`.
- Minor tweaks to ContentsManager tests to get methods from the right
object.
The purpose of this change is to provide an API for users to replace
just the checkpoint logic associated with a particular
`ContentsManager`. In particular, this change makes it possible to
easily support remote storage of checkpoints while otherwise retaining
normal filesystem interactions.
- start with no number (Untitled0 -> Untitled.ipynb)
- copy of copy increments instead of adding another `-Copy` (copy Foo-Copy1.ipynb gives Foo-Copy2.ipynb, not Foo-Copy1-Copy1.ipynb)
- copy file to new folder starts with the original filename, instead of unconditional `-Copy0`
Min RK
Scott Sanderson
Thomas Kluyver