Community
Participate
Working Groups
In accordance with Eike, I have migrated the CDO repository to four Git repositories which should now be made available as the primary CDO source code repository replacing our SVN repositories. To do that, please: 1. set our SVN repository to read-only (the CDO team has already been informed as of this morning to not do any more commits in the SVN, so the migration could already be done on the current repo) 2. grab the migrated git repositories from my home directory on dev.eclipse.org I have created new, bare Git repositories, imported the SVN history into the Git repos, did some necessary branch and tag renaming and zipped the resulting repositories. The repositories are contained in - org.eclipse.emf.cdo.deprecated.git.zip - org.eclipse.emf.cdo.git.zip - org.eclipse.emf.cdo.incubator.git.zip - org.eclipse.emf.cdo.infrastructure.git.zip and already contain the respective description file. 3. deploy the git repositories to git.eclipse.org I am not sure if additional configuration / adjustments to the git.eclipse.org infrastructure is needed (e.g. commit hooks etc.). Please double-check the configuration to be sure. 4. What is the policy about obsolete SVN repositories? Will the SVN repo still remain available or will it be archived, after we have checked that the Git repo works?
Stefan, thank you for this great piece of work. I know how hard it must hae been to bring order to the chaos of our SVN history! I've written an Email to the entire team to prevent from committing to SVN until we can continue with Git. I hope this period won't be too long :P
(In reply to comment #0) > 3. deploy the git repositories to git.eclipse.org > I am not sure if additional configuration / adjustments to the git.eclipse.org > infrastructure is needed (e.g. commit hooks etc.). Please double-check the > configuration to be sure. I recall that my former experiments have left a Git repo in our public container folder and now I don't seem to be allowed to remove it. It can/should be removed before the new repos are unpacked there!
To find the zip files more easily: they should be found on dev.eclipse.org in ~swinkler/org.eclipse.emf.cdo.deprecated.git.zip ~swinkler/org.eclipse.emf.cdo.git.zip ~swinkler/org.eclipse.emf.cdo.incubator.git.zip ~swinkler/org.eclipse.emf.cdo.infrastructure.git.zip (I don't know the absolute path of ~swinkler, but I guess you know where to find the home directories :-)) ---- Additional remark: as Eike pointed out there is already a repository from an earlier attempt of the migration (see Bug 351050) at git://git.eclipse.org/gitroot/cdo/org.eclipse.emf.cdo.git This should be deleted prior to the deployment of the new repos.
*** Bug 351050 has been marked as a duplicate of this bug. ***
Ok, I've removed the old 'test' repo, unpacked your new ones, updated the post-commit hook and config, and set the ownership and permissions. I've also set the CDO SVN readonly. Do you need access via http(s) or can everyone use the ssh protocol? -M.
Hey Mat, you're super fast. Thank you so much! I'd like to discuss with Stefan about the http(s) access, as I'm not experienced enough to foresee the consequences. We'll come back to you soon...
Well with the great job Stefan did with the import it was pretty straight forward. -M.
(In reply to comment #5) > Do you need access via http(s) or can everyone use the ssh protocol? Yes, we think for users behind a firewall that would be a must have.
Created attachment 205211 [details] Auth fail dialog (In reply to comment #5) > Ok, I've removed the old 'test' repo, unpacked your new ones, updated the > post-commit hook and config, and set the ownership and permissions. We're currently testing the main repo. Cloning was successful. However, I changed some code, committed and tried to push the changes. Then I got an "Auth fail" error with no further explanation (see attached screenshot). Can that be a problem on my end?
By monday morning https should be all setup. As for the auth issue here's what I see in the logs: Oct 14 11:47:19 sshd[4574]: Failed password for estepper from xxx.xxx.xxx.xxx port 51836 ssh2 Since I can also see some 'ok' access, to me it looks like your Git tool is maybe doing something funny. -M
After such an "auth fail" I can not even fetch anymore and my putty shell does also not open anymore. Can that be related with the new shell security mega system you've just installed? Pretty annoying then, I must say.
(In reply to comment #10) > By monday morning https should be all setup. Thx! > Since I can also see some 'ok' access, to me it looks like your Git tool is > maybe doing something funny. That's EGit!
(In reply to comment #11) > After such an "auth fail" I can not even fetch anymore and my putty shell does > also not open anymore. Can that be related with the new shell security mega > system you've just installed? Pretty annoying then, I must say. It's not the 'new' system, it's our older but faithful system that is seeing 'hordes'(37 on just one node!) of failed logins and presumes you're attempting to 'hack' an account, and so it blocked you. I've cleared the block(for now, it may re-appear) so things should be ok. I guess one of the lesson here is: automatic retry is nice but can be dangerous. -M.
> I guess one of the lesson here is: automatic retry is nice but can be > dangerous. I wonder why retries are needed at all. i've cloned with proper credentials and the network here is generally ok, e.g. the same IP address all this day. Now I get auth fail again ;-( I've no clue what I'm doing wrong. For Stefan all seems okay.
There seems to be a timeout period that an account gets blocked if something strange happens. How long exactly is this period? It seems that whenever I manually retry an action a little bit too early the period is extended. that makes it almost impossible to try various things without resetting my IP address (which creates other hazzles).
Hmm, there seemed to be a strange coincidence of EGit and a secure storage password provider. Now all seems to work properly. Resolving...
> Hmm, there seemed to be a strange coincidence of EGit and a secure storage > password provider. Now all seems to work properly. Resolving... You should apologize to our new shell security mega system (sabot) for calling it annoying... I think you hurt its feelings :) But on a related topic, say you're at home one night, and you hear someone trying to unlock your door 37 times in rapid succession -- what would you do?
(In reply to comment #17) > You should apologize to our new shell security mega system (sabot) for calling > it annoying... I think you hurt its feelings :) My fingers do hurt today from entering my password ~1000 times :P > But on a related topic, say you're at home one night, and you hear someone > trying to unlock your door 37 times in rapid succession -- what would you do? Kill my home for x minutes :P Jokes aside, I do appreciate your efforts to keep us safe!
