Bugzilla – Full Text Bug Listing
| Summary: | Plug-in split has caused incoming changes in old tags | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Markus Keller <markus.kell.r> |
| Component: | Compare | Assignee: | Tomasz Zarna <tomasz.zarna> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | P3 | CC: | daniel_megert, john.arthorne, kim.moir, Michael.Valenta, Mike_Wilson, philippe_mulet, remy.suen, Szymon.Brandys, webmaster |
| Version: | 3.4 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Markus Keller
It's not just about incoming changes: when I load org.eclipse.compare R3_4 into a fresh workspace I get completely different source as I got at R3_4 freeze time! The incoming changes are in a directory that is ignored by the build. So, while you may end up with additional source files, they should not be picked up by the builder. Are they? If so, it would suggest to me a bug in the builder. I'm only talking about what I see when I or someone else checks out an older release. How can this person know that those files should not be there? Also, I was very scared to see incoming changes in my workspace for a project that I've checked out as a version. First I thought this was a bug of our CVS client. It completely destroys the idea of a SCM if you have to tell people, oh - by the way: those files don't belong to that version. How can we be sure that the state of the other files match R3_4? I have verified that this does cause problems for the Java builder. I have removed the R3_4 tag from the new plug-in. As said before, this is a problem for every tag, not only R3_4. When I check out org.eclipse.releng for a an old build (e.g. R3_1 or I2007mmyy-0800) and then replace the project with the released version from the map file, I don't get the source in the state it used to be back then. The history should not get changed. Yes you do. You get the source in exactly the same state. You happen to get another directory. It happens to contain Java files but they are not included in any builds. I don't see what problem this causes. If you happen to know of a scenario for which this causes problems, please share it. It's just breaks the whole idea of a SCM. Ah, maybe besides having to know that the 'plugin' folder can be ignored, I have to do some editing in a file to get the R3.2 state? How can anybody except you know? Furthermore, the checkout also takes twice the time, because all the source files are checked out twice. This should not become the new way to split up plug-ins. Why can't you just use new top-level directories for the new plug-ins, as for all the other plug-ins we already have? Sorry, I don't understand your scenario. Are you saying you want to get the 3.2 state of a file? You would just compare the file with the R3_2 tag. Or perhaps you meant something else. Regardless, the reason I did it this way is that I did not want to pollute the top level of the Eclipse repository with yet another directory that would exist for all time and org.eclipse.compare was the best name for the component folder. The cost of this is that, on the off chance that someone is working on a previous tag, there may be some confusion as to why there is a plugins directory containing a duplicate version of the plug-in. I think it is highly unlikely that this would occur (i.e. who other than the component team works on version less than N-1 and even the component team rarely does this?) and, if someone did happen to load a previous version (i.e. pre-3.4), I think that they would either not notice the plugins directory at all or figure out that it can just be ignored. To me, the cost seemed small enough to justify using org.eclipse.compare as the component folder. I agree that, in general, this is not the best way to do this but I think in this particular case, it is justifiale for the following reasons: 1) org.eclipse.compare is the ideal name for the Compare component folder 2) With the R3_4 tag removed, people working on 3.4 maintenance will not notice the change 3) It is highly unlikely that anyone other than the component team will load pre 3.4 versions 4) If someone does load a pre-3.4 version, the new plugin is in a folder that is not picked up by the builder. 5) The compare plug-in is small so the additional checkout time is not a concern. >Sorry, I don't understand your scenario.
Mmh. Let's say you tag a file with 'xyz' in it. Then three years later that when you load that version you get 'uvw', do you think that's what an SCM is made for? And that's exactly what your change caused. Maybe not on the file contents level but on the files inside the project. Now, you tell me that this is the only change, but how can I trust the system if it is not able to give me the expected state?
I agree that the scenario you describe would be a problem. However, that is not what would happen. What would happen is that, if for some reason someone loaded the R3_1 version of the org.eclipse.compare plug-in they would get additional files in a plugins folder that are not referenced by anything in R3_1 and hence would be ignored. I agree that this is not ideal. My claim is that it doesn't cause any real problems. I also claim that this is rarely done and when it is done, it is done by the component team so they would know to ignore the directory as well. At this stage, all I can say is that I've made my case and, unless you can come up with a real failure scenario, I am done discussing this. I've copied Szymon and, as the component lead, I'll let him decide whether the current structure is OK or whether we need a new top level plug-in in the repository. In the end, it's a question of consistency and trust in the eclipse.org infrastructure, so I would like to ask the webmaster and the PMC whether they support such tweaks that impede the cleanliness of the eclipse.org repository.
> I also claim that this is rarely done and when it is
> done, it is done by the component team so they would know to ignore the
> directory as well.
I'm sure this also shows up when someone (e.g. an IP team member) tries to compare two versions of the plug-in. And there are always more people who take our code from CVS than you would think ;-)
I have discussed this with McQ. We will create a separate folder for the compare component. The work will be done by the Component team (i.e. Tomek). Tomek, you will need to do the following: 1) Request a new top level folder from the Eclipse webmaster. I'll let you decide the name. 2) Once you have that, you will need to copy org.eclipse.compare/plugins folder to the new top level folder on the server (I can do this if you lack shell access). 3) After verifying that the copy was successful, you will need to update the compare.map to point to the plug-ins in their new location. 4) Finally, you will need to delete the org.eclipse.compare/plugins/org.eclipse.compare folder from the server. Leave the other two since they have been included in a few integration builds already (again, I can do this if you lack shell access). Note that step 3 will make reproducing the I20070716 integration build impossible but I don't think that can be prevented. I'll chime in a humble voice of agreement with Daniel and Markus that an rtag is generally understood to be a 'snapshot in time of the code as it was'. > In the end, it's a question of consistency and trust in the eclipse.org > infrastructure Agreed. When an oddity is discovered, be it in CVS, Bugzilla or email, the integrity of our data is automatically called into question. See bug 213943 and bug 238334 for some recent examples. Thanks for working this out, and for doing what you can to protect the integrity of an rtag. (In reply to comment #14) > 1) Request a new top level folder from the Eclipse webmaster. I'll let you > decide the name. I guess it has to be different from org.eclipse.compare. It was the perfect name for the Compare component folder. Why do you need a top-level folder at all? Did we agree on a general strategy to bundle plug-ins into intermediate folders? Up to now, the world was usually flat inside :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse , and if we really need to change that, it should be clear a) what are the real advantages of this change? b) what naming pattern should be used for all these intermediate folders? Perhaps we should call the root folder "org.eclipse.team" which could be the namespace for all new team component plug-ins. As for why I wanted to do this, here are the advantages I see: 1) We don't have to bug the webmaster for every new plug-in we want to create (I know some people don't mind doing this but I frankly think it is a waste of the webmasters time and adds an unnecessary delay, albeit small due to the quick response time of our webmaster, to the creation of new projects). 2) Both Runtime and Team already have non-root plug-ins. The naming scheme is "plugins" and "fragments" 3) Every other project in Eclipse does it this way. As for the disadvantages, there are none that I can see given that there are already non-root plug-ins and a large number of the root folders in our repo are not plug-ins so no-one outside of our project could really figure out what they needed to load without direction anyway. Webmaster (I assume Denis but other opinions are welcome), I would like to know your opinion on this (i.e. flat vs. component based directory structure). Would you prefer that teams have their own component area in the repository or is a flat structure acceptable (i.e. not too much of a burden). I've copied McQ and John because I think that comment 17 raises a good point. Should we transition to a component based organization in the repository? Or, at least decide to allow Teams that want to to transition to such a structure to do so. I think the answer is that we have already started because, as I indicated in the previous comment, there are cases in Runtime and Team where fragments are embedded in plug-in folders and the eclipse incubator work is happening in its own folder. If the answer is "no", I'm fine with that but it is important to understand that there is a cost associated with that answer (i.e. I as a developer need to make a request to create a top level folder. I need to understand the group structure in Eclipse to get the permissions correct and then the webmaster has to carry out that request). To me, this seems like unnecessary overhead. Again, as I stated in my previous comment, I don't see any real disadvantages to having plugins inside component folders. A component based structure would certainly make the entire project's structure lighter and less intimidating for common civilians like myself who try desperately to find the right source file to submit a patch against but end up giving up. From a technical standpoint, I don't have a preference. As for the burden of asking webmaster to create a plug-in, that is nil. The Eclipse project's setup and process was in place before my existence, so I simply assumed the PMC wished to exert control over what gets created at the top-level of the cvsroot (hence the requirement for a bug and a PL's +1). I've seen cases over the years where this process has been beneficial. But again, between we-do-it and you-do-it, no preference here. (In reply to comment #18) > Perhaps we should call the root folder "org.eclipse.team" which could be the > namespace for all new team component plug-ins. I don't think that compare stuff should be in the same root folder with team plug-ins. I would find a more general name for all team/cvs/compare/proxy plug-ins or create one root folder for each. > > As for why I wanted to do this, here are the advantages I see: > > 1) We don't have to bug the webmaster for every new plug-in we want to create > (I know some people don't mind doing this but I frankly think it is a waste of > the webmasters time and adds an unnecessary delay, albeit small due to the > quick response time of our webmaster, to the creation of new projects). > 2) Both Runtime and Team already have non-root plug-ins. The naming scheme is > "plugins" and "fragments" > 3) Every other project in Eclipse does it this way. I agree with Mike. So far only fragments were put inside the plug-in root folder and I think we can do this in general. ...and I see one more advantage. Some plug-ins could be split into some smaller ones what would help to build smaller RCP apps. And this component based organization would speed up this plug-in splitting process. I hope it makes sense. A big disadvantage for having plug-ins below the root level is that it makes it harder for people to find the source for a given plug-in in the repository. It is not difficult for a committer to learn the layout, but for others in the community it would not be clear that they should have to dig down (or where to start digging) to find something. I would suggest the PMC give some guidelines here to establish consistency and to avoid creating further chaos in the already cluttered eclipse project repository. With well documented and consistent structure it would be somewhat easier for people to find things. If each component or committer does their own thing, it would be messy. I agree with the benefits of non-root level plug-ins, but I'm not sure the component level is the right granularity. Components are not concrete things and may evolve over time. For example "runtime" and "resources" evolved out of an old "core" component, and "IDE" evolved out of the "UI" component. Since we have several components today with <1 active committers, we may want to collapse some together in the future. Many eclipse.org repositories only have *projects* at the root level in CVS, and then further breakdown into components and plug-ins below that. The advantage of having components below the root level is that they can be removed/split/combined in the future without cluttering the top level of the repository. > It
>is not difficult for a committer to learn the layout, but for others in the
>community it would not be clear that they should have to dig down (or where to
>start digging) to find something.
Note that CVS modules can help here, like e.g. platform-text for example.
Also, I'm not against (or pushing for) the nesting of components in the repository in this bug. What I request is to fix the broken repository history that happened by tweaking the repository directly on the CVS server.
This got fixed long time ago. |