PQM and conflicts

[Nicholas Allen]

Thanks for your detailed response (as usual ;-)).

Putting the data into separate files sounds like a pretty cool idea to 
me. That way you could build the NEWS to any format (HTML, rst) from the 
individual files.

At least there is a simple solution to the problem.

Cheers,

Nick

John Arbash Meinel wrote:
> -----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-----
> 
>