Yeah, we could have done that in theory. In practice, we're all still fairly ignorant when it comes to using git, and we've all had close encounters with git disasters. Melanie is the one keeping branches in sync, she has spent a lot of time resolving conflicts by hand, helping out the messes we get into, etc. She can do that with one branch but not with many... so until several of us learn how to deal with git errors effectively, it's not wise to multiply branches. We'll learn as we go, and hopefully we'll get better at using git.
On Feb 22, 2010, at 11:47 AM, Toni Alatalo wrote: > d...@metaverseink.com kirjoitti: >> We can, by this order: >> 1) merge presence-refactor into master >> 2) create a sop-refactor branch from master immediately after >> 3) create a 0.7 branch some time later >> I would like to propose that the sop refactoring work be done in a >> branch rather than in the master branch, similar to what we did for >> the >> > > I also think a branch for it is a good idea, but don't know why wait - > the sop-refactor branch can also be branched from presence-refactor > right now if Adam wants to start already. Like Melanie suggested some > days ago in this thread. > > AFAIK this won't be a problem with git, 'cause commits are commits and > it doesn't matter from which repo they are from, a version being a set > of commits. So sop-refactor could first pull from presence-refactor if > work still goes on there, and then keep pulling from master when it > lives there, etc. > > Perhaps this is not relevant anymore if 1) can be done now, might have > been a good idea a couple of weeks ago when presence-refactor was > pretty > much done for parts that touch the scene(?). Also, I'm by no means a > git > expert, so am curious to know if have misunderstood it somehow and > this > idea wouldn't work .. Melanie did say in her post that it would. > > ~Toni > > > >> services refactoring. It works pretty well -- gives the refactoring >> devs >> peace of mind to leave things unstable and isolates the master branch >> from prolonged instability. >> >> Also, are there any suggestions for Adam before he starts doing >> this? He >> sent out a document some time ago, but there wasn't a lot of >> feedback or >> discussion. Are there any alternatives or wishes for his proposed >> work? >> >> Justin Clark-Casey wrote: >> >>> Frisby, Adam wrote: >>> >>>> I would like to start the SOP refactor fairly soon - what if once >>>> 0.7 is tagged for the RC process; I go and and make a new branch; >>>> we can sic testers on the presence-branch, while dev happens on >>>> the branch I tag? >>>> >>> My concern with branching for 0.7 release candidates immediately >>> after the presence-refactor merge is that we won't get everybody >>> helping to iron out the inevitable hiccups since most people >>> follow master. Waiting a couple of weeks for at least some of >>> this to happen is the minimum, I feel. Ideally, I'd like that to >>> be longer but I know that you and other folk want to press ahead. >>> >>> I guess some of this depends on how disruptive the refactor is. >>> What do you think? I'm assuming there will be breakage but >>> perhaps I'm wrong? >>> >>> Of course, I guess you could create a separate sop-refactor branch >>> at any point and start work there, possibly merging back to master >>> and continuing in master once 0.7 RC has been branched. >>> >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
