On Wednesday 07 Apr 2010 14:05, Phil Clayton wrote:
> Roger,
> This sounds like a good idea.  As I understand it, this
>  would be primarily intended for things built on top of
>  ProofPower, e.g. new theories, but wouldn't exclude
>  projects that contain the entire OpenProofPower source
>  code base if, for example, they need lower-level
>  integration with ProofPower or are even experimental new
>  features of ProofPower.  Is that right?

It had not occurred to me that a project might include the 
entire PP code base, and I had been thinking in terms of a 
set up which would not have accommodated that.

I would be inclined to think fairly open ended, and set up 
something in the first instance which is aimed at things 
rather like "maths_eqs", which would cover the kinds of 
things which I was looked to have hosted.

We could have one directory for such things, with 
subdirectories for each "contribution" and some rules for 
these to permit a uniform and simple way of installing 
whatever selection a user wants to make use of, and then 
have different top level directories for things which don't 
fit into that.

Perhaps one directory for "maths_eq"-like contributions, one 
for contributions in the form of patches, and another for 
other kinds of things.  The first two having some rules to 
provide uniform installation, the last consisting of 
contributions each of which makes up its own rules.

> Personally, I am happy with GPL (2 or 3).

Well, so far it looks like GPL3 on google with mercurial.
On google you can have a different licence for documentation, 
one of the creative commons licences. Does anyone think that 
would be a good idea?

> I have used Subversion on a few projects and found it too
>  inflexible. Without access to the Subversion repository
>  a number of things aren't possible.
>  (Simply being
>  connected to the internet doesn't necessarily solve
>  this: in my case, the Subversion server was only visible
>  from an internal company network.)

I don't understand the distinctions you are making here, and 
think that I need to.

>  Whilst the
>  Subversion working copy is local to a machine, without
>  visibility of the repository I couldn't see the log of
>  previous commits, nor make any commits.  Working on more
>  than one commit was a pain.  (Sometimes, I found that a
>  particular enhancement required a logically separate
>  enhancement to be made first...) Fortunately the
>  Git-Subversion interface worked quite well and I was
>  able to use Git locally to prepare a series of commits
>  and upload them once I was connected to the Subversion
>  repository.

I'm not convinced that the problems you are experiencing 
reflect what would happen if we had a properly set up 
subversion repository.

For this I think you need to have the repository on a server 
which runs a subversion service.  Having a repository which 
is visible across the network by other means is not the 
I have a subversion repository at rbjones.com, but cannot 
provide a general service because rbjones.com is on a 
virtual host so all access to the repository has to be 
through my username.

Also I don't understand your commit problem, why was it 
desirable to have a series of commits rather than just one?

> My preference is Git but, having read about Mercurial, I
>  would be happy to work with that.  Or possibly Darcs -
>  another distributed version control system.  Definitely
>  not Subversion though!

Well you and Rob are both against subversion so we can do 
Mercurial at google or Git at sourceforge, unless anyone 
prefers some other host.

Both of these are blocked for Cuba, Iran, Libya, North 
Korea, Sudan, Syria, does anyone think that important?

Roger Jones

Proofpower mailing list

Reply via email to