Martin Owens-2 wrote
But the first thought I think is for us to think of other developers as being competent first and then as us all as human, so mistakes will be made. But they can be cleared up by talking first.
I had no intent of saying anything different. Please, take my example as it is: just an example. I often find myself in the need of revising what I've done so I'm both the old and the new committer. If my sentence has touched a delicate subject, forget it and let's speak about the real problem.
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.
Up to now, the only solution I see is avoiding working with checkouts. So: what are checkouts for? Do you know a safe way to deal with this problem? Do you know a way to undo an heavy update over your uncommited code? Do you know a way to have an update preview over your uncommited code?
Regards. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969731.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.