PQM and conflicts

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Allen wrote:
> Hi,
> 
> I really like the development model that bzr uses where patches are
> reviewed and the PQM then runs the test suit and so on thus ensuring the
> trunk is always stable. I would like to use this model for my own
> projects but I have a question. How does PQM handle a conflict?
> 
> I can imagine something like this would happen often with a file like
> NEWS where each developer adds the changes to the end of the list. I may
> have updated my branch with the latest trunk before submitting a merge
> request but if someone else's branch is merged before mine and they
> added to the NEWS file to (obviously at the same place because we would
> both add new entries at the end) then PQM will get a conflict. As I
> imagine this would happen with nearly every single merge request I guess
> the bzr developers have found a solution to this problem. Is there a
> simple solution to this or have I overestimated the number of conflicts
> with files like NEWS?
> 
> Cheers,
> 
> Nick
> 
> 

To summarize:

a) NEWS conflicts quite a bit.
b) We've thought of ways to work around it.
c) It doesn't happen enough that we've bothered to implement the
workaround. If you have a project with a very active trunk, and a lot of
merging, it might be more worthwhile for you.


Long version:

If there is a merge conflict PQM just rejects the patch.
NEWS is certainly the biggest conflict generator that we have right now.
And it has been a bit of an issue.

It doesn't always conflict, because we generally have sections for

IMPROVEMENTS
BUGFIXES
INTERNALS
...
etc

So if I merge a bugfix and you merge an internal change, there isn't a
conflict.

We've actually discussed ways to avoid it, but we haven't specifically
done anything yet. The best way we've come up with is to have a NEWS/
directory, with 0.17/, 0.18/, ..., current/ as separate subdirectories.

We can automatically generate a real NEWS file from these individual
snippets. And when a release manager goes to make a release, he moves
all of the entries from current/ into a new directory (0.90/ for example).

This solves quite a few problems.

1) It conflicts a lot less. Each new change is introduced as a file, so
it won't conflict with other people making similar changes.

2) When you merge someones code, and they thought they would make it to
0.18, but it slips until 0.19, their NEWS entry still goes into
'current/' rather than going into the section for 0.18. (Note, this is
why we create a new 0.18 and move everything into it, rather than moving
current => 0.18 and creating a new current).

3) It makes it easy to generate custom views, like say you only want the
information from the 0.18 release.

The big downside is that it is a bit more effort to create a new file
and add information into it in the properly structured way. Rather than
just using the template of all other entries. And you have to have a
"make NEWS" step.

NEWS is also not versioned, otherwise you would still have problems with
conflicts.

All this work is also similar to introducing a custom merge algorithm,
that understands the format of NEWS. Basically, instead of a new merge
algo, we are laying out our disk to be kind to the existing merge
algorithm. However, stuff like step (2) means that it is probably still
better than having a single large NEWS and a smart merge algorithm.

Especially since every so often I clean up NEWS to conform to reST
guidelines, which would probably get really screwed up by a custom merge
algorithm. (Not to mention, we don't have the ability in bzr to specify
a custom algorithm per-file anyway).


John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGvH29JdeBCYSNAAMRAhWGAKC8CfhFa4LDfko4xAANZs7/kwqTAgCfdrtJ
NBgJwPqlLau0hYSLueGg09k=
=3dJn
-----END PGP SIGNATURE-----