Community
Participate
Working Groups
Files checked out with WinCVS cannot be used in Eclipse. This is because WinCVS (1.3.20.2) uses a different format inside the CVS/Root files. :pserver;username=<user>;password=<password>;hostname=<server.address.com>;port =<port>:/path/to/cvsroot/
This is not a standard Root file format -- I can't believe that the password is stored in this file? Ask WinCVS to provide a preference to keep this file in the canonical Root file format.
Does Eclipse actually read and parse CVS/Root file? Why would it do that!? This is the CVS administrative file and Eclipse should just leave it alone, or maybe read for display purposes but it should not prevent work with the sandbox! As the bottom line - if the command works from command line it should also work with any front end to CVS. It's elementary! Security is not an issue - password doesn't have to be specified (but it could be) and if not given it will be prompted by CVS when logging in as usual. For pserver it doesn't make any difference becuase it's getting send in clear text to the server... And of course, WinCvs doesn't write to the CVS/Root file so it can't be "asked" to change it or keep it in any particular format. Instead Eclipse should stop interpreting the file or alternatively it should read it properly as per documentation.
I'm changing the tilte as it's not a problem with WinCVS but CVSNT and i'm also reopening this bug for further comments. Re comment 2: Eclipse implements its own CVS client. This client stores repository information into the CVS/Root file. The main problem I have is that I can't use the Eclipse CVS integration if I checkout the project with WinCVS (which uses CVSNT) first. Example: - Checkout a project from CVS with WinCVS - Import project into Eclipse - Try to associate this project with the Eclipse CVS integration (Team -> Share Project...) -> Eclipse complains about an invalid repository.
So the question is, should a CVS sandbox be compatible with all flavours of CVS? If CVSNT is storing the CVS/Root file in a different format, then compatibility with any other client, including Eclipse, is broken. As it stands, Eclipse is compatible with the "standard" CVS client. If other CVS client tools deviate from this "standard", they will not be compatible with Eclipse. Tony, is CVSNT storing the CVS/Root file in a different format?
No, not at all. It can use/parse a lot more options, but if you don't use them then it uses an absolutely standard format... I'm not sure what generated the string below (CVSNT just uses what was passed to it - it doesn't try to 'simplify' in any way), as WinCVS has a freeform text field for entering the CVSROOT.. there's nothing to stop the user entering a standard string. The only difference in the CVS directories in a standard checkout is there's a couple of extra files, which aren't really essential anyway.
Tony's response seems to suggest that the invalid CVS/Root file format is not comming from CVSNT. As Jean-Michel stated in comment #1, the solution to this problem is to identify who is storing the CVS/Root file in an invalid format and request that they do not (or at least that they provide an option to maintain compatibility).
If Eclipse uses it's own CVS client then it's a simple matter of choosing to only use CVSNT and GUI that use it (WinCvs, TortoiseCVS) or only use Eclipse integration and it's CVS client. It's obvious that you can't just mix the clients like that - metadata in CVS folders can not be properly maintained, and it's not just Root file but other administrative files as well.
That's simply not true. If you make sure you use a common subset of functionality you'll be fine - CVS/CVSNT/JVCS/SmartCVS/whatever all use the same basic sandbox format and are interoperable. You obviously can't use things like SSPI and Unicode on eclipse, but then you probably wouldn't need to. The only issue comes when you try to do things like mix platforms via network shares... then line ending issues bite you (for Win32 purposes cygwin is a separate platform with the same issues).
Tony, If that's not true than why are we having this bug report? I am sure that more issues will emerge eventually so it's best to play safe and use only one CVS binary. Naturally it may more or less work but I would not recommend that in the production environment where the code matters.
Because the OP decided to use a CVSNT-only CVSROOT string then complained it didn't work on a non-CVSNT client. In the same way if you checkout using SSPI it won't work using eclipse. This isn't incompatiblity - you just have to use features supported by both.. sticking to the core cvs 1.11 protocols/root strings is not hard and will guarantee compatibility across clients (in fact this compatibility is one of the strengths of CVS). Once the checkout is done (I suggest doing the checkout on eclipse if you're unsure what is the common functionality) then the sandboxes will remain compatible no matter what client is used (avoiding mixing cygwin and win32, as noted previously). I routinely use different clients... I have to, because it's part of the testing procedure. Being unable to mix them would be a fairly serious bug.
Tony, Routinely? Well, I guess you have the right to live dangerously ;) I wonder whether the Eclipse allows to change the CVS binary it's using. That would probably be the best solution to the problem - it would solve the metadata issues and allow more flexibility. It should also be fairly easy to implement. On WinCvs side we will definately allow to use different CVS binaries in the future when I get some time to implement that.
Eclipse doesn't use a CVS binary.. it has its own implementation. That's not really an issue - the protocol is already defined and CVSNT doesn't break that (it extends it quite a bit, but then it's designed to be an extensible protocol). It's not living dangerously to use different clients... it's exactly the way things are supposed to work! I like to think of CVS as a platform that many clients can use equally - provided they stick to the protocol and don't try to over-interpret the textual output, it'll work fine. The CVS\Entries format is sent from the server and is defined by the protocol, so isn't likely to be changed on the client (I guess you could if you wanted to.. There doesn't seem much point though). Things like WinCVS, TortoiseCVS, MacCvsX and some others use the CVSNT binaries that gives them things like mergepoint handling, unicode, rename etc. for free, but that's by no means the only way to access the system - I even have experimental clients in c# for example. Not sure I see the point of using a different client in WinCVS though as you'd have to reimplement half the stuff anyway... lots of effort for no gain.
!SUBENTRY 1 org.eclipse.team.cvs.core 4 4 2005-08-09 16:50:20.459 !MESSAGE Invalid CVS repository location format: :pserver;username=anonymous;hostname=cvs.sourceforge.net:/cvsroot/phpxmlrpc !SUBENTRY 2 org.eclipse.team.cvs.core 4 4 2005-08-09 16:50:20.459 !MESSAGE Location must have form ':methodname:[user[:password]@]host:[port]/path/to/cvsroot' !SUBENTRY 2 org.eclipse.team.cvs.core 4 4 2005-08-09 16:50:20.489 !MESSAGE Only the following methods are supported: pserver, ext, extssh I don't mind if eclipse will convert WinCVS format into it's own. WinCVS can handle this. The problem that eclipse can't. =( From version 2 of WinCVS there is a wizard, which saves Root in this verbose format. BTW, you information is odd. Cederqvist says location must have form [:method:][[user][:password]@]hostname[:[port]]/path/to/repository not :methodname:[user[:password]@]host:[port]/path/to/cvsroot (http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_2.html#SEC26) Furthermore, WinCVS format is absolutely consistent with cederqvist (http://ximbiot.com/cvs/manual/cvs-1.12.12/cvs_2.html#SEC28) which says "The ext, fork, gserver, and pserver connection methods all accept optional method options, specified as part of the method string, like so: :method[;option=arg...]:other_connection_data " Why do you mind to help developers migrate from WinCVS to Eclipse platform more easily?
The problem is that the CVS spec doesn't say what any of those options are so clients are free to create their own. However, they do so with the understanding that they will be breaking compatibility with all other clients. Having said that, if you want to provide a patch that allows Eclipse to understand the WinCVS CVSROOT/Root format, then I would be happy to have a look at it.
Created attachment 25935 [details] parse alternative CVSROOT format from WinCVS * Also parse alternative format from WinCVS, which stores connection * parameters such as username and hostname in method options: * * :method[;option=arg...]:other_connection_data * * e.g. :pserver;username=anonymous;hostname=localhost:/path/to/repository * I suppose there must be a better technique to do this, but I hadn't programmed java before, so I made this patch as clear as possible.
Thanks for the patch.
I released the patch and ensured that it didn't affect the standard CVS/Root format. I'll leave it to you to test that it works for the WinCVS format.
*** Bug 107306 has been marked as a duplicate of this bug. ***
There seems to be a problem in the patch for parsing passwords (see bug 110922).
Bogdan, please verify this during the 3.2 M3 test pass
Verified in I20051101-0010
*** Bug 125850 has been marked as a duplicate of this bug. ***
