| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Also added ConnectionError pretty-print to ui.command_line, storage
version checking to BugDir.duplicate_bugdir(), and optional revision
argument to Storage.storage_version().
|
| |
|
|
| |
Now commands automatically check for storage version compatibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Running
python test.py libbe.storage.vcs
yields some EmptyCommit problems, an issue with bzr revision ids, and
some trouble with git's remove(), but nothing too critical.
On the bright side, now
./be list
Detects and uses the bzr backend :).
Onwards to moving over the remaining commands...
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to work around the same issue as mercurial (hg) issue 618. I
can't find a Darcs bug report for this, but it's been fixed somewhere
between 1.0.9 and 2.3.1.
Example scripts demonstrating the bug:
$ darcs=/usr/bin/darcs
$ mkdir x; cd x; $darcs init; echo a > b; $darcs add b; \
$darcs record --all --author 'x <a@b.com>' --logfile b; \
echo z>b; $darcs record --all --author 'x <a@b.com>' --logfile b; \
echo g>b; $darcs record --all --author 'x <a@b.com>' --logfile b; \
cd ..; rm -rf x > /dev/null; $darcs --version
Finished recording patch 'a'
No changes!
No changes!
1.0.9 (release)
And showing it's been fixed:
$ darcs=~/.cabal/bin/darcs
$ mkdir x; cd x; $darcs init; echo a > b; $darcs add b; \
$darcs record --all --author 'x <a@b.com>' --logfile b; \
echo z>b; $darcs record --all --author 'x <a@b.com>' --logfile b; \
echo g>b; $darcs record --all --author 'x <a@b.com>' --logfile b; \
cd ..; rm -rf x > /dev/null; $darcs --version
Finished recording patch 'a'
Finished recording patch 'z'
Finished recording patch 'g'
2.3.1 (release)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The output version strings change:
Version 1.5.4.3:
Created initial commit 217efa7: MESSAGE
Created commit acb3066: MESSAGE
Version 1.6.4.4:
[master (root-commit) c5b48cf] MESSAGE
[master 66a48c1] MESSAGE
Instead, get the full revid, and look for its beginning in the output.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
