|
From: <gor...@bl...> - 2002-05-13 12:51:49
|
"Andreas Raab" <And...@gm...> wrote: > Göran, > > > Tell you what - if we can agree on a model as the ones > > discussed here (branches, tags, releases, permissions) > > then I can offer to write (with your feedback of course) > > a short but concise howto/rulebook for command line CVS and > > WinCVS/MacCVS on the Swiki. > > I'll take you on that ;-) So let's talk about the recommended model > since that's still not entirely clear to me. Can somebody perhaps try to Hmmm, somewhere here it feels like I have missed some posting - I thought I was waiting for some feedback from you Andreas? :-) I am referring to my post beginning with the line "Long mail about CVS, branches, tags etc.". > outline how the line of development looks like given that: > a) we have a few "primary" maintainers for any given platform > b) somebody wants to add a "patch" or so (just had two requests on this) > c) somebofy wants to start off with an experimental version (like the BC > stuff) > d) the primary maintainers will want to merge those modifications at a > later point. > > What I'm interested in here is what we think this "should" look like. Ok, since I have also posted quite a long post recently and haven't really given anyone a chance to reply, I will try to make this one brief. Trying to answer: a) (well, that was not a question I think) b) Somebody wants to add a patch: Well, if it is sent/posted as a patchfile then it will just be up to the maintainer to apply that patch to his/her workingcopy, test it and commit it if it looks good. Since (given the proposed model) the maintainer works on the trunk it's just a trivial commit. c) Somebody wants to branch. Fine, anyone with "commit permission" on SF will likely be a trusted person (I mean, we have given him/her commit permission right?) so we can probably assume he/she has read our policydocument (to be written) and that he/she "asks publically for permission" before doing the branch. Then if noone objects I would assume say it is fine for him/her to branch. The branch operation will be done by him/herself. The policy document will describe how to do it and how to tag before branching etc. (God, that he/she is really tiresome... I will stick to he for simplicity! :-) d) Ok, Joe (the developer that did the branch) has fixed some pretty cool Win32 stuff on his branch and he alerts Andreas to this fact. Since the branch the trunk has moved forward. A few scenarios: -Andreas has plenty of time this weekend so he says to Joe "Cool, I will make the merge myself". And then he sits down and follows the instructions in the policy document how to do a full (=all changes that have been made on the branch) merge from a branch to the trunk. Technically it is quite easy but since the trunk has moved forward he needs to review the changes and resolve any conflicts. Since this is a full merge of the branch the branch should not really be used anymore, it is better for Joe to create a new branch from the trunk if he wants to continue working on a branch of his own. -Andreas says "Ok, Joe, I don't have time for this - produce patchfiles for me for feature X and Y, I don't want the rest". And the rest is like b) above. -Andreas says "Ok, Joe, how do I merge?". Joe says "Well, first I did the X feature up to tag XXXX-done. And then I did the Y feature up to tag YYYY-done. You can merge them one at a time. Then after YYYY-done I have been trying out Mega-Feature Z but it is only halfbaked and doesn't work so don't go there.". Andreas then follows instructions in policy document about how to merge repeatedly from a branch to the trunk and does this in two steps. He leaves out the stuff from YYYY-done and forward. To make things a bit simpler and to "force" the branches to be kept "short" I would propose that we don't merge from the trunk into the branches - we only merge stuff from the branches into the trunk. This means that the branch will move further and further away from the trunk. If we merge in both directions it is trickier, more work and would perhaps increase the risk of getting "longlived branches". Since the branch won't get any new stuff that goes into the trunk this will encourage the branch owners to merge with the trunk so that they can "rebranch" from the trunk and get the latest/greates from there. > Cheers, > - Andreas Cheers, Göran PS. "Brief" my ass^H^H^Hbehind. :-) DS |