I have moved / am moving the source repositories I have something to do with to Github / openEHR. Is it time to move the ref_impl_java SVN repo? Please note that it will have to be moved somewhere fairly soon anyway, because the CHIME@UCL hosting will disappear early this year. Github is not the only option, but I think it’s a good one.
I moved the ADL Workbench SVN repo there some weeks ago, you can see it here. It is possible to preserve all tags and branches, as well as user ids (try looking under the branches button). So in terms of faithfully preserving the state of things, it seems to be pretty good.
I am happy to perform the operation if you agree to doing it. Obviously you should make sure all final commits, tags etc are done before this!
I also want to remind all that you are free to play around with
handling the openEHR Github-space in the "Sandbox" sub-project: https://github.com/openEHR/Sandbox
Ok, I will do this move in the next few days. I am thinking of naming the repo "java_libs" or "java_library" or "java_core_libs" under the GitHib openEHR group. This seems a bit more human friendly than "ref_impl_java" (which was my fault, years ago!). It seems to me that this repo is really about reference libraries, not apps or solutions.
Can this group propose a reasonable name for the new GitHub repo, please.
Note, renaming a Git repo soon after creation, and before people start cloning is easy.
The name space of GitHub is not isolated by account/group name.
If I fork 'java-core', my repository would be 'skoba/java-core'.
GitHub has many projects with many languages, 'java-core' will be
conflict with other project. 'openehr-java' or 'java-impl-openehr' would
would be better.
Hi Shinji, Github uses namespacing on repo names. Try this search - you will see it picks up lots of repos all called ‘terminology’, including the openEHR one. Since repos are namespaced by their user or organisation, we don’t need to repeat ‘openehr’ in all the repo names. Have a look at the current openehr repos: However, if you fork to your own user login, you are right, you just end up with things like skoba/java-core. Personally I don’t think this matters, since you will probably have some directory on your machine like …/openEHR/, so you will probably clone the fork to a directory like …/openEHR/skoba/java-core or …/openEHR/skoba-java-core (i.e. since you might already have the real openEHR/java-core as well). The problem comes when you try to fork two repos on Github of the same name to the same target namespace. This is what happens after I had forked openEHR/terminology to wolandscat (my own user name) and then I try to fork some other users repo that also happens to be called ‘terminology’: It will actually lets you proceed anyway, and this is what happens: So obviously you are going to rename one of your repos, since ‘terminology-1’ isn’t a very helpful name. Personally, I think GitHub needs to do automatic renaming during forking, or at least automatically provide the option for renames of the form oldnamespace-reponame during a fork, since the current situation just forces the user to do it in a manual way anyway. Here’s what I ended up with on my own GitHub accountm after two manual renames: Github still remembers where the forks are from, so I don’t expect any trouble with pushing, if I wanted to do that. So, in summary, I think we should stick with repo names that don’t double up on the organisation namespace, and perform renaming in the rare circumstance when we fork two distinct repos that happen to have the same repo name. - thomas
