I don't think that the best answer is to implement a delete function in
a repository. A better answer is to have a decent workflow system so
that changes can get reviewed before they get committed.
There are probably multiple good ways to implement this. One that I have
in mind is to have three repositories. The first is for rough drafts:
developers should check their code into it frequently whether the code
works or not. Developers promote code from the first to the second when
they think their code is ready for review. A team lead promotes the code
from the second to the third "production" repository only after it has
gone through review and all unit tests.
All of this has to be enabled by a decent user interface that will let
you see what needs to be reviewed, and will let you promote code simply.
I spent quite a bit of time with other open-source version control
systems before picking Subversion. One in particular, Mercurial, seemed
much superior to Subversion, but lacked a decent UI or Eclipse plugin.
From an architectural standpoint, though, it was a much better fit for
what I've described above.
> 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.
I've heard this frequently, but it's unrealistic. This simply does not
work in the real world. People make mistakes, huge ones, inevitably.
Even me. In a professional software organization you must put in
controls and enforce reviews if you want to have a quality product.
...
> and some systems integrate code reviews into the process to that no
> un-reviewed code will ever slip into the repository.
...
> I suggest setting up a code review process. There are some products out
> there that can help you with that.
Any pointers to such products would be well-appreciated. I'm definitely
willing to pay for a commercial product if it would solve this problem.
Lasse Vågsæther Karlsen wrote:
> 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
> <mailto: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 <mailto:blair_at_orcaware.com>>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> <mailto:users-unsubscribe_at_subversion.tigris.org>
> For additional commands, e-mail: users-help_at_subversion.tigris.org
> <mailto:users-help_at_subversion.tigris.org>
>
>
>
>
> --
> Lasse Vågsæther Karlsen
> mailto:lasse_at_vkarlsen.no <mailto:lasse_at_vkarlsen.no>
> http://presentationmode.blogspot.com/
> PGP KeyID: 0xBCDEA2E3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-15 22:20:54 CET