RE: CVSRoot

>Well, I should read the manual first:
>http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_2.html#SEC9
>
>There's the clarification:
>":server: method specifies an internal rsh client, which is 
>supported only by
>some CVS ports." Thus it's like :ext:, but with a buit-in rsh 
>rather then
>external rsh (or another remote shell defined by CVS_RSH). 
>According to this we
>should probably use SSHConnection for both :server: and :ext: 
>method; I suppose
>that no one is using rsh any more because of security reasons.
>
>The LocalConnection would be more like a :fork:. Since in the 
>functionality
>there should be no distinction between :local: and :fork:, we 
>can map both to
>LocalConnection.
>
>Does it make more sense now?

I am slowly starting to understand (maybe).
So here is my formulation, please comment.

:server: & :ext:                     --> SSHConnection
:local: & :fork: & repositoryOnly    --> ServerConnection (or whatever it should be named. Starts cvs server program on local machine)
:pserver                             --> PserverConnection

> IMHO :server: method is not much used
> anyway and for local connection it does not make much sense to use JavaCVS,
> since you need to use the cvs.exe as a server anyway. In NetBeans we use
> JavaCVS only for :pserver: method, but :server: mode can be handy as well.

using javacvs for local connections IS useful.
My example:
I have done a build system that has defined
an interface for a generic version control system.

I have implemented that interface for cvs using javacvs.
It is much simpler for me to use javacvs also for local
cvs connections instead of triggering cvs program directly
for local connections. And besides if you have installed cvs server
locally you always have the cvs client on the machine.

> Well, somewhere at cvshome.org, I've found this definition:
> [:method:][[user][:password]@]hostname[:[port]]/path/to/repository

>> It should recognize urls with format
>> [:local:[username:][password:]]repositoryPath
>> So if :local: does not exist username and password are not allowed.

> Hmm, this is a mistake in the CVSRoot class. Following CVSROOT is not
> considered as a bad one:
> :local:user@hostname:/path/to/repository

Sorry but I did not understand what you ment.
Did you mean that my interpretation is incorrect and
:local:user@hostname:/path/to/repository should be accepted or
that the existing implementation is incorrect and
:local:user@hostname:/path/to/repository should not be allowed.

> One difference is, that the original
> CVSRoot can parse CVSROOTs of unknown method names, therefore the parsing as
> such finish correctly and the method name is compared later to the known once.
> It is therefore more generic. If you introduce integer constants for connection
> method types, you need to update the CVSRoot class each time you add a new
> method. But otherwise it works in a similar way I guess.

You are right. I will refine the code and send it soon for review (I will mark the changes
so it is faster to read).

> You have an extra
> constructor with Properties (where do you use this?). Since you change
> equals(), we need to implement hashCode() as well.

I think it is a normal thing that the components of cvs url come
from a configuration file. In my case they are configured in xml.
The Properties constructor would be a generic way to configure
cvs connections without the url. The url is so hard to comprehend
that I want to protect my users from it :-). But of course it is not
a necessary addition.

I will add the hashCode() method

> Instead of
> if (new File(this.repository)).equals(new File(compared.repository)))
> one can use:
> if (this.repository.equals(compared.repository))
> with the same result I believe. You probably meant to write:
> if (new File(this.repository)).getCanonicalFile().equals(new
> File(compared.repository).getCanonicalFile()))

That is exactly what I ment to write.
So that case issues, symlinks etc. would not hinder the
recognization of cvsurl.