This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Keeping 2.0 source tree up to date


>>> Grant Edwards <grante@visi.com> 09/22/03 09:34pm >>>
> On Mon, Sep 22, 2003 at 01:29:28PM -0600, Gary Thomas wrote:
> > What I do is have my own CVS server (repository).  Then, at
> > certain times such as starting a new project, I merge the
> > public CVS to the trunk of my local tree.  I then tag it and
> > work from there - all local. That way, I have an exact copy of
> > the public tree I started from, as well as any changes I needed
> > to make for the project.  If/when it makes sense, I can then
> > also push my local changes back to the public tree.

> That's definitely the right way to do it.  I've just been
> reading up on CVS "vendor" tags" which appear to be designed
> for just such situations.

I would *not suggest* using the vendor branch feature of CVS directly on the main branch,
as you might end up with an inconsistent state (at least temporarily).

Here is what we are doing:

We checked out a local copy from the annon CVS. Then we imported
it to our CVS main branch with the "cvs import" command. After that we created a branch
and started our own developments on this branch.

We have a cron job running, which will update the local copy of the annon CVS weekly and
generate a diff report about the ChangeLog files. This report is checked by the developers
and if there is an interesting change, we import from the local copy of the annon CVS to our
main branch "cvs import vendor-tag release-tag". We do this at least once in two months,
to keep track of the ongoing development.

As a final step we incorporate the changes on the main branch (same as annon CVS) into
our development branch. This is now very simple. Use:
"cvs update -j last-release -j new-release". This command will update our development with
only those changes, which were made between the two releases. last-release and new-release
are the release tags which were defined with "cvs import".

Note, that it is important to work on an development branch, because the "cvs import"
command automatically merges and commits. If you work directly on the main
branch you are not really happy about this (I know it from experience).

BR
   Reinhard

-- 
 Ing. Reinhard Jessich                Phone: +43/1/81150/2395
 Software Design                      Fax: +43/1/81150/3169
 Frequentis Nachrichtentechnik GmbH   A-1120 Wien, Spittelbreitengasse 34
 http://www.frequentis.com            eMail: reinhard.jessich@frequentis.com


--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]