state info, project management

[Gerard Jungman]

Hi. I just wanted to state a particular usage-case which should
be kept in mind. Maybe this has been discussed already, but I think
it is absolutely critical. The scenario is several developers
working on a project, with one or more not using the IDE. I work
on collaborative projects with small groups of people, and of
course the development tools are reduced to the lowest common
denominator. Sometimes very painful (editor+grep). I know other
people in this situation who have the same problem.

The question is what to do about it.

If I 'cvs update' my sources, which contain committed changes from
a non-IDE collaborator, obviously any previous project state in my
sandbox will become irrelevant and possibly dangerous.

At a minimum there has to be a re-scan to establish any local state
info.
That would be fine. Maybe one could do even better, using some kind of
logging model for local changes and have the system detect changes
from outside automatically. It could do a kind of lazy refresh as well,
to amortize the cost of the re-scan over time (although, like automatic
garbage collection, it would occassionally happen at annoying times...
I don't think that would be a real problem).

It is worth pointing out that this kind of model makes creating new
projects from old sources easier too. That activity is a similar kind
of stateless re-scan.

Another use is when you want to browse somebody else's sources, but not
make any changes. Then you have no need to create any persistent state
info,
and you probably don't want to either.


Finally, related to this is something that the core kdevelop
guys probably have thought about, but which I think is also
critical. That is that there has to be a very well-enforced
orthogonality between the basic IDE components: editor, source
browser, and project management. Maybe there are ways to break
these up further as well; that would be fine. This breakup
is related to project state info because not all of these
components need to have state, or at least they need to have very
well-defined interfaces to the state so that hidden
inter-dependencies do not get built into the design.


Anyway, that's my armchair commentary.

Thanks.

-- 
G. Jungman