Re: [codepatch] Re: [discuss] block all hosts

Okay, I tried all of these steps in as many ways as I could, and still 
no joy.  I got the diff files without a problem, but when I try to patch 
(after downloading patch for win32) it starts okay, but as soon as it 
starts to appy the patch it tells me that it can't find the file to be 
patched.  It looks to me like the problem is that the diff files refer 
to the files in the CVS structure.  Here is the output:

C:\LimeWire>patch -p0 -i file-filter.txt
can't find file to patch at input line 10
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|cvs server: Diffing .
|Index: ResultPanel.java
|===================================================================
|RCS file: /cvs/gui/com/limegroup/gnutella/gui/search/ResultPanel.java,v
|retrieving revision 1.140
|retrieving revision 1.140.26.2
|diff -u -w -r1.140 -r1.140.26.2
|--- ResultPanel.java   15 Nov 2004 04:48:24 -0000      1.140
|+++ ResultPanel.java   11 Jan 2005 18:13:28 -0000      1.140.26.2
--------------------------
File to patch: 
C:\LimeWire\gui\com\limegroup\gnutella\gui\search\ResultPanel.java
patching file 
C:\LimeWire\gui\com\limegroup\gnutella\gui\search\ResultPanel.java
Hunk #1 FAILED at 7.


--

Any suggestions? 

-Chuck

Sam Berlin wrote:

> You can get a diff of the changes on the file-filter branch by using 
> the cvs command:
>  cvs diff -uNw -r file-filter-branch-point -r file-filter-branch > 
> filter-changes.txt
>
> (It may also be -r file-filter-branch -r file-filter-branch-point -- I 
> can never remember the order.)
>
> Once you get those changes, you can incorporate them into your local 
> edits using:
>  patch -p0 -i filter-changes.txt
>
> Then, you can do a diff from your local copy to CVS head using
>   cvs diff -uNw > all-changes.txt
>
> The resulting all-changes.txt file should contain the diffs of both 
> your local edits & the file-filter branch.
>
> Hopefully that all made sense. :)
>
> Thanks,
>  Sam
>
> On Apr 4, 2005, at 4:47 PM, Chuck McNulty wrote:
>
>> Okay, nix the question on how to resolve merges, I've done that 
>> part.  At least I've resolved the conflicts between my versions and 
>> the file-filter-branch versions.  I'm just not sure what to do next.  
>> When I did a diff it just did a diff between my changes to the 
>> file-filter-branch.  I need to figure out how to get the diffs from 
>> the file-filter-branch (including my changes) and the main trunk.  
>> Any advise is welcome.
>>
>> Also, should I take this discussion off of discuss@lists?  Should it 
>> be on another list?  Should I just be sending these questions to you, 
>> Sam?
>>
>> -Chuck
>>
>> Chuck McNulty wrote:
>>
>>> Hi Sam and all,
>>>
>>> Okay, this is kinda fun learning so I'm going to go for it.  I have 
>>> a few questions and they're not really LimeWire specific I think, 
>>> but you've been so helpful and patient, what the heck...
>>>
>>> Like I mentioned earlier I'm still learning CVS, and I'm using 
>>> WinCVS, which is probably an unhelpful crutch in terms of learning 
>>> it, but whatever.  I think I've pretty much got checking out a 
>>> branch, and I see that when I did that, there were some conflicts 
>>> where I'd already made changes (to the block all hosts 
>>> functionality).  I assume that the next step after I resolve these 
>>> conflicts is to do a merge of the file-filter-branch with the main 
>>> trunk on my own local copies resolve those conflict, and then do a 
>>> diff to submit to you.  Does that make sense?
>>>
>>> If so, my question (and it's a total newbie question) is how I go 
>>> about "resolving the conflicts"  Here is the first conflict, for 
>>> instance, in ResultPanel.java:
>>>
>>> import java.awt.event.MouseListener;
>>> import java.io.IOException;
>>> import java.util.Date;
>>> <<<<<<< ResultPanel.java
>>> import java.util.Iterator;
>>> =======
>>> import java.util.ArrayList;
>>> import java.util.Arrays;
>>> >>>>>>> 1.140.26.2
>>> import java.util.LinkedList;
>>> import java.util.List;
>>> import java.util.Set;
>>>
>>> Is "resolving the conflicts" just taking out the <<<, ===, and >>>> 
>>> lines with a text editor and making sure it still works?  Or is 
>>> there some interactive CVS tool that I should be using to resolve 
>>> the conflicts?  I think that's it...
>>>
>>>
>>> After that, the next thing I'm really excited about adding to 
>>> LimeWire, if it would be accepted (and maybe into my own version in 
>>> either case) is a new window that displays the bitzi info without 
>>> having to open up a browser window (with all of it's accompanying 
>>> advertising).  I'd do it by using bitzi's XML format:  
>>> http://bitzi.com/developer/xml  I'm assuming here that LimeWire 
>>> doesn't have a financial partnership or arrangement with bitzi for a 
>>> share of their ad dollars.  I can certainly understand not wanting 
>>> to add this functionality if that's the case, and I certainly don't 
>>> object to LimeWire trying to make a buck, but if not it could really 
>>> be a nice little feature.
>>>
>>> -Chuck
>>>
>>> Sam Berlin wrote:
>>>
>>>> Hi Charles,
>>>>
>>>>> Is there anything I could do to move along merging in the work 
>>>>> that has already been done to block files?
>>>>
>>>>
>>>>
>>>>
>>>> If you'd like, you can incorporate the code that was on the branch 
>>>> for hashing files into your patch, and then we can merge the whole 
>>>> blocking shebang at once.
>>>>
>>>> > Here is the code... basically (current < total) never seems to 
>>>> evaluate to true.
>>>>
>>>> The 'filtered' display will only be shown if you use the 'filter 
>>>> results' tab on the left of the search results.  The GUI doesn't 
>>>> keep track of results that the core has thrown away (because they 
>>>> were blocked).
>>>>
>>>>> In a related issue, does LimeWire really want to report the total 
>>>>> number of all hosts (including alternates) in the tab title?  It 
>>>>> seems to me that it would make more sense to only show the number 
>>>>> of unique results, as that is a much more meaningful number for 
>>>>> the end user.  I could fix that pretty easily I think.  Would a 
>>>>> patch for that be accepted?
>>>>
>>>>
>>>>
>>>>
>>>> We used to display the unique results, but after 'filter results' 
>>>> were added, we changed to the number of sources.  Users like seeing 
>>>> high numbers. :)
>>>>
>>>> Thanks,
>>>>  Sam
>>>>
>>>> _______________________________________________
>>>> discuss mailing list
>>>> [email protected]
>>>> http://www.limewire.org/mailman/listinfo/discuss
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> [email protected]
>>> http://www.limewire.org/mailman/listinfo/discuss
>>
>>
>>
>
> _______________________________________________
> discuss mailing list
> [email protected]
> http://www.limewire.org/mailman/listinfo/discuss


_______________________________________________
discuss mailing list
[email protected]
http://www.limewire.org/mailman/listinfo/discuss