1 files changed, 0 insertions, 28 deletions
diff --git a/.be/bugs/56506b73-36cc-4e32-a578-258a219edba8/comments/4068c833-0c06-475e-8b7e-6701bc416dee/body b/.be/bugs/56506b73-36cc-4e32-a578-258a219edba8/comments/4068c833-0c06-475e-8b7e-6701bc416dee/body
deleted file mode 100644
index d3d9d0c..0000000
--- a/.be/bugs/56506b73-36cc-4e32-a578-258a219edba8/comments/4068c833-0c06-475e-8b7e-6701bc416dee/body
+++ /dev/null
@@ -1,28 +0,0 @@
-> With interfaces/email/interactive listening on the recieving end to
-> grab new-bug emails and import them into an incoming bug repository.
-
-The email-bugs -> be-handle-mail import is based on `be import-xml`.
-The current import-xml implementation allows good control over what
-gets overwritten during a merge by overriding only those fields
-defined in the incoming XML.
-
-For clients without the versioned bugdir (e.g. they installed via a
-release tarball or their distro's packaging system), `be email-bugs`
-will not know what fields have been changed/added/etc., so it sets
-_all_ the fields in the outgoing XML.  Importing that XML file will
-override any changes that may have been made to the listed
-bugs/comments between the release and your current source version, so
-you may have to do some manual tweaking of the post-merge bugdir.
-
-One possible workaround would be to change the merge algorithm in
-import-xml to take advantage of version information given in the XML
-file.  import-xml could checkout the shared root version of any
-modified bugs, and compute the changes made by the remote user and
-those made in the local tree.  It could then merge these changes more
-intelligently, by prompting the user, keeping the local changes,
-keeping the remote changes, etc.
-
-While the more automated approach might be better, it's also more
-complicated, so for now we'll stick with the simple "override all
-fields defined in the XML" approach.
-