[TxMt] Subversion and Merging?

[Chris Thomas]

On May 2, 2006, at 12:43 PM, Dan Weeks wrote:

> On 2006-05-02 12:40:29 -0400, Eric Coleman wrote:
>> Thanks for the information.... The reason is that:
>>
>> This is a commercial product.  We need to maintain the current
>> release while we finish work up on the next version.  The next one is
>> the biggest update we've done since launch, and well, just don't want
>> to get caught with our pants down.
>
> Isn't that what tags are for?  you then work on a tag and merge
> any changes you need upstream to the trunk.

That's what branches are for. A typical workflow for creating a major  
new version of a product might be:

1. tag the the last stable shipped sources from the trunk (svn cp  
$repo/trunk/ $repo/tags/1.0.1)
2. work on the unstable/development version commences on the trunk
3. maintenance work on the stable version can proceed on a branch  
from the old trunk snapshot (e.g. if you need to do bug fixes on  
stable version, create a branch: svn cp $repo/tags/1.0.1 $repo/ 
branches/1.0.x)

A variation on this is to perform the new development on a branch,  
and keep the trunk for maintenance on the stable version.

The question is how comprehensive the changes are; if there's really  
_no_ sharing and no history between the two versions, Eric probably  
wants to do what Sune said if he wants the new code to be the trunk:

> But really, why not do this:
> 1) Delete trunk.
> 2) Move in new files.
> 3) Commit.

It's the simplest option for the scenario where literally  
_everything_ is different, from the ground up. But it's not usually  
what you want to do, because it doesn't preserve the history of the  
files.

Chris