Re: CVSRoot

Ojares Rami EINT wrote:
> 
> >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

Yes, it looks good to me.

> 
> > 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.

I see. So we have a good reason to keep the ServerConnection (or
LocalConnection).

> 
> > 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.

It's a bug in the existing implementation which is at
javacvs/libsrc/org/netbeans/lib/cvsclient/CVSRoot.java ;-)

Valid roots seem to be parsed O.K., but invalid are not always detected.

> 
> > 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).

I've seen it. I'll look at it soon and send you feedback. Thanks.

> 
> > 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'm not sure whether this would be valuable for javacvs library as such, but
considering it's just one constructor, we can have it there.

> 
> 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.

Thanks,
Martin

> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]