Bugzilla – Full Text Bug Listing
| Summary: | [CVSNT] Cannot restore from repository with CVSNT | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jean-Yves TOUMIT <jyluciole-dev> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | major | ||
| Priority: | P4 | Keywords: | helpwanted |
| Version: | 3.0.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Jean-Yves TOUMIT
The Eclipse CVs plugin looks for files that are in the Attic directory but the trace you've provided does not have any files in the Attic. There are two possibilities. Either you have no files in the Attic which means there are non to restore or CVSNT has stopped communicating the Attic files when a "cvs log - R" command is sent. 'Attic' is an internal implementation detail of RCS - it is a bug if Eclipse is looking for it (cvsnt also does not have such a concept except for compatibility with old repositories). It won't work even on cvs 1.11 if for example you are on a branch and there is no HEAD revision (since that file will be in Attic even though the file is not deleted). It's also not that unusual to find a file in the Attic even if the file exists on HEAD (if the file permissions wouldn't allow the move, for example). The correct way to do it (on cvs 1.11 too) on is to look for 'dead' files using the rlog -s option. eg (cvs 1.11 test on the cvsnt repository - haven't tried against sourceforge but it should work as they're on the same version I'm testing with): $ cvs ver Concurrent Versions System (CVS) 1.11.17 (client/server) $ cvs -q rlog -l -R -S -s dead -rCVSNT_2_0_x. cvsnt 2>/dev/null /usr/local/cvs/cvsnt/TEST.TXT,v /usr/local/cvs/cvsnt/cvsnt.dsp,v /usr/local/cvs/cvsnt/cvsnt.dsw,v /usr/local/cvs/cvsnt/cvsnt.vcproj.vspscc,v /usr/local/cvs/cvsnt/cvsnt.vssscc,v /usr/local/cvs/cvsnt/readme,v Note that on cvs 1.11 -rHEAD. doesn't work (which is a bug), but -r1. serves as a reasonable replacement (as long as nobody has changed the default branch, which is rare). In this case, shouldn't this bug be reopened?... :-D The output of "cvs log -R" was the most efficient way to get the information we needed. Your suggestion to use rlog will not work since the structure of the local sandbox may not match the structure of the repository. It appears that the log command supports similar options so it is possible that what you suggest would also work with the log command. I don't have the cycles to address this issue at this time but would accept a patch for this if one were provided. Also, I don't really view the use of 1.11 output that may reveal the internal implementation of CVS as a bug. The fact of the matter is that if the Eclipse client stuck to what was in the CVS specification, then Eclipse would only be able to do the basic CVS functionality (i.e. no sync view, etc). Instead, we opted to make the most of what we could from the text messages communicated from the server in as efficient a way as possible. In essence, we are treating the output of the 1.11 server as the CVS specification. I understand that this is fraught with peril but we really didn't have an option given the CVS protocol. The statement we make is that, as new CVS server versions become available, we can only guarantee support the basic CVS funtionality (checkout, update, commit, tag, etc). There is currently no plan the address this item. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |