Community
Participate
Working Groups
"Commit Sets" does not work on cvs.dev.java.net the largest Java community site (e.g. jogl project). All of the changes appears as a plain list in the root folder. However if I double click on the changed file I can see the difference and linked CVS history view shows the author and comment details for given change.
It may be the case that this is the largest Java community site but they are running a customized CVS server. I found this is my log when I connected to the site: Host 'cvs.dev.java.net' is running 'Concurrent Versions System (scast-vc- 1.5.2) (CVS) 1.11.1p1 (client/server)' which is an unknown version to the workbench. Although most functionality may work, use version 1.11.1p1 or later for full support. The trace for the rlog command used to fetch the commit comments yields the following: rlog E lock.c:222: failed assertion `strncmp (repository, current_parsed_root- >directory, strlen (current_parsed_root->directory)) == 0' E cvs [rlog aborted]: received abort signal E cvs [rlog aborted]: received abort signal E lock.c:222: failed assertion `strncmp (repository, current_parsed_root- >directory, strlen (current_parsed_root->directory)) == 0' error It look like the customization they are running has broken the rlog command.
I still don't get it. Information presented in commit sets is seems no different then information in CVS history.
Note on bug maintenance: The severity is set by the reporter and the priority is set by the development team. As to your last question, the Commit set uses rlog while the Resource History uses log. It appears that the customization used by cvs.dev.java.net has a bug (or feature) that prevents the rlog command from working, at least for the parameters that are being used to populate the Commit Set. Not much we can do on our end except improve the error handling. We should be showing the user that an error occurred. Actualy getting Commit Sets to work with cvs.dev.java.net will require a fix on their end. We won't be pursuing this until 3.0 is out the door. However, feel free to contact the maintainers of cvs.dev.java.net yourself if you want to see this issue resolved sooner.
What was the reason to use rlog for commit sets?
By the way, it is difficult to reproduce, but I saw incorrect rendering of the commit sets for the projects that are using branches...
We use rlog because it gave us the information we needed (i.e. some of the changes may be incoming additions).
I see the similar problem for :pserver:anoncvs@cvs.apache.org:/home/cvspublic module maven-components.
Maybe we could implement the remote log using the log instead of rlog. The problem with log is that it assumes a sandbox, which we don't always have when files are only on the server and not updated yet. We may be able to workaround this though.
In any case it is not really good idea to drop all not recognized changes into the root of the commitset tree. I believe that at least some information could be retrieved and showed to the user (e.g. date, user who did the commit and also comment for commit), it will allow to sort by user and by date. Another possibility is to use rlog and switch into the log if it does not work.
Not for 3.1
Michael, I still see this happening on java.net. Since it became a primary repository hosting for many JEE projects it is became more critical now. Can you please enlighten me on rlog issue again? What is there and what is supposed to look like, so I can raise this with java.net and CollabNet folks. Thanks.
The problem is that the rlog command doesn't work, at least with the paramters that the Eclipse CVS client is providing. If you want to see what the exact parameters are during the failure, here is a link that describes how to get the complete client/server communications trace. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/cvs_features2.0/cvs-faq.html#misc_0
Micheal, I opened a ticket on java.net support and CollabNet folks said that they will fix it in 2007. https://java-net.dev.java.net/issues/show_bug.cgi?id=240 So, I wonder if in a mean time Eclipse can workaround it? E.g. try log command if rlog fail (then leave new files under "unknown changes").
This is not a high priority for us but you are free to implement a workaround in Eclipse and attach it as a patch.
There is currently no plan to address this item.
I got an update from CollabNet support team. See https://java-net.dev.java.net/issues/show_bug.cgi?id=240 Apparently rlog command is working when using /shared/data/ccvs/repository path (for java.net portal). However their rlog does not recognize -S option. So, I see the following error now. I wonder if Eclipse CVS client can live without -S or have an option to disable this flag. ---- Valid-responses ok error M E Checked-in Valid-requests Template Set-sticky MT Clear-static-directory Module-expansion Set-static-directory Clear-sticky New-entry Merged Removed Updated Remove-entry Update-existing Copy-file Created Notified Mod-time valid-requests Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot Static-directory Sticky Checkin-prog Update-prog Entry Kopt Checkin-time Modified Is-modified UseUnchanged Unchanged Notify Questionable Case Argument Argumentx Global_option Gzip-stream wrapper-sendme-rcsOptions Set expand-modules ci co update diff log rlog add remove update-patches gzip-file-contents status rdiff tag rtag import admin export history release watch-on watch-off watch-add watch-remove watchers editors init annotate rannotate noop version ok Root /shared/data/ccvs/repository CMD> cvs version version M Concurrent Versions System (scast-vc-1.5.6) (CVS) 1.11.1p1 (client/server) ok RESULT> Status INFO: org.eclipse.team.cvs.core code=1 The following warnings were reported while performing the "cvs version" command. null children=[Status INFO: org.eclipse.team.cvs.core code=-22 Host 'cvs.dev.java.net' is running 'Concurrent Versions System (scast-vc-1.5.6) (CVS) 1.11.1p1 (client/server)' which is an unknown version to the workbench. Although most functionality may work, use version 1.11.1p1 or later for full support. null] CMD> cvs rlog -N -S "/springmodules/sandbox/xt/build.xml" Argument -N Argument -S Argument springmodules/sandbox/xt/build.xml rlog E cvs server: invalid option -- S E Usage: cvs rlog [-lRhtNb] [-r[revisions]] [-d dates] [-s states] E [-w[logins]] [files...] E -l Local directory only, no recursion. E -R Only print name of RCS file. E -h Only print header. E -t Only print header and descriptive text. E -N Do not list tags. E -b Only list revisions on the default branch. E -r[revisions] Specify revision(s)s to list. E rev1:rev2 Between rev1 and rev2, including rev1 and rev2. E rev1::rev2 Between rev1 and rev2, excluding rev1 and rev2. E rev: rev and following revisions on the same branch. E rev:: After rev on the same branch. E :rev rev and previous revisions on the same branch. E ::rev Before rev on the same branch. E rev Just rev. E branch All revisions on the branch. E branch. The last revision on the branch. E -d dates Specify dates (D1<D2 for range, D for latest before). E -s states Only list revisions with specified states. E -w[logins] Only list revisions checked in by specified logins. E (Specify the --help global option for a list of other help options) error RESULT> Status ERROR: org.eclipse.team.cvs.core code=-10 The server reported an error while performing the "cvs rlog" command. null children =[Status ERROR: org.eclipse.team.cvs.core code=-10 The server did not provide any additional information. null]
This issue is decribed in bug 81960. Given that users of CVS have been advised to move to the latest 1.11.x versions due to some security holes that were found in previous versions, there is little incentive to invest manpower in fixing this. However, it wouldn't be much work to patch out the use of -S in the rlog command. I don't remember the specifics as to why we needed it but there was a reason. However, it may have been a corner case so it may be worth it for you to patch the CVS core plugin and try it out to see what results you get.
(In reply to comment #17) > This issue is decribed in bug 81960. Given that users of CVS have been advised > to move to the latest 1.11.x versions due to some security holes that were > found in previous versions, there is little incentive to invest manpower in > fixing this. However, it wouldn't be much work to patch out the use of -S in > the rlog command. I don't remember the specifics as to why we needed it but > there was a reason. However, it may have been a corner case so it may be worth > it for you to patch the CVS core plugin and try it out to see what results you > get. Michael, can you please give me a hint where this switch set in the code? Thanks in advance.
The RemoteLogOperation in the org.eclipse.team.cvs.ui plugin has a getLocalOptions method that includes -S (RLog.ONLY_INCLUDE_CHANGES).
(In reply to comment #13) > Micheal, I opened a ticket on java.net support and CollabNet folks said that > they will fix it in 2007. > https://java-net.dev.java.net/issues/show_bug.cgi?id=240 Eugene, the issue you referenced has been fixed. Could we close this bug?
(In reply to comment #20) > Eugene, the issue you referenced has been fixed. Could we close this bug? Sure. Thanks.
Closing as NOT_ECLIPSE.
