Projects/MoveToGit/Layout: Difference between revisions

    From KDE TechBase
    m (formatting)
    Line 4: Line 4:
    *each extragear application is one repository.
    *each extragear application is one repository.
    *kdereview and playground are implemented with individual repos and/or branches?
    *kdereview and playground are implemented with individual repos and/or branches?
    *tarballs??
    *tarballs stay the same as it is now


    split:
    split:
    *each SC application is one repository.
    *each SC application is one repository.
    *kdelibs and pimlibs are one repo each. kdebase is split how?
    *kdelibs and pimlibs are one repo each. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
    *extragear and review/playground as above.
    *extragear and review/playground as above.
    *tarballs??
    *tarballs stay the same as it is now


    ==Comparison==
    ==Comparison==

    Revision as of 21:49, 8 September 2010

    Definitions

    modules:

    • each SC module is one repository.
    • each extragear application is one repository.
    • kdereview and playground are implemented with individual repos and/or branches?
    • tarballs stay the same as it is now

    split:

    • each SC application is one repository.
    • kdelibs and pimlibs are one repo each. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
    • extragear and review/playground as above.
    • tarballs stay the same as it is now

    Comparison

    Pros for each option (cons are rephrased as a pro for the other one) Note: no mention of the magnitude of each point has been made yet.

    svn2git

    modules:

    • some work has already been done on creating module repos
    • moves within modules can be ignored

    split:

    Reviewboard

    modules:

    • less projects to choose from when submitting a patch? [web only, not an issue with post-review]
    • no namespacing issue

    split:

    • if something moves to another module, no changes are needed

    comments:

    • the reviewer groups won't be affected

    Redmine

    modules:

    • no namespacing issue

    split:

    • source code links are automatically available on each applicaton page, instead of the module page

    gitolite

    modules:

    • no namespacing issue

    split:

    • easier to find projects

    git

    modules:

    • projects can keep their interdependencies, module-wide libraries and so on
    • less server space

    split:

    • moving a project (eg. to unmaintained) moves its whole history

    user workflow

    modules:

    • keeps a sense of community by having a whole module kept together
    • increases passive testing of trunk (more people to notice if the build's broken)
    • lower barrier to hacking on other projects in the module
    • easier to refactor a module [rare]
    • less downloading & disk space for those who want entire modules

    split:

    • less downloading & disk space for people who only want a small part of a module
    • easier to get started on one little app?
    • easier to avoid being exposed to unstable versions of other projects [I think that's a bit selfish though]

    comments:

    • kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.

    releases

    modules:

    • closer to what we have with svn??

    split: