On 11 July 2012 12:26, Holger Knublauch <[email protected]> wrote: > On 7/11/2012 12:15, Peter Ansell wrote: >> >> To extract the full history for the spin-api folder to a new repository >> you can use this guide that I have used successfully before [1]. Once you >> have extracted the tree to a new repository you can put it back into the >> original git repository as a submodule [2], which works roughly the same way >> as svn externals work if you are familiar with those. Cheers, Peter [1] >> https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo [2] >> http://git-scm.com/book/en/Git-Tools-Submodules > > > This is interesting. While I haven't spoken to my co-workers yet my gut > feeling is that such a solution (of having the public repository a > sub-module of TopBraid Suite code) is not "politically" feasible. I believe > a good first step would be a solution in which I copy over changes back and > forth between two otherwise independent repositories. Does either one of you > have experience with that? How would I need to set this up to map a > sub-folder of TopBraid-Suite with the top-level folder of SPIN-API? >
If you wanted to map a subfolder to the top level folder of an independent SPIN-API repository the main thing you would need to check is that the maven modules would function (unless you are not using maven modules internally, in which case they would not be functional or present inside of the TopBraid-Suite repository and would not matter). In order to make SPIN-API work in its current multi-module maven form, it either needs to contain a top level pom.xml file (with no parent), or it needs to reference a public pom.xml file as its parent. I suspect that there would not be a public top level pom.xml file available, so the most likely option there is the first one I am guessing. I haven't had any experience with manually mapping changes between git repositories that use different subdirectory structures, other than using submodules. If you absolutely needed to, you could try a "cp -r" method from the TopBraid-Suite repository out to the SPIN-API repository and delete any files that need to be deleted manually. Then you could commit to the SPIN-API repository and push those changes to a fork of spin-api on GitHub and the others can suck them into their own repositories as necessary. The subpath method is only designed to be performed once as far as I can tell, as it does a lot of work trying to split up commits and rehashing them to get a clean new history. It would be expected that you would use a submodule after splitting the subpath out into its own repository. It may still be acceptable to use a submodule due to the particular way they work. A submodule inside of the TopBraid-Suite repository would link to a particular commit sha1 reference, and that commit would come from a private repository that you pull changes into from the public repository after checking that the changes are acceptable. There would likely be a public code review, using a GitHub Pull Request for instance, before changes get into the public repository from contributors forks. Even without an explicit public code review, any developments that are accepted into the public repository would be effectively staged before having an effect on the private repository as you would need to manually pull the changes and then update the submodule reference. If you design it that way, there should be no automatic link between a change accepted to the public repository and your commercial products. The submodule link contains both a repository URL, which could be private, and a sha1 reference, which could also not actually exist in the public repository if you always merge the public branch with the curated private branch using "git merge --no-ff". In addition, if you want to test out the effect of a SPIN-API update you could create a temporary branch inside of the TopBraid-Suite repository and then update the submodule reference on that branch to check whether the tests all still pass, as the submodule reference is local to branches. If you needed to selectively push changes back to the public repository from the private repository you could use "git cherry-pick" to avoid having to merge the private history out to the public repository if there were intermediate commits that were not yet ready to be publicised. If you wanted to set this up on GitHub I would suggest making the private repository a fork of a public spin-api repository, so that the private repository would then be configured by default to perform pull requests on the public repository (since Pull Requests can go both ways, not just into the parent fork). The private fork may be inside the TopQuadrant organisation and the public master repository may be inside a new spin-api organisation, if you wanted to ensure that the public and private repositories were sufficiently different so they would not be easily confused by someone working with the TopBraid-Suite repository. That may still be unacceptable, possibly due to its complexity, but it is definitely easier to manage using git and github then it ever has been in the past. In the end I think it is important to have this code open to the world to support the SPIN standardisation process, but it could be done in many different ways. Cheers, Peter -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
