info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS Merge, No Conflict


From: Stuart Cooper
Subject: Re: CVS Merge, No Conflict
Date: Fri, 2 Sep 2005 12:46:21 +1000

> Some more queries on your answers:
> 1. How does creation of non-branch tags help. Isn't it same as merging
> upon a version. Basically what I want to know is how is this different
> from what we currently do say:
> - cvs upd -j cr_abc

non branch tags before branches and before and after merges are winners;
just take my word for it. they allow you to do extra, later merges 
with the two -j flags as described in my first reply. just get in the habit
of doing them, it'll save you sooner or later.
 
> 2. Our project requirements are such that multiple developers work in
> parallel and to ensure no interference I need to provide multiple
> branches. Another complexity of the project is that there are frequent
> releases due to which by the time a development started on say 1.87 will
> finish the trunk would already be at say 1.90. So for testing purposes
> we first create another branch based on last baseline (1.90 in this
> case), merge changes of development branch on this branch (which I refer
> to as string) and test the changes in isolation. After that everything
> is integrated and merged on trunk. The idea behind doing so is that the
> trunk is not touched till the individual changes are thoroughly tested.
> Due to this we end up having 2 branches for each development work.
 
I worked somewhere once where everyone took a branch for each bugfix
they were working on and all these branchs (10 or more) were merged into
the trunk at release time. It was very strange to me, but seemed to work.
A more typical approach is for people to work mostly from the trunk, and
for developers to frequently update from the trunk. That way problems
are found earlier. In this model, branches are used for hot fixes to
the production
release (which is tagged) and the HEAD of the trunk is always latest
and greatest
unstable development release.

Your approach is more along the lines of the first scenario, albeit
not so extreme.
You'll need to find the right commands to suit your development practices.

Good luck,
Stuart.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]