Community
Participate
Working Groups
The subclipse plugin has access to the diff output from subversion in unified diff format. it would be desirable to be able to supply this input to the compare system, to overcome the limitations of the comparison framework, namely lack of support for ignoring spurious diffs caused by keyword expansion and EOL conversion. Given the different features and formats of various SCCM systems, implementing this concretely in the compare system would seem unworkable. one possible solution would be to supply a hook in the compare system, allowing a plugin to veto a particular line of diff. thus, the plugin would have a chance to identify a tag, or a diff caused by EOL conversion, and drop it from the comparison results. this forces the plugin implementor to rely on the eclipse diff algorithms (great though they be), instead of the diff functions inevitably built into their own underlying sccm system. Thanks,
I am also working on Subclipse. It seems like the way this could work would be rather than supplying two files and letting the compare engine produce the output, you could supply the compare engine with 1 file and 1 diff file and it would "synthesize" the same output. When comparing a set of files, we would supply the set of files and a unified diff and the engine would use the unified diff to show which files have changes and then for each file the actual change. This would solve a lot of problems for us in the Subclipse plugin.
I think this would be great. Unfortunately the Eclipse Platform team is maxed out at the moment and probably will be for 3.2. I believe that most of the logic for this already exists in the Apply Patch wizard so it may be that most of the work is refactoring that into a form that can be used by others. I think this would be a good candidate for a patch if someone was looking for a way to contribute to Eclipse.
I do not really know how the Eclipse code works, so this Apply Patch idea may very well apply. I just thought I would clarfiy. In Subclipse, we would like to offer a Compare with Branch/Tag option (among others). Subversion has a fairly efficient API that could give us a unified diff of the differences. We would like to pass that to some API and end up with the same sort of visual results we would have got if we had the Branch/Tag checked out locally and used the Eclipse Compare with Each Other option. Apply Patch obviously has the parsing code to pull the files and contents from the unified diff, but I assume it would take a fair amount of new code to turn that into the nice end result UI you get from Compare?
It really depends on the type of presentation you want to have. The current Compare framework is stream based in the sense that each contributor (left, right and ancestor) is a stream. To use this what you need is API that accepts a local file and a patch and gives you a stream (probably on a temp file) that consists of what the file looks like with the diff applied. This can then be fed into the existing compare framwork and displayed. The Apply Patch wizard already has code that generates a result from a source file and a diff but it is not API (the class you would be interested in is named Patcher in the org.eclipse.compare plugin). Of course, if you want an entirely different presentation than that is going to be a lot of work. I suspect what you are concerned about is storage efficiency in the wizard (i.e. why have two streams when a stream and a diff are enough). I suspect you could achieve this by creating a custom stream on the local file and the diff that combined them when the stream is read. This would still be a fair amount of work to get right but does not involve changes at the UI level.
When you compare two projects using Compare with Each Other, the initial part of the Compare UI only shows the files that are different. You can then drill into those differences. Let's say, my project has 1000 items and I compare to a branch in Subversion. The Subversion diff can tell me the 10 files that are different. I would be happy if the Eclipse compare could just easily be restricted to those 10 items. It could then dynamically do a compare based on the real streams as we already do for single files. The main thing is that I do not want to have to download an entire branch and let Eclipse compare it. The Subversion diff is a bit better than the Eclipse compare simply because it knows how to ignore things like line ending and keyword differences. But if the initial list could be whittled down using Subversion, that would get us most of the way there.
Eclipse already has several pieces that would help you. I would suggest you read the Team ISV doc (i.e. in the Plugin Developers guide) and particularly the section of synchronize participants and subscribers. This would seem to me to be the logic place to start to understand what Eclipse offers for the workflow you are describing. Just to give you an idea how CVS uses this, there is a CVS Compare Synchronize Participant and a Compare Subscriber. When performign a comparison, the contensyt of any differing files are fetched and the results shown in the sync view only contain the true differences. as you have indicated, there are more efficient ways to do that in Subversion but the mechanisms to surface the result in the UI can be the same. If you have more questions, I would suggest posting them to the platform-tam- dev mailing list as what we are discussing is not relevant to this bug.
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.
