[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cf-dev] Merging Californium repos
|
Committers,
I want to start with the merging into the top level repo following the approach outlined in this blog post [1]:
1) create a "unification" branch in the californium repo
2) create "element-connector" folder in californium.element-connector repo and "git mv" all content to that new folder
3) create "core" folder in californium.core repo and "git mv" all content to that new folder
4) create "scandium" folder in californium.scandium repo and "git mv" all content to that new folder
5) create remotes for "element-connector", "core" and "scandium" in californium repo and fetch all
6) merge "element-connector/master", "core/master" and "scandium/master" into "californium/unification" (having moved everything to subfolders first should now prevent lots of merge conflicts)
6) fix pom files etc and do a test build
7) commit & push "californium/unification"
8) Have you guys take a look and check if this is what we want
9) merge "californium/unification" into "californium/master"
We will end up with three separately originating commit histories (for the three modules) flowing into californium/master.
What do you think?
[1] http://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/
Kai
-------------------------------
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Thursday, January 14, 2016 4:55 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Branching strategy
To keep commit history, rebase should work, but this could be tricky if we currently have several branches in each project.
Le 14/01/2016 16:42, Kovatsch Matthias a écrit :
We also put effort into setting up multiple repositories. Hence, I want to be sure a single repo is what we want :)
The original structure was beneficial when I had multiple students with multiple theses working on Californium. Now, with an established team and better processes, I totally buy that we can still maintain multiple focus areas in the code. A big share of the effort so far actually went into the distributed POM definition and artifacts, which we probably can continue using almost unchanged. And I read your messages more or less as +1s for having a single repo.
For now, we could keep tools and actinium separate and break the version linking.
Again, first let's release 1.0.1 and then do the refactoring. I would create a "unification" branch in the parent repo ("californium"), add the complete code base there, and do the POM adjustments.
I wondered the same: Can we somehow keep and merge the current commit logs? My guess would be to use rebase to chain all commits from the different repos.
Should we proceed like this?
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Simon Bernard
Sent: Donnerstag, 14. Januar 2016 16:23
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] Branching strategy
I mainly agree with Kai.
If projects have same release/life cycle, this probably make sense to regroup it. I don't see any problem for element-connector, core and scandium. For actinium and tools, it's hard to say for me as I don't really know those projects.
About commit logs visibility, if we avoid merge and use rebase (interactive), we can have a readable repository.
What about current history if we merge repository ?
Simon
Le 13/01/2016 18:31, Hudalla Kai (INST/ESY) a écrit :
Having multiple repositories has required a lot of effort to maintain consistent versioning and build process. I think we could still have clearly distinguishable discussions around issues and PRs, e.g. by using appropriate tags for the individual modules. Regarding the separate commit logs, I do not really see the big advantage of that. On the other hand, having a single repository (and build) would make it easier to detect problems/incompatibilities/API breaks changes in one module introduce in other modules. We could still produce multiple artifacts but I think overall management of the code base would be much easier if we only had one code repository. We could also still have different committers have different "focus" areas in the code base based on the sub-modules (e.g. core, element-connector, scandium etc).
However, if we stick with the different repos we should definitely use the same branching strategy for all of them, otherwise I think we will have a hard time maintaining consistency between them.
Kai
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Kovatsch Matthias
Sent: Wednesday, January 13, 2016 5:07 PM
To: Californium (Cf) developer discussions
Subject: Re: [cf-dev] Branching strategy
Do you mean having everything from element-connector to Actinium in a single repo?
I see the point of reducing the maintenance effort. However, it would also convolute the development tracks. I found it actually quite nice that Scandium has had its own track, with separate DTLS-specific issues, discussions, etc. (also commit logs). Also forking out the Actinium development as we did over the last months was quite convenient (I still have to merge it back into the Eclipse repo).
Simon, Kai, how do you feel about this from the Scandium perspective?
Ciao
Matthias
From: cf-dev-bounces@xxxxxxxxxxx [mailto:cf-dev-bounces@xxxxxxxxxxx] On Behalf Of Julien Vermillard
Sent: Mittwoch, 13. Januar 2016 16:48
To: Californium (Cf) developer discussions <cf-dev@xxxxxxxxxxx>
Subject: Re: [cf-dev] Branching strategy
Since all the project are released on the same life-cycle, why not first merging everything in the same git repo?
I would make having 3 branches more sustainable.
Julien
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
