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'
conflicts.
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.
--
Martin
---------------------------------------------------------------------
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