[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] git migration for ECF
|
Hi Markus,
I have pending changes and additions that have not yet been committed to
the CVS repo...so I think it's a little early to be freezing the CVS
repo access. If this is just for testing...how long will the testing
period last?
When we do the final changeover, we'll need to give some advance warning
(i.e. days) via this list.
Some additional comments inline below
Markus Alexander Kuppe wrote:
Hi,
for testing, I've imported the ECF CVS repo to git [0]. Please do
_not_!!! write to this repository. Your changes will definitely be lost.
Currently the repo is a 1:1 copy of the original CVS repo. But I would
like to start a discuss if we want to:
a) purge old/outdated branches (e.g. everything that is not Release_*,
maint_*, master)?
This is probably ok...although there may be some branches created by
other committers (for non-releng purposes) that they might want to maintain.
b) restructure the repo into smaller parts/repo:
0. Leave it as it is
- To coarse grained
- folders are artificial (e.g. what is compendium/)
The compendium module contains that ECF impl of OSGi remote services
(which is part of OSGi compendium). I'm not married to this
organization, but loosely speaking it is how Equinox also structures
things (they separate standards parts impl so that it's clear what's
from core spec, what's from compendium, etc).
- framework/ contains a lot of non framework bundles
+ less work
1. Create a repo for each top level folder in org.eclipse.ecf/
- see 0.
2. Group functionality/feature sets into separate/distinct repos (e.g. a
discovery, remoteservice, presence, filetransfer, telephony, collab...
- providers are used by different feature sets
+ best compromise between maintainability and flexibility
+ well adopted (ecf-nonepl, other projects)
+ best reflects the areas of work
3. One repo per bundle/feature and execisvely use submodules to structure
- git submodule not yet supported by egit
o creating a bundle/features means creating a new repo
+ best flexibility
Personally I'm leaning towards 2. as the best solution of both
directions. Although for my GSoC project I have taken the one bundle per
repo attempt (3.) and am quite happy with it. Basically the git
supermodule can be aligned with the corresponding Eclipse features. It
even targets a specific version (e.g. feature A references bundle B in
rev 1, while feature A references bundle B rev 2). However Eclipse
tooling is definitely not up to the task (yet). One has to use cmd line
clients.
Although I think that 2 makes some sense, it might result in a large
number of separate modules...i.e. a very 'flat' structure...with many
directories (i.e. one for each ECF api results in quite a few now).
This can/could be seen by others (particularly those unfamiliar with the
project) as a complex structure...and therefore less
approachable/understandable.
I don't know what the 'optimal' organization is...I'm just pointing out
the trade-offs...i.e. more granularity (many directories at top level)
can/could mean more perceived complexity...and I would like to keep
things as approachable/understandable/simple as possible...both for
those that know/are familiar with the API structure (i.e. existing
committers) as well as others (contributors, community members,
consumers, others).
Scott
