diff options
Diffstat (limited to '.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments')
6 files changed, 81 insertions, 0 deletions
diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body new file mode 100644 index 0000000..ae7a57f --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/body @@ -0,0 +1,21 @@ +> 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. + +This is definately the way to go. Rough approach for the VCS family: + +1) Parse `bzr diff` or such to get a list of new,changed,moved,removed + paths. +2) Convert those paths to ids. +3) Return a list of ids to duplicate_bugdir(). +4) Provide Storage.parent(id, revision), so duplicate_bugdir() could + figure out what type of id we were dealing with (bugdir, bug, + comment, other?), and construct the appropriate difference tree. + +There could be a DupBugDir class which stored that diff tree and a +link to the current bugdir, which would make diffs much easier (work +already done, just copy the diff tree), and provide faster access to +unchanged files (just use the current version). + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values new file mode 100644 index 0000000..3dfe992 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9525e3f3-a044-4fa9-b311-56336267b8b5/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sun, 03 Jan 2010 12:25:03 +0000 + + +In-reply-to: 9c4b8921-7b43-4bb6-b650-34144b414dc0 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body new file mode 100644 index 0000000..e43a951 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/body @@ -0,0 +1,23 @@ +Ok, time to fix the issue I mentioned in this commit message: + +revno: 473.1.63 +revision-id: wking@drexel.edu-20091215114420-sbdnvm5jlx0ampbg + +... +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... +... diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values new file mode 100644 index 0000000..a02a32b --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/9c4b8921-7b43-4bb6-b650-34144b414dc0/values @@ -0,0 +1,8 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 02 Jan 2010 22:58:31 +0000 + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body new file mode 100644 index 0000000..b1b9b1a --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/body @@ -0,0 +1,7 @@ +> I'm stuck on how to handle upgrades though... + +I've satisfied myself with the solution mentioned in #bea86499-824e-4e77-b085-2d581fa9ccab/1100c966-9671-4bc6-8b68-6d408a910da1/bd1207ef-f97e-4078-8c5d-046072012082#, +namely, upgrading on disk the way we've always done, and not +supporting on-the-fly upgrading at all. This isn't important for this +bug, but I didn't want to just ignore that part of the commit message. + diff --git a/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values new file mode 100644 index 0000000..1d01491 --- /dev/null +++ b/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/ed5eac05-80ed-411d-88a4-d2261b879713/comments/c664b7be-ded5-42dd-a16a-82b2bdb52e36/values @@ -0,0 +1,11 @@ +Author: W. Trevor King <wking@drexel.edu> + + +Content-type: text/plain + + +Date: Sat, 02 Jan 2010 23:04:01 +0000 + + +In-reply-to: 9c4b8921-7b43-4bb6-b650-34144b414dc0 + |