Re: [java-gnome-hackers] Makefile and ProgressBar patch

[Andrew C. <an...@op...>]

On Sat, 2009-02-21 at 19:08 +0100, Bruno Dusausoy wrote:
> Here's a patch that include two separate fixes[1]

Merged to 'mainline'. Thanks!

++

> Sorry but I forgot to release a patch before commiting other
> changes.

So it's ok; it's only a problem as the collection of revisions grows
larger. The more unrelated things that are in a branch being submitted
means a larger patch [diff, whatever] to review, and a large likelihood
that something in one area will require work, thus causing the entire
bundle to be rejected along with all the other, unrelated, areas.

Since the likelihood of something needing revision is very high, it's
best to keep the submissions orthogonal and discrete. (There can still
be lots of revisions per branch; that's just DVCS in action)

This makes the maintainer's job easier. And that's a Good Thing™.

> I still have a lot to learn 

Sure. Distributed version control is powerful; it takes a bit of getting
used to. Even more, it's not always [easily] possible to create
orthogonal branches because of the fact that we work incrementally on
various things simultaneously.

If you've got unrelated things moving at the same time, one thing you
can try is:

a) create a bunch of branches

$ cd ~/src/java-gnome
$ bzr branch mainline fix-typo
$ bzr branch mainline improve-progress

b) switch to it

$ cd ~/workspace/java-gnome
$ bzr switch fix-typo
$ bzr add filename
$ bzr commit filename

c) go back to what you were working on

$ bzr switch improve-progress
$ edit filename
$ bzr commit filename

and repeat.

Now, this sequence means you won't see the revision created in
'fix-typo', so what I then find myself doing as a second layer is having
a working branch where I merge all the various things I'm working on,
switching back to a specific submission branch momentarily when it's
time to commit something that is [only] relevant to that feature.

$ cd ~/src/java-gnome
$ bzr branch mainline working      # you probably already have one
$ cd ~/workspace/java-gnome
$ bzr switch working
$ bzr merge improve-progress 
$ bzr merge fix-typo
$ make test
$ bzr commit

and then carry on with whatever application development you're doing
elsewhere, knowing that the Eclipse Project "java-gnome" at
~/workspace/java-gnome has everything you currently need in it.

Of course, if you're code formatting manually that means you're not in
Eclipse, which is fine of course; the principles all still apply - your
primary working branch, where ever it is, has all the pieces you need
merged into it, while you create individual branches for various
discrete orthogonal features you are aggregating so they can be
submitted as clean patches to the upstream project.

Anyway, this is all fairly advanced and it is not always necessary to go
to this level of complexity. `bzr switch` is magic, though, and if you
are doing unrelated things to unrelated files, if you take the trouble
to create separate branches you're more likely to get those changes
accepted.

AfC
Sydney