Dan Mick writes:
> James Carlson wrote:
> > A great many modules consist of multiple .c files
>
> but a great many of them don't. And keeping #ident strings would solve that
> issue for multi-file objects.
That makes it a solution that works at best "sometimes."
> > *and* that the ID numbers mean nothing.
>
> They mean exactly a source revision, if the one single rule of SCMS is
> followed:
> that you don't ever cut any sort of released version without a delta.
> I'm pretty sure that's absolutely true of every release Sun has ever made,
> and I
> rely on it.
They mean a source revision in a given copy of a tree -- independent
trees end up reusing the same number stream -- and then only if you
never collapse deltas in that tree -- as is commonly done during bug
fixing and some projects.
> > Guess what happens if someone modifies one of
> > those files without touching the one magic file with the version
> > number in it?
>
> 1) thank you for offering me a guessing game (speaking of thanks), but I
> understand that very well. #idents in all files would solve that today.
Not really. They're not preserved in core dumps, and they litter the
file with trash from all of the common #include files.
In fact, those are the reasons *why* people stick %I% turds in modinfo
strings and -V options and log files -- #ident is a dumping ground
that makes it too hard to see what version you've got, and doesn't
survive in the cases where we need it.
> Something else that encodes filenames and versions would, too. And it's a
> problem with the perfection of "one %I%", but it *doesn't make it useless".
> It's just fine for all those single-file driver and other modules around.
As I said before, if you think that it works for you, then feel free
to generate serial numbers on your own modules. I don't think it's
anything better than a localized hack, and I'm hoping that we can do
better.
> > Or guess what happens when we need to map this back to
> > a particular package or patch version?
>
> Yes, it doesn't help a lot for that. I'm not interested in a patch version,
> I'm
> interested in a source version, because I want to diagnose the actual
> problem,
> not diagnose RE.
You're not the system administrator or the tech trying to troubleshoot
why an installed patch didn't fix the problem. It's not a question of
"diagnosing RE" (whatever that might mean), but of knowing what
exactly was installed on the system.
Yes, I understand the specific usage case you're talking about. As I
pointed out before, %I% doesn't quite work well for that case anyway
-- it only works for one-file modules (or baroque maintenance plans),
and then only with significant constraints on how the tree is managed,
and constraints that don't actually match how we build all bits in
practice or how testing is done.
> But no, it's about referring back to source, so it doesn't
> really attempt to track the delivery vehicle, any more than the piston serial
> number attempts to track the sale of the automobile. So?
I'm afraid I don't follow your analogy. Automobiles aren't (as far as
I know) ordinarily designed in order to carry weapons, are they?
> > Or guess what happens when we have separate gates for separate releases?
>
> Yes, one has to find the gate. It's easy in Sun's current structure, with
> very
> little pain or management.
Don't forget about split gates. :-<
> > Or when someone delivers an IDR built out of his own private workspace?
>
> Well, that's what we call a "reassignable offense". There's a reason we have
> RE, and gates, and gatekeepers, and release management, and it's about
> accountability, and if you don't understand that, *clearly* you don't get to
> deliver code to customers, ever.
So IDRs never get shipped to anybody? Nobody ever runs test bits of
any sort? We don't put BFU archives up on opensolaris.org or hand
them out to test partners like UNH? That's an interesting world, but
not the one I've had to deal with.
> > It's entertaining at
> > best, and a total waste of time in the worst case.
>
> I'm sorry, Jim, that's just wrong. It has absolutely answered the question
> for
> me many times: 'just which version were you really running', quickly and
> easily.
>
> No, it's *NOT PERFECT*. But it beats the hell out of *nothing*.
The bottom line I see here is that SCCS and Mercurial quite simply
work *differently*. They're internally different. SCCS is a per-file
versioning system. You have to pile a ton of kludges on top
("Teamware") in order to get anything like a per-repository system.
Mercurial is a per-repository versioning system, and it *is* the one
that was openly, after a _very_ lengthy debate, chosen to replace
Teamware for at least ON and SFW. It doesn't maintain per-file
version numbers of any sort.
That means that the sort of %I% hackery common with SCCS -- whether we
can or cannot agree on its usefulness -- will disappear. SCCS will
disappear from ON after build 96. It's gone. RIP. Where you once
had quasi-useful hacks, you now have nothing. You can't beat the hell
out of that ... instead, we have to come up with something useful.
I can't tell what you're arguing. If you want Mercurial to be
something that it's not, then perhaps arguing with the Mercurial
maintainers would be a better idea. If you want ON to choose
something other than Mercurial or even to stay with SCCS (!), then I
guess I'd recommend talking with Stephen Hahn, as he had the
unenviable task of marshaling the data used to make the SCM choice.
If it's that you want to have the existing SCCS hacks perpetuated
using a yet-to-be-invented mechanism that (if possible at all)
continues to have the same flaws as the previous SCCS hacks, then at
least *I* don't think that's a useful direction.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
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
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
