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

Hi,

IMO the simplest solution would be a diff of file-filter and your local 
copy. The people at LW can apply the patch on the file-filter branch 
and merge the whole thing with the mainline. This will preserve the 
consistency of the CVS repository and won't create a ton of conflicts 
if somebody continues to work on the file-filter branch... Or am I 
missing something?

Well, I'd like to highlight the book "Open Source Development with 
CVS"[1]. It isn't a reference book for CVS (it has no index how to do 
this or that) but describes quite well the development process in an 
open source project. Starting with the 3rd edition is the entire book 
released under GPL.

cu
  Roger

[1] http://cvsbook.red-bean.com

On Apr 4, 2005, at 10:56 PM, Sam Berlin wrote:

> Hey Chuck,
>
> I'm sure there's other folks that are interested in some CVS pointers, 
> as well as some talk of how to create patches for LW -- so the 
> discussion is probably best kept to the list.  It's also good so that 
> I don't accidentally lose track  -- someone else here can take over 
> (or remind me).
>
> The discussion is probably better suited to either 
> [email protected] or [email protected], and the ultimate 
> patch to [email protected] -- but discuss isn't "wrong" per 
> say -- discuss has historically been for more business-oriented 
> discussion, although all the lists have very low traffic, and I don't 
> think anyone's complaining.
>
> 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