Community
Participate
Working Groups
Would be perfect if .psfs would support git urls like: git://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git ssh://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git http://git.eclipse.org/gitroot/ecf/org.eclipse.ecf.git Thanks Markus
I agree, but in order to do so, EGit will need to provide an object to serialize and deserialize references to projects in the first place. This job is done by a concrete subclass of ProjectSetCapability, which Team/UI obtains by calling org.eclipse.team.core.RepositoryProviderType.getProjectSetCapability(). To make this happen EGit guys will have to provide "typeClass" in their "org.eclipse.team.core.repository" extension. Moving to EGit, but feel free to ping me in case of any questions.
(In reply to comment #1) > I agree, but in order to do so, EGit will need to provide an object to How will this work practically? Say that the psf file contains 5 projects scattered over multiple repositories. First git needs to pull down each individual repository and then auto import the projects into the workspace? psf files are very handy for the occasional user who wants to pull in some code to examine. This is used very frequently and hides the user from creating a repository and checking out the project manually. The ability to check out a single project from a repository is a magnificent teaming feature and I hope this can be realized somehow.
Well, the API you need to implement is pretty simple: when exporting you'll get an array of IProjects for which you need to return an UTF-8 encoded String (for each project)[1]. The format of the String is up to you, it's provider specific. Just remember that when importing you will need to consume an array of such Strings and load the corresponding projects[2]. [1] org.eclipse.team.core.ProjectSetCapability.asReference(IProject[], ProjectSetSerializationContext, IProgressMonitor) [2] org.eclipse.team.core.ProjectSetCapability.addToWorkspace(String[], ProjectSetSerializationContext, IProgressMonitor)
(In reply to comment #3) It is the git side of things I am worried about. Henrik pointed out in the git mailing list that buckminster has support for git. I think he means that buckminster is able to get a single project from a repository and import that as a project. It won't be shared then as it will with a regular psf. Maybe with buckminster we can create an action that operates on a .bpsf file that gets projects from repositories but does not share them. The .bpsf file will have the same structure as psf files only it uses buckminster only. <adding henrik>
(In reply to comment #4) > > It is the git side of things I am worried about. Henrik pointed out in the git > mailing list that buckminster has support for git. I think he means that > buckminster is able to get a single project from a repository and import that > as a project. It won't be shared then as it will with a regular psf. If you want the project to be shared in your workspace, you will need the git metadata contained in the .git/ folder somewhere. Since there seems to be no way around a complete .git/ folder ATM [0], I guess a viable workaround is to just use the right granularity for your repo. E.g. if you take the one bundle per repo approach. I'm even inclined to argue that people want the SCM metadata if they use a .psf file, since they want to work with the code base (which usually involves operating the SCM too). Otherwise they would use a binary version of the bundle. > Maybe with buckminster we can create an action that operates on a .bpsf file > that gets projects from repositories but does not share them. > > The .bpsf file will have the same structure as psf files only it uses > buckminster only. Let's not create even more redundancy with yet another file. We have .map files, .psfs and Buckminster's cqueries. IMO a .bpsf won't solve anything but cause more problems. [0] http://www.spinics.net/lists/git/msg136221.html
*** This bug has been marked as a duplicate of bug 296082 ***
