| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This entailed a fairly thorough cleanup of libbe.util.id.
Remaining unimplemented completion helpers:
* complete_assigned()
* complete_extra_strings()
Since these would require scanning all (active?) bugs to compile
lists, and I was feeling lazy...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Note that it only upgrades on-disk versions, so you can't use a
non-VCS storage backend whose version isn't your command's current
storage version. See #bea/110/bd1# for reasoning. To see the on-disk
storage version, look at
.be/version
To see your command's supported storage version, look at
be --full-version
I added test_upgrade.sh to exercise the upgrade mechanism on BE's own
repository.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
duplicate_bugdir() works, but for the vcs backends, it could require
shelling out for _every_ file read. This could, and probably will, be
horribly slow. Still it works ;).
I'm not sure what a better implementation would be. The old
implementation checked out the entire earlier state into a temporary
directory
pros: single shell out, simple upgrade implementation
cons: wouldn't work well for HTTP backens
I think a good solution would run along the lines of the currently
commented out code in duplicate_bugdir(), where a
VersionedStorage.changed_since(revision)
call would give you a list of changed files. diff could work off of
that directly, without the need to generate a whole duplicate bugdir.
I'm stuck on how to handle upgrades though...
Also removed trailing whitespace from all python files.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
