Peter - this is greatly appreciated. We do have some company (strategy)
meetings this coming week and I will make this a topic. There is
certainly a great deal of benefit from having an architecture in which
some of our components are open source, or at least visible to a
different set of people than the whole code base. I'll keep you guys posted.
Thanks
Holger
On 7/11/2012 13:26, Peter Ansell wrote:
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
-- 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
