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

Re: rapidsvn feedback

From: Martin Pool <mbp_at_toey.home>
Date: 2002-08-04 06:03:53 CEST

On 30 Jul 2002, Karl Fogel <kfogel@newton.ch.collab.net> wrote:
> Josef Wolf <jw@raven.inka.de> writes:
> > loose the benefits of svn if you start "bad Practices". Just for an
> > example: run all the svn-code through indent(1) and commit the
> > results. While this is neither a failure in svn nor in indent, this
> > will lead you into hell when you have to merge across the revision at
> > which you ran indent. You can still get benefits from svn, but you
> > are calling for hell on the long run if you really do such a thing.
> This particular piece of advice I'm +1 on putting in the handbook.
> It's a "common unintended technical consequence" of a revision control
> system, and since people may not think of it, it's appropriate to warn
> them.

If you must reindent code (and sometimes you must), then

 - make no other changes in that revision

 - put the indent comand line in the log message

That makes it possible (although a bit of a hassle) to merge code from
a branch that has not been indented: you make a copy, indent it the
same way, and then merge. There will be relatively few 'noise'

I only realized this pattern a year ago or so, and I find it works
quite well. I think it could usefully be in there, in addition to the
rule about gratuituous reindenting.

For what it's worth I think it would be good to mention "good
practices" in the documentation somewhere, with appropriate context.
I don't think you need to prescribe a commit policy, but you can
usefully say "many projects find it useful to agree on a commit
policy, such as requiring the project to pass 'make check' before
commit (etc)." The current CVS manual at least touches on this.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 4 06:05:29 2002

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

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