Re: Version control tools
Joseph Rushton Wakeling writes: > On 08/01/14 21:13, David Kastrup wrote: > >> At the current point of time, due to a discussion about version >> control on the Emacs developer list, I am working on git blame which >> is ridiculously slow. For the file src/xdisp.c, it takes about 2 >> minutes on my computer. I've cut it down by some 20 or 30% on the >> first attempt, but with my current approach, I should eventually get >> it down to few seconds at most. At the current point of time, it >> segfaults almost instantaneously. One out of two ain't bad... >> >> Ridiculous that this code has not been sensibly improved over the last >> 10 years or so... > > It's a surprise to me, certainly. What do you think of the Facebook > developers' contention that Git's internals would be difficult to work > with if serious scaling gains are desired? Well, I'll answer like Gandhi when asked "Mr Gandhi, what do you think of Western civilization?": "I'd consider it a good idea.". I've taken a look at some of the difference machine internals (that's basically git's workhorse) and found out that optimizations I did in 2006 or so have not been superseded. Now it's hard to get those much faster but it was still sort of a surprise that the core stayed pretty much the same. It's mostly the callers who get some polish, and options, and utf-8 message re-/encoding and such things. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On 07/01/14 14:51, Urs Liska wrote: I don't think it would be advisable to encourage any _new_ user to learn SVN or CVS (if it isn't for a specific project of interest), but for your use case this is surely a valid question. One way in which svn can still be useful is in cases where you want the code but don't care about having a local copy of the version history. Example: recently I needed the latest gcc trunk source. Cloning via git-svn or bzr-svn proved extraordinarily slow and painful simply because the history was so large; taking a svn checkout was much quicker and easier, and (obviously) also used far less disk space; and it was completely adequate to purpose, because all I wanted was the ability to keep the code up to date, not to commit to it myself. I do wonder if this is one of the reason why some projects keep svn as the main VCS, using git or other DVCS mirrors for those who want to use them. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On 08/01/14 21:13, David Kastrup wrote: Actually, that seems like a mischaracterization to me. It's the single file logs which aren't cheaper than the multi-file logs. You could be right. In any case, the Facebook devs are claiming wins for all change-related commands, including status, diff, update and commit: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ At the current point of time, due to a discussion about version control on the Emacs developer list, I am working on git blame which is ridiculously slow. For the file src/xdisp.c, it takes about 2 minutes on my computer. I've cut it down by some 20 or 30% on the first attempt, but with my current approach, I should eventually get it down to few seconds at most. At the current point of time, it segfaults almost instantaneously. One out of two ain't bad... Ridiculous that this code has not been sensibly improved over the last 10 years or so... It's a surprise to me, certainly. What do you think of the Facebook developers' contention that Git's internals would be difficult to work with if serious scaling gains are desired? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Joseph Rushton Wakeling writes: > On 08/01/14 19:40, Yann wrote: >> With hg, each clone of a repository IS a complete repository itself. So your >> "working copy" is a repository itself (the main folder just contains a hidden >> .hg folder with all the history data). I feel this is an advantage over svn >> when >> working locally, as your data and the history are at the same place. > > Exactly, as with git (which Lilypond uses) and bzr (a very nice tool > as well, but now sadly somewhat neglected). > > If reddit is to be believed, it looks like hg has picked up a bunch of > recent interest and investment from Facebook in order to optimize > things like single-file diffs (which in git are no less expensive than > whole-repo diffs). Actually, that seems like a mischaracterization to me. It's the single file logs which aren't cheaper than the multi-file logs. At the current point of time, due to a discussion about version control on the Emacs developer list, I am working on git blame which is ridiculously slow. For the file src/xdisp.c, it takes about 2 minutes on my computer. I've cut it down by some 20 or 30% on the first attempt, but with my current approach, I should eventually get it down to few seconds at most. At the current point of time, it segfaults almost instantaneously. One out of two ain't bad... Ridiculous that this code has not been sensibly improved over the last 10 years or so... -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On 08/01/14 19:40, Yann wrote: With hg, each clone of a repository IS a complete repository itself. So your "working copy" is a repository itself (the main folder just contains a hidden .hg folder with all the history data). I feel this is an advantage over svn when working locally, as your data and the history are at the same place. Exactly, as with git (which Lilypond uses) and bzr (a very nice tool as well, but now sadly somewhat neglected). If reddit is to be believed, it looks like hg has picked up a bunch of recent interest and investment from Facebook in order to optimize things like single-file diffs (which in git are no less expensive than whole-repo diffs). So for those interested in these tools, it might be worth giving it a try. Perhaps the DVCS landscape is not as settled as it has looked recently ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Hello :) I used to work with svn some years ago (I learned it for programming at first). I mostly then used GUIs with it (TortoiseSVN on windows and kdesvn on linux). Then I moved to Mercurial (hg) after comparing between different softwares. One of the main reason I chose it over git was the availability of a good GUI on windows (TortoiseHG works very well and is integrated both with windows explorer and nautilus under linux/gnome). I also sometime use the command line directly, but mostly for administration tasks or scripting. I frequently use an addon to hg called mercurial-queues (mq) that allow to work on a patch queue. So most of the time, I use patches to try some new things (in scores also), or can switch between different queues depending on which project I work on (each change on patches can be versionned in a secondary repository). When things get a little more stable, I commit changes to the main repository, and I can push to a server if I'm working on a shared project (I guess hg and git are quite similar in term of possible workflows). To the question : > Simon Bailey: > > so, my follow up question: why use git as a single user? The main advantage I would see on using hg (but I think it is the same with git) over svn, as a single user, is that : in svn, you basically (if I'm not mistaken) need both the repository itself (either local or distant) and a local checkout/working copy. If by any chance by mistake you delete the repo folder, then all your history is lost (er... yes, I did it once). With hg, each clone of a repository IS a complete repository itself. So your "working copy" is a repository itself (the main folder just contains a hidden .hg folder with all the history data). I feel this is an advantage over svn when working locally, as your data and the history are at the same place. Yann ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools (was: Survey: Git (G)UIs)
Am 2014-01-07 um 19:27 schrieb Urs Liska : > As a follow-up question I'd be interested in whether people use other version > control systems beside Git. If you use more than one, a short comparison > would be of general interest I think. Hi Urs, I’m using everything that I need to fetch some project - I never needed something else than svn, git and hg (hm, there was that one project on bzr …), but personally only git. I guess hg is marginally better or simpler to learn, but I started with github and not bitbucket. Greetlings, Hraban ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Hi Simon, I just listed the reasons why I use git in general. And I like having one system for all version control use cases. You are right, the advantages apply more to software than to scores. > > - easy branching > what for when working with scores? Rarely in scores. But I use branches for the lily library for includes/modules I use it for different feature branches, which I only merge once they are done/usable. > > - I am a heavy user of git rebase > which does what? It takes a branch, decouples it from its connection to the rest and puts it on top of another given branch. That makes the history easier to read. If you consider this situation, the master advanced (e.g. with a ready feature) and now 'feature' is ready I could merge it. But I like to put it after the master commits: o--o--o--o--o--o master \ '-o--o--o feature git rebase master master o--o--o--o--o--o--o--o--o feature > > - being able to commit, branch, diff etc. without internet connection > how often do you branch or diff when working on scores? see above > > that way I can work on a train, for example > > > hmm. i do a lot of work on trains. however, i have a data plan on my > phone which i use for tethering if i need a connection. I don't have. For me the situation is this: I had the choice to learn svn or git and I chose git for the beforementioned reasons. And I like to use one system for all purposes. But I see no point in converting others to git if they prefer svn and like it. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Am 08.01.2014 11:24, schrieb Simon Bailey: hi, On Wed, Jan 8, 2014 at 10:20 AM, mailto:k...@aspodata.se>> wrote: Joram: > Simon Bailey: > > so, my follow up question: why use git as a single user? > > I always use git, event git-svn for svn repos. > Comparing to CVS and SVN, I see these advantages: > > - easy branching what for when working with scores? Did you see http://lilypondblog.org/2014/01/why-use-version-control-for-engraving-scores/ ? There's a section about this specific question. The remaining sections are rather tool-agnostic and apply equally to SVM. Bottom line is: You can use branches to keep master in a consistent state. You can work at different spots in parallel, keeping the whole consistent. > - I am a heavy user of git rebase which does what? > - being able to commit, branch, diff etc. without internet connection how often do you branch or diff when working on scores? > that way I can work on a train, for example hmm. i do a lot of work on trains. however, i have a data plan on my phone which i use for tethering if i need a connection. > - this makes the commit often & early paradigm easy i understand this when working on software programs. but on music scores? It's exactly the same :-) Why would you "commit often and early" in software development? mostly to have fine-grained control on the content of a commit and not to have a big blob of unrelated changes in a unit. That's exactly the same when you write scores. With svn/cvs you need more-or-less a permanent connection to "the server". With git I can work off-line and update (both ways) when connected. i only need the connection with SVN if i'm actually committing. with git i can commit offline, but then when i get a data connection i have to commit again to the repo? that's two steps compared to one with SVN. i still don't get it. especially as i generally commit when i reach certain milestones or at the end of a working day. A Git commit isn't about integrating your work with the main line (remote repository) but about tailoring a coherent changeset. You may enclose your day's work in a commit but you can (as the other extreme) enclose a singly typo fix in a commit. With this you have finegrained control over your project history. Each of these commits is a separate unit and step that can be inspected, reverted or modified individually later. When you contact the server again you don't "commit" (in Git speech) but "push" your local commits to the server. Obviously that's not what you're doing so far, so you don't miss it. But I'm sure it is superior to be able to "tailor" the commit history locally instead of creating commits depending on the availability of an internet connection. don't get me wrong, i'm really trying to find a reason to like git. but nothing seems different to SVN so far, except for the fact that i have to commit TWICE... Urs also pointed out: On Tue, Jan 7, 2014 at 2:51 PM, Urs Liska mailto:u...@openlilylib.org>> wrote: Ah, finally one idea about your question, not based on experience but on randomly read statements: How can you use branches with SVN? If it's correct that Git branches are conceptually different through being so exceptionally light-weight then I'd think this _is_ an advantage even for a single user. $ svn copy /trunk /branch/my-branch from http://svnbook.red-bean.com/en/1.8/svn.branchmerge.using.html : <<< Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects. >>> sounds fairly lightweight to me too... ;) (this is also the same workflow for tags). Hm, don't know. As said, my comment was based on arbitrary reading. Obviously (from skimming through that linked page) the branching concept between SVN and Git is _very_ different. I can't really judge that, but as far as I've read this area is one of the major improvements of Git over the older VCSs. Urs regards, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user -- Urs Liska www.openlilylib.org ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On Wed, Jan 8, 2014 at 11:24 AM, Simon Bailey wrote: > don't get me wrong, i'm really trying to find a reason to like git. but > nothing seems different to SVN so far, except for the fact that i have to > commit TWICE... > just to clarify: i'm trying to find a reason for using git for my workflow. in other scenarios (such as lily devel work or distributed software development) i know there are benefits/differences and possibilities compared to SVN/CVS or any other centralized source-code repo. regards, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
hi, On Wed, Jan 8, 2014 at 10:20 AM, wrote: > Joram: > > Simon Bailey: > > > so, my follow up question: why use git as a single user? > > > > I always use git, event git-svn for svn repos. > > Comparing to CVS and SVN, I see these advantages: > > > > - easy branching > what for when working with scores? > > - I am a heavy user of git rebase > which does what? > > - being able to commit, branch, diff etc. without internet connection > how often do you branch or diff when working on scores? > > that way I can work on a train, for example > hmm. i do a lot of work on trains. however, i have a data plan on my phone which i use for tethering if i need a connection. > > - this makes the commit often & early paradigm easy > i understand this when working on software programs. but on music scores? With svn/cvs you need more-or-less a permanent connection to > "the server". With git I can work off-line and update (both ways) > when connected. > i only need the connection with SVN if i'm actually committing. with git i can commit offline, but then when i get a data connection i have to commit again to the repo? that's two steps compared to one with SVN. i still don't get it. especially as i generally commit when i reach certain milestones or at the end of a working day. don't get me wrong, i'm really trying to find a reason to like git. but nothing seems different to SVN so far, except for the fact that i have to commit TWICE... Urs also pointed out: On Tue, Jan 7, 2014 at 2:51 PM, Urs Liska wrote: > Ah, finally one idea about your question, not based on experience but on > randomly read statements: How can you use branches with SVN? If it's > correct that Git branches are conceptually different through being so > exceptionally light-weight then I'd think this _is_ an advantage even for a > single user. $ svn copy /trunk /branch/my-branch from http://svnbook.red-bean.com/en/1.8/svn.branchmerge.using.html : <<< Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects. >>> sounds fairly lightweight to me too... ;) (this is also the same workflow for tags). regards, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Joram: > Simon Bailey: > > so, my follow up question: why use git as a single user? > > I always use git, event git-svn for svn repos. > Comparing to CVS and SVN, I see these advantages: > > - easy branching > - I am a heavy user of git rebase > - being able to commit, branch, diff etc. without internet connection > that way I can work on a train, for example > - this makes the commit often & early paradigm easy With svn/cvs you need more-or-less a permanent connection to "the server". With git I can work off-line and update (both ways) when connected. Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
> so, my follow up question: why use git as a single user? I always use git, event git-svn for svn repos. Comparing to CVS and SVN, I see these advantages: - easy branching - I am a heavy user of git rebase - being able to commit, branch, diff etc. without internet connection that way I can work on a train, for example - this makes the commit often & early paradigm easy As I have learned git and svn at the same time, there was no point in really using svn, because I can have the same but much more with git. Cheers, Joram ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
Am 07.01.2014 14:38, schrieb Simon Bailey: On Tue, Jan 7, 2014 at 2:27 PM, Urs Liska mailto:u...@openlilylib.org>> wrote: As a follow-up question I'd be interested in whether people use other version control systems beside Git. If you use more than one, a short comparison would be of general interest I think. i use svn, that's what i know professionally and have been using for more than 10 years (probably closer to 15). for me as a single user, i see no benefit in using git -- i have my SVN repo on a server, and use that as a backup and interchange solution for working on 3 or 4 different computers. on the macs i use cornerstone, windows TortoiseSVN and on linux command line. so, my follow up question: why use git as a single user? this is not a flame-war, i'm genuinely interested in any advantage that git will give me over svn. the most misused argument i hear, "you can check in regularly on your local machine and then send a big check-in to the repository later" doesn't do it for me. i generally check-in once a day, or when changing computers or when a score reaches milestones (initial setup, music entry finished, tweaking finished, final layout, etc.). i don't need to micro-manage my versions every time i add a musical phrase... ;) regards, sb Thanks for the opinion. Unfortunately I can't help you with your follow-up question (due to lack of experience). I don't think it would be advisable to encourage any _new_ user to learn SVN or CVS (if it isn't for a specific project of interest), but for your use case this is surely a valid question. One think I love about decentralized version control systems (which again doesn't apply to your use case) is that you can interact between multiple forks of the repository. For example I can add the repos of all the other Frescobaldi contributors as remotes and fetch their branches before they have even opened pull requests (or the other way round: I can ask others to test my branches before I open a pull request). Or I can collaborate with a given contributor and we prepare a feature branch together before opening the pull request. Ah, finally one idea about your question, not based on experience but on randomly read statements: How can you use branches with SVN? If it's correct that Git branches are conceptually different through being so exceptionally light-weight then I'd think this _is_ an advantage even for a single user. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools (was: Survey: Git (G)UIs)
On Tue, Jan 7, 2014 at 2:27 PM, Urs Liska wrote: > > As a follow-up question I'd be interested in whether people use other > version control systems beside Git. If you use more than one, a short > comparison would be of general interest I think. > i use svn, that's what i know professionally and have been using for more than 10 years (probably closer to 15). for me as a single user, i see no benefit in using git -- i have my SVN repo on a server, and use that as a backup and interchange solution for working on 3 or 4 different computers. on the macs i use cornerstone, windows TortoiseSVN and on linux command line. so, my follow up question: why use git as a single user? this is not a flame-war, i'm genuinely interested in any advantage that git will give me over svn. the most misused argument i hear, "you can check in regularly on your local machine and then send a big check-in to the repository later" doesn't do it for me. i generally check-in once a day, or when changing computers or when a score reaches milestones (initial setup, music entry finished, tweaking finished, final layout, etc.). i don't need to micro-manage my versions every time i add a musical phrase... ;) regards, sb -- Do not meddle in the affairs of trombonists, for they are subtle and quick to anger. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Version control tools (was: Survey: Git (G)UIs)
Am 06.01.2014 13:53, schrieb Urs Liska: Hi all Git users, I'd like to make a survey on how you are working with Git. Thank you all for your feedback! It was very interesting and inspiring for me. Due to its sheer number I can't reply to all opinions individually. Maybe I'll come back to this/these when I'm writing the next blog post. As a follow-up question I'd be interested in whether people use other version control systems beside Git. If you use more than one, a short comparison would be of general interest I think. Urs ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
