From: Florian J. <flo...@gm...> - 2013-04-27 22:58:11
Attachments:
signature.asc
|
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 |
From: Florian J. <flo...@we...> - 2013-04-28 11:08:02
Attachments:
signature.asc
|
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)? 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 > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer |
From: nilitonilito n. <nil...@ho...> - 2013-05-11 07:16:22
|
Hi guys, sorry if my comment is out of place, I didn't follow the thread. Why don't you move to github? it's *way* better than svn, branching and merging is very natural. I've already created several projects under github and I can assist you if you need any help. You'll enjoy much more committing changes with git and github will make more likely for outsiders to submit patches. If you are an Emacs user you can use magit, a very well designed front-end for git. Nil Date: Mon, 29 Apr 2013 08:17:30 +0200 From: flo...@we... To: lmu...@li... Subject: Re: [Lmuse-developer] status and svn sucks Am 29.04.2013 03:19, schrieb Tim E. Real: > 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. does it ask if you use svn commit from the command line? if yes, then you did something wrong. Does it ask you for your sf.net password, or for the ssh-key passphrase? > > 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. did he merge stuff, or just commit into trunk? (Committing to trunk works without issues. If someone knows how to merge, tell me!) > > Yikes... Sweating and nail-biting in apprehension of impending disaster...? it's not THAT bad. read svn help diff and man patch (especially the --merge option) you can do manual merging by svn diff-ing trunk from revision foo to HEAD, and then applying this patch using patch --merge to your branch. HOWEVER, this will break svn merging even more. i'll need to contact sf.net :/ 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 Lmu...@li... https://lists.sourceforge.net/lists/listinfo/lmuse-developer |
From: Tim E. R. <ter...@ro...> - 2013-04-29 01:19:26
|
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 |
From: Florian J. <flo...@we...> - 2013-04-29 06:17:37
Attachments:
signature.asc
|
Am 29.04.2013 03:19, schrieb Tim E. Real: > 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. does it ask if you use svn commit from the command line? if yes, then you did something wrong. Does it ask you for your sf.net password, or for the ssh-key passphrase? > > 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. did he merge stuff, or just commit into trunk? (Committing to trunk works without issues. If someone knows how to merge, tell me!) > > Yikes... Sweating and nail-biting in apprehension of impending disaster...? it's not THAT bad. read svn help diff and man patch (especially the --merge option) you can do manual merging by svn diff-ing trunk from revision foo to HEAD, and then applying this patch using patch --merge to your branch. HOWEVER, this will break svn merging even more. i'll need to contact sf.net :/ greetings, flo |
From: Tim E. R. <ter...@ro...> - 2013-04-29 07:45:19
|
On April 29, 2013 08:17:30 AM Florian Jung wrote: > Am 29.04.2013 03:19, schrieb Tim E. Real: > > 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. > > does it ask if you use svn commit from the command line? if yes, then > you did something wrong. > Does it ask you for your sf.net password, or for the ssh-key passphrase? Well it's kinda weird. Notice the SF project page presents three options for downloading. If I use the http method it asks for my SF password I think IIRC. If I use the svn ssh method it asks for my passphrase, I think. Can't remember exactly. > > > 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. > > did he merge stuff, or just commit into trunk? (Committing to trunk > works without issues. If someone knows how to merge, tell me!) I think it was just regular commiting to trunk. > > > Yikes... Sweating and nail-biting in apprehension of impending > > disaster...? > > it's not THAT bad. read > svn help diff > and > man patch > (especially the --merge option) > you can do manual merging by svn diff-ing trunk from revision foo to > HEAD, and then applying this patch using patch --merge to your branch. > > HOWEVER, this will break svn merging even more. > > i'll need to contact sf.net :/ Mm, dunno maybe there's something not done right see what Robert says first. ------- Just wanted to say to my dismay I found some flaws in my existing sample-accurate methods (in trunk + released) especially in regards to the automation modes like touch mode. For example it was possible for it to sound really crappy while operating a control or external midi-to-audio assignment control in say, touch mode, under certain conditions. (If play head was stopped on a section of audio automation graph with a fairly steep slope between two fairly close points.) So I've finally just solved these problems. The benefit is that operating controls in all the modes should be better now. If all goes well you should be able to even override automation READ mode - until play-head seek or start play. Even with external controls or GUI controls for which we don't have access to 'pressed' and 'released' signals. And I cleaned up some silly stuff with pressed/released/adjusted GUI controls and so on. This is on top of (if you read what I posted recently) speed boosts and fixes, including what you pointing out months ago about the sample-accurate stuff having potential speed bottle necks. Including new sample-accurate track and slew-rate limited controllers like volume and pan. Standardized to open the door for easy addition of future controllers like *cross* *fading* and so on. So all this stuff is audio engine and processing chain fixes and improvements. Audio engine rewrite number 3 Gazillion. I do not believe this should affect your new sub-tick and pos/length branch - as it currently stands in regards to audio controllers. It's just audio processing stuff with improved audio controllers. ---- Now, the other thing I really wanted to say is that while I was in the engine, I made the *meters* stay on all the time *regardless* of muting. So you guys can now check levels *before* hitting that (un-)mute button to let the sound through. 'Tis a small thing but just wanted to let you know. This kind of thing could be in conjunction with the concept of *monitor* or *cue* outputs, but as I pointed out earlier our tracks are rather 'generalized'. Someone began to include a monitor buffer but it is not used at all. Maybe in the future I can find a way to provide a dedicated monitor/cue buss and outputs. Tim. |
From: Robert J. <spa...@gm...> - 2013-05-01 12:29:41
|
2013/4/29 Florian Jung <flo...@we...>: > Am 29.04.2013 03:19, schrieb Tim E. Real: > >> 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. > > does it ask if you use svn commit from the command line? if yes, then > you did something wrong. > > Does it ask you for your sf.net password, or for the ssh-key passphrase? > >> >> 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. > > did he merge stuff, or just commit into trunk? (Committing to trunk > works without issues. If someone knows how to merge, tell me!) Man, that sucks! :( Unfortunately I haven't tried merging either. > >> >> Yikes... Sweating and nail-biting in apprehension of impending disaster...? > > it's not THAT bad. read > > svn help diff > > and > > man patch > > (especially the --merge option) > > you can do manual merging by svn diff-ing trunk from revision foo to > HEAD, and then applying this patch using patch --merge to your branch. > > HOWEVER, this will break svn merging even more. > > i'll need to contact sf.net :/ Sounds like a good idea before trying the worse scenario atleast. Regards, Robert > > greetings, > flo > |
From: Florian J. <flo...@we...> - 2013-05-11 13:59:09
Attachments:
signature.asc
|
Am 11.05.2013 09:16, schrieb nilitonilito nilitonilito: > Hi guys, > > sorry if my comment is out of place, I didn't follow the thread. > > Why don't you move to github? i encouraged them to use git before, but iirc they said "but svn works" :) maybe we now have a reason to move. > > it's *way* better than svn, branching and merging is very natural. > I've already created several projects under github and I can assist > you if you need any help. can we carry over our svn history? I tried with git-svn, but i ended up with lots of different trunks, and a pretty broken history. If you can do it better, please tell me! > > You'll enjoy much more committing changes with git and github will > make more likely for outsiders to submit patches. That's worth a consideration. I think we need this kind of support! Just one note about github vs bitbucket vs sf.net vs self-hosted. What's the specific benefit of github? @Others: discuss! greetings flo |
From: Robert J. <spa...@gm...> - 2013-05-11 14:12:41
|
Hi guys, 2013/5/11 Florian Jung <flo...@we...>: > Am 11.05.2013 09:16, schrieb nilitonilito nilitonilito: >> Hi guys, >> >> sorry if my comment is out of place, I didn't follow the thread. >> >> Why don't you move to github? > > i encouraged them to use git before, but iirc they said "but svn works" :) > > maybe we now have a reason to move. True true, can't remember if I voiced an opinion. In any case I'm not against switching, especially if svn _does_ make certain things a pain. There does seem to be some necessary work involved with a move though. - selecting a host - moving the repo to git (as you comment on below, the history may be hard to preserve) - changing documentation - learning git >> >> it's *way* better than svn, branching and merging is very natural. >> I've already created several projects under github and I can assist >> you if you need any help. I never tried git, it seem a bit different.. I'm sure it can't be all roses? > > can we carry over our svn history? I tried with git-svn, but i ended up > with lots of different trunks, and a pretty broken history. > > If you can do it better, please tell me! > >> >> You'll enjoy much more committing changes with git and github will >> make more likely for outsiders to submit patches. > > That's worth a consideration. I think we need this kind of support! > > > Just one note about github vs bitbucket vs sf.net vs self-hosted. > > What's the specific benefit of github? > > @Others: discuss! > > greetings > flo Regards, Robert |
From: nilitonilito n. <nil...@ho...> - 2013-05-11 20:23:38
|
> > i encouraged them to use git before, but iirc they said "but svn works" :) > > > > maybe we now have a reason to move. > > True true, can't remember if I voiced an opinion. > In any case I'm not against switching, especially if svn _does_ make > certain things a pain. > > There does seem to be some necessary work involved with a move though. > - selecting a host > - moving the repo to git (as you comment on below, the history may be > hard to preserve) > - changing documentation > - learning git > > > >> > >> it's *way* better than svn, branching and merging is very natural. > >> I've already created several projects under github and I can assist > >> you if you need any help. > > I never tried git, it seem a bit different.. I'm sure it can't be all roses? The only drawback of git is that its inner logic is bit more complicated than svn's, but that's probably an unavoidable price to pay for a distributed revision control system. The main advantages are: 1) committing is very efficient and can be done offline 2) branching/merging too The way you work with git is different than svn, you create branches all the time, almost every time you have a new functionality to add, you commit^N to that branch (you can do smaller/cleaner commits, if the code breaks between 2 commits it's not a big deal), then once you're happy with it you merge to the master. The revision history in git is not linear. For github the main advantage is the way it handles outsider contributions, really really easy, easier than bzr/launchpad, and of course easier than sourceforge (as you pretty much need to have write privilege, that or you send a patch to the list). Nil > > > > > can we carry over our svn history? I tried with git-svn, but i ended up > > with lots of different trunks, and a pretty broken history. > > > > If you can do it better, please tell me! > > > >> > >> You'll enjoy much more committing changes with git and github will > >> make more likely for outsiders to submit patches. > > > > That's worth a consideration. I think we need this kind of support! > > > > > > Just one note about github vs bitbucket vs sf.net vs self-hosted. > > > > What's the specific benefit of github? > > > > @Others: discuss! > > > > greetings > > flo > > Regards, > Robert |
From: nilitonilito n. <nil...@ho...> - 2013-05-11 20:04:59
|
> > > > it's *way* better than svn, branching and merging is very natural. > > I've already created several projects under github and I can assist > > you if you need any help. > > can we carry over our svn history? I tried with git-svn, but i ended up > with lots of different trunks, and a pretty broken history. > > If you can do it better, please tell me! I'm sure you can do that without losing the history (I actually did it once but I forgot the details). I'll try if I've got time (tomorrow perhaps). > > > > > You'll enjoy much more committing changes with git and github will > > make more likely for outsiders to submit patches. > > That's worth a consideration. I think we need this kind of support! > > > Just one note about github vs bitbucket vs sf.net vs self-hosted. > > What's the specific benefit of github? Frankly I don't know, I only know github, maybe it isn't the best, I can only assert that it's better than what sourceforge offers, interface-wise for the least. Nil > > @Others: discuss! > > greetings > flo > |
From: Florian J. <flo...@we...> - 2013-05-12 06:08:29
Attachments:
signature.asc
|
Am 11.05.2013 22:40, schrieb Tim E. Real: > I remember when Git was created by Linus for kernel development, > and I've checked out some code here and there but didn't know > more about it. I have read before about DVCS systems. > > Studying more today, seems there's more than just 'switching to Git' involved. > By it's nature, DVCS is a philosophical and operational change too. I think we shall definitely switch to a DVCS. Just unsure whether git or hg aka mercurial. git seems a lot more hackish and flaky than mercurial. I indeed had a bit of pain (MUCH less pain than with svn, however!) with git. None with hg so far. > > SF can host Git, apparently we just turn on a settings checkbox. > > Just wanted to point out something I read, may be important: > Github no longer allows separate non-versioned file uploads (binaries etc). > https://github.com/blog/1302-goodbye-uploads > http://sourceforge.net/blog/github-projects-downloads-are-welcome/#comments > > So we'd still need a host for the binaries and so on, right? muse-sequencer.org? I can also host stuff and/or the repo on my own server. > And what about importing tracker data? What about discussion board? again, muse-sequencer.org? greetings, flo |
From: Tim E. R. <ter...@ro...> - 2013-05-11 20:40:23
|
On May 11, 2013 04:12:35 PM Robert Jonsson wrote: > Hi guys, > > 2013/5/11 Florian Jung <flo...@we...>: > > Am 11.05.2013 09:16, schrieb nilitonilito nilitonilito: > >> Hi guys, > >> > >> sorry if my comment is out of place, I didn't follow the thread. > >> > >> Why don't you move to github? > > > > i encouraged them to use git before, but iirc they said "but svn works" :) > > > > maybe we now have a reason to move. > > True true, can't remember if I voiced an opinion. > In any case I'm not against switching, especially if svn _does_ make > certain things a pain. > > There does seem to be some necessary work involved with a move though. > - selecting a host > - moving the repo to git (as you comment on below, the history may be > hard to preserve) > - changing documentation > - learning git > > >> it's *way* better than svn, branching and merging is very natural. > >> I've already created several projects under github and I can assist > >> you if you need any help. > > I never tried git, it seem a bit different.. I'm sure it can't be all roses? > > can we carry over our svn history? I tried with git-svn, but i ended up > > with lots of different trunks, and a pretty broken history. > > > > If you can do it better, please tell me! > > > >> You'll enjoy much more committing changes with git and github will > >> make more likely for outsiders to submit patches. > > > > That's worth a consideration. I think we need this kind of support! > > > > > > Just one note about github vs bitbucket vs sf.net vs self-hosted. > > > > What's the specific benefit of github? > > > > @Others: discuss! > > > > greetings > > flo > > Regards, > Robert > I remember when Git was created by Linus for kernel development, and I've checked out some code here and there but didn't know more about it. I have read before about DVCS systems. Studying more today, seems there's more than just 'switching to Git' involved. By it's nature, DVCS is a philosophical and operational change too. SF can host Git, apparently we just turn on a settings checkbox. Just wanted to point out something I read, may be important: Github no longer allows separate non-versioned file uploads (binaries etc). https://github.com/blog/1302-goodbye-uploads http://sourceforge.net/blog/github-projects-downloads-are-welcome/#comments So we'd still need a host for the binaries and so on, right? Seems Github is geared towards developers and SF is friendlier for end users. (The new SF interface: Not sure if I like it over the old - must try more.) And what about importing tracker data? What about discussion board? Tim. |
From: nilitonilito n. <nil...@ho...> - 2013-05-12 06:58:44
|
>I think we shall definitely switch to a DVCS. Just unsure whether git or >hg aka mercurial. I've read/watched very good stuff about hg, but never tried it. My only advice would be to stay away from bzr, it has some serious design flaws and it's slow, at the end you pay for the "simplicity". Nil ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Lmuse-developer mailing list Lmu...@li... https://lists.sourceforge.net/lists/listinfo/lmuse-developer |
From: Joachim S. <js...@la...> - 2013-05-14 16:05:08
|
i would recommend github (or gitorious). and i would have changed muse-sequencer to git. On 05/12/2013 08:58 AM, nilitonilito nilitonilito wrote: > >>I think we shall definitely switch to a DVCS. Just unsure whether git or >>hg aka mercurial. > > I've read/watched very good stuff about hg, but never tried it. > > My only advice would be to stay away from bzr, it has some serious design flaws and it's slow, at the end you pay for the "simplicity". > > Nil > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is > the definitive new guide to graph databases and their applications. This > 200-page book is written by three acclaimed leaders in the field. The > early access version is available now. Download your free book today! > http://p.sf.net/sfu/neotech_d2d_may > _______________________________________________ Lmuse-developer mailing > list Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > > > > _______________________________________________ > Lmuse-developer mailing list > Lmu...@li... > https://lists.sourceforge.net/lists/listinfo/lmuse-developer > |
From: Tim E. R. <ter...@ro...> - 2013-05-14 23:10:38
|
No comments here, just to say... Hello Joachim ! Nice to hear from you. Thanks for your help on the site and so on. As always, if any concerns speak up, eh... Thanks. Tim. On May 14, 2013 05:49:04 PM Joachim Schiele wrote: > i would recommend github (or gitorious). and i would have changed > muse-sequencer to git. > > On 05/12/2013 08:58 AM, nilitonilito nilitonilito wrote: > >>I think we shall definitely switch to a DVCS. Just unsure whether git or > >>hg aka mercurial. > >> > > I've read/watched very good stuff about hg, but never tried it. > > > > My only advice would be to stay away from bzr, it has some serious design > > flaws and it's slow, at the end you pay for the "simplicity". > > > > Nil > > |
From: Florian J. <flo...@we...> - 2013-05-15 10:29:42
Attachments:
signature.asc
|
ok so we all agree that we want to move to one of {github, bitbucket} and {git,mercurial}. just, which of the three combinations (git,github), (git, bitbucket) and (mercurial, bitbucket) do we want? github is free-of-charge for open-source projects. bitbucket is even more free-of-charge, because it also allows "small" closed-source projects. but as this is not a problem for us, and because bitbucket seems to be a not-so-good plagiate of github, i'd vote against (git, bitbucket). So do we want to use git (and github) or mercurial (and bitbucket) then? i have used both systems a bit, but not much (only locally, committing and a tiny bit of branching), and have seen no real difference. vote! greetings, flo |
From: Geoff B. <ge...@la...> - 2013-05-15 12:27:08
|
On 05/15/2013 08:29 PM, Florian Jung wrote: > ok so we all agree that we want to move to one of {github, bitbucket} > and {git,mercurial}. > > just, which of the three combinations (git,github), (git, bitbucket) and > (mercurial, bitbucket) do we want? > > github is free-of-charge for open-source projects. bitbucket is even > more free-of-charge, because it also allows "small" closed-source projects. > > but as this is not a problem for us, and because bitbucket seems to be a > not-so-good plagiate of github, i'd vote against (git, bitbucket). > > > So do we want to use git (and github) or mercurial (and bitbucket) then? > > i have used both systems a bit, but not much (only locally, committing > and a tiny bit of branching), and have seen no real difference. > > vote! > > greetings, > flo > as a simple dumb-arsed user I find github no problem at all, so it gets my vote as a repo at least. easy to use from my pov and works fine. best g |
From: Florian J. <flo...@we...> - 2013-05-15 19:05:46
Attachments:
signature.asc
|
Hi git/hg have different convention regarding the committer names: SVN uses some kind of username, while git uses Real Name <em...@ex...>, where the email part is not neccessary. please tell me the Real Name <mail> mapping you wish for your commits (i think you safely can provide an email adress, spambots can already search the mailing list archives anyway.) otherwise i'll use the Name+Mail i saw from your Mails to the list. Does anybody know the mail addresses (and if those people want this) from: franky aka Frank Neumann lunar_shuttle aka Mathias Lundgren qknight aka Joachim Schiele a-lin aka Nil Geisweiller a user->Name mapping of any of the OOM folks? (is that correct so far?) greetings flo |