[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Native windows support (was Re: [Gnu-arch-users] Extension language)

From: Tom Lord
Subject: Native windows support (was Re: [Gnu-arch-users] Extension language)
Date: Sat, 18 Oct 2003 14:20:05 -0700 (PDT)

    > From: Joshua Haberman <address@hidden>

    > I would argue that a native Windows port is highly desirable right now,
    > and that any version control software that seeks to become pervasive
    > will need to run on plain Windows.  The cross-platform projects I work
    > on could never move to a version control system that didn't support
    > Windows because it would isolate the contributors that use
    > Windows.  

What you describe is a shop with these characteristics:

        *) some programmers working on unix-family platforms
        *) some programmers working on msft-line platforms
        *) a shared line of development between the two

Developers specializing in work on msft platforms are likely to be
already trained and ready to go using msft platform vc tools, horrid
though those tools may be.

Supposing that the unix developers would like to work with arch, then 
the shop you describe has a problem to solve:  how to bridge between,
say, "visual source [un]safe" and arch.

I would compare that to a problem that has already been solved in the
arch world, though refinements to the solution are ongoing:   bridging
between developers using CVS and developers using arch.

Building such a bridge to CVS seems to be a quite tractable problem:
the folks currently working on it are off tuning performance and
adding features, not trying to get something basically working.  I see
no reason why msft vc tools shouldn't be similarly bridgable.

It is, in fact, a distinct advantage of arch over some of its
competitors that it is flexible enough to support such bridging in
clean and sane ways.

You might reply saying "Yes, but I want the msft developers to have
all the benefits of arch," to which there are three replies:

  1) Your company will be more competitive in the labor market if you
     let the msft developers stick to things like "visual source

  2) Now you are beginning to understand why killing msft platforms is
     ultimately good for technology consumers:   the costs of making
     everything work well on both unix-family and msft-line platforms 
     tends not to fall well below the demand and the cost of
     developing good and lasting solutions on unix-family is
     distinctly lower.

  3) I hear that Common Lisp provides nice file system abstractions
     that work across platforms.   It could be an interesting exercise
     to try to make a CL port of arch.

It's a nice fantasy to wish for a world in which platforms and
applications were independent, but as they say, "If wishes and buts
were candy and nuts....."

I am curious: what is the _current_ solution you use for
multi-platform development?  Is it ad hoc?  Nonexistent? Is it CVS?
If it's CVS, then the existing arch<->CVS bridges already give you a
handy solution.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]