Garrett D'Amore wrote:
Stephen Lau wrote:
As Shawn noticed... the open-sourcing of the e1000g driver yesterday
contained proprietary source code headers in the diff.  This was a
mistake by the engineer moving the code, and needs to be re-bridged. We can't have proprietary source code headers in public open source
code, no matter how minor and trivial the code is.

I've re-bridged the putback in onnv/onnv-gate, which means you will
need to roll your repositories back to revision 3567:6d1c4dd92b63, or
else your repositories will grow a new head.

Thanks, and sorry for the inconvenience.
cheers,
steve

Events like this are confusing to me.   Please bear with me.

Maybe I'm just naive in my dealings with Hg, but is the need for this
kind of special attention a result of Hg itself, an artifact of the
current Hg bridge, or the result of rolling back a repository instead of
just "patching forward" (i.e. not treating the backout as 2nd update,
but instead actually "undoing" the original commit?)

I'm not sure this is the same kind of Hg snafu in the past, but the
upshot is that I'm not sure whether I should be using Hg at this time,
or should I be sticking with SVN?  (I don't work on my ON clone every
day; the last couple of times this happened I just deleted my old
workspace and started with a fresh one.)

Again, I apologize if I sound confused -- but I am.  I'd like to hear
some "official" word on what those of us on the outside _should_ be
using as the most up-to-date source for Solaris.

Hi Garrett,
It's an artifact of rolling back a repository, and is not an artifact of Hg in any way. The point of an SCM is to make sure no history is ever lost - correct? The problem is, due to the legal aspect of this, we need to make the repository "forget" that it ever happened - so it's going counter to what an SCM should be doing. We would have this exact same issue whether it was CVS, SVN, or even good old Teamware/SCCS. The problem with "patching forward" is that the mistake is still in the history..
        onnv/onnv-gate continues to be the most up-to-date source for Solaris.

cheers,
steve
--
stephen lau // [EMAIL PROTECTED] | 650.786.0845 | http://whacked.net
opensolaris // solaris kernel development
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to