Community
Participate
Working Groups
Currently "production" is a simple directory under eclipse.platform.releng.aggregator. But, we dont' "build them" in the usual sense of the word. They are used during the build, but typically they are "checked out" using various forms of CGit, and/or copying and/or rsync to proper locations, at proper time. If they were submodules, it'd be easier to simply check them out with git, where needed, and not have to pull along extra things from eclipse.platform.releng.aggregator. In fact, under production, are other "subdirectories" that would better be submodules of 'production' (so we'd have sub-modules of submodules): downloadsites sdk testScripts The advantage of having as submodules (instead of seperate repos) is then it is possible to "get everything", easily, and they all get tagged and kept in sync easily during the build. We typically using only "master" of these files.
CCing Git experts: Is there any complications chanding a "directory" to a "sub-module" I should be aware of? I did find some "step by step" directions on "how to do" at http://willandorla.com/will/2011/01/convert-folder-into-git-submodule/ Just didn't know if I need a general announcement that people need to "reclone"? Or will they pick up the change in an pull?
> Or will they pick up the change in an pull? I don't know; I know close to nothing about git submodules. But I think you can try this locally by doing the transformation, cloning the original repo again, setting the transformed repo as origin (with a file: URL), and then pulling. Just make sure you don't force-push anything to the aggregator repo but properly remove the production folder and commit the removals as usual. This will preserve the history of the repo (e.g. old links from Bugzilla). "git filter-branch" will create a whole new set of commits that only contains the sub-folder. That preserves history-browsing within the sub-folder, but there's no direct way to link the new commits to the old commits in the aggregator repo. (You'd have to look at the Authored Date and commit message.) I'd be very reluctant to apply this procedure to code repos where you'd expect a lot of clones in adopters' workspaces / Gerrit / etc., but that's probably not an issue with the aggregator repo.
(In reply to David Williams from comment #1) > Is there any complications changing a "directory" to a "sub-module" I should > be aware of? > Shouldn't be any complications but one thing that end users do need to be aware of is that they will need to run "git submodule init" and "git submodule update" to pick up the new submodule after they pull in the updates in aggregator. Other than that the hard part would be all on your end where you are making the actual change. The link you found with steps seem good to me. That's how I would do it.
(In reply to David Williams from comment #0) > In fact, under production, are other "subdirectories" that would better be > submodules of 'production' (so we'd have sub-modules of submodules): > downloadsites > sdk > testScripts > > The advantage of having as submodules (instead of separate repos) is then it > is possible to "get everything", easily, and they all get tagged and kept in > sync easily during the build. We typically using only "master" of these > files. I have experimented with this on a local repo, and can get it to work as described. But, was not as happy with the results as I thought I'd be. In short, I do not see much advantage to having these 'folders' as submodules of the aggregator repo. The main problem this is trying to solve is that these folders such as 'production/sdk' and 'production/downloadsites' really only have a 'master' branch (by design). Other things in 'production' are occasionally branched but are intended to have only one branch. (The reason they might need to be branched is all related to timing ... such as an improvement is desired by we are just about to release a maintenance release and "do not want to touch anything" during that period. Again, none of these directories are related to the "pom build" in anyway. Is there any harm in just have a separate repo, say "org.eclipse.releng.sdkProductionBuilds" And it would have submodues, such as 'sdk' 'prodution' and maybe 'downloadsites' The process of creating these additonal repos would be essentially the same (AFAIK) as described in http://willandorla.com/will/2011/01/convert-folder-into-git-submodule/ But I simple would not make them submodules of 'aggregator'.
I think this would not be worth the churn, given that it only makes things a little easier and is not really causing problems except for making some scripts more complicated and slows processing only a little. If I was doing it from the beginning I think still worth keeping separate, but not at this point.
