Re: How to reject svn changes?

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 <lesmikesell_at_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_at_gmail.com
> >
> >
> > ---------------------------------------------------------------------
> > 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