I have a project in one CVS repository that depends on source stored ina
subdirectory of other CVS repository(ies). In fact the main point of the
Eclipse project is coordinate the build of a component in an Eclipse
environment.
I therefore have a somewhat strange environment where the root of a project
is in one CVS repository and a subdirectory is in another. But this seems to
work okay when I do things by hand.
Previously I had an Ant script which uses a pure java CVS client to download
the files into a subdirectory of the project. I have configured this as an
Ant Builder for the project. If I configure this builder to run in the
background everything is okay. If I configure it to run in the foreground
then
org.eclipse.team.internal.ccvs.core.resources.EclipseSynchro nizer.commitCache
will delete the CVS directories ( with the Entries, Repositories and Root
files in ) that the other CVS client has created as it is out of step with
its in memory cache.

1) Is there some better way to invoke a checkout from CVS via an ant script
( i'd prefer not to have the users install a command line CVS first as per
the ANT cvs task ) using the Eclipse CVS client?
2) Is the background way of invoking the build a dependable thing to do or
have I just got lucky? - why does the EclipseSynchronizer not delete the CVS
directories when things are run this way?

JF wrote:
> The sort of stuff I need to do is like
> org.eclipse.team.internal.ccvs.ui.operations.CheckoutIntoOpe ration
>
> but all these classes are not available to me at runtime ( or can I
> ignore the discouraged access on these )?
>

I don't really follow what you're trying to do, but in general you can
ignore the discouraged access warnings if you are willing to accept the
risk that anything marked "internal" can change its interface and/or
behavior with any new release. The decision is a trade-off one: do you
want to trade the work of finding another solution for the risk that
your code won't work in a new release of Eclipse?

In my mind, part of the input to that decision is how stable and mature
the internal component is; I'd say that the CVS client stuff is pretty
stable and mature and thus *might* be less likely to change in the near
future.

The chief thing I wanted to do was to check out stuff from CVS into my
Eclipse project via a builder of some kind.
Since I'm using ant build files elsewhere I was re-using these. These
used the old (ahem, sorry :-)) netbeans cvs client to checkout stuff. When
I set up the ant build to run in the foreground then it seemed that the
eclipse cvs team stuff was deleting all the CVS directories that were
created because when it got notified that the project had changed it found
directories that were out of sync with its cached CVS info (
EclipseSynchronizer ). When I run it in the background everything is
okay. The problem occurs when the build file checks out stuff ( to create
a second supporting java source directory on the classpath ) into a
project which is already shared with a different repository. If I do this
by hand everything works "okay", otherwise I get the problem as stated.
Hence I was thinking about using the Eclipse CVS client to do stuff so
mimick what works by hand.