> -----Original Message----- > From: on-discuss-bounces at opensolaris.org [mailto:on-discuss- > bounces at opensolaris.org] On Behalf Of James Carlson > Sent: Friday, September 26, 2008 9:12 AM > To: Jose Borrego > Cc: on-discuss at opensolaris.org; 'Milan Jurik' > Subject: Re: [on-discuss] hg comments > > Jose Borrego writes: > > > That doesn't sound right to me. What you're describing sounds like > > > debugging a project into existence, which has long been discouraged > in > > > ON. Why wouldn't a project do its work outside of ON until it's > > > _done_ and only _then_ push? > > > > Well I won't get into why we putback to ON. All I'll say is when we > did we > > knew we still had extensive modifications that had to be made. Since > we > > didn't want to make ON instable we kept a separate gate in which we > make > > those modifications. A test team tests thoroughly those bits before > we push > > to ON. Since we are in ON, bugs are found by users which we fix in > our gate > > (most of the time) to avoid a difficult merge when we push to ON. > That > > wouldn't be a problem if we didn't have to collapse the changesets > (even > > when no merge has to be done) and lose the history. The same thing > was > > occurring with teamware but we could discriminate the CR comments per > file. > > That's a confusing state of affairs. > > I would have expected that you'd apply independent bug fixes to the > existing bits in ON and then (like any other development project) > merge those fixes in on the next project gate resync. Doing the fixes > in a separate branched-off workspace, testing, and then porting them > over to ON for integation sounds harder and riskier to me. > > But given that scheme, I think the best thing you could do would be to > use 'export' to extract those bug-fix changesets from your project > workspace, and then 'import' them into separate (clean) ON-based > workspaces for integration.
That's the first time hear of this. I'll try next time I push to ON. For anybody with multiple changesets in his workspace, however, the collapse may be inevitable. Since Mercurial doesn't allow a push to a repository until you pull for it all the changesets you don't have (even if they are completely unrelated file wise to your modifications), you'll endup doing a recommit which will collapse the changesets. And there will always be a window during which somebody may push something to the gate. Personally I wish we had an extension added to Mercurail doing what 'recommit' does without collapsing the changesets. That would also allow developers to works several CRs in parallel and push to ON once going through the RTI process only once too. > > That would preserve history in your development gate (because you > wouldn't collapse deltas there), and make sure the right things show > up in ON. The pain would be that you'd have to handle the duplicate > changes on the next resync, but with some merge practice, that > shouldn't be *too* hard. I'll have to acquire merge practive with Mercurial as I go along. > > -- > James Carlson, Solaris Networking > <james.d.carlson at sun.com> > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 > _______________________________________________ > on-discuss mailing list > on-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/on-discuss
