Posted by David Simpson May 12, 2004
At 06:15 AM 5/12/04, you wrote:
>At 05:56 AM 5/11/04, you wrote:
> >Hi
> >
> >I have an off topic question regarding version control with a 68HCS12
> >project I have been working on.
>
>There actually are commercial version control products. Microsoft makes
>one, there are others, and better. The key drawback, in my opinion, is
>that they are designed for huge teams of programmers. They have features
>that get in the way of the individual programmer (by design, I guess,
>considering the sloppy habits of too many programmers). The main problem
>with them, as a group, is that unless top management insists, the average
>programmer won't use it. At my last client, all the programmers refused to
>use the product that the programmers themselves had selected, despite an
>explicit directive from management that they use it. But management didn't
>follow up, and it didn't happen.

Check out an open source CVS called subversion at subversion.tigris.org

I have been using this now for a few months, an it was quite easy to setup,
and on a day to day basis is very easy to use. You can set it up locally if
you are the only user, or as a client/server is more than one developer is
sharing files. The windows interface is very easy to use. I couldn't live
with out it now.

David


Posted by Michael Farrugia May 11, 2004
I think this is not version control that you are looking at but just
maintaining two projects. I think the best way is to introduce some #ifdefs
in your source and then do the appropriate defines in the make files. In
this way the code which is common for both projects will get compiled always
while the parts which are relevant to only one of the projects will be
compiled when needed. Michael

>From: Graham Tricker <>
>Reply-To:
>To:
>Subject: [68HC12] OT: Version Control
>Date: Tue, 11 May 2004 13:56:08 +0100
>
>Hi
>
>I have an off topic question regarding version control with a 68HCS12
>project I have been working on.
>
>I have a generic HCS12 motherboard which acts as a user interface keypad,
>LCD display and lots of other generic bits. This interfaces via SPI to one
>of two HCS12 based receiver modules, which are closely related in function
>but fundamentally different in design. During the development phase I have
>been working with two source directories one for the motherboard and one
>for
>the receiver modules. I have two projects which use each source directory
>parsing a compiler switch on the command line to compile custom parts of
>each project. This approach works for the minute as I am saving versions
>before switching between different projects and have managed to not get
>myself in to big a mess.
>
>I am now at the point in the project where the two products are
>simultaneously being made into full prototypes for customer evaluation and
>require a robust version control system for all my projects.
>
>I think the simplest approach would be too split each project and have them
>as separate entities, which works well when modifying one project during
>the
>evaluation process, but if this is a common modification between the two
>projects I then have to modify two lots of source.
>
>On the other hand if I keep the source for the projects linked and I make a
>modification that only affects one project I am in a position of releasing
>both projects to keep them running side by side. >If anybody has any opinion or has had a similar experience on this topic
>please let me know as I don't want to make a decision now and find I have
>limited myself sometime in the future.
>
>Cheers
>
>Graham >**********************************************************************
>This message contains confidential information and is intended only for the
>individual named. If you are not the named addressee you should not
>disseminate, distribute or copy this e-mail. Please notify the sender
>immediately by e-mail if you have received this e-mail by mistake and
>delete this e-mail from your system.
>Although BERU F1 SYSTEMS believe this e-mail and any attachments are free
>of any virus or other defect which may affect a computer, it is the
>responsibility of the recipient to ensure that it is virus free and BERU F1
>SYSTEMS do not accept any responsibility for any loss or damage arising in
>any way from its use.
>This footnote confirms that this email message has been swept by MAIL
>Sweeper.
>**********************************************************************

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?pageatures/junkmail


Posted by Gary Olmstead May 11, 2004
At 05:56 AM 5/11/04, you wrote:
>Hi
>
>I have an off topic question regarding version control with a 68HCS12
>project I have been working on.

There actually are commercial version control products. Microsoft makes
one, there are others, and better. The key drawback, in my opinion, is
that they are designed for huge teams of programmers. They have features
that get in the way of the individual programmer (by design, I guess,
considering the sloppy habits of too many programmers). The main problem
with them, as a group, is that unless top management insists, the average
programmer won't use it. At my last client, all the programmers refused to
use the product that the programmers themselves had selected, despite an
explicit directive from management that they use it. But management didn't
follow up, and it didn't happen.

Gary Olmstead
Toucan Technology
Ventura CA



Posted by Andrew Lohmann's New Email Server May 11, 2004
I have two methods:

The most robust is to have separate projects (I have about 5 currently running) which use a lot of identical source files. Each project has a header file with a
#define InstTyp 1 // the first project
Other projects each have a unique value of 2, 3 etc for InstTyp.

