[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Branch merging to main trunk
From: |
Tyler |
Subject: |
Re: Branch merging to main trunk |
Date: |
Thu, 1 Jul 2004 09:58:01 -0700 |
User-agent: |
Mutt/1.4.2.1i |
On Thu, Jul 01, 2004 at 08:35:54AM -0700, Christophe Delarue wrote:
> Once a branch is created, bug are corrected on the branch and then
> merged into the main trunk.
>
> How do you deal with those merges :
>
> 1) On each release of the branch, done by the leader of the branch as
> describe in http://www.magic-cauldron.com/
>
> using cvs update -j last_release -j new_release on a main trunk
> sandbox
It seems this is the best bet.
> 2) Each week/3 days, the modifications are merge back into the main
> trunk by using the update -r new_release on a main trunk sandbox
This won't work; instead it will update your trunk sandbox to be a
branch sandbox.
> 3) each time a developper corrects a bug, (s)he has to merge it into
> the main trunk.
> To ensure the bug migration, a check could occur by verifying the log
> on commit : on bug correction the bug id has to be in the comment.
> When the bug is merged, the following commit follow the same
> convention. Therefore we can track in the log the bug migration.
I tried this policy for a while, but unless you have a tiny team of very
disciplined developers, someone will forget, or bungle a merge, and
changes will get missed. Having validation would help, but i still think
this is impossible in practice.
> 4) a rdiff is done between the last bug migration on the branch :
> cvs rdiff -r last_release -r new_release myproj
> this diff is collected, each is validated, and through a sh script the
> migration is done file by file through a
> cvs update -j <cvs-last-release-id> -j <cvs-new-release-id>
> foo/bar/file.x
This is the same as #1, but with a lot more overhead.
tyler