Community
Participate
Working Groups
With our move to git our 3.6.x and 3.7.0 Eclipse-SourceReferences headers won't be valid for much longer (after a year the EF has said they'll tar up CVS). I think that one of the ways we could deal with this is to allow a plugin to provide mappings for source references (via extension point and/or provider of some kind). Then we could build that into the SDK in 3.8/4.2 PW
One other reason this may be needed is for 3.7.1 builds from git. If we use a git scm for all the bundles in Indigo SR1 then technically the content could be viewed as changed. I don't think we want to force a retagging of every bundle to change the qualifier simply to pickup the new git scm for Eclipse-SourceReferences header.
PDE UI currently just passes the scmurl to a Team API to import. cc'ing Tomasz for Team input.
*** Bug 349466 has been marked as a duplicate of this bug. ***
Moving to TEAM as the bundle importers for CVS are provided by them. PDE can find cycles to assist. What we really need is to have eGit develop a bundle importer that we could use and extend (bug 327381).
(In reply to comment #0) > one of the ways we could deal with this is to allow a plugin to > provide mappings for source references By this you mean mapping from current source references (pointing to CVS repos) to their new locations in git repos? Do we really need an extension here? Correct me if I'm wrong, but at first I thought we need to address only two cases here: repos moved from CVS and SVN. Or do we want to have covered future scenarios when a git repo is moved to a different, git location? Is this the rationale for the extension? (In reply to comment #1) > I don't think we want to force a retagging of every bundle > to change the qualifier simply to pickup the new git scm for > Eclipse-SourceReferences header. Thomas could you elaborate of that? I'm afraid I'm not following. (In reply to comment #4) > What we really need is to have eGit develop a bundle > importer that we could use and extend (bug 327381). A git bundle importer that could consume not only git SCM Urls but also Urls for CVS ? Is that on your mind?
I would expect PDE to pass the correct scmurl to the Team API. So if any mapping is going to happen, it should be done by PDE and this is where we should have the ext. point. AFAIK Git does not keep any special data that could help to map cvs urls to git urls what could justify having the mapping in the team provider.
(In reply to comment #5) > (In reply to comment #0) > > one of the ways we could deal with this is to allow a plugin to > > provide mappings for source references > > By this you mean mapping from current source references (pointing to CVS repos) > to their new locations in git repos? > > Do we really need an extension here? Correct me if I'm wrong, but at first I > thought we need to address only two cases here: repos moved from CVS and SVN. > Or do we want to have covered future scenarios when a git repo is moved to a > different, git location? Is this the rationale for the extension? This is about mapping our existing Eclipse-SourceReference headers that point to the old CVS repos (e.g. from 3.6.x and 3.7.0). Once the foundation decides to close the CVS server down these bundles will no longer have functioning Eclipse-SourceReference headers. Paul's idea is to have some way to map these old headers so that we can find the equivalent git SCM URIs. And then pull in the source from there instead. > > (In reply to comment #1) > > I don't think we want to force a retagging of every bundle > > to change the qualifier simply to pickup the new git scm for > > Eclipse-SourceReferences header. > > Thomas could you elaborate of that? I'm afraid I'm not following. I was worried that during our builds for 3.7.1, where we have migrated the maps to use the new git repos, would end up with a built bundle with the same name/version/qualifier as a bundle from 3.7.0 but the Eclipse-SourceReference header would have changed from CVS to GIT. As it turns out this is not a concern because during the build the comparator is run and detects that the newly built bundle has the same name/version/qualifier as the bundle from 3.7.0 and discards the newly built bundle altogether. So for bundles that have not changed since 3.7.0 they will continue to have the same CVS Eclipse-SourceReference header as they did in 3.7.0. But for any bundles that have changed in 3.7.1 they will have a new GIT Eclipse-SourceReference header.
(In reply to comment #6) > I would expect PDE to pass the correct scmurl to the Team API. So if any > mapping is going to happen, it should be done by PDE and this is where we > should have the ext. point. > > AFAIK Git does not keep any special data that could help to map cvs urls to git > urls what could justify having the mapping in the team provider. It does sound like PDE is the proper place to translate between the scmurls. Though I don't know what information PDE has to do the translation either.
(In reply to comment #6) > I would expect PDE to pass the correct scmurl to the Team API. If Team has API that accepts SCMURLs, then to me that's the place to also put the translation. It doesn't matter where the old CVS URLs are coming from, only that they're invalid and we need to translate them. There's no PDE dependency on translating one SCMURL to another, is there? PW
We do not plan to work on this item. If one wants to help and contribute a fix, it would e welcome.
Move to git happened decade ago so any mapping to cvs is pointless now.
