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.
Hello, we are in the process of developing a strategy for restoring repositories in case of accidents. We came across the following (disturbing) case: UserA has worked on a file the whole morning creating new revisions 1.42 and 1.43. The nightly backup of the repository only contained rev 1.41 in the HEAD. Because of a hardware failuer we then are forced to restore the repository (containing 1.41 as HEAD). UserA then cannot commit his/her local modifications to the BASE 1.43 (thus trying to create 1.44) because 1.43 doesnt exist. CVS gives back the warning "could not find desired version 1.43". So fine so good. Lets assume that after the crash UserB started working on the same file and thus created two revisions 1.42 and 1.43. UserA went home after the hardware crash and thus doesnt know anything about UserB also midfying the file. The next morning UserA is able to commit his locally modified file without a problem where UserB's modifications are totally eradicated: no merge/conflict detection seems takes place. My questions: 1. What good are the date/time stamp in the file CVS\Entries. It seemd that only the BASE revision number was used to check the repository, but not the timestamp. 2. How do the experts handle a repository restoration? There might be 'hundreds' of sandboxes on various machines and the potential of overwriting somebody elses changes (not having a merge) can be a big problem. The overwriter can only be aware of such a problem if he does a diff after the commit (but why should he?) Thanks alot. Friedrich Niederreiter PS: Client (Win2000Prof) & Server (Win2000Prof) running 2.0.41 with Tortoise 1.6.5 over SSH __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/