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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
