If you work with a checkout, bzr won't let you commit unless your tree tip is up to date with the main repository, as a commit in a checkout is automatically performed also in the main repository in a single monolithic operation (i.e. if the main repository commit fails, the local fails too). So, if you started working on Rev 1023 in you local checkout and, after you made your changes, you get to a point and decide to commit, you expect your new commit to become Rev 1024; but when you launch the commit, bzr tells you: nope, the main repostory is now at Rev 1026 so you have to update your local tree before commiting. Hence you do a bzr update and this turns out to be an update+merge of your local still uncommitted changes: your local history becomes identical to the main repository's and your local files become a merge with the new Rev 1026. Now you are allowed to commit your changes which will become Rev 1027. But, if you have some conflicts, you still have to resolve them before committing. And, if the changes injected by the update into your code are quite big, you can find your still-uncommitted local code buried and lost inside foreign code which you hadn't the opportunity to analyze before. Now, getting everything fixed can get really hard and if you make some mistake you could lose the possibility of getting back to your already tested and working code as your changes haven't been committed anywhere yet.
I hope it's clearer now. Please, correct me if I'm doing a mistake somewhere in this description. This is what I've experienced while experimenting with checkouts on my projects.
Thanks. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969736.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.