> > For instance, is it common for ON people to run the first pass of a
> > merge, reparent their workspace to an integration workspace, 'push'
> > their half-merged changes to the new parent/integration workspace, ask
> > someone more confident with the conflicting files to complete the merge,
> > and 'pull' the completed merge back?
>
> Roughly, yes. The outline is correct, but the details differ based on
> the individual doing the work.
>
> I'd say a more accurate pattern for complex merges would be:
>
> - create a new "merge" workspace based on the current project
> gate.
>
> - bringover ("pull") files from the main gate.
>
> - resolve as many changes as possible.
>
> - have others take children of that merge workspace.
>
> - they resolve conflicts in whatever way they need, and then
> putback ("push") to the merge workspace.
Hmmm, this would imply that hg clone clones unresolved (or) files. I
don't think this is the case (or am I wrong?). I would think that
children will have to re-parent to master workspace and re-pull from
master workspace. But I haven't tried that.
> - finally, the updated merge workspace is resynced with the
> project gate ("pull") and putback ("push") there.
If your merge workspace is updated from merge-child, won't you get new
conflicts while pulling from project gate ?
I haven't actually tried this with mercurial, so maybe I'm just plain
wrong here ...
--
Vlad
pgpOK6BA1xwhR.pgp
Description: PGP signature
_______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
