Merging and branching (Was Re: Fourier elimination)

Robert Dodier wrote:
> On 12/7/07, Jaime Villate <villate at fe.up.pt> wrote:
> 
>> 1- After the creation of the release branch is announced, I make a fresh
>> new copy of the CVS repository, with the release branch:
>>   cvs -d :ext:villate at maxima.cvs.sourceforge.net:/cvsroot/maxima co -r
>> "RELEASE-5_14_0-BRANCH" maxima
>>
>> 2- I continue making changes and committing them in the old repository
>> (with the CVS head branch). If a change should also be in the release
>> branch and I think it is safe to put it there, I will copy the file to
>> the copy of the release branch and commit it there too.
> 
> Hmm, this seems more complicated than it needs to be.
> cvs update -r whatever-tag-or-branch -dP
> changes the sandbox files to the tagged version.
> cvs update -dAP
> makes cvs forget the tag and go back to the trunk.
> Those commands can be applied to a single directory or file.
> So it's really not necessary to maintain two separate sandboxes;
> it should be enough to use cvs update to switch between the
> branch and the trunk. But if someone is more happier with
> two sandboxes, then I certainly won't stop them.

That way lies madness.  At least for me. :-)

The nice thing about separate sandboxes is that you never accidentally 
commit something to the wrong branch or have a merge conflict when 
switching back and forth.

And I think for the release branch, we should be extra careful.  It is a 
release, after all.

Also, concerning merging changes between branches, it's nice to do an 
actual merge (using cvs -j option).   This is quite nice in clearcase 
where you can see in the version tree an arrow showing that you merged 
from this version to that version, so you know how the change came about.

I don't think cvs has that ability though.  It's nice to know, though, 
that it's a merge rather than a new or coincidentally the same change. 
I guess all we have are the checkin comments to state that.

Ray