Just my opinion based on working with SVN with an entirely different
development model:
Trunk is production and branches are different people individual or
collaborative efforts, with one branch for maintenance changes. When
enough maintenance changes are ready for a release, we merge it into
trunk, cut a tag and release the tag. Merging from trunk into
development branches occurs prior to releasing the development
branch. When it happens is at a time that is agreeable to the
developers for the branch. Most developers merge trunk into their
branch shortly after a release. In this model, all merges are in and
out of trunk and apart from merges, trunk never changes. One short
coming of this model is that the changes within a branch are not
readily visible via svn info.
Given the nature of this project, I am not recommending this model.
There are simply to few releases and the interval between them is too
long. The other nature of this project is that "developer branches"
are peoples personal work area and they check in via patches.
What I wanted to comment on was how merging behaves. I found merging
works very well provided that a change is not applied to two
different copies that are to be merged (e.g. a branch and trunk) In
this case, it will almost always produce a conflict. When using merge
to apply the changes to a copy and then merging it into trunk works
very well. When it does merge without a conflict it does it silently.
Since the merge is purely textual, it cannot determine whether the
merge preserves the semantic meaning of the code. If care is taken to
only change what is necessary, this generally works as expected. If
the code is significantly refactored and then receives a merge, it
will require careful review.
So if trunk (2.1 development) is going to diverge significantly from
the branch (2.0 maintenance), sooner or later a change won't make
sense to merge. At that point it won't make sense to merge ever
again. It may also be that a patch only applies to 2.0 and not 2.1.
So I guess, I recommend not using merge ever.
If a file has changed between the 2.1 copy and the 2.0 copy, then the
patch will probably only work on the one from which it was made. If
the changes are not too great then using a merge tool (such as the
one that comes with TortoiseSVN) after the patch is applied to the
one is easiest.
-- DM
On Jun 1, 2006, at 4:34 PM, Daniel Naber wrote:
On Donnerstag 01 Juni 2006 01:12, Otis Gospodnetic wrote:
I saw this commit on trunk. Did you simply make the same change
in both
branches/lucene_2_0 and in trunk?
Yes, I copied the changes manually. I would have thought that the
person
who commits can also best decide whether something should be
backported.
When someone later merges a a large amount of patches he would need to
rely on the changelog entry or study the patch, or am I missing
something?
Regards
Daniel
--
http://www.danielnaber.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
