[TYPO3-v4] Git submodules or not?

[Oliver Hader]

Hi Ernesto,

thanks for summarizing that up and following the dicsussion on that.
Indeed it showed that submodule have some benefits (that's why we have
them, I guess... ;-)

However, and as everywhere else, there are a few conditions to have
things setup correctly. Since I'm not a Windows user maybe somebody of
"that" group can give some advices on best-practices on Windows system.
If you need any help or feedback, please get back to me.

Concerning ChangeLog:
Yes we can do this. We could also create separate parts for each
release, e.g.

Core
====
abcdef	[BUGFIX] Something here
...

Workspaces
==========
bcdefa	[BUGFIX] Something there
...

Or otherwise the external projects are just mentioned the same way all
issues are. Concerning the "raise submodule pointer" commits, I could
split them up for each submodule, thus it would be (if there have been
changes of course):

[TASK] Raise dbal submodule pointer
[TASK] Raise extbase submodule pointer
[TASK] Raise <module-name> submodule pointer

Cheers,
Olly


Am 30.08.11 11:09, schrieb Ernesto Baschny [cron IT]:
> Hi,
> 
> thanks for the valuable feedback. So it seems that most developers are
> fine with the submodules, considering these conditions:
> 
> 1) no new submodules are created on existing branches
> 
> 2) you get no trouble if you use the "multiple branch setup" (one
> directory per release), so you don't switch to different release
> branches within one working copy
> 
> So considering this, remains only:
> 
> - document better the multiple branch setup, and add a hint or two for
> Windows users (so that they simply clone the source multiple times,
> instead of doing the symlinking stuff, as disk-space is cheap anyway).
> 
> - I would also like to see a more detailed view of "what has changed" in
> the submodules in our main ChangeLog. This is nothing new, we have had
> this problem with SVN too: We have for example "dc3c35e [TASK] Raise
> submodule pointer" in the 4.5 ChangeLog which doesn't even say which
> submodule (it's dbal) and also not what was changed of fixed by this
> "raising". Maybe Olly could include this information in the ChangeLog
> generation script? In this case, it would be:
> 
> 93b6a39 [BUGFIX] Incorrect handler detected with DELETE, INSERT and UPDATE
> 
> Other than that, I close my RFC about the submodules issue. Thanks!
> 
> Cheers,
> Ernesto
> 
> Ernesto Baschny [cron IT] schrieb am 22.08.2011 09:45:
>> Hi,
>>
>> I'd like to re-open a discussion which we hold some months back, where
>> the Core Team decided to go for "submodules" when including external
>> team projects into the core (i.e Workspaces, DBAL, Linkvalidator, etc).
>>
>> While it has proven to work, and Olly has made a great job in keeping
>> all things linked together (thanks!!!) I rather feel that the submodules
>> are the only one big pain in the a** for all kinds of troubles the
>> developers are having with our GIT repository: Be it when switching
>> branches, even when switching their local branches, or when suddenly
>> having to cope with "untracked modified files", etc.
>>
>> Before introducing them, Olly made a list of advantages / disadvantages
>> for the two methods we have at our disposal:
>>
>> 1) Subtree merge
>>  - there will be one big commit to the Core repository containing
>>    all changes since the last merge
>>  - development currently happens in local extensions in typo3conf/ext/
>>  + by just checking out the Core repository one has everything she
>>    needs (not further requirement of initializing something)
>>
>> 2) Submodules
>>  - additional initializations and updates to the submodules are required
>>    (if not doing this, the Core source will be incomplete)
>>  - additional documentation is required for init, update, commit hooks
>>  + makes the life for developers a bit easier since the just work with
>>    one source directory and git takes care to put the things to the
>>    accordant repositories and branches there
>>
>> The bottom line was that Git is "for developers" and they should be able
>> to handle the additional overhead that Submodules might cause.
>>
>> After three months of experience gained, I tend to rethink about it, and
>> consider moving back to Subtree merging after the release of 4.6.0 (and
>> branching 4.6) which would avoid most of the trouble for the "regular
>> developer" (which is not even interested in developing in one of the
>> external projects), but put a bit more overhead for the project leaders
>> (or maybe on the Release Managers / Team Leader) - at least while we
>> cannot automate the merges into the core.
>>
>> What do you think?
>>
>> Cheers,
>> Ernesto
> 


-- 
Oliver Hader
TYPO3 v4 Core Team Leader

TYPO3 .... inspiring people to share!
Get involved: http://typo3.org