Comment 5 for bug 1175462

Is the problem that the 'shelve' code wants to have a bzr version associated with each file system element it processes, but the elements in the situation this bug describes don't yet have one since they haven't been committed?

I suppose one method of dealing with that would be to modify the shelve code to allow bzr_lib.revsion.NULL_REVISION and use that to track shelved, never-committed file system elements. On the other hand I'm probably missing the point of 'shelve', to keep uncommitted changes in the tree?

Does 'bzr add' put something in the tree, or in some 'on-deck' position where 'bzr commit' will actually put it in the tree?