Bugzilla – Full Text Bug Listing
| Summary: | Unable to see Ascii/Binary changes | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Chris Nappin <c.nappin> |
| Component: | CVS | Assignee: | Michael Valenta <Michael.Valenta> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | Keywords: | helpwanted |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Chris Nappin
Yes, you can perform a Replace with>Another branch or version and choose HEAD. This results in a "cvs update -A". I don't think it will help you though, since the server will just send back the keyword mode that was sent up from the client, regardless of what it was set to on the server. That is why we have the message appear during the Change ASCII/Binary Properties action that states that all users of the project must check out the content from scratch. Of course, if I am wrong on this, I would be happy to be corrected but the last time I looked, CVS just didn't handle keyword changes well. Michael, I'm no CVS guru but I'm not sure your assesment is correct. I've never had any problems with changing Ascii/Binary until moving to using Eclipse. We're using CVS 1.11.18, BTW, though I don't think any CVS functionality has changed in this area in many years. The command line CVS tools can cope with this scenario quite happily, so if at all possible I think this functionality should be added to Eclipse. Allow me to detail further. I have a CVS module open in Eclipse, and a separate checkout of that module using the Cygwin command line tools to simulate another user. I create a new binary file, add it and commit it. From the command line, I then checkout that file (by running "cvs update"). A "cvs status" of that file is as follows: $ cvs status test2.sh =================================================================== File: test2.sh Status: Up-to-date Working revision: 1.1 Repository revision: 1.1 /opt/cvsroot/test/test2.sh,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb So the command line has checked it out as binary. I then alter the file in Eclipse from Binary to Ascii, and commit that change. Running "cvs status" now recognises that the file has changed: $ cvs status test2.sh =================================================================== File: test2.sh Status: Needs Patch Working revision: 1.1 Repository revision: 1.2 /opt/cvsroot/test/test2.sh,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: -kb I then run "cvs update -A" on the command line, nothing else, and I get the more recent version of the file: $ cvs update -A test2.sh U test2.sh $ cvs status test2.sh =================================================================== File: test2.sh Status: Up-to-date Working revision: 1.2 Repository revision: 1.2 /opt/cvsroot/test/test2.sh,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Notice the Binary flag has been reset to ASCII. Fair enough. We'll investigate this for 3.2 if we can fit it in. We do not plan on addressing this issue in 3.3. It's very disappointing to see that such major CVS bugs (e.g. this one and 41331) are given such low priority. I appreciate you only have fixed resources, and I'm afraid I don't have the time to supply patches myself, but it appears the CVS component itself has a low priority? A major bug is something that affects your day to day development. Apart from testing, I don't think I have used the Change ASCII/Binary property dialog more than once or twice in the last few years. Realistically, we will use our resource more effectively if we address bugs that can make user more prodictive on a day to day basis. Unfortunately I'm a CVS administrator for a large development team so I come accross this issue quite regularly. The fact it affects the entire project team and has no realistic work around I think justifies the "major" description. I also work with a large development team, both in the UK and offshore in india, and a lot of the developers have their eclipse settings incorrect at some point or another, which leads to a lot of incorrect filetype checkins. This causes considerable pain to the whole team every time it happens. Fair enough. I'll add it back to 3.3 and I'll have a look to see if the fix can be made easily. If it turns out to be a small amount of work, we can do it. However, if it requires a significant effort, I doubt we will be able to address it. OK, here's what I have found. We cannot change the default update to have -A since the update is meant to work when either HEAD or a tag is loaded. However, you can get an "update -A" by either performing a Replace With Another Branch or Version and choose HEAD or, if the user does not want to loose changes, they can perform a Switch to Another branch or version and explicitly choose HEAD. Both of these perform an "update -A". I would recommend the later since it does not affect local changes. |