World: r3wp

I.e. a 'Linux" repository and a "Win32" repository where you manually 
do merges (or copy/paste) in between will only lead to trouble.

Back in a while. Go ahead and post your notes, then I'll reply. Thanks!

Quick Q: what version control system do you use atm?

Third step is to write a post-commit hook which exports from internal 
to external.

And then the automation kicks in.

The same post-commit hook then:

- moves the export to someplace public (i.e. another public VCS like 
Github or Google Code; or simply uploading them to rebol.net/rebol.com),
- and somehow notifies anyone interested of the new upload.

You'll get the notification for free on Github (I don't know about 
Google Code). But this could also be updating a simple .txt on a 
webserver somewhere which lists all available exports. Heck, it even 
the directory listing features of a webserver would suffice (as long 
as the exports are named consistently).

And from there on, we can have build bots which pick up any new export 
and build it for their platform. Build results are reported back 
somewhere (email, static website on the bots which gets aggregated 
elsewhere, a simple CGI, R3 chat, ...).

The details of those latter parts are not particularly exciting, 
as they are easy to do in a variety of ways.

For example, even the makefiles are not really important at this 
point.

But what's important is how to keep those "external" builds consistent 
with your "internal" builds.

Which is why it's also important to realise that those build bots 
need not necessarily be public. They could well be Carl's own machines 
standing at home which put the final binary in a central place for 
Carl to use.

If that's not immediate, you can obviously still use your own build 
stuff (Visual Studio projects, whatever), and as long as you regularly 
keep the sources up to date by committing, the builders will notify 
you anyway if the external build mechnisms got out of sync.

The most important thing to realize, is that not every commit, even 
if externally visible, needs to be perfect. It's perfectly fine if 
the external builders break, that's what they are there for: telling 
you when something went amiss.

A few comments...

I was expecting that all these various implementation parts were 
already available.  That is, we're not reinventing the wheel.

They are.

Next, is there any conern about flooding. On a good day, I make about 
10-20 commits.

Nope.

BTW, there are no merges between Linux and Win32 files.  These are 
all in the same repository.

So, all of the above seems pretty standard.

It is.

It just needs to be done for R3.

That's why I asked earlier about where we want to put it.... because 
that seems to be a bigger question.

http://www.rebol.net/builds/rebol3/alpha/

Call the exports r3-<datestamp>-<revision>.zip.

dinner. bbl

Or export into Git and put it on your server or on Github.

Or export into Subversion and put it on Github, or Google Code, or 
....

I think using Git is the way to god for a new project.   every big 
project I see that is changing VCS is goint Git.  it seems to be 
the most powerfull VCS right now.  do you agree Andreas?

god... hahaha 
obviously I meant  "go"

Absolutely.

And I personally would suggest Git, put that'll take time and effort 
to get started with.

So it's probably quicker to get things going by using whatever Carl 
is familiar with.

are there free Git servers?

(Let's switch this to "Source control".)

good idea.

Any one of them is fine with me.

So, A110 will be released soon.

(Meaning in a day or so.)

For this release, i'll be making fixes to the posix files, and most 
of what Steve Solie posted on CureCode.

Just to explain, my part has to remain focused on R3 development, 
mainly at the kernel level.


That means we need someone to take charge of what we've talked about 
above, using Git or whatever.

I'd be willing to do that.

Ok, very good.

What do you think about soliciting a few inputs from other developers 
regarding choice of rev control and related issues... because we'll 
want them to use it?

Fine with me, but not really a necessity.

As long as it is in _any_ version control we can easily bridge to 
almost any other VCS.

Well, I want to make sure that Brian, Cyphre, Henrik, Maxim, and 
a few others have a chance to say something... since they're going 
to be some of the primary users.

There are a few side issues around it too. Eg. do we need web access.

BTW, the reason I suggested Google was simply to gain greater visibility.

We only need to source for starters :)