You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chris <sh...@yahoo.com> on 2008/03/15 18:43:21 UTC
How to reject svn changes?
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.
How can I do a rejection of changes in a particular checkin? Sometimes I
want to reject changes to a particular file, and sometimes I want to
reject everything in a particular revision. I really want the garbage
out of the repository permanently.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Blair Zajac <bl...@orcaware.com>.
Marc,
Thanks for the correction.
Regards,
Blair
marc gonzalez-carnicer wrote:
> blair, you probably forgot a '-' sign :
>
> svn merge -c -N . .
>
> anyway, that was (to me) one of the most interesting posts
> to the list lately. thanks :)
>
>
> 2008/3/15, Blair Zajac <bl...@orcaware.com>:
>> 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
>> <bl...@orcaware.com>
>> Subversion training, consulting and support
>> http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by marc gonzalez-carnicer <ca...@gmail.com>.
blair, you probably forgot a '-' sign :
svn merge -c -N . .
anyway, that was (to me) one of the most interesting posts
to the list lately. thanks :)
2008/3/15, Blair Zajac <bl...@orcaware.com>:
> 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
> <bl...@orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Talden <ta...@gmail.com>.
> Let me just make the point that I was not arguing for removal of
> obliteration functions, I just don't believe they should be a common
> function easily accessible.
Somewhat offtopic...
I don't believe ANY function should deliberately be made 'hard to
access'. If you don't want it easy in your system - don't give anyone
else access to it, it should be an admin-only feature.
Restricted access, certainly.
Explained and advised against in recommended practices, sure.
But please don't advocate using obfuscated or arduous UI as a good thing.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Lasse Vågsæther Karlsen <la...@vkarlsen.no>.
Gah, why is gmail jumping from replying to person and the mailing list on
every other post I make...
Sorry les, this was intended for the group, not you personally.
---
Let me just make the point that I was not arguing for removal of
obliteration functions, I just don't believe they should be a common
function easily accessible.
I've seen too much problems resulting in a source control tool that made it
easy to remove files altogether, and then trying to tie together older
revisions of projects that I personally feel that the Subversion has done
the right thing, made it painful to do, but not impossible.
Personally I feel that there should be other mechanisms in place to handle
the problems being described.
As I see it, there are two problems:
1. mistakes, in the form of uncompilable code, bugs, etc. are committed to
the repository, causing problems for developers updating their working copy
afterwards
2. insecurity, in the form of committing things you really *really* don't
want in a historical repository. Things like lists of passwords, etc. that
someone with read access to your repository really shouldn't have access to
In the first case, this is easily fixable by reverting the revision. Yes,
it'll leave the buggy revision in the repository, but that shouldn't cause
too much problems.
In the second case, this can be handled by the dump/reload cycle. It's
painful, yes, but hopefully your developers will learn not to do that after
their first encounter with this.
If, on the other hand, an obliteration function was easily used, it would be
used, often. Often enough that some day you'd like to get to an old version
of something only to find out that it's no longer there because of space
concerns on the disk, or someone obliterated the wrong version, etc. As you
said, mistakes do happen, and there's no guarantee someone won't make a
mistake when obliterating something either. At least with a historical
system you can find all the historical data, faults and all.
I still stand by my original point. As long as things are fixable,
pretending they didn't happen isn't the way to go.
On Sat, Mar 15, 2008 at 11:10 PM, Les Mikesell <le...@gmail.com>
> wrote:
>
> > Chris wrote:
> > > 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.
> >
> > I think that there are reasons to delete things from a repository, but
> > coding mistakes or differences in design decisions aren't among them.
> >
> > > 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.
> >
> > Why can't you do this with branches? If you have multiple competing
> > designs in phase one, start them on separate branches, for phase 2, move
> > one to the trunk for more development, then start cutting release-track
> > branches when something is close to a release and you want to freeze its
> > features.
> >
> > > 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.
> >
> > Can't you do that now, merging between branches?
> >
> > > 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.
> >
> > Did you look at svk or similar systems that let you mirror an svn
> > project, work with a local branch, then eventually commit the changes
> > back? There may a similar operation with mercurial. Personally I think
> > it is better to keep everything visible to all developers so they can
> > take advantage of each other's work concurrently instead of being
> > surprised by large changes, though.
> >
> > > > 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.
> >
> > You need the ability to manage revisions, but only rarely do you need to
> > pretend they never happened. Your 'quality product' is most likely
> > going to be built from the head of a release branch or a tag copy of it.
> > It won't matter at all if there are mistakes in the trunk or even that
> > branch if they were reverted or subsequently replaced with better
> > versions.
> >
> > --
> > Les Mikesell
> > lesmikesell@gmail.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
Re: How to reject svn changes?
Posted by Les Mikesell <le...@gmail.com>.
Chris wrote:
> 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.
I think that there are reasons to delete things from a repository, but
coding mistakes or differences in design decisions aren't among them.
> 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.
Why can't you do this with branches? If you have multiple competing
designs in phase one, start them on separate branches, for phase 2, move
one to the trunk for more development, then start cutting release-track
branches when something is close to a release and you want to freeze its
features.
> 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.
Can't you do that now, merging between branches?
> 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.
Did you look at svk or similar systems that let you mirror an svn
project, work with a local branch, then eventually commit the changes
back? There may a similar operation with mercurial. Personally I think
it is better to keep everything visible to all developers so they can
take advantage of each other's work concurrently instead of being
surprised by large changes, though.
> > 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.
You need the ability to manage revisions, but only rarely do you need to
pretend they never happened. Your 'quality product' is most likely
going to be built from the head of a release branch or a tag copy of it.
It won't matter at all if there are mistakes in the trunk or even that
branch if they were reverted or subsequently replaced with better versions.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Erik Huelsmann <eh...@gmail.com>.
On Sat, Mar 15, 2008 at 10:20 PM, Chris <sh...@yahoo.com> wrote:
> 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.
How is this different than having (in 1 repository):
/employees
/reviewed
/production
?
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Tom Widmer <to...@camcog.com>.
Chris wrote:
> > 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.
TeamCity has a delayed commit feature for their build server which could
be useful. Does Hudson have this?
Crucible is a code reviewing tool; SmartBear Software have a couple of
code review tools too.
Other VCS tools have better support for not letting changes hit 'trunk'
until they have been checked. AccuRev is a good example of a commercial
tool, and the DVCSes like Mercurial and Bazaar have some features for
this too.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Re: How to reject svn changes?
Posted by "Gleason, Todd" <tg...@impac.com>.
This thread went on for awhile but I didn't see any suggestions for code
review-related products. Here are two:
Free: CodeStriker (http://codestriker.sourceforge.net/)
Commercial: Crucible (http://www.atlassian.com/software/crucible/)
Re: How to reject svn changes?
Posted by Chris <sh...@yahoo.com>.
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@orcaware.com
> <ma...@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@orcaware.com <ma...@orcaware.com>>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> <ma...@subversion.tigris.org>
> For additional commands, e-mail: users-help@subversion.tigris.org
> <ma...@subversion.tigris.org>
>
>
>
>
> --
> Lasse Vågsæther Karlsen
> mailto:lasse@vkarlsen.no <ma...@vkarlsen.no>
> http://presentationmode.blogspot.com/
> PGP KeyID: 0xBCDEA2E3
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Talden <ta...@gmail.com>.
On Sun, Mar 16, 2008 at 8:35 AM, Lasse Vågsæther Karlsen
<la...@vkarlsen.no> 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.
I am a proponent of getting something done improving the obliterate
feature urgently - however I really do have to concur here that this
isn't a great use of obliterate.
Backing out the changes with a reverse merge is easy and, in terms of
UI simplicity, unlikely to be improved in obliterate.
The cost to the system in terms of space is trivial (only the size of
the change, ignoring skip-deltas). It would seem that, at best, a
case could be made for avoiding a noisy revision history but even then
I'm hard pushed to see this as a good use.
Trying to use obliterate in this fashion outright demands that either
all users re-check out or that the system do a considerable amount of
complex but low-value work to communicate how history has changed to
clients that need to be informed (such as mirrors or clients with
working copies at the removed revision).
> 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.
Developers make mistakes, sure, that's expected - it happens - seeing
that it's happened in revision history isn't going to hurt anyone.
Obliterate needs to deal with these specific cases when there is no
way to continue with the repo in its current state - surely this isn't
one of those cases when a reverse merge gets you to where you need to
be with minimal cost.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Lasse Vågsæther Karlsen <la...@vkarlsen.no>.
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 <bl...@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
> <bl...@orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
Re: How to reject svn changes?
Posted by Blair Zajac <bl...@orcaware.com>.
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
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How to reject svn changes?
Posted by Karl Fogel <kf...@red-bean.com>.
Chris <sh...@yahoo.com> writes:
> 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.
>
> How can I do a rejection of changes in a particular checkin? Sometimes
> I want to reject changes to a particular file, and sometimes I want to
> reject everything in a particular revision. I really want the garbage
> out of the repository permanently.
You've asked a very common question, and there's not (yet) a good answer
for it, but see this issue for workarounds and for discussion of future
(post-1.5 release) improvement:
http://subversion.tigris.org/issues/show_bug.cgi?id=516
Best,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org