Community
Participate
Working Groups
Build ID: M20060629-1905 Steps To Reproduce: 1. create a project, submit to cvs (pserver) 2. disconnect from network (no cvs-connection) 3. make changes in the project, try to create a patch More information: i expect that the created patch have all diffs to the current local version. i should doesnt matter if a cvs-connection is available or not
While this is technically possible, it is not really how CVS works. The "cvs diff" command performs the diff by contacting the server. This would require the following two pieces of functionality: 1) A reliable cache of the base of the CVS sandbox. While we do often have the base contents available, it is not guaranteed. 2) Client-side diffing support. Currently, we rely and the server to perform the diff. To make this work, we would need an implementation of diff on the client. Currently, we do not have the manpower to address this but would be willing to accept a contribution.
Thxs for the info. Is it possible to add this functions with a new plugin?
Clientside Diff-support for eclipse is available with http://sourceforge.net/projects/externaldiff/
For the first functionality (local cache) i propose to add a new flag per cvs-server (e.g. "hold local cvs-cache"). I remember there exists in eclipse a "local history" per file. perhaps we can use this informations?
It would be difficult to add in a separate plug-in. As for the tool you mentioned, it would appear that the purpose is to allow the user to launch an external diff tool for the purpose of inspecting the differences. What this request would require is the ability to generate a patch file from the client. One possible way to do this would be to launch a separate tool but it would be better if the patch generation code was internal to Eclipse (i.e. this leads to an easier install and an improved user experience). Or, to put it another way, we do not generally ship code that depends on an external library. In regards to the local history, that is one of the mechanisms we have but it is not reliable (i.e. content is cleared after a certain time or if the cache grows to big). We also have a CVS revision cache but, again, entries are cleared after a certain amount of time or across a restart of Eclipse. I don't think we need a preference for this. I think a good policy would be to keep revisions indefinitely if they appear somewhere in the local workspace.
Subversion will allow you to do this, because it does keep a cache of local files :-) But back to this point -- there's a number of revisions that are kept around as items are changed for comparing with local versions etc. Could the same be done for files under CVS? If there was a change to something under CVS, couldn't you just lock that particular revision for a later compare?
Certainly. The problem then becomes one of ensuring that the proper notification occurs to unlock the revision and also to handle the case where a revision applies to multiple projects. The complicated parts of the cache are maintaining the cache across restarts (we currently clear the cache across restarts) and populating the cache when a change occurs (This could probably be done using an EFS wrapper).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
