While I sympathize with the problem I do believe that the problem is not
something that a source control system should do much to solve.
There are systems, however, that has features like running automated
integration and unit tests before the changes are commited to the trunk, and
some systems integrate code reviews into the process to that no un-reviewed
code will ever slip into the repository.
However, at some you're going to have to trust your developers, and if you
can't do that, I'm sorry to say this, but there isn't much a source control
system will do to help that problem.
If your group need more control over what changes gets into the system, I
suggest setting up a code review process. There are some products out there
that can help you with that.
This will of course add more bureaucracy to the commit process but then you
would have more control.
Now, as for obliterating a commit altogether, you can do that, as noted with
the link in a previous answer, a dump/load cycle will do that for you but
will probably be a great deal of pain to execute. Or if you simply want to
get the files back to a pre-commit state so that they can be worked on
without the changes, you can do what the other poster said about using
merging.
One of your developers made a concious (I hope) decision to commit changes
to the repository and for better or for worse, that is part of the
repositories history, and this should be hard to get rid of, otherwise the
word "history" wouldn't have much of a meaning.
As a former SourceSafe users, where both the words "safe" and "history" are
rather loose, believe me when I say that the harder it is to actually get
rid of historic data, the better it is.
If you have specific things you want to forbid committing, like particular
file types, or connection strings or easily recognized passwords, then you
can probably add a hook script to reject changes with particular patterns in
them.
On Sat, Mar 15, 2008 at 8:02 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> Chris wrote:
> > Every once in a while (more often than I care to admin) one of our
> > developers does something really boneheaded. They check in changes that
> > shouldn't be there.
> >
> > I'm finding it an enormous pain to back out the changes, particularly if
> > then extend across multiple files.
>
> That's really easy to back out. If revision N is the bad commit, then you
> can use
>
> svn up
> svn merge -cN . .
> svn commit -m 'revert rN'
>
> If you want to keep in some changes, then you can either do the merge for
> the
> few files you want, or if more files need to be kept, then you can svn
> revert
> the few that shouldn't be reverted.
>
> Regards,
> Blair
>
> --
> Blair Zajac, Ph.D.
> CTO, OrcaWare Technologies
> <blair_at_orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
--
Lasse Vågsæther Karlsen
mailto:lasse_at_vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
Received on 2008-03-15 20:35:47 CET