[Coco] Nitros9 Mercurial
Bill Pierce
ooogalapasooo at aol.com
Sat Nov 16 18:46:19 EST 2013
Tormod,
Though it's true you can pull older versions of Nitros9, but other than the revisions of the past year (or so), anything older would have to be built with toolshed instead of lwtools as the current makefiles were just recently fully converted to lwtools (as you should know, you made a lot of the changes :-)
In any older pulls, the makefiles would revert back to the toolshed methods..
Having used nitros9 from the repo for many years now, I can say the current build is one of the best I've used. The only problem I have with the current nitros9 is that somewhere along the line, we lost some system memory. In using certain programs and drivers, this loss can be noticed, but it's rare. And I think that comes down to actual code changes to a few system modules and not the build method. This has been apparent for some time now, since about nitros9 3.2.6 or a little earlier. Also, some report problems with the latest shell+ and the shell scripts. I don't use shell scripts so I do not see those problems. I do know NOT to use shell+ 2.1 as it has a memory problem and was fixed in shell+ 2.2a. The problem was that shell+ 2.1 was reserving too much memory for a process on startup and if the process requested more memory, there wasn't enough. There used to be a patch for this, but I think shell has been modified slightly and the patch probably wouldn't work anymore. I haven't seen any problems with shell+ 2.2a of which I use daily. I have now tried "most" of the available disks in the repo for the Coco3, 2, and 1 and have had no problems. Also the build process is "almost" error free now. The only errors being in some of the 3rdparty folders of stuff that has never been updated to work with the current build methods. Most of this stuff has never been successfully built anyway. There are a few things that have been omitted from the builds (or ignored) that really need to be added, but what is being built is building correctly. My main 3 complaints on the repo are the same as they have been for a long time now which are:
1. No builds for Vcc or MESS (emudsk boots) as 45-60% of the people still using the Coco use emulators, even if they also still use the Cocos (I do).
2. No 35 track SSDD boot disks available for direct backup from RSDOS or HDBDOS and making HDBDOS HD boots. (DOS255).
3. Undescriptive names for some 3rdparty packages (mm for microscopic mission, rof for rescue on fractalus etc)
Other than that, the current state is the best it's been in a long while :-)
Bill Pierce
My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Webmaster of The TRS-80 Color Computer Archive
http://www.colorcomputerarchive.com/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
E-Mail: ooogalapasooo at aol.com
-----Original Message-----
From: Tormod Volden <lists.tormod at gmail.com>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sat, Nov 16, 2013 9:44 am
Subject: Re: [Coco] Nitros9 Mercurial
One feature of code revision systems like mercurial and git is that
you can rewind your repository tree back to any older revision (hg
update -r some-old-revision) without keeping separate copies of the
directory trees. Of course, this only affects the source code checked
into the repository, and not any built files. However, it should be
possible to reproduce any older builds this way.
And if you for some reason want to keep separate copies, there is no
need to do a full hg clone repeatedly, you can just copy the old tree
to preserve it and run "hg pull; hg update" in the original tree.
"make clean" and "hg purge" will clean up your working tree so that
you get a clean build from scratch if you want. Alternatively, if you
are really worried about cruft in your working tree, do all builds in
a copied tree while reserving the original tree for "hg pull; hg
update" only.
Tormod
--
More information about the Coco
mailing list