lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DM Smith <>
Subject Re: svn commit: r410680 - in /lucene/java/branches/lucene_2_0: CHANGES.txt src/jsp/results.jsp
Date Thu, 01 Jun 2006 22:07:14 GMT
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
> -- 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message