http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Bill, You are absolutely correct in that. But note the part about centralized SCM, I don't think you can get away with that as long as you are centralized. There IS one truth in the centralized model. http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment5http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment5Sun, 27 Jul 2008 14:00:14 GMTYou are missing the hard part of the problem. 1-4 deal with 1 person submitting patches to a project; in each of these cases the solution you propose is perfectly valid. The trouble is in the _We_ part of the problem. If several people are working on related components of the system, there comes a point where people are having to deal with dependencies on either work that hasn't been committed centrally yet, or functionality that is changing by patches from another person. This is the hard part (in a centralized vcs) because it inevitably comes down to somebody maintaining a merge of someone else's work as part of their patch (normally we see this in terms of patches rotting and needing to be updated to current sources). While this works somewhat (it fails to scale past a small-medium amount of contributors), it is a failure from a separation of concerns perspective. So... Scenario 5: multiple people with patches at the same time somehow in conflict with each other solution A: review/apply 1 patch, other patches must be resubmitted as they no longer apply (patch contributor takes on burden of merging the patch forward with new source, submits new patch for review) solution B: review/apply 1 patch, commit and update to revision without patch applied; review/apply another patch, update and modify to merge the work together, finally committing a patch modified from the one contributed. repeat until complete (or opt out to one of the other solutions) (this second patch is an implicit branch, someone has to do the work to merge them together because only explicit branches exist in a centralized vcs) solution C: review/apply patch 1 and commit explicitly create a branch for patch 2; review, apply and commit repeat until complete have someone create patches for merging and review as necessary -- I have seen all 3 solutions used in various OSS projects. A is how most seem to work, I've seen B on some very small projects, and C is used when a project wants to always have a shippable main branch http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment4http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment4Thu, 24 Jul 2008 19:29:45 GMTWrite a better one! http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment3http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment3Mon, 21 Jul 2008 16:52:22 GMTYou bugger! ;) I've got a draft of this in my queue.... sigh.. http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment2http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment2Mon, 21 Jul 2008 16:49:38 GMTMaybe this will help you with the grokking bit: http://www.kenegozi.com/Blog/2008/07/21/patch-management-approaches-using-decent-csm.aspx http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment1http://ayende.com/3432/patch-management-approaches-using-centralized-scm#comment1Mon, 21 Jul 2008 14:11:12 GMT