Converted libbe.storage.vcs.base to new Storage format.

2 files changed, 0 insertions, 86 deletions

diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body
deleted file mode 100644
index fce4941..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/body
+++ /dev/null
@@ -1,72 +0,0 @@
-On Tue, Jul 14, 2009 at 10:36:26PM +1000, Ben Finney wrote:
-> "W. Trevor King" <wking@drexel.edu> writes:
-> > I've switched my branch over to the current url, and moved to
-> > last-commit-timestamp version numbers.
-> 
-> Please, no. Timestamps aren't version strings, that's conflating two
-> pieces of information with very different meanings. Correlating the two
-> is the job of a changelog.
-
-Which we don't bother keeping (also NEWS), since "bzr log" works so nicely.
-If you really want an standard changelog, see
-  http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00186.html
-
-> > This removes the "prefered branch" issues with the old scheme, and
-> > version numbers should increase monotonically
-> 
-> The English word “should” is ambiguous in this context. Are you saying
-> this is desirable, or are you predicting that it will likely be the
-> case?
-
-Both.
-
-> I don't see how it's either, so am doubly confused :-)
-
-The timestamp should at least replace the patch release number, which
-you agree is-desirable-to increase motonically ;).  I also predict
-that it will increase monotonically for any given branch, since the
-branch HEAD will have both the most recent commit and the highest
-version number.  The only problem I can think of is having your clock
-_way_ off, and that is unlikely enough to ignore.  If you hop between
-branches, the timestamp is much more likely to increase going to the
-more modern branch than the bzr revision number, which desynchronize
-between branches fairly quickly.
-
-> The convention for three-part version strings is often:
-> 
->   * Major release number (big changes in how the program works,
->     increasing monotonically per major release, with “0”indicating no
->     major release yet)
-> 
->   * Minor release number (smaller impact on how the program works,
->     increasing monotonically per minor release, with “0” indicating no
->     minor release yet since the previous major)
-> 
->   * Patch release number (bug-fix and other changes that don't affect
->     the documented interface, increasing monotonically per patch
->     release, with “0” indicating no patch release since the previous
->     major or minor)
-
-One problem is that we don't actually have "releases".  People just
-clone a branch, install, and go.  If you're worried about stability,
-just clone from a more stable branch (i.e., Chris' trunk).  I think
-this is good for distributed development, but maybe makes it hard to
-package into a conventional release-based system.  With the bzr patch
-number in setup.py as the patch release number, I would be releasing
-my 0.1.363 while Chris releases his 0.1.314, even though they're at
-about the same point.  I would rather be releasing my
-  0.1.20090714121347
-while Chris releases his
-  0.1.20090713154540
-Since then the similarity is clearer.
-
-At any rate, I think the two approaches are close enough that an
-auto-updating timestamp beats a manually bumped patch number, since
-no-one ever actually bumps the patch number ;).
-
--- 
-This email may be signed or encrypted with GPG (http://www.gnupg.org).
-The GPG signature (if present) will be attached as 'signature.asc'.
-For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-
-My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
diff --git a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values b/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values
deleted file mode 100644
index a3f74c4..0000000
--- a/.be/bugs/529c290e-b1cf-4800-be7e-68f1ecb9565c/comments/ea01c122-e629-4d5c-afa7-b180f4a8748b/values
+++ /dev/null
@@ -1,14 +0,0 @@
-Alt-id: <20090714133732.GB6160@mjolnir.home.net>
-
-
-Author: W. Trevor King <wking@drexel.edu>
-
-
-Content-type: text/plain
-
-
-Date: Tue, 14 Jul 2009 09:37:32 -0400
-
-
-In-reply-to: 744435b7-1521-4059-a55d-f0c403d7b4d8
-