I have a text file called com-modu.txt which lists all the source files which are common to more than one project. When I start work on another project I look through com-modu.txt to see which project has the latest version of the common files my current project uses I then copy the file's into my current project and amend com-modu.txt to show that that the newest files are also in the project I am working on. I have a key "+" "-" used or not used in project, "*" most current version, and "~" previous version.

The "InstTyp" is used to switch different option in or out e.g. a common serial port source file may have modem control lines enabled in only one of the projects.

The less robust method that I have started using more recently is to keep all the common files within a common directory.

I keep a copy of each of the previous 3 versions of each file, and the whole project is achieved when it is released. You may need to force compilation of all files when you start working on another project. Andrew Lohmann AIIE
Design Engineer

PLEASE NOTE NEW EMAIL ADDRESS IS: Bellingham + Stanley Ltd.
Longfield Road, Tunbridge Wells, Kent, TN2 3EY, England.
Tel: +44 (0) 1892 500400
Fax: +44 (0) 1892 543115
Website: www.bs-ltd.com

----- Original Message -----
From: Graham Tricker
To:
Sent: Tuesday, May 11, 2004 1:56 PM
Subject: [68HC12] OT: Version Control Hi

I have an off topic question regarding version control with a 68HCS12
project I have been working on.

I have a generic HCS12 motherboard which acts as a user interface keypad,
LCD display and lots of other generic bits. This interfaces via SPI to one
of two HCS12 based receiver modules, which are closely related in function
but fundamentally different in design. During the development phase I have
been working with two source directories one for the motherboard and one for
the receiver modules. I have two projects which use each source directory
parsing a compiler switch on the command line to compile custom parts of
each project. This approach works for the minute as I am saving versions
before switching between different projects and have managed to not get
myself in to big a mess.

I am now at the point in the project where the two products are
simultaneously being made into full prototypes for customer evaluation and
require a robust version control system for all my projects.

I think the simplest approach would be too split each project and have them
as separate entities, which works well when modifying one project during the
evaluation process, but if this is a common modification between the two
projects I then have to modify two lots of source.

On the other hand if I keep the source for the projects linked and I make a
modification that only affects one project I am in a position of releasing
both projects to keep them running side by side. If anybody has any opinion or has had a similar experience on this topic
please let me know as I don't want to make a decision now and find I have
limited myself sometime in the future.

Cheers

Graham **********************************************************************
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Although BERU F1 SYSTEMS believe this e-mail and any attachments are free of any virus or other defect which may affect a computer, it is the responsibility of the recipient to ensure that it is virus free and BERU F1 SYSTEMS do not accept any responsibility for any loss or damage arising in any way from its use.
This footnote confirms that this email message has been swept by MAIL Sweeper.
**********************************************************************

--------------------To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu
o learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu
------
Yahoo! Groups Links

a.. To


Posted by Graham Tricker May 11, 2004
Hi

I have an off topic question regarding version control with a 68HCS12
project I have been working on.

I have a generic HCS12 motherboard which acts as a user interface keypad,
LCD display and lots of other generic bits. This interfaces via SPI to one
of two HCS12 based receiver modules, which are closely related in function
but fundamentally different in design. During the development phase I have
been working with two source directories one for the motherboard and one for
the receiver modules. I have two projects which use each source directory
parsing a compiler switch on the command line to compile custom parts of
each project. This approach works for the minute as I am saving versions
before switching between different projects and have managed to not get
myself in to big a mess.

I am now at the point in the project where the two products are
simultaneously being made into full prototypes for customer evaluation and
require a robust version control system for all my projects.

I think the simplest approach would be too split each project and have them
as separate entities, which works well when modifying one project during the
evaluation process, but if this is a common modification between the two
projects I then have to modify two lots of source.

On the other hand if I keep the source for the projects linked and I make a
modification that only affects one project I am in a position of releasing
both projects to keep them running side by side. If anybody has any opinion or has had a similar experience on this topic
please let me know as I don't want to make a decision now and find I have
limited myself sometime in the future.

Cheers

Graham **********************************************************************
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Although BERU F1 SYSTEMS believe this e-mail and any attachments are free of any virus or other defect which may affect a computer, it is the responsibility of the recipient to ensure that it is virus free and BERU F1 SYSTEMS do not accept any responsibility for any loss or damage arising in any way from its use.
This footnote confirms that this email message has been swept by MAIL Sweeper.
**********************************************************************