I wrote:
>> People are likely to keep changes in their checkouts for a number of
>> days before checking them in. These changes need to be backed up.
On Wed, Nov 24, 2004 at 12:55:11PM -0800, Krebs, Steven wrote:
> In our process (windows world): work is done on a local drive that is not
> backed up. Developers are not allowed to commit work in progress that
> does not build with 0 errors and 0 warnings and pass Build Verification
> Tests. Developers use the TortoiseSVN "Create a Patch" feature to create
> patch file of all changes and store the patch file in their sandbox on a
> networked drive that is backed up nightly. The Idea is to not lose more
> than a day's work, and to only backup changes not the entire workspace
> and to not bloat the repository with lots of personal branches by using
> it as a temporary sandbox. Maybe you could do something similar?
We do something similar to that for Windows and MacOS development already
and it hasn't really been problematic. However, noone has ever suffered
from a failure beyond their control so it hasn't really been tested.
I suppose this is where systems like Bitkeeper and Arch have an advantage -
each user can have a private repository (which can be backed up) where they
can keep all their changes until they are ready to push them to the rest of
the team. I might encourage people to try SVK if we do move to Subversion.
We already have cleverness in the backup scripts that ensures that built
files are not backed up.
I shall put forward the idea of not backing up working directories - it
would certainly reduce the size of our backups greatly what with a full
checkout containing three complete Linux kernel trees!
--
Mike Crowe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 25 12:19:31 2004