search for: rebranch

...ee that the current release_31 branch has been created on r155051 as a copy of r155050 from trunk, and r155050 is actually removing an older release_31 branch: Revision 155050 Author: void Date: Wed Apr 18 16:38:33 2012 CDT (11 days, 20 hours ago) Log Message: Removing old release_31 branch for rebranching. This "old release_31 branch" was created on r154899: Revision 154899 Author: void Date: Mon Apr 16 21:00:08 2012 CDT (13 days, 16 hours ago) Log Message: Creating release_31 branch Here is how I fixed this in my local git repo: looking at the last commit to trunk r155049, befor...

...en created on r155051 as a > copy of r155050 from trunk, and r155050 is actually removing an older > release_31 branch: > > Revision 155050 > Author:         void > Date:   Wed Apr 18 16:38:33 2012 CDT (11 days, 20 hours ago) > Log Message:    Removing old release_31 branch for rebranching. > > This "old release_31 branch" was created on r154899: > > Revision 154899 > Author:         void > Date:   Mon Apr 16 21:00:08 2012 CDT (13 days, 16 hours ago) > Log Message:    Creating release_31 branch > > > Here is how I fixed this in my local git...

> In your svn section of llvm/.git/config, you can specify how to map > the svn branches to different name spaces, something like this: > > [svn-remote "svn"] >        [...] >        branches = branches/*:refs/remotes/origin/* >        fetch = branches:refs/remotes/origin > > I would also change "branches = branches/*:refs/remotes/origin/*" > into

...gt;> copy of r155050 from trunk, and r155050 is actually removing an older >> release_31 branch: >> >> Revision 155050 >> Author:         void >> Date:   Wed Apr 18 16:38:33 2012 CDT (11 days, 20 hours ago) >> Log Message:    Removing old release_31 branch for rebranching. >> >> This "old release_31 branch" was created on r154899: >> >> Revision 154899 >> Author:         void >> Date:   Mon Apr 16 21:00:08 2012 CDT (13 days, 16 hours ago) >> Log Message:    Creating release_31 branch >> >> >> H...

Hi Anton, On Thu, Apr 26, 2012 at 4:05 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Sebastian, > >> I just saw that the git branch remotes/origin/release_31 has been created >> for llvm.  Unfortunately it is missing the right context: right now I can only >> see 11 patches in that branch with the last patch having no parent. >> >> Could

...e! > > I haven't noticed any ill-effects. Is this a harmless warning or does it > need to be fixed? > > I'm on Linux/Fedora 9, x86-64. The warnings are harmless, but regardless libLTO shouldn't be trying to build on any platform except Darwin. It looks like the 2.5 rebranching took place at just the wrong time and picked up a change when I tried to have libLTO build on Linux as well. That change should never have made it into the 2.5 branch. Tanya, could you please revert 62987 from the 2.5 branch? It's this patch: http://llvm.org/viewvc/llvm-project/llvm/branc...

...tect that a path is no good. It might even fall back to TCP only or (to be really fancy) use STUN. 4. Better TCP-only security. #1 and possibly #2 would not require protocol changes, so they could happen in 1.0 if it were to live on. So could work like converting to libevent. 2.0 could be rebranched when one of the protocol changes is ready, and not be so different that it'd be impossible to merge between them. Oh by the way - thanks for catching that stupid close() bug in my last patch. Ironically similar to the sort of bug I was trying to fix... Best regards, Scott -- Scott L...

Hi all, I just svn-updated the 2.5 branch on my machine and I noticed this warning during the build. *** Warning: Linking the shared library /home/maurice/installation/llvm/Debug/lib/libLTO.la against the non-libtool *** objects /home/maurice/installation/llvm/Debug/lib/LLVMCppBackend.o /home/maurice/installation/llvm/Debug/lib/LLVMMSIL.o /home/maurice/installation/llvm/Debug/lib/LLVMCBackend.o

...changes will only get more strict over time. > >> If so, will the current LLVM head end up in the branch for 2.2 when that time comes? > > No. We already created the llvm/clang release branches to be used with Swift 2.2 to give us a longer time to stabilize them. We do not plan to rebranch again from trunk for Swift 2.2. > >> >> Given that the coordination costs to attempt any kind of change in swift that requires a change in LLVM are so high, I’m tempted to keep the logic of stripping the ‘l’s from armv7l and armv6l inside swift itself. It really seems like the wro...

> You assume triples make sense. That's the first mistake everyone does > when thinking about triples. :) I know they don't make sense in many corner cases, but I think discarding logic where it *does* exist is a mistake. > AFAIK, "ARMv7B" is only used by HighBank, which is no more. But that, > too, was "ARMv7A big endian". I believe it's what any