[M3devel] additional CVS repositories for additional gcc forks?

[Olaf Wagner]

Quoting Jay K <jay.krell at cornell.edu>:

> Olaf, I have some temporary so far hypothetical interest in trying   
> gcc 4.3.0 again -- the SOLgnu/SOLsun problem with 4.3.5.
>   Really, hopefully that's not something needed long term.
>
> I have some possibly lasting so far hypothetical interest in another  
>  gcc fork -- to fork OpenBSD's 4.2.1.
>  Though I guess I can try to apply their patches to 4.5.1.
>
> It is trivial and reasonable?
> Or it would be a pain in Hudson?

The main problem wrt. performance and i/o load is importing different
gcc versions in different directories and not as different versions.
Thus they get stored as lots of new different files, which all need
to be read and their directories locked. The gcc structure is huge
compared to all the M3 code. Of course, if we use the gcc versions in
parallel, i.e. they are variants in one of our configuration, this
is actually needed.

It might help if you postpone your gcc projects for some weeks until
we've either moved our WWW services or setup a repository mirror or
whatever.

>   In paritcular the notion of gcc-openbsd in a separate repository?
>   I actually think maybe we should use gcc-apple for *_DARWIN but   
> Tony disagreed and mainline seems ok.
>   It is for ARM_DARWIN, which isn't in great shape (Hudson?! :) )
>
> I'm open to moving the existing gcc (gcc-4.3/gcc-4.3.5) to its own   
> repository.
> And the existing gcc-apple to its own.

I wouldn't like to change much now, just remove what we really don't
need.

> (Besides, a C backends wipes this all away. : ) )

No. I would see a C backend as a variant (option) too, but probably not
use it on platforms were I can compile without it.

> I don't much like CVS but I have slowly learned to use it a bit.
>   My favorite by far by far is Perforce. We could possibly use it   
> free for open source work.

Perforce is nice, agreed. I haven't used it much in practice though.
I'm not sure how much effort it would cost us to get a Perforce setup,
and if all users would be comfortable with it.

> I have lots of experience with it. It is fast. It has good gui. It   
> has atomic changes. It does branching right (unlike svn which does   
> branching completely wrong)

I wouldn't say that, though subversion still has several severe problems
with merging, especially tree merges.

> I have no experience with anything else -- svn, mtn, git, hg, etc.
We (Elego) have, but the experience of the M3 developers will vary
very much I think.

Git may be an interesting option, though I'm not sure if it is really
mature enough and has got all the infrastructure support we may need.
We've got commercial customers who are thinking about switching over to
it completely though.

As I've said before, switching to another version control system will
involve much tedious work, and I cannot contribute much (time)
for that. However, if the M3 community decides to use something
different and plans and implements a reasonable migration to the
new tool(s), I wouldn't object to that.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194