diff options
Diffstat (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments')
8 files changed, 144 insertions, 0 deletions
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/body new file mode 100644 index 0000000..861fb1d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/body @@ -0,0 +1,14 @@ +> We also have the unfortunate situation of duplicate UUIDs from the old +> be merge +> implemtation. This means that id-to-path is not a well defined +> mapping with single-uuid ids. That's ok though, we get a bit uglier +> and send the long_user() id into the storage backend instead. While +> not so elegant, this will avoid the need for the cached id/path table. + +The situation is worse than just the old `be merge` effects, because +the existence, children, and parents of a particular UUID may be +revision dependent. A UUID will always refer to the same +bugdir/bug/comment, but that bugdir/bug/comment may have different +relatives. Another point in favor of long_user()-style storage ids, +but that just pushes relation-tracking up to the command level. I'm +still figuring out a good way to deal with this... diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/values new file mode 100644 index 0000000..65e4472 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Mon, 28 Dec 2009 12:12:45 +0000 + + +In-reply-to: bd1207ef-f97e-4078-8c5d-046072012082 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/body new file mode 100644 index 0000000..df5b8c5 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/body @@ -0,0 +1,14 @@ +> The situation is worse than just the old `be merge` effects, because +> the existence, children, and parents of a particular UUID may be +> revision dependent. A UUID will always refer to the same +> bugdir/bug/comment, but that bugdir/bug/comment may have different +> relatives. + +I'm not sure how to support .children(revision) in the Arch backend +or the older versions of Darcs without checking out a pristine tree +for the revision in question. That's how we used to support + BugDir.duplicate_bugdir() +but it doesn't fit well with the new Storage system. Since I don't +feel strongly about tla or old Darcs support, I'm leaving that +functionality unimplemented. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/values new file mode 100644 index 0000000..d21650d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/7812d2e5-9d4b-4621-b071-22e91e8757d2/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 29 Dec 2009 16:20:06 +0000 + + +In-reply-to: 3646e056-a2df-46e5-b877-88608c7cc5af + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/body new file mode 100644 index 0000000..abb898c --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/body @@ -0,0 +1,30 @@ +Rather than all the hackery that goes on with email-bugs, the email +interface, etc., it would be nice for distribution if be provided a +uniform issue/bug tracking library and a number of interfaces and +backends. + +Current backends: + filesystem (with assorted VCSs) +Current UIs: + command line (be) + email (be-handle-mail) + web (CFBE) + +Future backend architecture: + be --repo REPO ... +where --repo REPO replaces and extends the current --dir DIR. Example +REPOs could be + path/to/repo (the current DIR) + http://some-server.com:port/path/to/repo (http interface) + mysql://user@server:port/?db=db-name;pwd=password + ... +Each repo would have to support a few get/set commands at the bugdir, +bug, and comment level. + +The UIs would all load BugDir(REPO), and thus be backend agnostic. +This way a GUI app that let you work on your own machine could also be +used to work on a public repository. Setting up a public repository +would just consist of exposing one of the wire-capable REPO formats +(e.g. http via a future `be serve MY-URL`) with public write +permissions. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/values new file mode 100644 index 0000000..d2e65d3 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bb406a33-92b6-46dd-950c-c7cfb5440e7b/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 08 Dec 2009 01:06:12 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/body new file mode 100644 index 0000000..21170a2 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/body @@ -0,0 +1,45 @@ +Some additional thoughts, as I've been developing this idea: + +Different BE storage versions will be difficult to handle. +We currently do disk upgrades via + libbe.storage.util.upgrade +which browses through the .be/ directory, making appropriate changes. + +The new formats know very little about paths, which brought on the +whole libbe.storage.vcs.base.CachedPathID bit. Still, most VCSs +seem to be able to handle renames, e.g. + $ bzr cat -r 200 ./libbe/command/new.py +works, when as of revision 200, the file was + ./becommands/new.py +In fact, bzr recognizes both names: + $ diff <(bzr cat -r 200 ./becommands/new.py) \ + <(bzr cat -r 200 ./libbe/commands/new.py) +returns nothing. Still, I'm not sure this is something we should +require in a storage backend. Which means we'd need to have a +version-dependent id-to-path(version) function. + +We also have the unfortunate situation of duplicate UUIDs from the old + be merge +implemtation. This means that id-to-path is not a well defined +mapping with single-uuid ids. That's ok though, we get a bit uglier +and send the long_user() id into the storage backend instead. While +not so elegant, this will avoid the need for the cached id/path table. + +Ok, you say, we're fine if we have the compound bugdir/bug/comment ids +going out to storage, with the upgrader upgrading the file +appropriately for each file type. Almost. You'll still run into +trouble with upgrades like dir format v1.2 to 1.3 where targets +moved from a per-bug string to a seperate-bugs-with-dependencies. +Now you need to create virtual-target-bugs on the fly when you're +loading the old bugs. Yuck. + +All of this makes me wonder how much we care about being able to +see bug diffs for any repository format older than the current one. +I think that we don't really care ;). After all, the on-disk +format should settle down as BE matures :p. When you _do_ want +to see the long-term history of a particular bug, there's always + bzr log .be/123/bugs/456/values +or the equivalent for your VCS. If access to the raw log ends +up being important, it should be very easy to add + libbe.storage.base.VersionedStorage.log(id) + libbe.command.log diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/values new file mode 100644 index 0000000..f0af48d --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/bd1207ef-f97e-4078-8c5d-046072012082/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Tue, 15 Dec 2009 12:21:11 +0000 + + +In-reply-to: bb406a33-92b6-46dd-950c-c7cfb5440e7b + |