Fedor Sergeev writes: > On Tue, Jun 16, 2009 at 10:29:01AM -0400, James Carlson wrote: > > The higher level issue (how does versioning work anyway?) has been > > discussed several times. > > And? :)
And see the archives. In short, Mercurial just doesn't do that at all, and versioning is something better left to packaging anyway. Alexander.Gorshenev at Sun.COM writes: > On Tue, 16 Jun 2009, James Carlson wrote: > > > Alexander.Gorshenev at Sun.COM writes: > >> So is it something to be addressed later or users just have to live > >> with it from now on? > > > > The 'hg keywords' check will tell you to remove that old SCCS-based > > swill when you're updating files. The general rule is that you fix it > > (by removing it) when you come across it. Old files still have it, > > though. > > That is probably an answer a developer of Solaris would give to a > developer of Solaris. Which I am not. I am from Sun Studio team. And > mostly concerned with the fact that a useful functionality has been > taken out without any substitute. Correct; it's just gone in OpenSolaris due to the use of different tools. Mercurial doesn't do that. > > The higher level issue (how does versioning work anyway?) has been > > discussed several times. > > I've read the two mail threads mentioned in "Mercurial Workflow"/"No > ID keywords". The thread where it was decided to drop sccs keywords > only talks and cares about versioning of the modules and other sun built > binaries. What I am interested in is to tell which system header files > were used to produce user's binaries. I want to be able to approximate > user's compilation environment given a binary of a questionable origin. That's a good question, and I'm afraid we just have no way of doing that. In theory, we could develop some new tool to stamp the header files in ON builds, but I'm not sure it would necessarily solve the problem. > You see, we put into binaries (to comment sections and debug sections) > lots of info one can use to reproduce the environment: user's ident > values, versions of the compiler components and the linker. And we used > to put useful ident strings of system headers as well. Not anymore. > > So since #pragma-ident-to-comment-section path is now useless to tell the > header files from the binary, I am looking for any reasonable subsitute. > In theory it would be enough to have hg hash. But something more readable > and in a sence monotoneously increasing would be better. I think it'd be nice if the tool chain "knew" that a given file came from packaged software, and extracted the packaging-resident information necessary to identify the source. I'm not sure, though, how to do that in a reasonably efficient manner. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> 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
