Re: [ecf-dev] git migration for ECF

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

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)?

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


Markus

[0] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git