Community
Participate
Working Groups
Some missing files: org.eclipse.cdt.codan.core.internal.checkers.ReturnStyleCheckerTest org.eclipse.cdt.codan.core.internal.checkers.SuspiciousSemicolonCheckerTest org.eclipse.cdt.dsf.mi.service.IMIExpressions org.eclipse.cdt.dsf.mi.service.command.commands.CLIMaintenance and probably others in dsf.gdb Also, it looks like the HEAD of CVS is in the origin branch, see bug 315076.
Is this still an issue? -M.
(In reply to comment #1) > Is this still an issue? Yes, I just did a fresh clone and the files are still missing.
(In reply to comment #2) > (In reply to comment #1) > > Is this still an issue? > > Yes, I just did a fresh clone and the files are still missing. I can also confirm that the problem was still there as of Friday the 7th of Jan.
Now it seems that some branches are missing which were there before. Those are missing: remotes/origin/cdt_6_0 remotes/origin/cdt_6_0_2_special remotes/origin/cdt_7_0 remotes/origin/cdt_7_0_1 Also, I am getting after a fresh clone message "warning: remote HEAD refers to nonexistent ref, unable to checkout." "git log origin/origin" shows last commit as being done in March. Is the CDT repository corrupted?
I've forced a rebuild of the git mirror, so you may have caught the mirror as it's updating. It should be finished in a couple of hours, so let me know if it's still misbehaving. -M.
How is it being rebuilt, are you doing every time from scratch or incrementally?
In this case I simply deleted the git copy and started the mirror script which re-creates the git mirror from cvs with a full import. -M.
(In reply to comment #5) > I've forced a rebuild of the git mirror, so you may have caught the mirror as > it's updating. > It should be finished in a couple of hours, so let me know if it's still > misbehaving. It does not look like it advanced anywhere, still March 2009 in git log on another fresh clone. Same as comment 4.
(In reply to comment #8) > (In reply to comment #5) > > I've forced a rebuild of the git mirror, so you may have caught the mirror as > > it's updating. > > It should be finished in a couple of hours, so let me know if it's still > > misbehaving. > It does not look like it advanced anywhere, still March 2009 in git log on > another fresh clone. Same as comment 4. For me too. I actually ran a diff -r between by old clone of the rep and the new one and did not see the missing files having appeared.
After most recent pull the recent CDT changes are there but I am getting message: # On branch origin # Your branch and 'cdt/origin' have diverged, # and have 9709 and 14014 different commit(s) each, respectively. That is pretty scary. I did the previous pull just a few days earlier and kept my "origin" branch up to date. I guess that is the risk of recreating the git repo from cvs with full import from scratch. Need to figure out how to rebase my nontrivial changes to the new different origin.
I'm 're-importing' CVS into a new location beside the current repository as the import on friday failed(around 10pm) with 'unkown error'. I'm using the CVS mirror in case the problem was caused by activity in the repository. -M.
Well the new import has finished(without issue). Could I impose on someone to take a look at gitmirror/org.eclipse.cdt/org.eclipse.cdt.1.git and tell me if that is 'closer' to what the repository should look like? -M.
(In reply to comment #12) > Well the new import has finished(without issue). > > Could I impose on someone to take a look at > gitmirror/org.eclipse.cdt/org.eclipse.cdt.1.git and tell me if that is 'closer' > to what the repository should look like? > > -M. I've just started a git clone git://dev.eclipse.org/org.eclipse.cdt/org.eclipse.cdt.1.git
When CDT is migrated once and for all to git. The migration should use cvs2git not git cvsimport as the latter is prone to corruption, missing tags and branches.
(In reply to comment #0) > Some missing files: > org.eclipse.cdt.codan.core.internal.checkers.ReturnStyleCheckerTest > org.eclipse.cdt.codan.core.internal.checkers.SuspiciousSemicolonCheckerTest > > org.eclipse.cdt.dsf.mi.service.IMIExpressions > org.eclipse.cdt.dsf.mi.service.command.commands.CLIMaintenance > and probably others in dsf.gdb The missing files below are now there. (In reply to comment #4) > Now it seems that some branches are missing which were there before. Those are > missing: > remotes/origin/cdt_6_0 > remotes/origin/cdt_6_0_2_special > remotes/origin/cdt_7_0 > remotes/origin/cdt_7_0_1 > > Also, I am getting after a fresh clone message "warning: remote HEAD refers to > nonexistent ref, unable to checkout." > "git log origin/origin" shows last commit as being done in March. Is the CDT > repository corrupted? I got no errors or warning when doing my clone. "git log origin/origin" shows the last commit to be yesterday. I haven't check the above remote branches yet. I'm just getting familiar with git and I'm not sure how to do that yet. But, things seem good up to now. Thanks!
(In reply to comment #15) > (In reply to comment #0) > > Some missing files: > > org.eclipse.cdt.codan.core.internal.checkers.ReturnStyleCheckerTest > > org.eclipse.cdt.codan.core.internal.checkers.SuspiciousSemicolonCheckerTest > > > > org.eclipse.cdt.dsf.mi.service.IMIExpressions > > org.eclipse.cdt.dsf.mi.service.command.commands.CLIMaintenance > > and probably others in dsf.gdb > > The missing files below are now there. I meant the missing file _above_ are now there.
When will the mirror get refreshed to the code from HEAD?
(In reply to comment #12) > Well the new import has finished(without issue). > Could I impose on someone to take a look at > gitmirror/org.eclipse.cdt/org.eclipse.cdt.1.git and tell me if that is 'closer' > to what the repository should look like? It seems that one difference is that the earlier imports would combine CVS commits with the identical comments into one git commit and the newer imports (both org.eclipse.cdt.git and org.eclipse.cdt.1.git) created separate commits for each. I'd rather prefer combined one.
Ok, I've moved org.eclipse.cdt.1.git into place as org.eclipse.cdt.git. The update scripts should start bringing the repo in line with the cvs HEAD as the data is mirrored. I don't see any flags that indicate they would 'condense' cvs comments. -M.
(In reply to comment #19) > I don't see any flags that indicate they would 'condense' cvs comments. cvsps should do this by default, combining any See the -z switch on git cvsimport / cvsps. This defaults to 5 mins. Any files changed not within the fuzz window are treated as a separate commit.
I can re-run the import and increase the fuzz time. The only question is how large should the fuzz time be? Frankly if the git mirror is now up to date(or only a couple of hours out), I'm inclined to leave it alone and let everyone get back to work. Unless of course the commit grouping is really blocking someone. -M.
The defaults should be fine -- most commits are within seconds of each other. It's odd that Andrew's seeing different behaviour; Andrew what files are you seeing this on, and what are the timestamps on the commits?
Created attachment 187140 [details] screenshot I just fetched again and I see the origin I was working with diverged from the new one in the repo currently on commit from 2006. The reason is this commit, see screenshot. The last file BaseUITestCase.java got to a separate commit and it seems that there is 5 min difference. Maybe we could try 10 min?
(In reply to comment #23) > Created attachment 187140 [details] > screenshot > I just fetched again and I see the origin I was working with diverged from the > new one in the repo currently on commit from 2006. The reason is this commit, > see screenshot. The last file BaseUITestCase.java got to a separate commit and > it seems that there is 5 min difference. Maybe we could try 10 min? Wait, that was not 5 min but 5 sec., oops :). 10:18:08 and 10:18:13. But they went to different commits even the comment is the same.
(In reply to comment #21) > Frankly if the git mirror is now up to date(or only a couple of hours out), I'm > inclined to leave it alone and let everyone get back to work. Unless of course > the commit grouping is really blocking someone. The only thing slightly blocking me is switching repositories. :). I am kind of waiting for the repository to stabilize on something then I'll rebase against it.
Ok, well unless there are more missing files I'm not going to 'rebuild' the repo again. So the only updates going forward should be the automated ones to keep up with CVS head. -M.
(In reply to comment #25) > I am kind of waiting for the repository to stabilize on something then I'll rebase against it. I spent a couple of evenings and successfully rebased my stuff. But it was a major PITA. I learned a bunch of things on git in the process, things I really don't want to know. Sure, this rebuild was justified (and thanks for that!), but I hope we won't do it again before CDT moves to git.
