| Summary: | Migrate 'eclipse.platform.text' to Git | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | Releng | Assignee: | Kim Moir <kim.moir> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | kim.moir, markus.kell.r, pwebster, remy.suen |
| Version: | 3.7.1 | ||
| Target Milestone: | 3.8 M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 345479 | ||
|
Description
Dani Megert
Test repo is here ssh://userid@git.eclipse.org/gitroot/platform/eclipse.platform.text.git Kim, did you create the maintenance branches? If so, can we assume that they are all based on the corresponding correct version? As you're probably aware, we condition the repo before the migration so that all the maintenance branches for builds >= 3.0 have all the bundles associated with that. Otherwise, the bundles that were not branched for that maintenance release because they didn't change will not exist in the branch. So yes, I did condition the repo for this test migration. The top-level content looks good. We didn't verify on the file level yet. This is coming soon... I verified the test Git repository and found only one issue: The Git repo contains the following two files for the 'R3_4' tag /org.eclipse.search.tests/ipl-v10.html /org.eclipse.search.tests/plugin.xml which should not be there and which are also not there for 'R3_4_1', 'R3_4_2' and the 'R3_4_maintenance' branch. Kim, any idea why this happened? I know about the non-perfect tag migration but in this case it looks strange that 'R3_4_1', 'R3_4_2' and 'R3_4_maintenance' are correct but not 'R3_4'. General (E)Git issues: - Tags which don't exist on all projects are not trustworthy as one only gets the correct contents for the files that have that tag in CVS. For the others one gets an approximated content (instead of none like in CVS). - Text files are checked out with LF delimiter instead of CRLF on my Windows box. (In reply to comment #5) > - Text files are checked out with LF delimiter instead of CRLF on my Windows > box. May want to check your settings and/or CGit's behaviour. Also see bug 301775. (In reply to comment #6) > (In reply to comment #5) > > - Text files are checked out with LF delimiter instead of CRLF on my Windows > > box. > > May want to check your settings and/or CGit's behaviour. Also see bug 301775. CGit? Are you saying it works for you? If so, please tell me the correct settings. (In reply to comment #7) > CGit? I mean the C implementation of Git. > Are you saying it works for you? If so, please tell me the correct > settings. [core] autocrlf = false After setting the 'autocrlf' to 'true' in my gitconfig file (mine was in C:\Program Files\Git\etc), I was able to clone the repository and get the Java files to show up in Notepad correctly with the right line delimiters. C:\git>git clone git://git.eclipse.org/gitroot/platform/eclipse.platform.text.git I haven't tried pushing but there may be an additional step for that (to ensure that the push only pushes LF instead of CRLF, which I presume is the desired behaviour here). > After setting the 'autocrlf' to 'true' in my gitconfig file (mine was in > C:\Program Files\Git\etc), I was able to clone the repository and get the Java > files to show up in Notepad correctly with the right line delimiters. I guess you tried via command line and not via EGit. (In reply to comment #9) > I haven't tried pushing but there may be an additional step for that (to ensure > that the push only pushes LF instead of CRLF, which I presume is the desired > behaviour here). Yes. Remy, can you clarify whether this works for you via EGit? (In reply to comment #11) > Remy, can you clarify whether this works for you via EGit? No, it seems only CGit is honouring that configuration option. We are ready to migrate once M2 is finalized. Your repo is ready here committerid@git.eclipse.org:/gitroot/platform/eclipse.platform.text.git I ran the migration yesterday since you said you were ready early I think this can be closed, map files have been updated. |