It's the ideal. Inkscape is more anarchistic and has many people committing to trunk directly, which opens us up to conflicts (and isn't ideal) but we don't have a lot of resources for peer-review.

Here are some tricks I picked up dealing with conflicts of trunk committing:

Use `bzr pull` before you commit. Use `bzr push` right away. Thus only commit working code.

If your commit mis-times and you diverge from trunk:

Uncommit all of your commits using `bzr uncommit` Then `bzr pull` to sync up Then `bzr commit -m "foo"` again to get your commit in after.

Pay attention to any merge conflicts when you do pull requests.

Try not to do `bzr merge parent/lp:inkscape` because you'll then be committing someone else's work as if you merged it for them. Especially several someones.

Also help with any merge requests that come in, it's a good way to know more code I find and maybe we can make inkscape more ideal.

Martin,

On Tue, 2013-06-25 at 15:35 +0200, Christoffer Holmstedt wrote:

hmm, that workflow is what I use today (when I don't have access to trunk), do everyone do that within the Inkscape development process so all additions get peer reviewed?

On Tue, 2013-06-25 at 19:52 +0200, Krzysztof Kosiński wrote:

In fact merging from trunk from time to time is encouraged, because it allows you to keep up to date and reduces the risk of surprise bugs appearing only after the final merge.

For separate branches, that's right. But if he's working from trunk then a push doesn't run a 'merge' on the remote branch, it replaces the revision history. At least, that's what happens from experience.

Martin,

2013/6/25 Martin Owens <doctormo@...400...>:

On Tue, 2013-06-25 at 19:52 +0200, Krzysztof Kosiński wrote:

...

In fact merging from trunk from time to time is encouraged, because it allows you to keep up to date and reduces the risk of surprise bugs appearing only after the final merge.

For separate branches, that's right. But if he's working from trunk then a push doesn't run a 'merge' on the remote branch, it replaces the revision history. At least, that's what happens from experience.

Push will always fail if the target branch has any revisions not present in the source branch. As such, push *never* removes revisions, it can at most change their numbering (unless you use the --overwrite option). So it is not like replacing the revision history.

Renumbering will happen only if the source branch has a different primary path in the revision graph than the target branch. The "primary path" consists of the revisions committed directly to that branch - e.g. all revisions merged from other branches are not numbered. The append-only option, which is enabled on Inkscape trunk, disallows this kind of pushes.

2013/6/26 Christoffer Holmstedt <christoffer.holmstedt@...400...>:

hmm, this is what have been bugging me. That is the workflow I'm used to from git but I got the feeling that I should NEVER merge trunk into one of my feature branches because that would mess up earlier revisions later on in trunk (not sure how though). I will have to set up a new project locally and try it out for myself, that's the best way to learn =)

I don't like to work out of trunk, always branch to a bugfix branch or feature branch. As a response to the checkout/branch difference, yes got that one (I'll stay away from checkouts).

Some clarification, once more:

1. Bazaar does not allow you to push a branch if it's diverged - e.g. a push only allows you to add revisions, never remove them.

2. However, sometimes pushing a branch will renumber revisions, because the pushed branch has a different primary path in the revision graph. This will happen only in one case: when you branch from trunk, add some commits, merge from trunk, then push the resulting branch as the new trunk. We have disallowed such pushes. You should always merge the feature commits *into* the branch you're pushing to trunk. This does *not* mean that merges from trunk to feature branches are disallowed, only that the last merge should be in the direction feature -> trunk.

3. If you work with remote branches which you share from a machine different than your own, for instance on Launchpad, it's far more convenient to work with checkouts of the remote, shared branches than push your local branch to the remote branch every time you make a commit. Basically, Bazaar extends the Git paradigm by allowing to you to work directly on the remote branch. There is no reason to avoid checkouts.

Regards, Krzysztof

Thanks for the clarification Krzysztof. The problem I see with checkout is that I can't commit if I go offline, I must have access to e.g. Launchpad.

On Thu, 2013-06-27 at 12:18 -0700, alvinpenner wrote:

but the result was rather confusing.

And bad manners, sorry apenner.

Martin,

2013/6/27 Martin Owens <doctormo@...400...>:

We should test this is truly blocked. I managed to renumber someone's commit a few months ago and pushed it without issue. If trunk had bounced me, I wouldn't have developed a strategy to avoid doing it again.

Hm, it seems like this setting was turned off. Maybe it vanished after some upgrade on Launchpad. I have enabled it again. Just in case, here's how to set this option:

bzr config -d bzr+ssh://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/ append_revisions_only=True

The full path can be found by running "bzr config" in a checkout, it willl be present as the value of bound_location.

Regards, Krzysztof