Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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)