Re: What's in the NT branch

Hi,

At 21:08 13/03/2008, Henrik Nordstrom wrote:
>On Thu, 2008-03-13 at 20:48 +0100, Guido Serassio wrote:
> > Too much times something like this is happened:
> >
> > - Update from CVS of my work dir
> > - Fix of build problems
> > - Commit of fixes
> > - Finished the little time that I have available for development,
> > usually during weekend
> > - Hope to do some test/debug during the next weekend
> > - During the next week someone commit changes in the source
> > - Update from CVS of my work dir (again during weekend)
> > - Fix of NEW build problems
> > - Commit of fixes
> > - Finished again the little time that I have available for
> > development just for fix NEW problems .....
>
>So why do you update your workdir if you only want to test the stuff you
>had last weekend?

Using CVS, many times I cannot commit because the local tree is outdated.
Hoping that using bzr things will be better.

For now, I'm still looking for the time to read bzr documentation,
install Python and bzr on a test machine, and try to understand how it works.

Now I'm preparing things for the tomorrow job, no time for everything
else ... :-)

>You'll get extact the same breakage when updating your branch (i.e.
>running cvsmerge in the CVS setup, or bzr merge in the new bzr setup),
>so I am sorry but I don't see why keeping a shared branch helps this.
>
>I don't mind you having as many private branches for testing as you like
>to support your own workflow (thats after all one of the points why we
>selected bzr), but I do mind having stable binary releases made from a
>possibly different tree, or including sources not seen in the main tree.
>
> > >What aspect of Windows do you see as the most fragile part?
> >
> > The main problem is in the code that is touched from others developers.
>
>I would say the main problem is code changes only tested on one
>developers platform and not Windows..

Yes and no.
Sure I don't think that other developers doesn't work well.
But I think that the majority of developers is developing with a
"POSIX only mind", this is well enough for all Unix like platforms,
but not for Windows compatibility.

> > >- the socket/filedescriptor emulation?
> >
> > Many times very big problems here, and also with proprietary IPC and
> > IPv6 support.
> > This is the section where currently Squid 3.0 is failing on Windows.
> > I think that the forward port of the all 2.6+ related enhancements
> > could help the Squid 3.0 Windows support.
>
>Which Squid-2 changes do you have in mind there?

All the changes related to the new 2.6 comm event framework. The 2.6
comm code is very clean and simple. Probably this bug:
http://www.squid-cache.org/bugs/show_bug.cgi?id=1633

> > >- something else forgoten in the list above
> >
> > Different C/C++ compiler not always compatible with gcc and a totally
> > different run time library not based on glibc and not Posix
> > compliant. And many times this is a very big problem, true for both
> > Visual Studio and MinGW native environments.
>
>Yes, and this will always be seen for as long as we develop for more
>than one platform and compiler. But see above for my counter argument
>here..

Windows is more different: it's not POSIX compliant, and this is a
very big difference. All other supported platforms are generally
POXIS compliant.

Regards

Guido

-
========================================================
Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1 10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135 Fax. : +39.011.9781115
Email: guido.serassio@acmeconsulting.it
WWW: http://www.acmeconsulting.it/
Received on Thu Mar 13 2008 - 15:20:48 MDT