[git] Nebula plans of moving to git

[Wim Jongman]

Hi Guys,

Nebula plans to move to git. Since there are a number of widgets and each
is owned by a single committer, I was thinking to make a repository for
each widget. Does this make sense?

Would that also mean that if someone would want to have all 20 widgets that
he would be getting RSI and sleep deprivation because he would have to make
so many repos in egit?

Could this be fixed by providing a project set file for all the
repositories?

Thanks for the help, I have more questions but I will RTFW(eb) first.

Regards,

Wim

[Mickael Istria]

Post by Wim Jongman
Hi Guys,

Hi Wim,

Post by Wim Jongman
Nebula plans to move to git. Since there are a number of widgets and
each is owned by a single committer, I was thinking to make a
repository for each widget. Does this make sense?

As a side-effect, I think that will lead to having one build for each
widget. I don't think this is only relevant for git repository: each
widget is slowly becoming a project (= contributors + roadmap), that's
probably something more structural about the Nebula project itself.
IMHO, a good strategy would be to first move the whole Nebula to Git
(does not require more than opening a bug to webmaster asking them to
perform migration + updating links to SCM on website, wiki and so on);
and then to start discussing about how to structure the Nebula project
and components. Git repo and builds will be the consequence of that
structural choice.

Regards,

[Wim Jongman]

Hi Mickael

Post by Wim Jongman
repository for each widget. Does this make sense?
As a side-effect, I think that will lead to having one build for each
widget. I don't think

You mean Hudson has a problem aggregating and building several git
repositories in one build?

I wanted to ask this list for best practices. I have been reading that the
best practice is to use different git repositories to combine related
projects or even use a single repository for each plugin.



Regards,

Wim

[Mickael Istria]

Post by Wim Jongman
Hi Mickael

Post by Wim Jongman
repository for each widget. Does this make sense?

As a side-effect, I think that will lead to having one build for
each widget. I don't think
You mean Hudson has a problem aggregating and building several git
repositories in one build?

No, I don't think there is a big problem, but I'm concerned about the
difficulty to set up and use one (Tycho) build and one (Hudson) job from
several Git repositories.
But my remark is indeed more related to the build system rather than the
SCM. So that's out of topic on this mailing-list!

Sorry for the noise.

[Wim Jongman]

Post by Wim Jongman
repository for each widget. Does this make sense?

Post by Mickael Istria
As a side-effect, I think that will lead to having one build for each
widget. I don't think

You mean Hudson has a problem aggregating and building several git
repositories in one build?
No, I don't think there is a big problem, but I'm concerned about the
difficulty to set up and use one (Tycho) build and one (Hudson) job from
several Git repositories.

I don't think that is off-topic. It could indeed lead to a difficult setup
in Hudson. Especially regarding listening for changes in the repositories.

So this votes against multiple repositories (if assumption is true).

[John Arthorne]

Post by Wim Jongman
I wanted to ask this list for best practices. I have been reading
that the best practice is to use different git repositories to
combine related projects or even use a single repository for each

plugin.

My experience has been that minimizing the number of repositories is best.
Each repository you need to work with adds the overhead of doing
push/pull/fetches, configuring properties, creating branches and tags,
etc. This affects committers, consumers, and adopters. For example if I
want to grab a couple of widgets from Nebula, creating and managing two
clones to do that is a pain. Also if you ever need to commit a change that
spans multiple repositories, you have lost ability to track that change as
a single commit, making it difficult to revert, cherry pick, etc. I don't
know Nebula very well, but I would suggest starting with a single Git
repository for all of Nebula, and only break it up if absolutely
necessary. Another project similar to yours would be Linux Tools, which is
compromised of several mostly autonomous components. They have used a
single Git repository for the whole project and it seems to be working
well. I would only considering breaking up a repository if it becomes
physically too large to manage, or requires different committer
permissions for different parts of the project.

John

[Andrew Overholt]

Post by John Arthorne
I would only considering breaking up a repository if it becomes
physically too large to manage, or requires different committer
permissions for different parts of the project.

+1. And yes, things are working out quite well in Linux Tools (and will
be even better in the future as we align the components more).

Andrew

[Wim Jongman]

Thanks guys for the reactions. I will advise our committers the single repo and I will also checkout the Linux Tools repo for some inspiration on structure.

Sent from my iPhone

Post by Andrew Overholt

Post by John Arthorne
I would only considering breaking up a repository if it becomes
physically too large to manage, or requires different committer
permissions for different parts of the project.

+1. And yes, things are working out quite well in Linux Tools (and will
be even better in the future as we align the components more).
Andrew
_______________________________________________
git mailing list
http://dev.eclipse.org/mailman/listinfo/git