Krzysztof Kosiński wrote
- bzr update -r xxx, where xxx is the revision where your changes
applied cleanly 2. bzr unbind - this will convert from a checkout to a regular branch 3. bzr commit
Unfortunately this does not work if the update has been issued on changes that were not yet committed and this happens because the commit of a checkout is impossible until the update is done.
One of us must be missing something. The commands I wrote would have the following effect:
- Return to the state in which you were before the "bzr update" that
introduced conflicts. 2. Convert from a checkout to a normal branch. The association with the remote branch is broken. 3. Commit to the normal branch locally. After that, you can do a merge or continue working on your code locally.
Maybe I'm wrong but I think the missing point is that the local modifications have _not_yet_ been committed when you issue the update (as we are working on a checkout), so when you say: "1. Return to the state in which you were before the "bzr update" that introduced conflicts." you can't do that without losing your not-yet-committed modifications, or at least I still haven't found one and this is what I'm looking for.
Also, if you have conflicting files (those with .BASE, .OTHER and .THIS), bzr update -r xxx does not purge them; instead it creates another bunch of .moved files (.BASE.moved, .OTHER.moved and .THIS.moved) and it's not clear to me how to handle all these: it looks like a mess, there's no one between them that corresponds to the original files with my still uncommitted modifications and the original files are still filled with duplicated merge conflicts signatures.
This makes me think that the workflow simplification made by using checkouts can be vastly overcome by the disaster in which a not so skilled person can find himself inside when he inadvertently falls into such a situation. And the major problem I see is that it is not avoidable by giving simple advices or by simple best practices that people working with checkouts should take into account (different than not using checkouts, of course). I really can't believe that if an update completely turns upside-down your local working tree just when you are doing a commit to save your valuable work, you have no way to recover from the disaster and you need to manually track what other developers have done as some of those modifications may have altered important parts of the code you were relying on (even renaming or deleting files!). And at that point you have no way to distinguish between what you have changed and what other have changed, unless you have worked on few lines of code or you can remember everything of what you touched. What I would like to do in such situations is: a) revert the update so my working tree goes back to the state it was before the commit (i.e. the last revision I started working on _with_ my subsequent _local_uncommitted_ changes); b) commit my modifications locally so they are stored somewhere and cannot be lost anymore; c) create a parallel, updated checkout of the current trunk and work on differences, maybe also reverting some other users' changes I don't agree with because they conflict too deeply with my work and my patches are better that theirs ;P d) do a local merge with current trunk state (so I don't get new surprises) and test the result before making it public; e) merge and commit to trunk, repeating the previous steps if still necessary (wow, how many people are working on this project? ;). A variation of a) could be: whenever the commit tells that an update is needed, have a preview of what an update would change into my working tree, to see if it's a dangerous or an innocent (i.e. not related to what I'm working on) update. Of course to be able to see this, the "update preview" should be done over my working tree, not in a separate branch because it could be not so easy to cross-check the changes to understand which are the relevant parts being touched. Also, having to do this for every update, even a really simple one, would kill the benefits of working with a checkout.
Finally, if there is a difference between a "bzr unbind" + "bzr commit" and a "bzr commit --local", I'm probably missing it. The "bzr unbind" seems not having any effect on the current merge conflict status.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969724.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.