On Wed, 2014-03-12 at 09:03 -0700, LucaDC wrote:
When you do an update it's not always obvious what to keep and what to discard, otherwise the version control system would have it easy in discarding the new changes in favour of the olds, or maybe the opposite. In big projects like Inkscape, usually the existing code should not be touched (except for some very particular cases) and the update process is an adaptation of your recent work to new trunk changes. Unfortunately bzr does not help in this when working with checkouts, as it messes up your code and puts your work in a limbo state: neither commited nor easily retrievable. And you can't go on with your work until you fix this situation which, even for an experienced programmer, can be tough to fix: everybody will always be able to get back their already commited changes while you may lose your work if you can't get out of it.
I don't understand the problem. If you have uncommitted changes, then bzr wont let you merge. If you merge, then one can undo that with `bzr revert` if you committed the merge by accident you can do `bzr uncommit` I've never had a situation where I couldn't back out of a merge.
Can you explain?
Martin,