Re: [PATCH] Best Practices

Karl Fogel wrote:
> 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.

Okay, I'll mention that reason.

I have to wonder if there's a fairly easy way to reduce this problem,
similar to how my branch example works.

Hmm, let's say there's an argument to "svn up" or "svn switch" called
"--no-merge". It updates the working copy base files only. Useful for
explicitly saying "I've already merged this".

Then let's say I've checked out revision 62. At revision 65, someone
reindented. I've made changes to my working copy and want to commit them
without conflict. I could this with:

     $ svn up -r 64
     $ svn up -r 65 --no-merge
     $ indent -gnu src/*.[ch]
     $ svn up

And there'd be no conflict. Still an inconvenience, but I think less so
if you've made a lot of changes.

-- 
Scott Lamb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org