On Thu, 29 Jan 2009, Hans Petter Jansson wrote:
So, please, think about the pain that people feel when they have to handle those manual merges, and use the devel projects.
I think I asked before if the build service is moving to a more capable VCS backend (for handling merges) in the long term.
AFAIU the pain is in merging text files, right? (In comparison to somehow magically merging conflicting tarballs) In that case you don't need any fancy VCS to help with this. In fact most VCS simply use merge(1) or an internal variant of it, the conventional three way merge.
It's only this part that is missing from the tools (e.g. ocs), so someone should perhaps simply implement it.
If we were to use git, for instance, and expose its - or part of its - functionality directly, we'd get less error-prone merges, a UI that many developers are already familiar with, and the possibility to maintain branches even outside the build service (or across build services).
We wouldn't be able to use git directly (handling the binary blobs like tarballs would inhibit all size optimizations that git tries to do with deltas). I don't know how much better using a hacked up version of git (or one where only the package text files, like diffs and .spec would be handled by git and the tarballs by something else) would be. Probably it would still help, but AFAIK noone is evaluating this currently.