Hi, Just stumbled over the Git root for projects like Tamaya: https://git1-us-west.apache.org/repos/asf
It contains many or all Git-hosted projects, just curious why Browsermap is not there? Is it mirrored in a special way between GitHub only and the DeviceMap SVN? While some projects like DeltaSpike have a single Git repo and the module structure (resulting in several dozens of Jenkins jobs) occurs underneath, other projects have dozens of Git repositories there, too. If more than just BrowserMap was to use Git (and that doesn't even seem to use the "official" Apache Git repo at the moment) we could chose either of these strategies. Both are legitimate and it is up to the project/PMC to figure out what's best for them. A very polyglot nature of DeviceMap sounds like it could justify at least separate repositories for "data", "java", "vb" and maybe other languages. Again this could also start from scratch with 2.x rather than a separate SVN branch. Werner On Wed, Jan 7, 2015 at 1:58 PM, Werner Keil <[email protected]> wrote: > Yes, it sounded like that. Switching the entire "root"/repo to Git was > also an option, a more drastic one of course than gradually doing this on a > module per module basis. > > We have a few differences in Maven artifactID and the folder name, e.g. > /trunk contains a pom.xml called something like "devicemap-reactor" so I'd > say we can try to harmonize some of these folder names, but unless e.g. a > Git sync of exactly that sub-module (like "java", for "examples" it should > be pretty much the same for most modules) makes it appealing, I don't see > it as the highest priority. Nobody would suggest calling the parent POM > just "trunk" though under "org.apache.devicemap" even that would not do a > great harm. > > Werner > > > On Wed, Jan 7, 2015 at 1:52 PM, Bertrand Delacretaz < > [email protected]> wrote: > >> On Wed, Jan 7, 2015 at 1:47 PM, Werner Keil <[email protected]> >> wrote: >> > ...A good question (Volkan/others do you have ideas where it could help >> most?) >> > is which of the "tree" structure we'd like to sync with Git?... >> >> We're not talking about *syncing* to Git - what Volkan's suggesting is >> *switching* to Git. >> >> -Bertrand >> > >
