so, bzr-svn will have to start storing the revision id for each file text in a file property just like it does for other bzr-specific metadata.
Unfortunately this will badly hurt stacking performance since lookup up a file text may take O(rn) time (n as size of ancestry, r as roundtrip time to the svn server).
This will likely improve somewhat when revision properties-based mappings land, it'll make looking up such texts O(n) and probably even significantly better than that in the general case when the svn server is running svn >= 1.5.
so, bzr-svn will have to start storing the revision id for each file text in a file property just like it does for other bzr-specific metadata.
Unfortunately this will badly hurt stacking performance since lookup up a file text may take O(rn) time (n as size of ancestry, r as roundtrip time to the svn server).
This will likely improve somewhat when revision properties-based mappings land, it'll make looking up such texts O(n) and probably even significantly better than that in the general case when the svn server is running svn >= 1.5.