Thanks Ed, and Ed. There is an existing bug for aggregator editor: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325145
I'll let others debate the merits of autocrlf as I don't feel I'm qualified. If it was up to me, I'd just recommend everyone use Linux :) Thanks again, From: Ed Willink <e...@willink.me.uk> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 01/19/2013 03:31 AM Subject: Re: [cross-project-issues-dev] Corrupt Simrel repo??? Sent by: cross-project-issues-dev-boun...@eclipse.org Hi The Simrel project explicitly specifies Unix line endings, which I find to be an almost mandatory practice with GIT so that's good. autocrlf IMHO is the wrong solution to the wrong problem; if we all have the identical file we won't need fragile adaptation. A CM that modifies files is an obviously bad idea. CVS had its problems here too; often there were spurious 100% changes in the CVS difference view. Because not all tooling respects the line ending setting, I work with whitespace showing so that I can detect where broken line endings are coming from. Hence https://bugs.eclipse.org/bugs/show_bug.cgi?id=388418 and some others. I strongly recommend that new GIT users watch their whitespace stability very carefully. Convert all rogue files to Unix line endings before commit, but don't use the Convert Line Endings command if you use also have advanced XML tooling such as Papyrus or WTP installed; a) because you need to be prepared to have a coffee break; and b) because converted files may be reformatted provoking further changes. ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=390792). Regards Ed Willink On 19/01/2013 06:54, Ed Merks wrote: David, I'm not sure it's good advice to suggest autocrlf=false. The problem is, if the wrong endings are contributed by some tool, they'll end up pushed to the actual repo in that incorrect form (the repo itself must use \n) and then when anyone pulls, they'll end up with those wrong endings. I had to repair the whole EMF and XSD repos because of this problem so if you see wrong line endings in the repo, you need to take action to fix all those files. Note that EMF itself was one of the things that contributed to this problem, i.e., XML serialization always uses the Java system default for line endings, or at least it did until https://bugs.eclipse.org/bugs/show_bug.cgi?id=388418 was recently fixed. That bugzilla introduces a new option to respect the line endings in the resource or the workspace preference in effect for that resource, if it doesn't exist yet. With the latest EMF version, the generator automatically uses the new option in the generated editor. The b3 aggregator likely needs to be regenerated to avoid having folks on Windows corrupting the repo to which they push the their aggregated results. Also note that EGit does a much better job respecting autocrlf=true these days, so perhaps advice based on its previously broken behavior should be reconsidered. Regards, Ed On 19/01/2013 3:16 AM, David M Williams wrote: Do people who always have to "deal with the consequences" use Windows? Linux? Mac? Do they use EGit or command line? I ask, since I do not see the problem you describe, using Linux and EGit. But, I did look closely at the file, and see that it had mixed line endings (some "windows" CRLF and some "linux" LF). This, in turn, makes me wonder if participants have read http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_repo and http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_workspace_content_types In short, use autocrlf=false and define your content types and/or associate the file types with text editors. autocrlf=false should prevent a "change" from occurring on checkout, and having correct content types defined make it easy to fix using "Convert Line Delimiters To ... ". If you're the CLI only type, you'd have to use "dos2unix" to fix. I have corrected the delimiters (so it is now no longer a "test case") ... but, having the repo configured correctly will help avoid it in future and make it possible for you, participants, to fix files in the future, if it happens again. Maybe we should add a reminder "test case" file, with deliberate mixed line endings that'd say "if you see this file as changed, you need to set autocrlf=false"? :) At least, I'm assuming that was (one of) the problems ... like I said, I've not actually seen the issue. HTH From: Eric Gwin <eric.g...@oracle.com> To: Cross project issues <cross-project-issues-dev@eclipse.org>, Date: 01/18/2013 07:09 PM Subject: Re: [cross-project-issues-dev] Corrupt Simrel repo??? Sent by: cross-project-issues-dev-boun...@eclipse.org Hi, I understand that the message is usually a standard Git protection to keep me from inadvertently overwriting edited files. However, my point is I haven't edited the file. Ever. It "comes" edited when the repo is cloned. Therefore, I surmise that the file is, in fact, corrupt in the repo, and everyone using that repo is having to deal with the consequences. It would be nice if it were fixed. Eric On 2013-01-18, at 4:54 PM, Ed Willink <e...@willink.me.uk> wrote: > Hi > > This is standard GIT protection for edited files. > > As the message says you must either preserve of lose the changed files. > > To lose it/them just replace all files shown in the Staging View by HEAD. Then you're good to go. > > Regards > > Ed Willink > > On 18/01/2013 21:45, Benjamin Cabé wrote: >> FWIW I have the very same issue, so sth is probably wrong in the git repo itself indeed... >> >> Benjamin >> >> Eric Gwin<eric.g...@oracle.com> a écrit : >> >> >> Ok. got past it again by "unstaging" the file. and was able to checkout the Juno branch, but it should still probably be looked into. >> >> -Eric >> >> On 18/01/2013 2:14 PM, Eric Gwin wrote: >>> David, >>> >>> For a while now I've been having trouble switching my simrel branch. I thought it was just my system, but tried from another system recently. Any attempt to switch to the Juno_maintenance branch is giving me: >>> >>> "error: Your local changes to the following files would be overwritten by checkout: >>> soa-bpel.b3aggrcon >>> Please commit your changes or stash them before you can switch branches." >>> >>> This is from a freshly cloned repo. >>> >>> I don't know if the issue is mine (can't see how), or a corrupt git repo, or something to do with the soa-bpel file. >>> >>> -Eric >>> >>> _______________________________________________ >>> cross-project-issues-dev mailing list >>> cross-project-issues-dev@eclipse.org >>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >>> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> cross-project-issues-dev@eclipse.org >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.2890 / Virus Database: 2639/6039 - Release Date: 01/17/13 >> >> >> > > _______________________________________________ > cross-project-issues-dev mailing list > cross-project-issues-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2890 / Virus Database: 2639/6041 - Release Date: 01/18/13 _______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
