Open m3dwards opened 12 years ago
serialseb
commented
12 years ago Nah theres nothing that prevents appharbor from building stuff from openwrap.
The commit should contain /wraps/_.wrap and /wraps/openwrap, and not commit /wraps/__. Then you can point appharbor to any csproj and it will just build.
Can you be more specific with what issue you're seeing?
m3dwards
commented
12 years ago serialseb
commented
12 years ago I get an access denied on this
m3dwards
commented
12 years ago serialseb
commented
12 years ago Ok I debugged it, the files descriptor files themselves ought to be in CRLF line endings, yours seem to me to be in LF. Note also that wraps/_cache should not be committed. OpenWrap 2.0 tells you about LF as being an error. We could normalize those automatically and relax the parsing rules, but doing it just because git is being stupid about this stuff is quite frustrating. I'm keeping this open till we decide what the best course of action is.
m3dwards
commented
12 years ago I have removed the _cache files from the commit, what are the descriptor files and how did they get LF endings? Did git cause this?
On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla < reply@reply.github.com
wrote:
Ok I debugged it, the files descriptor files themselves ought to be in CRLF line endings, yours seem to me to be in LF. Note also that wraps/_cache should not be committed. OpenWrap 2.0 tells you about LF as being an error. We could normalize those automatically and relax the parsing rules, but doing it just because git is being stupid about this stuff is quite frustrating. I'm keeping this open till we decide what the best course of action is.
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458056
serialseb
commented
12 years ago Yes, git messes with line endings, so if you commit files its gonna by default go and turn crlf into lf, which is no good.
Sebastien Lambla
On 20 Jun 2012, at 16:44, "maxwe789" reply@reply.github.com wrote:
I have removed the _cache files from the commit, what are the descriptor files and how did they get LF endings? Did git cause this?
On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla < reply@reply.github.com
wrote:
Ok I debugged it, the files descriptor files themselves ought to be in CRLF line endings, yours seem to me to be in LF. Note also that wraps/_cache should not be committed. OpenWrap 2.0 tells you about LF as being an error. We could normalize those automatically and relax the parsing rules, but doing it just because git is being stupid about this stuff is quite frustrating. I'm keeping this open till we decide what the best course of action is.
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458056
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458439
m3dwards
commented
12 years ago Thanks so much for this, I'll look to fix that.
On Wed, Jun 20, 2012 at 4:47 PM, Sebastien Lambla < reply@reply.github.com
wrote:
Yes, git messes with line endings, so if you commit files its gonna by default go and turn crlf into lf, which is no good.
Sebastien Lambla
On 20 Jun 2012, at 16:44, "maxwe789" reply@reply.github.com wrote:
I have removed the _cache files from the commit, what are the descriptor files and how did they get LF endings? Did git cause this?
On Wed, Jun 20, 2012 at 4:33 PM, Sebastien Lambla < reply@reply.github.com
wrote:
Ok I debugged it, the files descriptor files themselves ought to be in CRLF line endings, yours seem to me to be in LF. Note also that wraps/_cache should not be committed. OpenWrap 2.0 tells you about LF as being an error. We could normalize those automatically and relax the parsing rules, but doing it just because git is being stupid about this stuff is quite frustrating. I'm keeping this open till we decide what the best course of action is.
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458056
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458439
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6458478
m3dwards
commented
12 years ago Looking at the git documentation it suggests that having "* text=auto" in .gitattributes will change CRLF to LF when stored but will change it back to CRLF on checkout. Is this not happening?
m3dwards
commented
12 years ago I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.
Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv
serialseb
commented
12 years ago You should be able to set eol per file type.
Sebastien Lambla
On 20 Jun 2012, at 18:30, "maxwe789" reply@reply.github.com wrote:
I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.
Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6461431
serialseb
commented
12 years ago No idea. Is that dll committed?
Sebastien Lambla
On 20 Jun 2012, at 18:30, "maxwe789" reply@reply.github.com wrote:
I forced it to use CRLF by setting * eol=crlf in the .gitattributes file but this feels dirty because mac and linux users would also get crlf.
Now getting another build problem, any ideas what this one is? http://pastebin.com/Hx5rZcTv
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6461431
serialseb
commented
12 years ago Afaik AppHarbor exports as LF always.
Sebastien Lambla
On 20 Jun 2012, at 18:11, "maxwe789" reply@reply.github.com wrote:
Looking at the git documentation it suggests that having "* text=auto" in .gitattributes will change CRLF to LF when stored but will change it back to CRLF on checkout. Is this not happening?
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6460895
m3dwards
commented
12 years ago I think the problem with the .dll was git trying to normalise a binary's line endings.
I updated my gitattributes to tell git that .dll files are not text files, please leave them alone.
( * eol=crlf + *.dll -text )
Now I have another build error... sorry! http://pastebin.com/M6uj9Jmp
serialseb
commented
12 years ago Hmm. I'd recommit the packages, one zip file is obviously invalid.
Sebastien Lambla
On 20 Jun 2012, at 19:38, "maxwe789" reply@reply.github.com wrote:
I think the problem with the .dll was git trying to normalise a binary's line endings.
I updated my gitattributes to tell git that .dll files are not text files, please leave them alone. *.dll -text
- eol=crlf
Now I have another build error... sorry! http://pastebin.com/M6uj9Jmp
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6463335
m3dwards
commented
12 years ago Recommitted and it builds!!! I am super happy with this. What pain git has caused, I'm sorry you got lumbered with debugging it.
This is my .gitattributes file I'm using http://pastebin.com/dPrqgsik
I wonder if just telling git not to change any line endings would be better. I just like the idea that I can jump into mac and use MonoDevelop with git to pull in the files and have them left with LF. Why can't the world just agree on one way to have a new line?!
To answer your previous question about how OpenWrap should behave I would just be done with it and accept LF as well as CRLF. Defensive programming and all. It's stupid but git exists and is popular so you know this isn't the last time this will rear its ugly head.
serialseb
commented
12 years ago You may be right, I'll keep this open so we can relax the rules.
Sebastien Lambla
On 20 Jun 2012, at 20:14, "maxwe789" reply@reply.github.com wrote:
Recommitted and it builds!!! I am super happy with this. What pain git has caused, I'm sorry you got lumbered with debugging it.
This is my .gitattributes file I'm using http://pastebin.com/dPrqgsik
I wonder if just telling git not to change any line endings would be better. I just like the idea that I can jump into mac and use MonoDevelop with git to pull in the files and have them left with LF. Why can't the world just agree on one way to have a new line?!
To answer your previous question about how OpenWrap should behave I would just be done with it and accept LF as well as CRLF. Defensive programming and all. It's stupid but git exists and is popular so you know this isn't the last time this will rear its ugly head.
Reply to this email directly or view it on GitHub: https://github.com/openrasta/openwrap/issues/332#issuecomment-6464238
AppHarbor builds from source which I don't think will work if OpenWrap isn't installed on the build machine. I have tried removing the Symlink folder of openwrap from the wraps directory and copying in the files manually but still got a build error.
Not really sure what the solution would be, it may be that they are not compatible and that's that but thought I would raise it here in-case there is a simple step which I'm missing.