Simon,
You do realize that in Subversion you can just checkout a given
subproject, create a patch against it, then delete it, right?
-> richard
On 10/27/15 15:52 , Simon Chemouil wrote:
Benson Margulies wrote:
There was some discussion a while back about git, which I recall
(perhaps inaccurately) as vaguely positive. It's a lot easier if each
releasable thing gets its own git repo.
Hi,
At this point it looks like the switch is going to happen, and there has
been this argument repeated a few times that the current situation with
SVN is not broken and that changing will imply significant pain.
It's most likely true :).
However as a user of Felix and its sub-projects, I'd like to state that
this switch would be very welcome and ease working with Felix and
contributing patches a lot.
First, the Felix SVN repo is humongous and mixes so many sub-projects
that it's a pain to navigate through it to get the right ones, the right
branch, the right commit.
Second, there's the problem of hassle-free contribution: when I
encounter an issue, I just want to just fork a sub-project, and create a
pull request and the associated JIRA ticket, and go back to my routine.
But forking the whole felix project just for a single a component is a
big overhead, and last time I tried the Felix Git repo on GitHub did not
look up-to-date. It might not look like it because you guys have your
environments set up and you spent enough time to do so, but that is an
artificial entry barrier to contribution (not because it's difficult,
but because it's so heavy compared to the Git workflow we got used to).
So while this switch might not go as smoothly as hoped, it will also
benefit users and I believe will help the Felix project get
contributors, new committers and even maybe new sub-projects, as long as
there is no new overhead introduced by the way the switch is made :-)
In my experience having one repo per bundle results in the opposite
overhead (having too many repos to clone, update, etc), and I think
having one repo per sub-project is the right compromise. That's also
we've been doing at work for a while (we had one repo per bundle before
for a long time).
Finally, it would be great not to bump versions for bundles that have
not changed just to avoid having several releases prefixes handled by
the maven-release-plugin within the same repository. So I am not
favourable to systematically making all bundles in a sub-project part of
the same multi-module Maven project (and thus share bundle version by
default) for that reason alone.
Although proper package semantic versioning would make this transparent
at runtime (or 'install' time), it makes it impossible to track releases
and the evolution of the different bundles, and generally feels against
OSGi principles' of proper modules and versions.
A big non-binding +1 from me. :)
