Howto continue development after the astyle update (was Re: nt branch KILLED)

lör 2003-02-22 klockan 17.36 skrev Guido Serassio:

> I know this, but keep in mind that many branches are based on functionality
> additions, with many NEW code sections, and the merging is simpler
> The nt branch is based on many and many existent code CHANGES to address
> the Windows/Unix differences, and it's very complex to maintain.

In my opinion the bulk of the nt branch should have been merged long
ago, after suitable cleanups.

To merge large branches is not a painless effort. It requires

  a) The branch to be split into manageable pieces which can be
explained.

  b) A review process by one of the core developers to make sure the
patch to be merged looks correct given the explanation to the changes.

  c) If the review process finds obvious errors, these needs to be
corrected for the process to continue.

For the review to be at all possible, 'a' needs to be done. The core
developers can help with 'c' on obvious errors.

To do 'a' in a large branch like the nt port is not an easy task.

> - After the C++ changes, the nt branch is broken on IPC
> - After the changes around 2-3 February there are again C++ problems with
> MS VisualStudio
> - I don't know C++ at all, and so i can't fix the previous problems

To get help you need to ask.

> - I'm the only developer

Which is a problem.

> - the nt branch is very big: 690 KB diff file

Which is a even bigger problem.

> - now the nt branch is totally out of sync

Which is not such a big problem, but a bit of a hassle until sorted out
by either having the bulk of the patch merged into HEAD allowing you to
start over in a new clean branch without too much effort, or you or
another developer find time to sync the nt branch again.

> This not true:
>
> I have posted the latest patch at 5 February: I have NEVER received ANY
> reply and it was not commited.

Rule of thumb: If you haven't seen a patch merged within a week or a
negative response telling that it cannot be merged in it's current form
then repost, with a clear indication that it is a repost..

The Squid core team mostly works on an opt-out principle. If no
objections have been to a proposed change within the review period then
it is assumed to be OK by the other core members. As members of
squid-dev you also have an option to opt-out changes when the core team
thinks the change may have negative effect for other developers using
Squid.

Occasionally changes in HEAD will break development branches, but such
large changes as the restyling is relatively rare. I agree that it was
unfortunate that it was not clearly communicated that the styling will
cause a lot of work for all developer branches.

You are far from alone having development branches broken by HEAD
changes.

To minimize the damage to your developments I can only repeat what I
said before: For now, stop merging from HEAD and instead concentrate
fully on splitting the nt port into mergeable pieces and send them in
for review. When this is done the amount that is left in the nt branch
should be fairly trivial to resync with HEAD.

For other developers of HEAD my recommendation is to

1. Save a patch file of their current developments. "cvsmkpatch HEAD
>../branchname.patch"

2. Close the current development branch by using "cvsclosebranch HEAD
2003XXYY" (2003XXYY == todays date)

3. Recreate the branch and apply the changes again.

Using cvsmerge to update branches over the astyle update is both a bit
dangerous due to the very high collision rate, and creates a lot of
overhead for CVS.

To reapply the changes you may have better luck if you create a diff
with the sources properly styled. To create such diff use the following
procedure after closing the current development branch:

1. Grab a clean copy of your "old" development branch
  cvs co -d yourbranch-2003XXYY -r yourbranch-2003XXYY
   cvs -d cvs.devel.squid-cache.org:/cvsroot/squid co -d head-2003XXYY

2. Grab a matching clean copy of the HEAD sources
  cvs co -d HEAD-2003XXYY -r yourbranch-2003XXYY_merge_HEAD-2003XXYY

3. astyle the modified files in both source trees ONCE with

    astyle -cs4 -O --break-blocks -l sourcefiles...

4. Generate a unified diff of the astyled sources

   diff -urN --exclude='*.orig' HEAD-2003XXYY yourbranch-2003XXYY

Regards
Henrik

-- 
Henrik Nordstrom <hno@squid-cache.org>
MARA Systems AB, Sweden