Hi, As mentioned, this is not a counter-proposal to a refined SVN structure. Some parts, e.g. "data" may well use SVN if a sort of "workflow" could be found, either with JIRA or a dedicated UA-contribution service or similar.
However, as expressed by some earlier, and Browsermap also shows, some of the "clients" discussed or some we may get for other languages over time could benefit from Git. Not just by using a Git workflow similar to that used by DeltaSpike, Tamaya or other projects. DeltaSpike (Apache doesn't seem to have such extensive documentation on a top level yet) shows extremely well how Git should be used: http://deltaspike.apache.org/documentation/source.html and in more detail https://deltaspike.apache.org/suggested-git-workflows.html @Radu, if someone raised a Pull-request on https://github.com/apache/devicemap-browsermap could you merge that in GitHub and it'll automatically propagate back into https://svn.apache.org/viewvc/devicemap/trunk/browsermap/ or is that a Read Only mirror? While there are no deltas between branches, a developer of what you can call one of Day/Adobe's big Open Source competitors in the Java Enterprise CMS market (http://dotcms.com/) just forked both OpenDDR Data and Java Client on GitHub. I am not aware, the OpenDDR team would still merge pull-requests if they created any. Nobody can prevent them from just improving their fork, but since it's all Open Source any hypothetical fix, patch or improvement this company or others make to OpenDDR device data can in most cases be merged into the 1.x data stream, too if it doesn't exist there already. Their website claims fitbit.com and other large Global 100 brands (http://dotcms.com/explore/customers/) use it. So if they don't just "play around" with it, I'd say there's a reason they forked a W3C compliant library and data, too;-) Will ask the developer who forked it, what their intentions are. Unless they prefer to work on their own fork (which I could of course observe and legally "harvest" unlike commercial closed-source alterntives) maybe they are also interested to collaborate at DeviceMap directly. Regards, Werner
