Stephen Lau wrote:
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.
They form a base to lay the bundles reflecting them on top of, but don't
reflect them.
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'd say that the builds are everyone's, not just Sun's.
Doing these things in one tree has certain attractions, but I'm not sure it
has enough attraction for me.
We'd have nearly 58 (well 42, but you know what I mean) branches now, some
of which would effectively be tags, some of which wouldn't.
I'm not sure build-synchronized workspaces pose that much of a problem, they
can't be easily be used as a base for work (other than for respins), or
merged by projects, since in a mercurial world any snapshot containing a
respin is diverged.
-- Rich
_______________________________________________
tools-discuss mailing list
[email protected]
