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.
Mitch, You bring up another good thing to ponder. What is the point of no return for a developer? i.e. Should they check their code back in at the end of the day so that it can be recovered? Theoretically they could check out the code in May and keep it local and work until July if they wanted to .... but to expect a recoverable situation with a check out duration that spans the backup cycle I think is ludicrous (Space Balls Rules). What kind of practical limits do you have for coordinating backups and recovery with developers? -- **************************************** Name: David Williamson Company: Integrated Visual Systems, Inc. **************************************** Mitch Davis wrote: > > > We are debating the best approach to setting up our > > repository. Should we setup a repository for each customer > > that we have and put each of their projects in a separate > > module or should we have one large software repository that > > has a module for each customer? > > > > The administrators thought was to create a repository for > > each customer and place their projects within it. Reason: > > One factor to consider is the scripts in the $CVSROOT/CVSROOT > directory that control operations such as checking in and out. > If you have multiple repositories, you can have a separate set > of scripts for each project, so you can use this to have > distinct policies for each project. > > > If something happened to a repository then our down time > > would be limited to one customer and backup recovery would be > > easier by replacing the entire repository from last night's backup. > > Be a bit careful here. Whether it's because of hardware or > user error, rolling back can have consequences. If for example > I have revision 1.9 of a file and you roll back to 1.8, then > someone adds a 1.9, CVS won't properly handle this, because it > has no good way of knowing that my 1.9 isn't the same as your > 1.9. > > Hope this helps. > > Mitch. > > PS: I agree with everything Glen Starrett said. > > ---------------------------------------------------------------------------- > ------------------------ > The information contained in this message and any attachments is > confidential and intended for the named recipient(s). If you have received > this message in error, please contact sender by return e-mail and > destroy the message and any attachments. > Any opinions or undertakings expressed in this message are those of the > individual sender except where the sender expressly and with authority > states them to be the opinions of Extel. > ---------------------------------------------------------------------------- > ------------------------