Karl Fogel <kfogel@newton.ch.collab.net> writes:
> * If you're working in some area of code anyway, and you see
> inconsistent indentation in the context lines around that area,
> it's okay to fix them up too while you're there. Just point out
> in the log message that there were also formatting changes, so
> people know to ignore them when scanning the change. In fact,
> this kind of gradual, as-you-go reindentation is one of the best
> ways to get a badly indented but active code base into shape,
> while still avoiding a painful "flag day" on which everything
> gets reindented at once. (Not that we have that problem, but CVS
> does, and this is how they're solving it).
Oh, I forgot mention an important reason to avoid sweeping
reformattings. People may have outstanding patches (at home, attached
to an issue, posted to a website, whatever), and big reformats make
those patches suddenly inapplicable, or at any rate much harder to
apply.
And the reason that gradual, as-you-go reformatting is good is that it
means you're doing the reformatting in an area of code that's changing
*anyway*, so you're not likely to be making a patch inapplicable
unless it was going to be made inapplicable anyway (by the semantic
changes).
I think it would be good to explain this. People often think of
working copies and the repository, but forget to think about other
places where changes might be stored.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 8 19:04:01 2002