httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: indent
Date Thu, 10 Oct 1996 10:43:20 GMT
"Roy T. Fielding" <fielding@liege.ICS.UCI.EDU> writes:

> It can't be right after 1.2 -- that would make it impossible to get patches
> from users with 1.2 and apply them to the current tree.  It has to be done
> when people are not working with the pre-indent'd source, which means

I think the 2.0 tree is going to become radically different very
quickly which is why I think it's a good time to do this. There's the
new threaded code, the NT port, the work to abstract the OS dependant
code etc. I think it'll become a very different beast. Whitespace
changes as a precursor to that won't add that much more confusion :-)
It's a major number bump, don't expect it to be easy to migrate bug
fixes from 1.2 into 2.0 in any case.

> I agree that we can't rush into these things; I said I was going to do this
> over two months ago.  The reason I've been waiting until now is because it
> can't be done while people are working on the code being reformatted.
> Furthermore, it can't be done all at once because it is not an automated
> process -- first you run indent, and then you go through the source
> line-by-line and investigate errors (many preexisting bugs get illuminated
> this way) and reformat things that are better formatted by context rather than
> by simple rules.

Umm, this isn't a good way to do this. It needs to be done as a single
mega-commit with a pre and post tag applied so it's easy to get back
to pre-formatted sources so applying bug fixes to the older code is
reasonably easy. i.e. you checkout the pre-clean code, apply the
patch, then roll the patch forward into the current code using a
merge. cvs shouldn't have too much trouble with this (patch isn't
phased by whitespace, it's diff that's the problem).

If you do the indent job piecemeal you'll have a mess on your hands.

> When all the unreserved files are cleaned, we will start work on the
> reserved ones.  A CVS branch would be made for each external subproject
> and all reserved code changes would be committed to those branches, after
> which the cleaner will go in and reformat *both* the 1.2 source and
> the external subproject source.  Finally, the external project branches

This is really nasty in my opinion. I don't like lots of branching.

> will be consolidated into a single 2.0 branch, into the 1.2 head, or deleted.
> The end result will be a single common code base from 1.2 to 2.0, on
> two branches, such that bug fixes on one can be applied to both.

As I said, I doubt very much that pre 2.0 patches will be able to
seamlessly apply to the 2.0 codebase so worrying about the whitespace
issues isn't worth it and as I explained, cvs should be able to cope
with merging pre 2.0 fixes into 2.0 if we can apply them cleanly to
the 1.2 branch even if 2.0 has been cleaned (except where there is a
radical restructuring of the code).

My plan of action would be as I said before:

1) Tag, branch and release 1.2
2) Everyone with outstanding work-in-progress gets it into cvs
3) Code freeze on 2.0 branch.
4) Apply indent to all files
5) Tag the indented files "as-is" even if indent screwed up.
6) Unfreeze code.
7) Tweak badly indented file and continue development.

This is the only way to get it all done on one commit (easy to revert
this process then if it goes badly wrong) and to also get all the
private code bases updated in sync. It doesn't matter so much if
things become badly broken just after 2.0 because of uncompleted work
getting committed since we're right at the beginning of a new major
development cycle and we can put up with things being in disarray for
a few weeks at that stage.

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message