Hello Stablers & Heads, Based on the parts of the script with the additions for tracking source using git(1) I set out to add support for mercurial hg(1) and ended up cleaning some of the script while making some of those additions. This works exactly as before but a little more correct and with the additions to be able to track kernel sources or whole source tree with a local revision system. Example output follows (uname -v) from my system being tracked locally with mercurial. FreeBSD 8.1-STABLE #0 r211092M 55:65408c40b051 Mon Aug 9 07:03:32 EDT 2010 jhell@ujump.dataix.net:/usr/obj/usr/src/sys/MITHOP Inspiration for making these changes came from mercurial, OpenSolaris and finally http://wiki.freebsd.org/LocalMercurial Following is a list of changes that I have made that I believe people that are involved with the source may find useful. 1 file changed, 55 insertions(+), 35 deletions(-) This allows a user: * That is using csup(1) or cvsup(1) to locally keep track of the whole source tree or just the kernel part of the tree using svn(1), hg(1) or git(1). * That is using svn(1) to checkout their source tree to use hg(1) or git(1) to keep track of the whole tree or the kernel part of the tree. http://svn.freebsd.org/base/ * That is using git(1) to checkout their source tree to use hg(1) to keep track of the whole tree or the kernel part of the tree. http://spoerlein.net/gitweb/ This checks for: * SCM roots in src/ or src/sys for .svn, .hg, & .git and acts accordingly if they exist while prioritizing using an SCM root in src/ before it uses src/sys/ * Then looks for acceptable binaries for svn(1), hg(1) git(1) within the select paths /usr/local/bin & then /usr/bin. The paths may change for svn(1) or git(1) & maybe mercurial if it ever becomes part of world. Currently I have set these to only look in /usr/local/bin. Cleanups: * Instead of using variables that shared the same name as their counterpart binaries to hold a revision number use more descriptive names like svnrev gitrev & hgrev for revisions. Use git svnversion & hg variables for their respective binaries. * Adjust the paths that are checked for binaries to be of only /usr/local/bin and /usr/bin. "/bin" is highly unlikely to hold svn(1), git(1) or hg(1). * Test for a SCM root in the source tree locations before we look for binaries. If these don't exist there is no need to know where svn or git are. * For git(1) always set work-tree and git-dir so there is no possibility to end up with a "-dirty" git(1) revision. * Remove extraneous "touch version" since the previous if statement already creates the file if its not found. * Inline the test for version file. I have opened a PR: misc/149510 here: http://bit.ly/buBqXc And have uploaded the patch here: http://bit.ly/9hvVfx Throw me some feedback, concerns or other information. It will be really appreciated. Regards, -- jhell,v
On 08/10/2010 19:32, Anonymous wrote:> jhell <jhell@dataix.net> writes: > >> * Adjust the paths that are checked for binaries to be of only >> /usr/local/bin and /usr/bin. "/bin" is highly unlikely to hold svn(1), >> git(1) or hg(1). > > Please, look at conf/146828. That script shouldn't blindly assume where > user installs his packages[1]. > > [1] using non-default LOCALBASE is a convenient way to identify > non-conforming ports >And that would be to identify non-conforming ports using non-standard locations. Though the option is available to look in a non-standard location for binaries, IMHO it does not belong here and I don't find that right for building world. I also find this method a little hard to adjust for targeting specific locations, for example if the base system finally had a svnversion(1) installed and we prefered that over use of a local installed port. Currently I can just subtract that path from any one of the given SCM's configured to work with this patch without effecting the others. I have had another idea along the likes of this but just throwing an entry point hook in that checks for the existence of a user built or supplied file if you will so newvers.sh can keep doing what it has been doing for all these years without the interruption for small changes like the ones were talking about now. If people are interested in something like this I would be more than happy to oblige and provide a patch to do just that.>> + gitsvnid="`$git log |fgrep 'git-svn-id:' |head -1 |\ >> + sed -n 's/^.*@\([0-9][0-9]*\).*$/\1/p'`" > > The above line can be sed-only. A few parts can be simplified, too. >I agree with this. I had just copied it over from what was already existing and excepted by the original committee and whoever reviewed it. I will adjust the patch for the sed(1) portion of this but I would prefer to wait for further comments from the lists before adjusting the search paths to use a function and look in a non-standard place. I also meant to CC dougb@ on this as I believe he had something to do with the original commits of the git(1) portions and possibly other parts. Thank you for following up with me on this. Regards, -- jhell,v
On 08/10/2010 17:34, jhell wrote:> I also meant to CC dougb@ on this as I believe he had something to do > with the original commits of the git(1) portions and possibly other parts.I have specifically sworn off any further contact with that file. I have no idea why screwing around with what should have been a simple thing continues to hold such endless fascination for people, but I refuse to dive back into that swamp. Good luck, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
On 08/10/2010 20:39, Doug Barton wrote:> On 08/10/2010 17:34, jhell wrote: >> I also meant to CC dougb@ on this as I believe he had something to do >> with the original commits of the git(1) portions and possibly other parts. > > I have specifically sworn off any further contact with that file. I have > no idea why screwing around with what should have been a simple thing > continues to hold such endless fascination for people, but I refuse to > dive back into that swamp. >I can respect that. I just find it to be of real use to be able to identify what is currently running on the system to what revisions were available at the time it was compiled whether it be local revisions or remote or mixed like what I have done with this patch. Personally I have drove off ideas of my own for a long time due to the long standing nature and background of newvers.sh because it is just a simple straight forward use that is needed from it. To complicate something as simple as this just seems fundamentally wrong in a lot of ways so I had to weigh the negatives and positives before I decided to submit this one. Regards & thanks for the good luck, -- jhell,v
jhell <jhell@dataix.net> wrote: > Based on the parts of the script with the additions for tracking source > using git(1) I set out to add support for mercurial hg(1) and ended up > cleaning some of the script while making some of those additions. > [...] > I have opened a PR: misc/149510 here: http://bit.ly/buBqXc Just out of curiosity, why are you obfuscating this if statement? -if [ ! -r version ] -then - echo 0 > version -fi +[ ! -r version ] && echo 0 >version It should rather be fixed like this (FreeBSD standard is to put if...then on one line): -if [ ! -r version ] -then +if [ ! -r version ]; then On a tangential note ... I've been using a wrapper script for "make kernel" for ages, long before svn existed. It adds the date of the checked-out sources to the release name, e.g. uname -rsm gives "FreeBSD 8.1-PRERELEASE-20100720 i386" on this machine. http://people.freebsd.org/~olli/scripts/makekernel Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We will perhaps eventually be writing only small modules which are identi- fied by name as they are used to build larger ones, so that devices like indentation, rather than delimiters, might become feasible for expressing local structure in the source language." -- Donald E. Knuth, 1974
On 08/10/2010 21:50, Anonymous wrote:> Anonymous <swell.k@gmail.com> writes: > >> jhell <jhell@dataix.net> writes: >>> >>> And that would be to identify non-conforming ports using non-standard >>> locations. Though the option is available to look in a non-standard >> >> You're confusing default and standard value. LOCALBASE has a default for >> /usr/local. If it were a standard one wouldn't care about it and just >> hardcode /usr/local everywhere. > > ...or at least used `=' and not `?=' in bsd.port.mk.The only mention I see of LOCALBASE in all of source on stable/8 is: /usr/src/contrib/bind9/config.threads.in /usr/src/secure/usr.bin/ssh/Makefile /usr/src/secure/usr.sbin/sshd/Makefile /usr/src/tools/kerneldoc/subsys/Makefile /usr/src/tools/regression/atm/Funcs.sh /usr/src/tools/regression/atm/proto_cc/RunTest.sh /usr/src/tools/regression/atm/proto_sscfu/RunTest.sh /usr/src/tools/regression/atm/proto_sscop/RunTest.sh /usr/src/tools/regression/atm/proto_uni/RunTest.sh /usr/src/tools/tools/tinybsd/CHANGES /usr/src/usr.bin/make/Makefile So what your telling me is we would have to pull in something else to do this just for newvers.sh or is this sinking into the source from somewhere I am not aware of? -- jhell,v