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.
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
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
|
