From: Anthony Fox 
Subject: HOL4 via Git
Date: Fri, 16 Mar 2012 12:43:09 +0000
To: Mike Gordon 

You can get a read-only version of HOL4 with:

git clone https://github.com/mn200/HOL.git

If you wish to commit at some point then you can do:

git clone git@github.com:mn200/HOL.git

---------------------------------------

from Michael Norrish 
to HOL developers mailing list 
date Thu, Dec 16, 2010 at 4:22 AM
subject[Hol-developers] upgrading for standard kernel users
mailing list hol-developers.lists.sourceforge.net Filter messages from this mailing list
unsubscribe Unsubscribe from this mailing-list
      
If you are using the standard kernel and want to continue to use HOL after the "BIG refactor" check-in (r8802), you will not only have to do a

  bin/build cleanAll

but also

  rm src/bool/SharingTables.{sig,sml}

in order to get your subsequent bin/build to work.

Experimental kernel users shouldn't be affected.

Michael

---------------------------------------

Date: Mon, 16 Jul 2007 18:48:31 +1000
From: Michael Norrish 

I have switched the repository to Subversion.  You should be able to
access it now - use the URL

   https://hol.svn.sf.net/svnroot/hol/HOL

do something like

   svn co https://hol.svn.sf.net/svnroot/hol/HOL

and it will check-out a working copy.

I have tried to turn off CVS access.  For "active" people I have gone
through and turned off developer access to the CVS repository, which may
still be present.

Diffs of changes should still be sent to the hol-checkins mailing list.

Let me know of any problems.

Michael.

---------------------------------------

Date: Wed, 18 Jul 2007 15:19:16 +1000
From: Michael Norrish 

Mike Gordon wrote:
 > Presumably "http://www.cl.cam.ac.uk/~mjcg/SourceForge.html" needs 
to be updated.

Yeah, some comments on how svn@S/F works:

Anonymous browsers and developers check-out working copies in the same
way.  The only difference between the two is that developers will
eventually want to do a

   svn ci

command.  When this is attempted, the system will ask for a username
and password (use your SF identity).  These details are cached on the
client machine once they've been provided successfully, so you
shouldn't need to provide them subsequently.  (This should be a big
relief for those who never got this to work over ssh.)

Only committing requires the password.  The other important commands
that only need to read the remote repository can be used by anyone.
These important commands are things like

   svn stat   - show the status of local files
   svn update - update local files from the repository
   svn diff   - show differences

In changing from CVS, I think the big thing to get used to is typing

   svn stat

instead of

   svn update

to see what's been done.  (Though there is a cvs status command, I
almost never used it.)

If you have to deal with a merge conflict (i.e., your local changes
conflict with a change that is in the repository, which you discover
on doing a svn update), you need to both fix it, and then also issue
the

   svn resolved 

command.

My standard practice with a checked out repository sees me cycle
through

   svn stat
   svn update
   svn ci

Other more exotic commands are much rarer.  The next most common is
probably

   svn add    - add a file, so that a subsequent commit moves it into
                the repository

One of Subversion's big benefits is good support for renaming (moving)
and copying files.  Just do

   svn mv file1 file2

or

   svn cp file1 file2

and the appropriate stuff happens.  Similarly, the process for
removing a file is better than in CVS where you have to do the
annoying two-step of removing it in the file system and then doing a
'cvs rm'.  With Subversion, just do

   svn rm file

With add, mv, cp and rm you have to follow-up with a ci to get your
changes committed to the repository.  If you want to undo a scheduled
(i.e., as yet uncommitted) change, use

   svn revert

Also, note that you can do a svn diff and a svn revert even if you
aren't connected to the network, because the client retains a local
copy of the latest state in the repository.

                          --------------------

As for HOL, there aren't any real changes.  The only difference is
that when you do a checkout (as per previous instructions), you will
end up with a directory called HOL, not hol98.  Configuring, building
and all the other stuff from Mike's web-page should be the same.

Michael.


Instructions for working with HOL from SourceForge


WARNING. The material below is obsolete: (see emails in red above describing the change to Subversion)!

HOL is now an official open source project at SourceForge.

The HOL system can be downloaded anonymously, which gives read-only access.

Alternatively, developer access is available if you are a developer and need to check-in changes.