Re: Eclipse-compatible :extssh: method...

[Deven T. Corzine]

On Tue, 6 May 2003, Derek Robert Price wrote:

> Deven T. Corzine wrote:
> 
> >The Eclipse IDE (www.eclipse.org) supports a CVS method of "extssh".  The 
> >attached patch extends the standard CVS client to support this method as 
> >well.  For this method, "ssh" is the default rsh client instead of "ssh", 
> >and CVS_SSH overrides it, instead of CVS_RSH.
> >
> >With this patch, the "cvs" command can operate on workspaces checked out 
> >via Eclipse using the "extssh" method.
> >
> >Can this patch be incorporated into the mainline CVS code?
> 
> No.  It adds no new functionality and I'm fairly close to making the 
> default CVS_RSH value `ssh' anyhow.

That's not a bad idea.  In my patch, I made a separate CVS_SSH variable 
control the "ssh" default, but how many people really want to use "rsh" 
still anyhow?  (They could always set CVS_RSH="rsh"...)

> Why aren't you just setting CVS_RSH from the command line?  If it's just 
> because you want the information encoded in the CVSROOT rather than in 
> an env variable, then come up with a resonable, but more generic way of 
> encoding _any_ value of CVS_RSH into the CVSROOT string and I will 
> commit it.  Reasonable means that the new code will parse old CVSROOTs 
> without problems and that new strings look as much as posible like old 
> strings, as subjective as that may be.  I'd prefer you extend the syntax 
> of the :ext: method, not add a new method as well, but if you feel you 
> can't avoid it, please provide justification.

I can set CVS_RSH to "ssh" in the environment, but it won't change the 
fact that Eclipse checks out the files with a method name of "extssh", 
which stock CVS rejects as an error.  I can't control how Eclipse works, 
and the working files I was using had been checked out by Eclipse.  With 
the patch I submitted, the command-line CVS can operate directly on the 
working files checked out by Eclipse, instead of aborting with an error.

While I might agree that "extssh" is a strange choice for a new method, 
and it's not as generic as one might like, it is what it is.  That's what 
Eclipse is already using, and it's out of my control.  Feel free to take 
it up with the Eclipse developers.  Maybe you can convince them to do 
things differently.  Don't put me in the middle of that discussion.

I was only looking for interoperability between command-line CVS and the 
implementation in Eclipse.  Patching CVS to understand the "extssh" method 
that Eclipse uses was trivial.  Making "extssh" an alias for the "ext" 
method would have been even more trivial, but then I'd need CVS_RSH set.

> Don't forget cvs.texinfo documentation and test cases in sanity.sh.  
> See the HACKING file in the top level of the CVS source distribution for
> more on what is required for patch acceptance.

Do you require every patch author to embark on a quest for acceptance 
before you integrate the patches?  That's a good way to discourage people 
from even sending the patch in the first place.

The patch I sent was trivial.  I offered it to you because I've heard many 
complaints from open-source authors about patches that get created and 
never submitted back to the author.  I've done my part -- I made a clean 
patch and offered it to you for incorporation into the main distribution.  
I didn't try to design a better solution because the goal was real-life
interoperability with another implementation.

Don't ask me to spend more of my time expanding on the patch to conform 
with your preferred patch etiquette -- it's too trivial of a patch to be 
worth such an effort on my part.  If you need documentation and a test 
case, you should already know how those are expected to be written and 
where they go, and you could probably write both in a couple minutes, 
faster than I could learn the project-specific details.  (This email
conversation is already taking too much of my time.)

Don't expect me to expend much effort on justifying this patch either; if 
you care about interoperability, it should be a no-brainer.  If you don't,
then you'll probably never be convinced anyhow.  Either way, an extended 
debate isn't likely to benefit either of us.

If you don't want this patch, I'll offer it downstream to the Red Hat 
package maintainers.  If they don't want it either, I'll just keep track 
of it myself.  It's not that important to me at the moment, and I don't 
have time to shepherd this patch through a byzantine submission process.  
Maybe I'll find the time later sometime.  Until then, you'll have to take 
it or leave it, as it stands.  I just don't have the time to spare now.

Deven