Re creating patches with svn diff that include files that are not under version control yet... I know this is possible with TortoiseSVN (it defaults to including all modified files in the patch, but lists unversioned files and allows you to check them, so it is possible, and I think it basically uses svn diff underneath)..
With some testing, you can do this by "svn add"ing the files you wish, then performing the diff -- with the files added (even if not known by the repository), they will be included. If you then subsequently want to remove the add flag, you'll have to "svn rm" them -- but beware! if they haven't been committed, then they won't be removed unless you add "--force" - and if you add that, the files will be deleted -- so make sure you copy them somewhere first to keep your changes. (course, you'll also have the patch file now too, so you will have the changes).. Anyway -- that's how it can be done. On 7/27/07, Alexander Boreham <[EMAIL PROTECTED]> wrote: > > Hi, > > Sorry I haven't got back to this sooner. I've now had a chance to look > into > this a little more. Adopting these changes from XMR-70 to use the > non-windows message queue makes a huge difference to the issue seen. > > I've started creating a patch file but am not sure how to handle the > addition of new files (NonWin32Queue.cpp and NonWin32Queue.h) using 'svn > diff' or how to make sure these are added to all the project files. As > they're for Windows only I assume we can leave the Makefiles alone. > > I've attached what I've got already in case this is suitable for a > preliminary check. I haven't yet tested applying the patch though but will > do that on Monday. > > The following threads are explicitly set to be highest priority: > m_hMessageThread, m_TimerThread. Also in the changes is one that makes > threads created through OsTaskWnt to be given highest priority. I plan to > undo this last change but don't know if I should also undo the first two > priority changes. Again, I'll try undoing these on Monday and just > checking > everything still works okay. I can understand these two threads needing to > be very responsive. > > I'm sure there is still another problem with going silent but I doubt I'll > have a chance to investigate this any further. My suspicion is that the > cyclic jitter buffer is replacing entries before they're being played and > therefore the decoder is always looking for entries with older timestamps > that have been removed. I can't verify this though so it's only a guess. > > Thanks, > Alex > > -----Original Message----- > From: Alexander Chemeris [mailto:[EMAIL PROTECTED] > Sent: 13 July 2007 16:56 > To: stipus > Cc: Alexander Boreham; [email protected] > Subject: Re: [sipxtapi-dev] Silence on Windows Minimise / SipXmediaMpdSip > xPcma::decodeIn fun ction drops RTP Packets > > On 7/13/07, stipus <[EMAIL PROTECTED]> wrote: > > I haven't changed thread priorities.... I have just installed the Non > > Windows Message Queue. > > Could you attach your patch to XMR-70 too? > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 > _______________________________________________ > sipxtapi-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ > -- Keith Kyzivat SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
