.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/1100c966-9671-4bc6-8b68-6d408a910da1/comments/3646e056-a2df-46e5-b877-88608c7cc5af/body

   1 > We also have the unfortunate situation of duplicate UUIDs from the old
   2 >   be merge
   3 > implemtation.  This means that id-to-path is not a well defined
   4 > mapping with single-uuid ids.  That's ok though, we get a bit uglier
   5 > and send the long_user() id into the storage backend instead.  While
   6 > not so elegant, this will avoid the need for the cached id/path table.
   7
   8 The situation is worse than just the old `be merge` effects, because
   9 the existence, children, and parents of a particular UUID may be
  10 revision dependent.  A UUID will always refer to the same
  11 bugdir/bug/comment, but that bugdir/bug/comment may have different
  12 relatives.  Another point in favor of long_user()-style storage ids,
  13 but that just pushes relation-tracking up to the command level.  I'm
  14 still figuring out a good way to deal with this...