RE: [cdt-dev] logistices for the EFS work

[<ken.ryall@xxxxxxxxx>]

I'd vote for (a) as well. And let us know when you start looking into
using EFS to include an arbitrary set of files in a project, that's
something we really need a solution for.

- Ken

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of ext Doug Schaefer
Sent: Monday, October 15, 2007 10:13 AM
To: CDT General developers list.
Subject: RE: [cdt-dev] logistices for the EFS work

BTW, I got great feedback from people at ESE on the Add File/Exclude
File feature I've proposed. EFS support will be critical for that
(although Dave Inglis has found a way we can cheat :).

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]

> On Behalf Of Doug Schaefer
> Sent: Monday, October 15, 2007 11:05 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] logistices for the EFS work
> 
> I'd vote for (a). I fear dropping all the changes in at once since 
> there will be a period where things won't work at all (remember the 
> new project model :). At least this way, we can put a priority on 
> fixing the bugs before continuing incremental work.
> 
> Doug Schaefer, QNX Software Systems
> Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On
> > Behalf Of Chris Recoskie
> > Sent: Monday, October 15, 2007 10:57 AM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: [cdt-dev] logistices for the EFS work
> >
> >
> > Hello everyone,
> >
> > Greg and I are at the point where we want to start making changes to

> > the code as we implement EFS support in CDT.  This is a large task 
> > which
> will
> > take a while to complete, and will have direct implications on APIs
> people
> > are using.
> >
> > As such, we want to get feedback from everyone as to how to handle
> putting
> > the changes in.  We can:
> >
> > a)  Make incremental checkins as we go on HEAD.  Pros:  everyone can
> adapt
> > to API changes incrementally.  People can collaborate more easily on

> > the new changes.  Cons:  EFS support will trickle in, and will not
> necessarily
> > provide a complete or functional solution until we are done.  Things

> > are apt to be broken frequently.
> >
> > b) Work for months until we think we're done, then do one gigantic
> checkin
> > once things are "working."  Pros:  nothing changes until stuff
works.
> > Cons:  It's very hard for everyone to react to the new APIs and 
> > functionality.  People may modify the same code we're trying to 
> > modify, which will making staying in sync difficult.
> >
> > c)  Work on a branch in the CDT, then merge it back to HEAD when 
> > we're done.  Pros:  Nothing changes until stuff works.  Cons:  CVS 
> > merge tools suck.  Also, no one is forced to look at the changes 
> > because most people will work on HEAD and not our branch.  Staying 
> > in sync is still a
> problem.
> >
> > We are leaning towards doing a).  Does anyone have any concerns with
> this
> > before we start doing anything?
> >
> > ===========================
> >
> > Chris Recoskie
> > Team Lead, IBM CDT Team
> > IBM Toronto
> > http://www.eclipse.org/cdt
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev