Hi, On Sat, Oct 24, 2009 at 01:57:22PM +0200, Arne Babenhauserheide wrote: > Am Samstag, 24. Oktober 2009 06:08:49 schrieb olafbuddenha...@gmx.net:
> Yay, reviving the thread! ;) Sorry, couldn't resist... :-) > If you use the system for tracking your coding and occassionally > merging with changes from others, then you don't have to fully > understand it, since the tracking of changes can be done quite well > without full understanding. > > If you don't have to integrate hundreds of branches, then there's no > merit in learning how to do that efficiently - so it isn't efficient > to have to learn background for that before being able to use the > system efficiently for other stuff. The point is that there is hardly anything you need to learn for specific tasks like integrating many branches -- once you understand the basics, most specific tasks become trivial! And programming is not systematic enough that you can avoid doing all kinds of specific stuff now and then. I claim that *every* regular programmer can profit considerably from being really proficient with the VCS. It's different for a wiki of course -- here indeed the requirements for non-trivial operations are so rare, that learning efficient VCS usage is not likely to pay off... > For me the measure of efficiency is: * Time for initial learning until > I can use it, plus * Time I spend relearning stuff I forget (a major > factor with git for me), plus * Time to learn the new stuff I need and > for optimizing, plus * Time I actually spend using it. > > That calculated for different systems to be able to compare them. > > With git the first and second are quite high (for me) for basic > features like branching and merging (that's why I wrote a guide on > merging the news - I use that guide myself when I prepare the next > news). > > The optimizing part only makes sense, when it saves netto time -> when > I use the system so much that the time I save per usage ??? the number > of times I use it is higher than the time spent on optimizing it. > Since most developers firstly write code and only secondly manage > history, optimizing a git workflow often doesn't make that much sense > (simlarly it doesn't make must sense for most people to write a > Mercurial extension for their individual workflow). You can't measure the efficiency of VCS usage by "the time spent using it". That just doesn't reflect reality. "Managing history", and other VCS usage, is not a separate task -- using the VCS is part of the programming workflow. Efficient VCS usage is about being able to perform my *programming* work in the most efficient manner. > With Mercurial on the other hand, the first is very short and the > third also stays short for the stuff most people need. For example I > never had to work with Mercurial Queues (doing patch reworking), so I > never had to learn how to use them. It's not about what you *have* to do, but about what you *can* do. As I already said at the setout, it is perfectly possible to perform all tasks with only a handful of fixed workflows, and with VCS knowlegde limited only to these few workflows. (In fact, even most git users seem to work that way -- which is a very sad situation indeed :-( ) But that's not efficient. Programming is not a linear or systematic task. When programming, I write a bit of code; while at it, I discover something else I can improve or need to fix; or I realize that I have to change something else first in order to do the change I intended; or I realize that the changes are more complex, and I have to split them up; or I realize that I have to go back and change the approach; or I realize that something I changed in the past didn't make sense after all; or I decide to work on an entirely different thing for now; or I realize that the change I am working on makes more sense in a different branch; or I realize that I forgot to commit something, or commited too much; or I want to try things out, later abandoning them again, or include them in some branch; and so on. These things happen *all the time*; they are part of the normal programming process. All of them require using the VCS in some particular way -- and only with a VCS that allows me to do exactly what I want without ceremony, I can work efficiently. If I have to work around, because the thing I want to do doesn't fit the model of the system; or if I have to learn new functionality to be able to do the thing I want: that's not efficient. (This is where Git scores: the model is so flexible that very few things do not fit in it; and the fundamental concepts so universal, that once I internalized those concepts, I can do almost anything I want -- no matter how unusual -- without needing to learn new things.) Let's take changing history as an example, as this seems to be a major point of contention. You can muse about the meaning of history etc. as much as you like -- but I simply don't buy the (implicit) claim that there are many people and projects who really don't give a damn about how the history looks, when I apply changes back and forth five times while changing my mind, or about loads of micro-commits I do while working on more complex changes. Such a history not only is really ugly to look at, but also makes it virtually impossible to review changes, and totally breaks bisecting. The truth is that no matter what the policy is regarding history: if I can't easily change my mind or do temporary commits without making a mess, this *will* create pressure to avoid doing these things, and thus hamper my productivity: it means I have to try to make up my mind up front, and stick to my decisions even if they prove suboptimal, rather than using the much more efficient approach of trying things out and adapting as I go along. (The only alternative being to refrain from doing any commits at all until I am confident that the decisions were right, resulting in other problems.) It also means I can't use the VCS to track temporary steps while working on larger changes, i.e. I can't make use of the VCS to ease my work. In short: creating temporary commits that are not meant to be part of the permanent public history of a project, is a natural desire of every (normal) developer; and using a VCS that doesn't encourage this, or a VCS that I don't understand well enough to do this with ease and confidence, considerably hampers my efficiency as a developer. > And since git isn't noticeably faster for most common operations, it > simply isn't more efficient (for people who don't need complicated > workflows). For me its overhead for learning and relearning its basics > is too high (though the relearning grows much smaller over time, if > you use it all the time. Yeah, if the Hurd wiki is the only project using Git you are involved with, it might indeed not be worth it to learn it properly. But for anyone doing serious coding, the situation is very different. -antrik-
