Note: This page is intended as a dumping ground to keep track of "deficiencies that I think/know of". This is not intended to be read as "Why haven't people fixed these things", or "Why is nobody working on this", or "Why is this taking so long". They're not "fixed" because nobody has gotten around to it yet, nobody's working on it because there're other things that are higher priorities, and it's taking so long because life is tough.
bzr log issues
log sometimes takes a long time to notice that its output channel has disappeared. It appears most obvious when doing a bzr log somefile | less of a single file which has been touched 'recently', but then not for a long time before then; q out of less after it displays the 'recent' stuff, and it will apparently just sit there churning away back through the history until it finds the next most recent rev affecting the file. Then it will try and output that log rev, notice that the output channel has gone bye-bye, THEN exit. I've got histories where that can take an easy 10-15 seconds. Not what you expect; when I q out of less, I want my prompt back dangit!
(this may not be entirely a log issue, so much as a history research issue) Finding out when in the history an executable bit got turned on/off can be tricky. log -v shows a * by the filename, but that doesn't tell you whether it was +x'd or -x'd, just that something changed the executable bit. diff only tells you "(properties changed)", and you're left to kinda guess what property and how.
In fact, the only way I could find to track down the change was to just manually pick some revisions ranges and do a stat -rX..Y file until I narrowed down a sufficiently small range that changed it, look through log -v until I found what revision had a * by the filename, then verify it by ls'ing a pair of checkout --lightweight's of the before and after revisions. Kinda unpleasant. At least, it would be nice if bzr ls could give some hints about +x, so I didn't have to actually do those full checkout's to use real ls on.
- Shared repositories
- We lack a way to 'clean up' unreferenced revs in a repository.
- Having no pointer to our repository, and simply searching upward through the filesystem for it opens up some nasty ways to screw yourself. Consider:
~/x % bzr init-repo --trees . ~/x % mkdir y y/z ; cd y/z ~/x/y/z % bzr init ; touch a ; bzr add ; bzr ci -m 'x' ~/x/y/z % bzr log (works fine) ~/x/y/z % cd .. ~/x/y % bzr init-repo --trees . ~/x/y % cd z ~/x/y/z % bzr log (BOOM!)This isn't trivial to fix, though. If the branch has a pointer relative to itself to where the repository is, we break mv'ing the branches around inside the repo, and that's no good. If the branch has an absolute pointer to the repo, we break moving the repo, and that's no good either. This is probably more a 'gotcha' than a problem per se.
- tags (many of these are known "todo" or "next-gen" items)
- Lack of history means that some ops can reverse themselves. Ex: have branch a with tag, branch to b. Delete tag from a. Pull into b, doesn't delete. Pull b from a, resurrects tag.
merge brings over new tags. revert after merge still retains tags for revs that don't exist (99137)
merge, like pull, doesn't copy over moved or deleted tags. It doesn't warn about conflicts for moved, though.