The Eclipse Che project spans 6 or 7 repositories now. We do it for a couple reasons: 1. Dependency management for assemblies that combine many pieces together 2. Size management for git cloning operations. Specifically our customizations to Tomcat and our documentation are sizable. 3. Components that are part of the product, but release on a different cycle than the product. For example, Che has a library of stacks which are Dockerfiles compiled into images and pushed onto DockerHub in an eclipse organization. These stacks are referenced by and loaded by Che, but we version and release them on a different timetable.
Tyler Tyler Jewell // CEO // tyler@codenvy.com // 978.884.5355 On Wed, Apr 19, 2017 at 4:07 AM, Ed Willink <[email protected]> wrote: > Hi > > I don't think distinct technologies is a justification for distinct > repositories, however: > > When my projects moved to GIT, I wondered whether one large repo per > project was a good idea, or whether modules would improve performance. At > that time there was a strong recommendation for a single repository. A few > years later I see the time to clone an ever increasing GIT repo as > unwelcome and notice that some projects such as Xtext seem to be > refactoring. I suspect that multiple modules would be a good idea, but do > not have time/inclination to reorganise my own repos. Arguably CVS had each > file as a distinct module and so communication was much smaller. > > Regards > > Ed Willink > On 19/04/2017 09:15, Rémi Druilhe wrote: > > Hello, > > We received the first commiters status on the newly created sensiNact > project. We sh=ould soon provide the initial contribution for IP review. We > just had a small meeting with the team and we have some questions. > > Our project is mainly composed of, at least, 2 larges subprojects, i.e., a > client and a server. Thus, we would like to know what is the better way to > proceed for the IP review. Should we submit the two subprojects or should > we do it incrementally (the server and then the client). I know there is > the parallel IP process > <https://wiki.eclipse.org/Development_Resources/HOWTO/Parallel_IP_Process> > we could ask for but I don't know if this is relevant for this case. > > To accelerate the IP review, we are not going to submit all the modules in > the initial contribution. It will also let us put in the right format our > existing code and still start the IP review process. Is a new module (or in > the future a new feature) must always be sent for IP review? According to > the Eclipse Legal Process > <https://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf>, we could > just submit a minimal set of code of the project (initial commit on page 2) > and then commit everything else using the normal process (page 1, Figure 1). > > And the last question. We have at least 2 subprojects. We saw that it is > possible to create new repositories (cf. https://wiki.eclipse.org/Git#C > reating_a_new_repository). Can we ask for others repositories to host > subprojects (e.g., the client, the server, etc.)? It will ease the project > management because we are not using the same technologies on the > subprojects. Or should we request for a new Eclipse project in order to > have a separated GIT repository? > > Thanks, > > Best regards. > -- > Rémi DRUILHE > Phone: +33 (0) 6 87 17 93 77 <+33%206%2087%2017%2093%2077> > > > _______________________________________________ > incubation mailing [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://dev.eclipse.org/mailman/listinfo/incubation > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_3427375925841205274_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > >
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
