Re: [mantisbt-dev] Removal of Submodules

[Paul R. <pa...@ma...>]

Following up on this,

1) I notice that the tagged git exports on github are no longer complete
and are missing files for the 1.2.17 release. For previous releases they
are complete. We need to get this fixed so a export includes all the files.

2) There's a fairly detailed post of some of the issues of submodules from
May last year @
http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/

3) There's been some commits recently for submodules that do not show up in
Mantis History and have not been included in the Diff's sent. As such, it's
not possible to review these changes.

There is documentation online to remerge changes in submodules back into
the main repository which would allow us to implement option B from the
original list of options:

b) Go back to having everything in a single repository so it's easy to diff
changes between two git revisions - and not having to work out seperately
if a submodule might have changed

Unless someone can come up with a better idea, I'll work on submitting a
pull request to implement this option.


On Tue, Feb 4, 2014 at 4:13 PM, Paul Richards <pa...@ma...> wrote:

> Since starting to add sub-modules previously we said we'd review.
>
> From what I can tell there are a number of points where submodules break
> functionality - for example the github download tarballs.
>
> In addition, I've found that client support for submodules is lacking -
> it's actually harder to do a diff of changes between releases where some of
> those changes are now in seperate repositories.
>
> I'd like to propose that we either remove submodules so that our
> repository shows history correctly, or we set up a second repository that
> mirrors the first without the submodule support.
>
> I don't mind which option we choose, but it's not possible to easily track
> changes that happen to submodules when viewing git history.
>
> In addition, the code that we have added to version 1.3 checks to check
> file versions are correct now breaks because not all the files within
> mantis are in the same repository.
>
> I don't mind us having two repositories, that we sync changes between -
> one with submodules and one without, but having tried to work around
> finding data I used to be able to find at a glance, it's not actually
> saving us any time of hassle by using submodules to what we were doing
> before.
>
> I know when we originally started talking about sub modules some users of
> mantis jumped in with them being annoying, and have we considered looking
> at things like 'composer' - and I think I've concluded that they are indeed
> annoying over the past few months.
>
> I see 3 options moving forwards:
>
> a) take a serious look at using the public modules/classes available via
> composer instead of keeping them in our repository at all
>
> b) Go back to having everything in a single repository so it's easy to
> diff changes between two git revisions - and not having to work out
> seperately if a submodule might have changed
>
> c) Have a copy of the mantis repository that is a single repostory, and is
> built from the repository containing submodules such that this can be used
> and developed against to make it easier to view history/compare versions -
> and allows people to get a working git tarball at any time easily - whilst
> allowing people to have a split repository containing the submodules if
> they so choose.
>
> Paul
>
>
>