[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: managing patch files

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-08-03 00:00:08 CEST

On Aug 2, 2005, at 4:46 PM, John wrote:
> Do you think the repository is the best place for this? The text
> above implies
> intrinsically creating a branch (if I follow), so wouldn't it have
> to make
> assumptions about repos structure ('/branches' existing).
> My worry is that patches may be utter junk (!) and you don't want
> to keep an
> immutable copy of them, until approved (when they'd get committed).

You have some notion that because the repository never loses data,
only "perfect" data should ever be written to it. That's overly
paranoid. People create long-lived feature branches all the time,
committing "broken" code for review. Eventually the feature branch
is finished and deleted.

The main features of the repository is that it (1) remembers history
and (2) is a shared data resource; the history doesn't need to be
absolute perfection. If you become obsessed with making sure all
history is perfect, then you end up sacrificing feature #2 at times
when it would be really convenient! It's just not worth it.

What's important is that your team follow policies that guarantee
stability in the *right places*: tags should be stable, trunk should
compile and pass tests, etc. But it's totally over-the-top to insist
that every byte in history be immaculate.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 00:04:46 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.