don't know how exactly the team support is implemented in eclipse, but
think that the team framework can provide such support. Suppose there are just
"strict" and "relaxed". Eclipse remembers for each problem its severity
in both modes, and when the
chooses to commit his work the "strict" level tasks will be presented. This will
save the time of performing
another compilation. However, if you allow each repository provider to
simply supply his menu actions (I see that clearcase
this way), there will be a problem.
understand your suggestion, but I'm afraid it will be too complicated for most
if there is a simple flag (a check menu item in the project's context menu) it
Associating this code checking with commit/check-in is actually quite
complicated. It either requires each repository provider to implement support
for it (which is unlikely) or a repository provider API that all repository
providers implement (which, at this time, does not exist).
It seems to me that what is being
described is the stages in the development process. In the early stages, the
developer wishes to have the minimal constraints (i.e. no NLS, no
accessibility, etc). In the later stages, tighter constraints are desired
(i.e. NLS checks, etc). The final stage would be releasing (committing to a
repository or whatever other form of release is being used).
The above scenario is similar to the
concept of user roles (i.e. providing support for the role the user is playing
at this point in time). I'm not sure how this would be supported in Eclipse
but if there were such a mechanism then the user could explicitly say what
stage they were in and they would get the appropriate errors, menu operations,
etc. The mechanism could enforce that the user go through the approriate
stages in the correct order and even prevent transitions if certain conditions
were not met. Without such a mechanism, I doubt that support for such a
workflow will be possible.
Sent by: eclipse-dev-admin@xxxxxxxxxxx
22/04/2003 02:43 PM
Please respond to eclipse-dev
Subject: RE: [eclipse-dev]
I agree with the suggestion that the code gets
when it's committed/checked-in to the repository.
need a solution for people who don't use any
revision control for
> From: eclipse-dev-admin@xxxxxxxxxxx
[mailto:eclipse-dev-admin@xxxxxxxxxxx] On Behalf Of Dirk Baeumer
Tuesday, April 22, 2003 8:24 PM
> To: eclipse-dev@xxxxxxxxxxx
> Subject: Re: [eclipse-dev] Compiler
> I would prefer a solution were the code gets
> checking it in
> into the
We could even write some tools that remove unused element
> on check-in.
> My two cents