| 2009-11-26 10:47:41 |
Gareth White |
description |
The default behaviour of "commit" is to remove (unversion) files that have already been deleted locally, even if they weren't delete via the "remove" command. Is there a way to disable this behaviour? I'm thinking something similar to how "--strict" prevents committing with unknown files.
It just seems a bit dangerous for it to automatically assume a file that's not there at commit time was actually intended to be unversioned. A user or some script could inadvertently delete a file from disk and accidentally commit the change. Having an option to prevent the commit in this scenario could be useful.
(Then again, maybe I'm just too used to how ClearCase works. Provided everyone does "bzr status" before comitting it may not be too much of an issue.) |
The default behaviour of "commit" is to remove (unversion) files that have already been deleted locally, even if they weren't deleted via the "remove" command. Is there a way to disable this behaviour? I'm thinking something similar to how "--strict" prevents committing with unknown files.
It just seems a bit dangerous for it to automatically assume a file that's not there at commit time was actually intended to be unversioned. A user or some script could inadvertently delete a file from disk and accidentally commit the change. Having an option to prevent the commit in this scenario could be useful.
(Then again, provided everyone does "bzr status" before committing it may not be too much of an issue.) |
|
