Hi Krzysztof, I started using bzr with Inkscape, which I take as a reference project, but then extended it to my personal workflow. I've found some problems dealing with the checkout model when more than one person is working on a branch and I can see the same could happen, even more frequently, when dealing with the Inkscape code (although I've not had yet the opportunity to try).
1. create a local checkout of Inkscape branch 2. work on it 3. done: you commit
That's it: repeat 2 and 3 until...
3. done: you commit: ah, bzr tells you need to update (you're not alone)... 4. you update and... ops, there are some conflicts! 5. you take a look at them for resolving and, wow! there are tons of them...
Here you start thinking that you'd had better taken a look at the situation before updating but how could you know this in advance? Maybe a local commit would have been better: store your situation and work on aligning to trunk in a more comfortable moment; but now your local modifications are interleaved with conflicts and already updated parts.
Is there a way to undo the update and get back the situation before the failed commit so you can turn it into a local (successful) commit with your changes only? This will make your future trunk merge into a parallel branch but that's how the story has gone so nothing bad.
I've already searched for an answer to this problem, but without success. Maybe I'm following a wrong procedure or I'm missing some useful step. Keeping a branch of the trunk and always make the double commit-merge step is not a good solution for small projects which need small modifications and a lot of quick commits.
Thanks. Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969705.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.