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.
Tom, > Sometimes you will submit something which you don't want to > submit to the > repository by mistake, exp: password of online bank(just an > example here to > show the bad result), my questions is: Is there any way to > rollback this > wrong submit? > The point of SCM is to track the changes you make to file(s). Your example is a good one of showing when it is really really important NOT to delete that change. After a password has been published to unauthorised users, the password should of course be changed. Let us assume in this example that you are not using any access control on the versions and therefore the password stored in the SCM tool is considered to have compromised the security. The solution to the security breach is to change the password. Several days later someone tries to break into your online bank using the published password. This is repeated over several weeks/months/years. At some point in the future someone asks "why do people keep on trying to break into our security using this password"? If the SCM revision was deleted then there is no way to track what happened in the past to lead to the present day situation. And in a nutshell that is what CVSNT is supposed to help you do: track what happened in the past to lead to the present day situation - whether that be code, passwords, documents whatever. Whether those changes be good bad or ugly. They happened and the fact that they happened may be inportant for other people to know in the future. Ie: just because WWII was bad doesn't mean we erase it from the history books. There is a "cvs admin" command that will let an administrator destroy your SCM integrity by removing a revision, however it has not been tested in years and there are various reports that it can harm the repository. This option should never be used except by an experienced administrator who is aware of the technical and the process / security implications of using it. Regards, Arthur Barrett