[cvsnt] Re: Branch merging - this seems wrong...

[Bo Berglund]

On Tue, 06 Jun 2006 17:44:13 +0100, Tony Hoyle
<tony.hoyle at march-hare.com> wrote:

>Tony Eva wrote:
>  > 'Development' = a branch used essentially as a place for a
>> developer to save their working copy while they are in the
>> process of writing and testing their code.  The code
>
>That's called a sandbox.

Not really...
We do not rely on our developer's PC being functional the next day so
every evening work in progress *must* be committed so it will be:
1) Saved also on the CVSNT server disk
2) Included in the nightly backup that will not touch the workstations
because they are not on or they are removed from the network (laptops)

I have personally had the following disasters in recent years:
- Burglary that snatched *all* of the PC:s on my department (13 of
them) in less than 5 minutes in the middle of the night.
- A developer's laptop being broken by dropping on the floor
- A developer not returning to work because of serious illness

In all of these cases CVSNT has helped us getting back into operation
in a short time without data loss.

Could not have been done if code was left in the sandbox for long
periods of time. If this were the case then we would have to revisit
the long discussed "sandbox on network share" topic for security and
backup purposes....

>
>> committed to a development branch is work in progress:
>> highly unstable and subject to change.  Development branches
>> are short-term and related to a single feature or bug.
>
>There should be *a* development branch.
>
>Producing a branch per bug reduces communication and is extremely wasteful.
>
>It's important that developers always know the current state of the module 
>they're working on.  Multiple development branches make this impractical.
>
>At the bug level it'll affect two or three files but those files aren't 
>independent of the whole - they should be tested and developed within that not 
>separate from it.

Which is why you need to get the other developer's effort merged into
*your* development branch and basically setting a new branch point.
I see this as if the feature development was started at a later time
from the point where the new merge was done. Thus it will now be based
on this later branch point and therefore the final merge back will be
simplified a lot.


HTH

/Bo
(Bo Berglund, developer in Sweden)