2014-03-11 1:54 GMT+01:00 Jabiertxo Arraiza Cenoz <jabier.arraiza@...2893...>:
Thanks Krzysztof for the quick reply.
It is not removing the pushes, it is just changing the revision numbers so that the other users' pushes are in subrevisions.
I feel confortable by this way but think isn't the normal usage in inkscape trunk
If you want to prevent changes in revision numbers, use this:
bzr config -d lp:path/to/branch append_revisions_only=True
However if you set this, you won't be able to merge other users' changes and then push. Use this instead:
bzr checkout lp:path/to/branch working_dir <-- only the first time cd working_dir bzr update <-- after the first time bzr merge <path to your working tree> bzr commit
Another option - you need the "rebase" or "rewrite" plugin:
bzr pull bzr rebase bzr push
Think one of this ways is the best, but i have the extra problem to update the branch from trunk. Maybe this need to be done direcly in the launchpad branch instead merge from trunk localy and push. Is correct?
If you have your own branch on which you collaborate with a few users, you can just use a checkout. Instead of saying "bzr branch lp:path/to/branch" at the start, say "bzr checkout lp:path/to/branch". Then everything you commit will appear on Launchpad immediately, and to update you can simply say "bzr update".
You can also say "bzr bind :push" to convert an existing non-diverged branch into a checkout.
Regards, Krzysztof
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.
2014-03-11 10:21 GMT+01:00 LucaDC <dicappello@...2144...>:
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?
If the manual is correct, I think you could use this:
1. 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
Regards, Krzysztof
Krzysztof Kosiński wrote
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?
If the manual is correct, I think you could use this:
- 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. You should do a commit --local (shorter than bzr unbind; bzr commit) before the update, hence: how can you know how "heavy" the update will be before doing it? When you've done it, it's too late... And if you always do a local commit before every update (just in case of), your changes will be recorded as a separate branch which has diverged and then has been merged, even for just a couple of lines of code.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969713.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
2014-03-11 18:16 GMT+01:00 LucaDC <dicappello@...2144...>:
- 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: 1. 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.
Regards, Krzysztof
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.
Em Qua, 2014-03-12 às 07:24 -0700, LucaDC escreveu:
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
It looks like a bad approach. You should merge the commits, not discard one of them.
If you commit provides what the other commit provides too, then it's okay.
Vinícius dos Santos Oliveira wrote
It looks like a bad approach. You should merge the commits, not discard one of them.
If you commit provides what the other commit provides too, then it's okay.
My sentence was a provocation to say that existing commits are not always good, sometimes you need to modify also what others have done to fit it with your work. Or do you think that you should never touch what others have written? If so you could only add code and it's pretty hard to correct bugs in this way... ;)
What I want to do is have the possibility of testing the interaction between my code and others' code before committing. What bzr does is make a mess, without advice, between others' code and mine and does not give me the opportunity to be able to distinguish my changes from others' changes after the update has been done, nor to have a preview of what would happen if you did an update.
And about discarding commits, it's not possible if the --append-only flag is specified. At most you can revert the changes and commit a new version: this has already happened in the Inkscape project. The old commit is still present in the project history and can be re-reverted, if necessary.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969727.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, 2014-03-12 at 07:54 -0700, LucaDC wrote:
My sentence was a provocation to say that existing commits are not always good, sometimes you need to modify also what others have done to fit it with your work. Or do you think that you should never touch what others have written? If so you could only add code and it's pretty hard to correct bugs in this way... ;)
It depends how long ago the commit was. If we're talking months, then consider the code settled and change it as needed to fix issues.
On the other hand, if it's a recent commit, please contact the committer before reverting. I don't mean things like spelling mistakes or correcting make files or the like. But functional changes.
Maybe they forgot to put in a comment that explains things or maybe they're right. A discussion here on the list would unpick the different perspectives if needed.
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.
Martin,
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.
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,
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.
On Wed, 2014-03-12 at 11:18 -0700, LucaDC wrote:
If you work with a checkout
Don't do that.
Although Inkscape doesn't follow the review-then-merge process for trunk commits, it's not really an SVN repository.
a. Checkouts prevent you from committing while offline b. Urges the developer use a workflow which is not ideal for multi-participant development (i.e. what your seeing) c. Encourages less care to be taken when committing (this also applies to pushing directly to trunk, but at least there's one more command to type) d. We might adopt the review-then-merge process and this will leave some developers completely baffled as they'll no longer have trunk commit access.
Use a branch of trunk (shallow even) and merge your changes into it. `bzr uncommit` is great for backing out your modifications and reapplying them.
Martin,
Martin, I don't agree to some of your points. Maybe you're speaking about lightweight checkouts, in this case I agree to some more.
Martin Owens-2 wrote
a. Checkouts prevent you from committing while offline
Not true: bzr commit -local -m "..." In this case, when you'll commit, your local versions are turned into a parallel branch (after you merge, of course). This point is true for lightweight checkouts.
Martin Owens-2 wrote
b. Urges the developer use a workflow which is not ideal for multi-participant development (i.e. what your seeing)
Ok, so please answer my previous question: what are checkouts for? @Krzysztof: do you agree with Martin? Why did you suggest using a checkout?
Martin Owens-2 wrote
c. Encourages less care to be taken when committing (this also applies to pushing directly to trunk, but at least there's one more command to type)
Don't understand this: which "one more command"? Maybe true for lightweight checkouts.
Martin Owens-2 wrote
d. We might adopt the review-then-merge process and this will leave some developers completely baffled as they'll no longer have trunk commit access.
This process would still be compatible with checkouts: eventually you need to have a place where to commit to and you may work into a checkout of that place being it the "real" trunk or simply a gate. Or are you talking about sending patches only?
Martin Owens-2 wrote
Use a branch of trunk (shallow even) and merge your changes into it.
Ok, this is a different solution I was trying to avoid because it has many disadvantages for small projects. I don't understand what you mean with "shallow even".
Martin Owens-2 wrote
`bzr uncommit` is great for backing out your modifications and reapplying them.
I completely disagree. In my opinion "uncommit" is evil if you are working with someone else. You may consider it _only_ if you are working alone and still can lead to disasters when abused.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Help-with-bzr-tp4969689p4969742.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (4)
-
Krzysztof Kosiński -
LucaDC -
Martin Owens -
Vinícius dos Santos Oliveira