[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] Corrupt Simrel repo???
|
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 <ed@xxxxxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
01/19/2013 03:31 AM
Subject:
Re: [cross-project-issues-dev]
Corrupt Simrel repo???
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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.gwin@xxxxxxxxxx>
To: Cross
project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date: 01/18/2013
07:09 PM
Subject: Re:
[cross-project-issues-dev] Corrupt Simrel repo???
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <ed@xxxxxxxxxxxxx>
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.gwin@xxxxxxxxxx>
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@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
