[Coco] nitros9 level3

[Gene Heskett]

On Saturday 20 October 2012 13:47:57 Lothan did opine:

> From: Gene Heskett
> 
> > Aaron:  I have installed mercurial, and configured my bashrc's to
> > include the /etc/bash_completion.d/mercurial file.
> > 
> > But the hgrc files installed are empty of any active content, and from
> > reading the man pages I don't have a clue what to put in them.  Are
> > there any examples extant that can be shared?
> 
> I've never looked at the hgrc file on Linux, but it's probably similar
> to the one in Windows. If it's like the one in Windows, it has a list
> of options that are different from the defaults along with a path to
> your default editor, diff tool, and so forth. I'll update my Ubuntu VM
> and let you know what's in mine later today if someone doesn't beat me
> to it.
> 
> > Once that has been solved, what would a command line to pull the repo
> > with hg look like?
> 
> There are a couple of ways to go about it. If you want to clone the
> NitrOS-9 repository into the current folder, you can use this one:
> 
> hg clone http://nitros9.hg.sourceforge.net:8000/hgroot/nitros9/nitros9
> 
> When I say current folder, I mean something like ~/src/nitros9 or
> /usr/src/nitros9 where nitros9 is the current folder.
> 
> Alternatively, you can specify the relative or full path to the folder
> you want to use and hg will create it if it doesn't exist:
> 
> hg clone http://nitros9.hg.sourceforge.net:8000/hgroot/nitros9/nitros9
> ~/src/nitros9
> 
> > And one to just pull any updates without destroying any local work
> > since the last pull?
> 
> cd into the root of your local repository (e.g. cd ~/src/nitros9) and
> then pull and update:
> 
> hg pull
> hg update
> 
> or you can pull --update (or pull -u) to do both at once:
> 
> hg pull --update
> 
> If you want to browse the options and command, you can run "hg help" or
> "hg help command", like this
> 
> hg help
> hg help pull
> hg help update
> 
> One thing to keep in mind is that when you clone a Mercurial repository,
> you clone the whole thing -- it's basically an exact copy of the
> original repository at that point in time. When you do an hg pull and
> hg update (or hg pull --update), it grabs only the latest commits from
> the host that you don't have just as you would expect.
> 
> I mention this because you can make changes to any files in your local
> copy of the repository and when you commit the changes (hg commit), the
> changes are committed only to your local repository. If you have write
> permission to the master repository on SourceForge, you'll need to "hg
> push" your changes to the master at some point (usually when whatever
> you are working on is complete and ready for the public).
> 
> To your specific question: When you pull/update from the master to your
> local repository, Mercurial does not clobber any changes in your local
> repository. If you make a change to say OS9Defs and Boisy makes a change
> to OS9Defs in the master, Mercurial will attempt to merge Boisy's
> change to OS9Defs into your copy. Just keep in mind that this ain't CVS
> or SourceUnsafe or Subversion or any of the others that don't have a
> clue how to merge changes correctly. The first time I tried to merge
> changes with Subversion, I ended up with a horribly broken working
> copy, spent hours merging files manually, and swore off merging
> indefinitely. Mercurial merges actually work, although you do need to
> be aware that it happens somewhat silently for the most part. The one
> time merge doesn't work is when there are conflicts; e.g. you change a
> line to DD.BtSiz and someone else changes it to DD.BTSiz. In that case,
> Mercurial complains about the conflict and leaves it to you to resolve.
> I haven't run into merge conflicts yet, so I'm not sure how this works
> on Linux.
> 
> You can commit changes to your local repository in one of two ways:
> 
> hg commit
> 
> On Windows, this pops up an editor in which you can type the commit
> message. I assume it works the same way on Linux, but I haven't tried
> it yet. The alternative is to enter the commit message on the command
> line:
> 
> hg commit -m "Some explanatory text about the change"
> 

And the first thing I run into is that ALL the defs have been renamed, so a 
make dsk in level3/coco3_6309 goes completely stark raving blitherfousy.
However it appears the level1 and level 2 coco_6309 stuff at least builds, 
using mamou.

But it appears that copy -r may have a src date to target date problem.

All the stuff in the MODULES tree, a tree I created not more than 10 days 
ago from scratch, including the z stuff Aaron has been working on, carry 
dates, which are correct in the dsk image, but as installed in my 
/dd/bootmaker-stf tree by dsave, have file creation dates just short of 2 
years old, or even older, like

 0  2004/08/04 13:18  ----r-wr 718 2D1 lltc3.dr !

My clock here is ntp set, milliseconds from WWV in Boulder Co., and my 
coco's clock, which has not been set in yonks, says
{t2|08}/DD/bootmaker-stf:date -t           

October 20, 2012  14:26:46

Nominally 10 minutes slow.  My TC^3 has an rtc I haven't set in at least a 
year.  I reset it just now, but that doesn't explain the old dates in view 
of the observation that this whole /opt/nitros9 tree on my drive carries a 
date -t (ls -l) of about an hour ago, when I pulled it.

The dates in the just built and dw re-mounted .dsk are correct.

This could make version tracking on my coco's drive into a cast iron 
nightmare.  How can we fix this?
 
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Without life, Biology itself would be impossible.