[commits] [Wiki] changed: Project/SplitGitRepo

[Wiki Guest]

guest [73.166.73.28]  Fri, 10 Mar 2017 18:05:45 +0000

Modified page: https://wiki.horde.org/Project/SplitGitRepo
New Revision:  18
Change log:  Revert

@@ -1,7 +1,9 @@
  [[toc]]

-+ Split Git Repo into individual components.
++ Project Name
+
+Split Git Repo into individual components.

  ++ Bugs

  N/A
@@ -11,48 +13,37 @@
  All developers.

  ++ Description

-Global:
+From dev mailing list:
+
+Going to try to sum up what I think is forming as a consensus.
+
+# Moving applications and framework packages to separate repos seems  
to be the most supported idea.
+ * GitHub allows unlimited public repos, so we are good there
+ * Can maintain all history.  See  
https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repo
+ * Might be a bit more unwieldy to work with (current monolithic repo  
allows commits across applications; but it might be a good thing to  
require different commits for each application for a more granular  
approach at adding features/fixing bugs.)
+# Talk of using git subtree(?)
+ * http://log.pardus.de/2012/08/modular-git-with-git-subtree.html
+ * However, this approach seems to completely neglect the current  
issue of "what should the master branch be?" or whether this question  
can even be properly solved when dealing with so many disparate pieces
+# Worries about scripting to setup repos
+ * Argument was made that it only takes 2 lines currently to create  
an installation.
+ * However recent discussion on mailing list pointed out it is  
extremely difficult for non-developers to set up an installation using  
git.  So the current scripts aren't perfect by any means.
+ * Additionally, whatever way we switch to will also need to be  
scripted so we would be in no different place than we are currently.
+ * No solution is going to work out-of-the-box.
+ * Use PHP Composer to help automate the process of generating a  
usable build from git (http://getcomposer.org/).
+
+...
+
+And the last time I chatted with Nils about composer it didn't have  
support for the installation of web assets - so for Horde the result  
would be a mixture of using composer and PEAR package definitions. I  
have no clue how much work it would be to get composer on par with  
PEAR in that area. Nils suggested that this should not be too hard.  
But the components helper we have should also be capable of managing  
PEAR and composer package definitions in parallel.
+I would assume we would do something like maintain package.xml files  
and then use the components script to create a composer.json file.  We  
could probably leverage this code:

-# Create script to automatically build list of apps/libs (for use by  
install script)
-  * Get all repos via https://api.github.com/orgs/horde/repos
-  * Check for .horde files at  
https://raw.githubusercontent.com/horde/[REPO]/master/.gitignore
-# Create single installation script
-  * This script can create/clone the git repos as needed.
-  * All repos will be stored in a base folder
-  * Option to create a separate, web-accessible directory.
-  * Includes stuff in framework/bin
-  * Includes stuff in horde-support/maintenance-tools
-  * Includes the groupware install code (in fact, the  
Horde_Core_Bundle code is probably a good place to start in terms of  
creating the install script).
-  * Use Horde_Pear libs to query for list of packages to install
-  * This script can be packaged via PHAR
-    * Allow config file
-# Create autoloader driver for use with script-facilitated  
development install
-# Create Vagrant image to allow for testing/development
+https://github.com/claylo/conductor

-For each application and library:
+BTW, adding yet another advantage to separate repositories: this  
greatly simplifies/improves continuous integration reporting.  Not  
only does this drastically take the time to check a commit, it more  
directly targets the actual changes the commit made.

-# Split git repo
-  * Tool at framework/bin/horde-git-split
-    * Example: ./horde-git-split --component Imap_Client --  
horde_imap_client_3
-  * Stored in separate git repo.
-@@--- # Merge master into FRAMEWORK_5_2 for all libraries @@ (Only  
necessary when doing the split //after// the Horde 6 release)
-# Add files to new repo
-  * composer.json
-    * Ensure that composer.json points to packagist/composer install  
paths instead of PEAR
-  * Travis
-    * .travis.ini, .travis.yml
-# Set up email updates for new repo
-# Generate documentation for each repo
-# Add package-specific entry to bugs.horde.org (if it doesn't exist)
+++ Resources

-++ Open Questions (Votes)
+...

-* Prefix split repositories with "horde-"?
-  * Jan: no
-  * Mike: no
-* What to do with the "horde" base repository. Delete current "horde"  
repository and replace it with the current "horde" application, or  
find a new repository name for the current "horde" application and  
keep or empty the current "horde" repository.
-   * Jan: leaning to the former
-   * Mike: leaning to the later (Wouldn't deleting the contents of  
the current repository mess anyone who has it checked out?)
  ----
-Back to the ((Project|Project List))
+Back to the ((Projects|Project List))