[llvm-commits] svn assistance...

Relph, Richard Richard.Relph at amd.com
Thu Dec 20 10:42:46 PST 2012


Tom, John, anyone else… ;-)
    So Tom just walked me through the process he's been using with git to do similar merges on his R600/AMDGPU branch. Thanks, Tom.

    His process produces a patch to AMDILBackend that brings it up to LLVM 3.2 level. OK, that 'works'. I can do effectively the same thing using SVN by merely checking out AMDILBackend and release_32, replacing everything in the AMDILBackend tree with the files from release_32, and generating an svn diff.
    I was trying to avoid this "bruteforce" approach because I assume that svn gains some benefit from knowing that the replaced files are actually "merged" from elsewhere in the repository, rather than seemingly invented from whole cloth.
    But 2 questions occur to me now…

    First, DOES svn benefit from doing a merge using svn instead of a simply replacement? Perforce certainly does (the history of a file and the branch/merge graphs all depend on using perforce to do branches and merges) and I just assumed that all revision control systems would.
    Second, even if svn does benefit, is there enough value from the benefit to warrant all the trouble I've been going through… this is, after all, not trunk, but just AMDILBackend.

    Should I just bruteforce the merge? I'm thinking now that the answer is yes. I'm thinking no one outside of AMD really cares about the detailed history of the non-AMDIL portions of the AMDILBackend branch. If there's a big checkin that says "bring LLVM up to 3.2 level", that'll be good enough, even if svn log doesn't get the history quite right…

Thanks,
Richard

On Dec 20, 2012, at 8:36 AM, Tom Stellard <tom at stellard.net>
 wrote:

> On Thu, Dec 20, 2012 at 04:29:16PM +0000, Relph, Richard wrote:
>> Tom,
>>    Thanks for the reply…
>> 
>> On Dec 20, 2012, at 7:59 AM, Tom Stellard <tom at stellard.net>
>> wrote:
>> 
>>> On Wed, Dec 19, 2012 at 10:53:20PM +0000, Relph, Richard wrote:
>>>>   I'm stuck behind a firewall with no IRC access.
>>>>   I want to bring the AMDILBackend branch in sync with the LLVM 3.2 branch.
>>>>   I'm NOT an SVN expert… I can check out, and check in, but mass merges across branches with a common base are well beyond my capabilities. That it should be possible seems obvious… how… not so much.
>>>>   The AMDILBackend branch on llvm.org was branched from trunk at r161674. Since that time, in AMDILBackend, we've made almost no changes outside the new lib/Target/AMDIL backend directory itself, and the related test/CodeGen/AMDIL. The LLVM 3.2 branch branched from trunk at r167702 and has had several changes to it since then.
>>>>   Because the LLVM 3.2 branch was made after the AMDILBackend branch, I thought it would be relatively straight forward to do this, but alas, I haven't found the correct incantation to get SVN to do the trick.
>>>>   svn merge <3.2 URL> seems the most likely choice. But when I tried that I was surprised by the number of "conflicts" that svn reported, in files that had not changed in the AMDILBackend branch at all since the branch from trunk.
>>>>   I'd appreciate some help to save me having to spend several hours (or days, given my reading speed) to learn SVN to do what I'm sure will be a 15-minute task which I won't repeat often enough to have it "stick".
>>> 
>>> I am not an SVN expert either.  I usually use git svn, so if you are
>>> familiar with git that would be my recommendation.  No matter which 
>>> VCS system you use I would recommend the following:
>>> 
>>> 1. Generate a diff of all the non-AMDIL backend files that have changed
>>>  in the AMDILBackend branch since r161674.
>> There are a total of 4 files different outside lib/Target/AMDIL and test/CodeGen/AMDIL.
>> CMakeLists.txt, configure, include/llvm/CodeGen/SelectionDAG.h, and lib/Target/LLVMBuild.txt.
>> Really, that is ALL the changes…
>> 
>> Here's what I've done, and because I suspect at the end of the day, it'll be something stupid I've done, I'm spelling it out in gory, reproducible, detail.
>>> svn co http://llvm.org/svn/llvm-project/llvm/trunk@161674 trunk
>>> svn co http://llvm.org/svn/llvm-project/llvm/branches/AMDILBackend AMDILBackend
>>> diff -rq -x .svn trunk AMDILBackend
>> Files trunk/CMakeLists.txt and AMDILBackend/CMakeLists.txt differ
>> Files trunk/configure and AMDILBackend/configure differ
>> Files trunk/include/llvm/CodeGen/SelectionDAG.h and AMDILBackend/include/llvm/CodeGen/SelectionDAG.h differ
>> Only in AMDILBackend/lib/Target: AMDIL
>> Files trunk/lib/Target/LLVMBuild.txt and AMDILBackend/lib/Target/LLVMBuild.txt differ
>> Only in AMDILBackend/test/CodeGen: AMDIL
>> 
>> Now, I can certainly back out the 4 changes (after getting approval, of course ;-), but that's not going to change the files that svn merge is telling me conflict… Effectively, I'm at step 4 in your list, but I can't get that to work. As I say, it is bound to be a basic misunderstanding of svn on my part, but I'm really confused about why svn merge complains that my "changes" to many files NOT listed above conflict with the changes from trunk between 161674 and 167702.
>> 
> 
> For step 2, I was assuming you could commit the changes locally, but I
> guess this isn't possible with SVN.  You could skip this step and just
> use the patch as a guide for steps 4 and 5 while you are doing and
> verifying the merge.
> 
> -Tom
> 
> 
>> Richard
>> PS. Sadly, I don't know git… both AMD and Adobe, the only I've worked from since 1989, both relied on Perforce.
>> 
>>> 2. Apply the diff in reverse (effectively reverting these changes) and
>>>  save the diff for later.
>>> 3. Break this diff into logical patches and submit to llvm-commits for
>>>  review. ;)
>>> 4. Merge the LLVM 3.2 branch into the AMDILBackend branch.  If there are
>>>  conflicts, just take whatever came from the 3.2 branch.
>>> 5. Now the AMDILBackend branch should be 3.2 + the AMDIL backend.  To
>>>  verify this, do a diff between the AMDILBackend branch and the 3.2
>>>  branch.
>>> 6. Apply the patch you created in step 1 to the AMDILBackend branch and
>>>  then you should be done.
>>> 
>>> Hope this helps.
>>> 
>>> -Tom
>>> 
>>>> Thanks,
>>>> Richard
>>>> 
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>> 
>> 
>> 
> 






More information about the llvm-commits mailing list