On April 28, 2013 01:07:52 PM Florian Jung wrote: > fail. > > recreating the branch leads to the same error: > > regardless whether you check out branches/poslen_changes or > branches/poslen_changes_old, > > when you do a > > svn merge ^/trunk > > in the root directory, it just tells me: > > flo@thinkpad:~/muse-svn/plc2$ svn merge ^/trunk/ > -- Merging from r2 to r1739 in ».«: > C muse2 > C muse > > this is wrong. it shall merge from r1739, not r2. > also, there are no conflicts, cannot be, because there were no changes. > > and especially there cannot be any conflicts for the muse and muse2 > directories itself > > (svn status later says: > C muse2: Deleted incoming and deleted locally > C muse: Created incoming and created locally) > > > -> i cannot merge any more :(. what's wrong here? tim, did you have > similar issues with your branch(es)?
Wow, I haven't even tried to merge the stuff I'm working on, into local copies of the new repo yet. So I'm not even at the stage where I can commit to the new repo. Hopefully soon... Actually I have not even attempted to update my older local repo copies yet with new material from the new repo. But as I posted earlier I'm a bit frustrated that I must now supply a password *every* time I want to download or update my local copy of the new repo - even *every* time I simply open the repo in KdeSvn simply to examine it ! Seems that something still may not be right, I've set up my SSH and so on, and it still asks for a password when I just want to examine the repo in KdeSvn. So I'm kind of worried what's going to happen when I finally complete my (long awaited months-long) current work and sit down and try to merge - both to and from the new repo. Robert seems to have had no trouble at all committing new stuff, although that's not the same as what you and I are faced with - his was fresh new stuff I think, but we both have back-logged material that needs to be merged - both to and from the new repo. Yikes... Sweating and nail-biting in apprehension of impending disaster...? Tim. > > greetings > flo > > Am 28.04.2013 00:58, schrieb Florian Jung: > > Hi > > > > just to let you know that i'm getting into working on MusE again: > > > > the svn update seems to have broken merging branches, at least for the > > poslen branch > > > > real men don't use svn merge, they apply 4MB-patches by hand. (or, let > > patch do the work and clean up after patch by hand.) > > > > this will probably become a horrible mess when merging back (probably > > exactly the same as now), but let's hope it will work :) > > > > > > I haven't tested stuff yet, but at least it compiles. Can't be *that* > > broken :) > > > > -- > > > > UPDATE: i really, really hate SVN. i hope svn will suffer a slow, > > painful death (it actually is quite good at being slow and painful > > anyway.) > > > > now recreating the branch, my merging attempts failed -.- > > > > [/update] > > > > -- > > > > > > My immediate plans are now: > > > > (this is already done: add subtick-resolution) > > > > - make 'clone parts' not share EventList pointers any more. Rather keep > > > > redundant data in the memory. Memory is cheap, you know. > > (Large audio data still will be cached, redundancy-free.) [1] > > > > - Change the whole process(dataFrom, dataEnd) (sounds like random > > > > access, which is a lie) semantics to getMoreData(howMuch) (sounds > > like stream access, which is true) > > > > that made: > > - each wave event will have a private AudioStream object (clones of the > > > > "same" event will have *different* AudioStreams [1] > > > > - These AudioStreams will unite and manage the following components: > > - read data from disk, or cache, or whatever > > - decode this data, if it was OGG/FLAC or the like > > - possibly do sample-rate-conversion > > - possibly do time-stretching or pitch-shifting > > > > They will only provide a function like > > getMoreData(howManySamples, currentSamplingRate, stretchFactor, pitch) > > (currentSamplingRate shall not change upon calls. howManySamples is > > the number of samples *returned*. Internally, probably a different > > number is fetched (especially when stretching/converting sampl.rates) > > > > - These AudioStreams may cache, do fancy stuff or whatever. The caller > > > > never sees what happens under the hood. > > > > - add some "original tempo" structure to wave events > > > > > > > > if you have urgent feedback about this, please tell me :) > > > > greetings, > > flo ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
