Re: [platform-vcm-dev] The WVCM API

[birdo@xxxxxxxxxxxx (Roberto Scaramuzzi)]

On Thursday 17 April 2003 07:49, Jean-Michel Lemieux wrote:
> Roberto,
>
> There is a long history of VCM APIs in Eclipse :) In the early days of
> Eclipse we thought that an API was the foundation on which the Eclipse VCM
> support should be built and spent quite a while trying to realize this.

[snip]

> As you have noticed, without any APIs you can't build tools based on a
> repository. And we agree that this is a missing piece of the Eclipse VCM
> story. But we don't know if there is a need for a general API instead of
> having each repository plugin provide it's own. Could you please help us
> understand this by answering some questions:
>
> 1. Do you need programmatic access to CVS or more generally to any
> repository?
>
> 2. What 'unattended' CVS operations do you require?
>
> Cheers,
> Jean-Michel and Michael

1. Programmatic access to CVS is a minimum requirement, but it would be great 
to have vendor-neutral access to other VCM systems (we do have customers that 
use Clearcase, etc. and we would like our product features to be available to 
them too).

2. At present we need the following operations:

Tasks that ask for information about a resource:

a) is a resource under source control?
b) last modification date of a file in source control (cvs status + some 
parsing)
c) diff versus a specific revision or a specific date (cvs diff -D or cvs diff 
-r) - the output should be one of the classes in org.eclipse.compare
d)  last author of a file (cvs log + some parsing) (it would be nice to have a 
method that determines the last author of a specific line of a file, but we 
haven't yet figured out a way to do this in a reasonably efficient manner)

Tasks that modify the workspace:

e) check out a file/directory (cvs checkout)
f) update a file/directory (I realize update might generate a need for a 
merge; it's OK to throw an exception if a merge cannot be automatically 
performed) (cvs update)

Tasks that modify the repository:

g) add a resource to source control (cvs add + cvs commit)
h) check in changes to a resource (cvs commit)

As far as priorities go, the first group is essential, and the third group 
would be good. The second group would be nice to have, but we can work around 
it.

At present we are implementing all of this using our own CVS interface which 
relies on running the cvs binary and interpreting the output. 

This has a few drawbacks apart from the obvious one of having our own code we 
need to develop test and maintain:

a) It's not easy to extend the structure to other SCM systems (we would need 
to provide interfaces to every possible SCM system; Microsoft has a generic 
interface called SCC,  but it has insufficient features, is Windows-only and 
has restrictive licensing)

b) Interoperability with Eclipse is tricky: if we add a file to source control 
using our API, Eclipse doesn't know about it; the cvs binary and Eclipse get 
their authentication information from different places; and so on.

c) using a combination of C-based and Java-based tools has its own problems: 
for example, a rogue beta version of Eclipse inserted some bare \r's in some 
of our source code. Now Java (and Eclipse) think that's a line terminator, 
but C (and cvs diff) don't agree, so various features having to do with line 
numbers are broken.

As far as using the IDE, I have (reluctantly) come to agree that it is OK to 
give more control to the user. For example, if we want to add a file to 
source control it's OK to just add it to the file system and perform a 
refreshLocal(). The CVS plugin will generate a task and the user will 
eventually add (or not) the file.

However our tool is also intended to run in headless mode (for example as part 
of a nightly build process) That makes the ability to get information, add 
and check in files without user intervention essential.


-- 
Roberto Scaramuzzi
System Engineer
Parasoft Corp.