Chad,

> IB currently compiles in MSVC++. Thats not open source. What happens if we
> decide to write utils for IB and we do them in Delphi or CB? Oops, we cant.
> Dave won't let us, Delphi and CB arent open source.

It seems I am coming over harder than I meant to.

1. I have zero problems with people writing open source utilities for
Interbase in Delphi, CB, Java, VB, ...

2. IB only compiles in MSVC++ on Windows as MSVC++ is only available for
windows.

3. My guess is that the majority of volunteer C programmers for the Open
Source project will come from non Windows platforms. Remeber that IMHO
we need to pick up programmers from outside the user community, because
for the most part the user community is dbms application builders not
dbms system coders.

a) because their communitites are more used to contributing to open
source projects

b) because you find more C progammers there than you do on windows,
remembering that I am talking about core IB here ie a C dbms with no gui
written in highly portable C code.

So if you accept my premises so far then will you accept my belief that
we should do all we can to attact the coders we need. My assertion
(that you obviously believe I am trying to force you into [sorry about
that] is that adopting tools that are different to the norm (of open
source), and particularly tools that cost money is counter productive to
getting this community going.

On a political note, does the feeling of this group carry any weight in
the selection of VCS anyway?

On a technical note I have used both PCVS and Source Integrity on OS/2
and Windows (16 and 32 bit) prior to using CVS. My feeling is that

Source Integrity has a fantastic feature of the sandbox, to my mind this
is critical to large and distributed projects. Essentially PCVS lost
track of the files once they were on your hard disk. CVS also has this
feature, only unlike the GUI of Source Integrity I have never yet got it
confused.

CVS works least well with binary files such as Delphi forms. These
files really need locking when people are editing them and CVS
discourages locking (you can set it up for locking but it's not the
natural way). However, in distributed projects where people are not
immediately accessible if they have locked a file you need access to I
think locking is generally a bad thing (and therefore I personally think
tools like Delphi are not very well suited to large distributed
development).

Bitkeeper will have better support for Lines of Development (like
sophisticated branches) and also has consistancy checks to protect
against corruption. It also has a very neat feature of allowing stages.
eg we could run a site copy of IB, we could then modify that as a team
and only when all our team had completed the feature commit the whole
back to the main project. That is very powerful and flexible and is hard
work with CVS (and pretty impossible with Source Integrity).

My requirements for a VCS would be

- Widely accepted by the open source community (as if you did not know I
thought that)

- Available for as many platforms as possible (anyone got the full list
of IB platforms, current and planned?)

- available with a web interface for zero install access to the current
source code

- support for the development team getting patches (created using a free
tool) from anyone. These patches should then be able to be reviewd
before committing to the main tree. The core developers should not have
to get full source files to process.

- simple access to repositories over the internet with support for low
bandwidth access (eg only sending differences)

- anonymous read-only access

- gui interfaces for most common platforms (Windows, Linux, Solaris
etc).

- support for large numbers of concurrent users on the server

- acceptable to current interbase developers

- ability to import existing source and version history

- support for sandboxes (ie when you get a local copy the cvs keeps
track of it and can tell whihc parts are out of date, which conflict
with other changes and can update your local copy to get other peoples
work without losing your changes).

- be widely proved ie not a new untested product (we have enough
problems without a buggy VCS) for similar projects (size, cross
platform, language, server based).

- allow automation of things like daily

> CVS will likely be our end choice. But if we blindly choose it wo consdering
> alternatives, then we are very closed minded.

I was not proposing blindly choosing it. I was simply suggesting that
other factors than feature set were more important.

> What if a free (but not open
> source) VCS was available? Lets say for instance we decided StarTeam was the
> perfect VCS, and Starteam liked our cause and donated free copies for our
> effort. You would turn it down because its not open source?

I would personally turn it down yes. I believe the image of the open
source Interbase amoungst the open source community from where we need
(IMHO) to recruit coders (and to a much lesser extent users) would be
harmed by such a decision.

I am sorry you think this is dictating (I am not sure how I could
dictate from a position of zero power anyway) but to my mind the
critical fact that needs to be taken into account is that we are
planning an open source project not just a database server project. I
would definately consider all VCS tools for a closed source project, but
to my mind that is not really appropriate in this instance.

In other areas I am much more flexible and willing to consider different
tools such as ANT for building instead of make. But a vcs is different,
it is the only tool a coder has no choice about. If you say IB will
compile with MSVC++ then I can check it out and make it compile with
XYZ++ (and you might accept patches to make that the standard). I do not
have the same freedom when it comes to the VCS, if I want the source I
cannot choose to get it with SourceIntegrity if it is kept in PCVS.

Dave