[cvsnt] Branching and Merging advice needed (parallel development)

Czarnowski, Aric aczarnowski at unimax.com
Wed Dec 3 15:40:33 GMT 2003


Keeron Modi wrote:
<<<<<
1.	A dev creates a  branch off the "MAIN" trunk called "Branch_A"
2.	A second dev creates a branch off the main trunk called
"Branch_B" - same point as what DEV 1 did
3.	Both devlopers continue work on their branches . and at some
point, Dev1 is done with his changes .. and decides to merge onto MAIN
4.	Bcoz we follow "heavy" tagging .. the dev tag his "final"
revision on "Branch_A" as "Merge_from_Branch_A"
5.	Checks out the "HEAD" of MAIN branch
6.	Tags this revision immideatly with the tag "Pre-Merge_Branch_A"
so that he knows what he is merging ... 
7.	Does a CVS update -j "Merge_from_Branch_A"
8.	During the update, he got conflicts . so he is busy resolving
these conflicts .. 
9.	BUT ->>> (this is the fun part) Developer 2 in the mean time
does
his merges on the HEAD trunk and now suddenly the HEAD is not what it
used to be. Its changed. But developer 1 has an old head now.
10.	Dev1 resolves the conflicts and merges his changes after a day.

11.	Tags is "Merge_to_Branch_A"     (If anyone using
viewcvs/cvsgraph - this will help us draw pretty merge  lines between
the source and destination revision)
12.	From above,  the MAIN branch is Broken ! .. since what the
"dev2" checked in is not in the last revision of MAIN . because
developer1 merged his changes and that became the tip/head.
>>>>>

I could be wrong but I don't think the problems you are describing are
practically going to happen.  When developer 2 tries to commit after
merging to the HEAD they will, I think, get an error that they are not
up to date and the commit will be aborted.  This is assuming files are
shared between developer 2 and developer 1 who beat them in for changes.

But I wouldn't do things this way anyway - too many branches and tags.
Why not allow the HEAD to be the development branch for everybody on the
project and branch off stable code at release time for maintenance work?

Before any commit it is standard practice to update and if there are
changes brought in recompile and retest.  This way developer 2 will get
developer 1's changes and be able to resolve conflicts before they
commits their mods.

If a person needs to back up they could update to a specific date and
time they knew was good.  CVS can tell you what changed between date1
and date2 or you can use scripts (some publicly available) to tell you
and/or create change logs.

If you run nightly builds, which I think every serious software project
should, you could tag at each build and use those as update points in
case problems occur.  We build nightly but do not tag nightly FWIW.

This really gets into software engineering process which is different
for everybody and probably why I didn't see a lot of responses.  I
personally think the heavy tagging you have outlined above will be more
error prone and confusing than simply letting the HEAD for a project be
the place for development.

1. cvs checkout  ** gets you the HEAD by default
2. mod
3. compile/test
4. cvs update
5. resolve conflicts if any
6. recompile/retest if merges were brought in
7. cvs commit
8. check next morning's build log to confirm mods passed the build

Have you seen http://cvsbook.red-bean.com/?  That's a good introduction
into using CVS and touches on the software management issues and best
practices you are running up against.

> * Another one (similar to the 'email' suggestion) is anyone
> merging changes (a final commit on the branch) should email 
> everyone in the group that the "Tip/Head" is changed .. so 
> they can update their sandboxes . hence they will always
> merge their changes with the latest head revision. 

You can do this easily with CVS's loginfo support and some simple
scripting.  Many, many CVS installations automatically send emails on
commits.


--Aric

Aric Czarnowski
Unimax Systems Corporation
612-204-3634



More information about the cvsnt mailing list