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

[Deven T. Corzine]

On Wed, 7 May 2003, Derek Robert Price wrote:

> I do do it for trivial stuff as well as vital stuff, sometimes, but a 
> lot of trivial fixes ends up taking up a lot of time.

That's true, but the flip side is that putting off the trivial stuff lets 
it pile up, when it's often easier to just get it out of the way.

> In this particular case, however, I was also objecting to the nature of 
> the change.  I think the voting developers will agree with me, this 
> patch just doesn't add enough functionality to justify the overhead.

What overhead?  It's maybe 20 lines of extra code, if that.  While I agree 
that "extssh" is probably not the best solution to the problem, do you 
really expect to want that method name for something else entirely?  It's 
arguably clutter, but not much.

> Like I said, I'm guessing that the design goal here was to allow the 
> remote shell client to be encoded in the CVSROOT string.  If the patch 
> did this in a more general way and came with test cases and docs, I 
> would probably commit it.  At present I am taking the other voting 
> developer's silence for implicit acceptance of this.  :)

For me, the design goal was to make it work with Eclipse workspaces, that's 
all.  While a general solution to encoding the external client into CVSROOT 
might be worth looking into, it would NOT solve this compatibility problem.

In the grand scheme of things, isn't interoperability more important than a 
little bit of undesirable clutter?

> >Well, since the "extssh" method I implemented is nearly identical to the 
> >"ext" method, whatever documentation and regression tests that the "ext" 
> >method uses should be trivial to copy and modify for ths "extssh" method.
> >
> >If I get a chance, I'll try to do that for you.
> 
> Again, sorry about that, but in this case it wouldn't be enough.  If you 
> think you will have problems finding time to do this and it is important 
> to you, you might consider sending the report to whoever patched CVS for 
> Eclipse.  If you can explain your problem to them and they think it 
> likely to affect other users, perhaps you can get them involved in this 
> discussion and perhaps submitting patches on their time.

You don't seem to understand.  Eclipse has its own CVS implementation, and 
it's written in Java.  It's either a reimplementation from scratch, or a 
port of the C code to Java.  Either way, it's an independent codebase, and 
it's widely distributed.  I agree that they should have approached you much 
sooner and worked out a solution for everyone, but I guess they assumed 
that their users would never need to fall back on command-line CVS.

> >If you point me to the exact location of the documentation and regression 
> >tests for the "ext" method, that might let me expand on that patch more 
> >easily.  Right now, I'd have to look for them.
> 
> All the tests are in src/sanity.sh.  The "crerepos" tests are the only 
> ones that test :ext: and the CVS_RSH client specifically.

And the documentation in question?

> >It's not a huge deal to me either way, but I suspect I'm not the only one 
> >who was bitten by the incompatibility between Eclipse and standard CVS...
> 
> Again, if not, then perhaps you can get some support from the people at 
> Eclipse.

They can't do anything about making standard CVS work with their installed 
base of Eclipse systems.  Maybe they could get rid of "extssh" in a newer 
version of Eclipse and replace it with something you like better, but I'm 
not part of that process, so I don't know if they'd do that or not.  Maybe 
they've got other fish to fry right now...

Deven