Am Samstag 28 Juni 2008 04:24:50 schrieb [EMAIL PROTECTED]: > Well, as you seem to have used Mercurial much more and longer, that > isn't really surprising :-) If I learned Mercurial now, I'd most likely > hold exactly the opposite opinion... That doesn't really tell much.
Please tell me how it works for you, once you have to use it. It would be interesting for me to see your experience from the Git side of DVCSs. (yes I know that sounded silly ;) ) > Honestly, how often did you actually need to GC Git repositories so > far?... :-) I didn't yet have to, but what I heared from other people is about once a month for a halfways active project, and some claim to do it once a day. It would be interesting to have stats about garbage collecting the linux kernel. > Actually, this is much easier with a sanitized history. It's always > clear when and why a change was introduced -- It is only clear that it happened during "implementing feature x", but not that it happened during "hacking that damn network table - quick fix to get it working". > while otherwise, with > omission and later amends, mistakes and later reverts, prototypes and > later cleanups, experiments and later switching approches, it is much > harder to make sense of it. It's just useless data getting in the way. You just let your system search through a batch changesets at once, then it looks the same for the reviewers as modified history, but it offers more information if you need it. But while we're at it: I really like the approach to apply one clear summary to a set of changes, and that wasn't easy in Mercurial till now. So I took a dive into hacking Mercurial for the first time yesterday. It took me some time to get familiar with the code structure, but after some dabbling and discussing in IRC to refine my concept, I came up with the group extension: -> http://selenic.com/pipermail/mercurial/2008-June/019884.html It still is only a proof of concept, but it works for me and supplies the same functionality (hiding away steps which aren't useful for most people) while preserving history. What it does: - Enable me to put changesets into a group. - Hide all grouped changesets from the log and show their groups instead. - Only look at groups. - Also group groups. I can now say hg commit -m "A" -> rev 1 hg commit -m "B" -> rev 2 hg commit -m "C" -> rev 3 hg commit -m "undo B" -> rev 4 hg group -m "AC" 1 2 3 4 And instead of many small commit messages which can't convey a bigger picture, people can see all the changes I grouped with one clear description. On the long run the concept can allow groups to be overridden, removed, modified and inspected (show all contained changesets). You got me quite enthusiastic with the concept of better readable history :) And I was happy to see that writing Mercurial extensions (which can change every aspect of the user interaction) isn't that hard. More exactly: I could do it, so it can't be that hard ;-) > I don't think that when Linus designed Git, he was thinking "it must be > easy to change history". Rather, I suspect that the flexible design of > Git just made changing history easy as a byproduct, along with many > other things considered uncommon up till then. Which is something I am really glad for (but it could also be connected to Git being decentral, advanced _and_ free software, so people knew they could dabble). > Well, such a discussion will always tend to touch more general question. > However, when I was pointing out that it doesn't matter for the Hurd > repository, I was obviously not trying to make a statement about GC in > general, but to come back to the actual topic at hand :-) Then thanks for that. Words often miss the intentions and backgrouns, even though those are often he most important part of a message :-) I miss Telepathy for that :) > By requireing to learn more stuff from the beginning, Git on the other > hand makes every user into an expert -- thus indirectly helps to use the > tool really efficiently... Or makes users frustrated or afraid to touch anything they don't know. This is what often happens when people work on a system where they don't understand how their commands affect the system. --- short philosophical insertion --- System here is "the changes", not "the storage". The changes are what you get as result. The storage is just the technical solution and only matters, where it affects (means: limits or forces to modify) interactions with the changes. o <- me | <- my interactions [-] <- changes | <- interactions of changes and storage [-] <- storage The storage only is of interest, where it changes my and others interactions with the changes. (yes, I actually drew this on paper to visualize what version tracking systems offer me, so I could clear up my thoughts :) ) Naturally, it does necessarily affect them at every stage, but that should be limited to speed of actions (and that also as little as possible), and it should not force me to do a certain action - but that's only my personal philosophy. Since yours is different, I assume you get a different conclusion -> again different priorities, and again, that is a good thing I think :) We just have to be aware of our different priorities - and that is one of results a discussion can always bring, and I think it's worth more than most people think. --- end philosophical insertion --- Mercurial makes reading up on stuff very easy, so it isn't an uphill battle, but rather the joy of learning easily (mainly due to the very good hgbook). Instead of "bah, I don't know how to do this", it rather is "cool, I can do that, too!" And that's where the benefits are, and they are pretty clear, I think. And you only need the basic usage in most cases, so you almost only need to read up on things, if you really try something new. You can't know every nuance from the beginning without losing a vast amount of time. --- I don't know how much the following applies to Hurd contributors. It's one of my general reasons to prefer Mercurial --- I learned about that on much lower scale from my wife who works in a bank. Some of her collegues are simply computer DAUs (dumbest thinkable user - dümmster anzunehmender User), who only do exactly what they were told to do, because they fear that they could break anything if they do something wrong. I know this sound like encouraging to "force every user to learn", but rather the opposite is true: As soon as the basic usage is (or just feels) so complicated that a user gives up on understanding it, trying to "force people to become experts" makes them DAUs instead, who don't feel comfortable in their own environment. And everyone is conservative or afraid to fiddle somewhere, and it can hit you in the damnest of areas when you just have a bad day when starting to learn it. Having a lowest possible frustration potential helps reducing the chance of it, though. > the other variant. Or perhaps it is considered less annoying as a > default action. (Commiting too much by accident if "-a" was default > would be worse than the command simply failing if forgetting the "-a" as > it is now. It's actually something that bothered me with CVS quite > often.) At least for me, having to add the -a wouldn't help me remembering. After having adde it about 20 times, my hands would do it automatically without me even noticing it. And different from Mercurial I'd have to listen to the Git people saying "well, you added the -a switch, so it's your problem; we worked to avoid it", but sadly not in a way which works with humans as I know them :) > I am sure that with most *any* kind of workflow, "-a" is more often used > than not. So it is *not* optimizing for a particular workflow. It is optimizing, just not done consciously. And optimizing for a workflow not used by most people. > Rather, > it's simply a manifestation of Git's interface being very direct; > avoiding abstraction where it's not important to have it. It's a > manifestation, in fact, of *not* optimizing for specific workflows. I would argue against that :) With Mercurial I have good aliases to start with, and when I happen to work at the computer of a collegue, I can use the same commands instantly, and the same goes for him working on my computer. What I think about is: Where most workflows differ, it's useful to tell the user to just create his own aliases. But in most places the workflows will just be very similar or the same, or there will be a few competing workflows which a huge percentage of developers use. And consciously offering precreated aliases for efficiently working in these workflows leads to good usability and a tool you can learn very quickly. Git on the other hand also has these easy commands, but they don't look consciously added to me, but historically grown. > > But checkout doesn't work the same in subversion, which is what I was > > used to before switching to Mercurial. > I really don't care about Subversion. I can see some little merit in > trying to be similar to CVS, because that's the least common > denominator, what has been used for ages, what almost everybody knows. > Subversion on the other hand is nothing else but just the least useful > one among the newer systems. While this isn't really the point here, I want to object. Subversion might not be as advanced as Git or Mercurial, but it is the system many large software projects switched to, and were very happy with, and it seems good enough that it is easy to switch onwards from it. I like subversion, even though I definitely prefer Mercurial and Git (I wouldn't use subversion at home, but it seems a huge step ahead of cvs). > > "svn checkout" gets a repository onto your disk (like "git clone"/"hg > > clone") and "svn update" updates the data (like "git checkout"/"hg > > update"). > > > > But "svn update" and "cvs update" both update the working directory. > > And what about switching branches? In CVS, this is usually done with > "cvs update" as well, although the action is actually more similar to an > initial checkout... hg update <branch> the same as hg update <tag> and hg update <revision number, hex or short> They update the working repository to some specific state (and in the case of a branch that state just didn't only differ linearly but went "sideways", too). > "git-checkout" requires getting used to, but it's a fact that it is more > consistent and logical, and helps in the long run. Which IMHO is true > for many things in the Git UI. In that aspect it seems similar to "hg update", but "git checkout" has some nasty pitfalls. One of them already ate several hours of my time - I already talked about that one in here. > > How is $ git checkout > > > > the same as $ git checkout . > > > > The former says what I changed, the latter gives me changes I pulled > > beforehand. > > Actually, they do *almost* the same: Both check out files from the > repository to the working copy, but abort and warn if there are local > changes. The only difference is handling of files missing in the working > copy: The first treats them as changes and fails, while the second just > checks them out. > It happens that in your specific situation, because of this slight > difference, the one command failed with a warning, while the other did > work. That doesn't make them fundamentally different actions. What happened was: "git checkout" worked quite well. It didn't warn or anything. It just said "there are missing files, sucker." And it does the same for changed files, etc. "git checkout ." on the other hand gave me back the files. Technically these two might be quite similar, but from the user interaction standpoint, they are vastly different. > > If a tool doesn't feel familiar after 15 min (or rather after some > > hours), then I will have to wrap myself around the tool, and it is > > likely to be inefficient on the long run, even though I might not even > > notice it anymore, because I got used to it. > > This is a baseless claim. It is based on my personal experience. And please mind the "likely" :) I don't claim that it has to be inefficient on the long run. > "Ich weiß nicht, ob es besser wird, wenn es anders wird, ich weiß nur, > dass es anderes werden muss, wenn es besser werden soll." -- Georg > Christoph Lichtenberg That's what I added with the second part: If it proves to be bad on the long term, it isn't good either. But a tool should manage both, else it's very likely that it skews my perseption. And not every different is better, though it's almost always useful to try different things to find out, where to change next. And that citation also says, you should try Mercurial :) > I doubt the others on this list are still reading this thread :-) *gg* > > To finish it, I created a small side by side comparision of Git and > > Mercurial which I hope I managed to keep neutral. > > [...] > > > Hg | vs | Git > > [...] > > > + | documentation | > > I don't agree here. IMHO the Git documentation is perfectly good. Then this is likely skewed by my own experience. Let's add it to the "different opinion" list :) > > = Usability = > > > > Hg | vs | Git [...] > > + | just works | > > I don't fully agree on your conclusions, but more importantly, I don't > agree at all to what constitutes "usability" in your list :-) Could you create a different list, so we can merge (or get two lists for different sets or priorities)? > And what is "just works" supposed to mean, anyways?... That means: it didn't yet surprise me with unexpected behaviour, which is something I also heared from many other Mercurial users. > The main committers over the past few years have been Thomas Schwinge > and Samuel Thibault. > > Thomas set up the Git-based wiki, so I guess his preference is clear :-) > > I asked Samuel now, and he said he doesn't care, though on further > questioning he admitted a preference for Mercurial. > > Neal Walfield has been commiting a lot recently in the hurd-l4 module. > As this is totally seperate though, there is no reason why it must use > the same VCS... (I have no idea about his preference.) > > We also have the GSoC students presently, which are devided as well. > > So this leaves us still in the same place I fear... Damn! :-) But at least, we are now better informed, why we are in this place ;-) *gg* Aside from being funny, this makes it easier to know, when we can safely move on. I can't think of a useful finish right now, so I'll just leave it at this... Or, maybe this one fits: When free tools which programmers use get spread enough (and there isn't something in place to stop people from contributing), it will almost always come down to philosophy and basic concepts in the end, because everything else can be fixed by throwing person-hours at it :) Maybe next someone will invent incremental garbage collection for git (can be done at each pull), just like Mercurial gets simpler rebasing at the moment, and step by step the projects will push each other onward. I hope they will exist side by side for a long time, so they can surpass any proprietary VCS in every aspect. Having friendly competition can be a huge gain for a project (if it's friendly), since ideas in each project also bear fruits in the other one. :) Best wishes, Arne -- Unpolitisch sein Heißt politisch sein Ohne es zu merken. - Arne Babenhauserheide ( http://draketo.de ) -- Weblog: http://blog.draketo.de -- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the history of free software. -- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln -- Mein öffentlicher Schlüssel (PGP/GnuPG): http://draketo.de/inhalt/ich/pubkey.txt
signature.asc
Description: This is a digitally signed message part.
