Merge lp:~benji/lpsetup/bug-1023519-store-version-information into lp:lpsetup
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Benji York on 2012-07-13 | ||||
| Approved revision: | 54 | ||||
| Merged at revision: | 53 | ||||
| Proposed branch: | lp:~benji/lpsetup/bug-1023519-store-version-information | ||||
| Merge into: | lp:lpsetup | ||||
| Diff against target: |
146 lines (+89/-5) 2 files modified
lpsetup/subcommands/inithost.py (+39/-5) lpsetup/tests/subcommands/test_inithost.py (+50/-0) |
||||
| To merge this branch: | bzr merge lp:~benji/lpsetup/bug-1023519-store-version-information | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Brad Crittenden (community) | code | 2012-07-12 | Approve on 2012-07-13 |
|
Review via email:
|
|||
Commit Message
adds creation of a version directory (/var/lib/
Description of the Change
This branch adds creation of a version directory (/var/lib/
This branch fixes bug 1023519 but we may want to create a new follow-up bug that contains the parts of 1023519 that were optional and this branch does not address.
| j.c.sackett (jcsackett) wrote : | # |
- 52. By Benji York on 2012-07-13
-
add a version directory and backing up of system files we change/delete
| Benji York (benji) wrote : | # |
> There doesn't actually appear to be a diff here, Benji. Expected, or a
> commit/MP error?
Heh, yeah PEBKAC error. It should be better now.
- 53. By Benji York on 2012-07-13
-
merge from tunk, fixing conflicts
| Brad Crittenden (bac) wrote : | # |
Benji,
* It is a wee optimization in make_version_dir but since mkdirs creates parents you could eliminate the call mkdirs(
* make_version_dir should utilize backup_path.
* Why explicitly use os.path.sep instead of os.path.join?
* I would expand your comment in the docstring for initialize_lxc. I had to read it a few times before realizing what you meant. Perhaps adding "so that it is only called when in a container" would make it clearer.
* In make_backup I was initially confused until i saw that backup_path is not a path but a method. Perhaps a name that would make that more obvious could be used.
Does this strategy of using the version number for storing the original files put any restrictions on how we update the version? Or is the idea that when the version changes we'll first restore the files saved in the previous version, remove the saved copies, and then proceed, applying the new workarounds under the new version number?
| Benji York (benji) wrote : | # |
> Benji,
>
> * It is a wee optimization in make_version_dir but since mkdirs creates
> parents you could eliminate the call mkdirs(
> mkdirs(originals). Doing so will have impact on your tests, though, as your
> mock mkdirs has different behavior.
Right, I think it's a slight win to keep the version and originals
directories explicitly created.
> * make_version_dir should utilize backup_path.
Good catch! Fixed.
> * Why explicitly use os.path.sep instead of os.path.join?
I guess that bit deserves a comment. Here is the one I added:
# We don't use os.path.join here because both of the input paths are
# absolute (i.e., they start with a slash) so we instead construct the
# path ourselves in order to "re-root" the otherwise absolute source path
# in the backup directory.
> * I would expand your comment in the docstring for initialize_lxc. I had to
> read it a few times before realizing what you meant. Perhaps adding "so that
> it is only called when in a container" would make it clearer.
Good idea. Done.
> * In make_backup I was initially confused until i saw that backup_path is not
> a path but a method. Perhaps a name that would make that more obvious could
> be used.
I vacillated a bit on that. I normally prefer verb function names too.
You mentioning it has pushed me back to the other side. I changed
backup_path and version_path to be get_backup_path and get_version_path.
> Does this strategy of using the version number for storing the original files
> put any restrictions on how we update the version? Or is the idea that when
> the version changes we'll first restore the files saved in the previous
> version, remove the saved copies, and then proceed, applying the new
> workarounds under the new version number?
We aren't exactly sure how the saved files will be used, if at all. At
a minimum they provide some protection against a bug in lpsetup
catastrophically modifying a person's system. They also provide some
hint as to what lpsetup has changed (after the fact).
- 54. By Benji York on 2012-07-13
-
respond to code review by renaming some methods and adding/enchancing some
comments
| Gary Poster (gary) wrote : | # |
> Or is the idea that when
> the version changes we'll first restore the files saved in the previous
> version, remove the saved copies, and then proceed, applying the new
> workarounds under the new version number?
Yeah, that's my idea, at least.

There doesn't actually appear to be a diff here, Benji. Expected, or a commit/MP error?