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 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. -- 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
