Danek Duvall wrote:
Steve sticks a tag on in a changeset that immediately follows the last
changeset of the build, but (to my knowledge, at least), doesn't follow any
> of the respin changes. What this means is that the build tags in the
Yup, it doesn't reflect any respins/backouts.
Do you think this would be generally worthwhile?
Is the introduction of multiple heads too confusing? Would old ON
developers detest the very idea of multiple heads? (Note that these heads
would never be merged.)
Would it be worthwhile trying to persuade the mercurial folks to formalize
the handling of unnamed branches?
Any other thoughts or comments?
My summary thoughts:
PRO:
+ I like the idea of one canonical repository.
(one repository to rule them all...)
+ Removes the need to hunt down locations of other older builds,
or build-bundles
CON:
- Potential user confusion (in that 'tip' could refer to any branch,
and not necessarily the "main"/"default" branch)
- Messiness of having multiple branches in one tree
- This is potentially confusing since currently it's easy to tell if
you screwed up something like a merge just by looking for the presence
of multiple heads. With in-tree branches, this becomes less obvious.
- If build-demarkations are solely a "Sun Solaris" specific thing, then
they should be done within Sun - and not to the external OpenSolaris
repository.
I can lean either way... someone convince me :)
cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
tools-discuss mailing list
[email protected]
