Re: Keeping different platforms in sync?

[Jesus Manuel NAVARRO LOPEZ]

Hi, Stephen:

Stephen Jowitt wrote:
> 
> Hi,
> 
> We're currently using cvs and I have to investigate how we can
> best keep our source code in sync on both the platforms used by the
> developers.
> 
> We develop for Windows and Linux and both systems share source code from
> 
> the same repository. Our developers would like to be able to do the
> following:
> 
>   1) Write code on windows machine. Compile and test.
>   2) Compile and test the same code on a linux box
>   3) Commit changes to cvs
> 

The "standard" way:
Develop where you want.  It really doesn't matter.  Most probably, you
will end up developing Win specific code on Windows and Linux specific
one on Linux, if only because it will be easier to debug while coding,
but this is not needed.
The only "issue" you need to have in mind is don't move *physical files*
between platforms (in order to avoid end-line problems).  Have a
distinct sandbox for editing on a Win platform and *a different one* to
edit on Linux (this is true for each single developer; you can have as
many sandboxes as you need, probably two for each developer, if each
developer can/will develop both in Linux and Windows).

Then build with the aid of (for instance) make, so from the very same
source pool you can build (using make with params, like configure
--win/--linux) the whole lot of (sub)products.
Obviously since you are not in short of machines you will build the win
versions on a win platform and the linux on linux from a sandbox (or an
export) managed directly on the same platform, or at least on the same
*kind* of platform (no cross-compiling issues if at all possible,
thanks).  This way there should be no problems.

> This would be easy to do if the developers committed the source in
> between
> stages 1 and 2, but they don't want to do that as it is a busy tree and
> would break
> others' builds.
> 

First of all, this mean you have a project management problem.  Your
team should checkin soon and checkin often.  If they don't want to, it
is because the "support stuff" (yes, stuff, not staff.  Stuff for
people, programs and strategies all in a box) is failing to do its work.

1/ Don't share the sandboxes among programmers. Each programmer will use
one sandbox on each plaform he works on.
2/ Modularize your program (this is not a CVS issue, but a engeneering
one) so a given programmer can be sure that everything but the pieces of
code he is working on (or his "subteam" is working on, at least) will be
stable enough.  Under CVS this can be done, for instance, more or less
like this.
Imagine a client/server app with access to some database resources.
Modularize you program:
Module 1: Database configuration.  Scripts to build and maintain your
databases
Module 2: Data Base Access Layer (aka DAL).  Encapsulates access to
databases
Module 3: BOL (Bussines Objects Layer): The "server" side properly
speaking.
Module(s) 4/5...: Client apps (which can have a common pool of shared
libraries, for instance, as a separated submodule).

With this structure, and good encapsulation (conceptual encapsulation,
not necesarily the same as in OOP, but the same idea) each subteam can
work on their modules without affecting others's work but when changing
the access API among modules.  API among modules only can change after
team aproval (be it somehow "democratic", or manager-driven).  You know,
CVS won't stop the need for good communication among devel-team members.
Now.  Let's imagine your program needs a change on the database schema. 
First, all team members know and aprove (or at least know and give their
opinion) the changes to be done.  Imagine that your team is accessing to
the database version 1.0.0
You probably will label/branch that scripts leading to database schema
version 1.0.0 and all the rest of the team will access to this
last-approved version while developing.  Only the subteam for database
development will work with unstable database-mangling code.  It won't be
till database version 2.0.0 (or 1.0.1 or whatany versioning schema fits
for you) is stable enough that it will be released to all the other
members of the team.  So, as I said, all members will be working on
"stable" code for all the "program" but the part they are directly
involved with.

You can see that this schema will fit specially well with a more or less
already matured product.  On development on the very early stages, while
the paradigm stays basically correct, it will accept more flexibility
about release times.  Anyway, is already expected for the code that it
migth compile but it won't offer "signed" functionality.

> Possibilities I have thought of are:
> 
> 1) Storing checked out copies of the source on a personal samba mount
> accessible
>     on both hosts - But would the conversion of ascii characters etc
> screw things up?

No.  As long as all editing on linux platform is done on a different
sandbox from that for editing on windows platform you will be safe (you
can workaround this for instance by using editors able to properly
manage different EOLs, but this will probably be more of a problem than
a solution: go the easy way and have different sandboxes).

> 2) Everyone has a personal branch of the main trunk which is up to them
> to synchronise
>     with the main trunk. This would then allow them to commit their
> source, test compile,
>     change to the other platform, run cvs update and then run a test
> compile. But, this
>     seems hellishly over complicated...

This is (more or less) the way to go.  Probably one branch for each
developer is overkill but you most probably will have two or more
branches for each (sub)module of your project (in general, on a
more-than-few-files project people will tend to be organized around
these "modules": like the database gurus, the local GUI experts and the
like, and the same people will spend most of their time working on the
same subset of files): the one, more or less "stable" and the "bleeding
edge" one.  Probably the "bleeding edge" one will be main trunk for each
of these modules.  If your project is short enough you can acomplish
this very same just with labels.  Everybody is working on main trunk but
they remain "sticky tagged" to a known-to-be-good version of all files
but the ones they are directly working with.  Upon aproval, that tag
will be pushed to the new know-to-be-good versions and all will
actualized their sanboxes to them.  If this change *unexpectedly* breaks
other's code, it is a sign of bad practices/bad communication: either
some parts of the code are not properly encapsulated thus arising
undesirable side effects upong upgrade, or API among submodules has
changed without letting this to be known and accepted by the rest of the
team.

Now, you see, your seeming to be trivial question has gone far away from
a simple CVS question.  I would say you still have not digged enough on
the general aspects of you project organization, thus this question
would fit better at comp.software.config-mgmt, for instance.  Once you
know exactly what you want to do, what your "strategy" will be, you can
start to look for the rigth tool, be it CVS or not, for the "tactics" to
acomplish your goals (ie: then, if you end up with CVS being your tool
of choice, what's the better solution for managing branches/revisions,
etc. under your *thoroughly thougth* scenario?).
Hope this helps.
-- 
SALUD,
Jesús
***
address@hidden
***