[VOTE] git versus mercurial
|
| 1 2 3 4 |
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
In reply to this post
by Jakub Narebski
|
||||||||
|
|
In reply to this post
by Leo Razoumov
|
||||||||
|
|
In reply to this post
by Felipe Contreras
|
||||||||
|
|
|
||||||||
|
In reply to this post
by Jakub Narebski
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> > * Recently, Hg development seems to have somewhat slowed down. To > > simply put it, there is not enough room in the world for several > > similar SCM systems. With git's pace and momentum the other SCMs > > including Hg are fighting an uphill battle. > > The competing _distributed_ version control systems left seems to be > Bazaar-NG (Ubuntu), Mercurial (OpenSolaris, Mozilla), Git (Linux kernel, > Freedesktop.org, Ruby on Rails people). There are many IDEs, many > editors, many web browsers; there is Linux and there are *BSD; I hope > that Mercurial would continue to be developed, and not vanish in > obscurity like Arch and clones... I created a head-to-head code_swarm of Mercurial and Git and it clearly shows that Mercurial development didn't slow down. The code_swarm isn't a fancy one with music and annotations, but I think you'll directly see for yourself what I mean: - http://www.rakjar.de/shared_codeswarm/hg-vs-git-short.avi red is git, blue is Mercurial. It is a result of my shared_codeswarm project with which you can create code_swarms from more than one repository automatically - and update them incrementally, creating new code_swarms of only the new commits in the repositories: - http://www.rakjar.de/shared_codeswarm/project_activity_battle_swarm.html Best wishes, Arne -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- 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. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt |
||||||||
signature.asc (204 bytes) |
|
In reply to this post
by Jakub Narebski
Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> I agree, and I think it is at least partially because of Git having > cleaner design, even if you have to understand more terms at first. What do you mean by "cleaner design"? From what I see (and in my definition of "design"), Mercurial is designed as VCS with very clear and clean design, which even keeps things like streaming disk access in mind. Also, looking at git, git users still have to garbage collect regularly, which shows to me that the design wasn't really cleaner. As an example: If I want some revision in hg, my repository just reads the files in the store, jumps to the latest snapshots, adds the changes after these and has the data. In git is has to check all changesets which affect the file. If you read the hgbook, you'll find one especially nice comment: "Unlike many revision control systems, the concepts upon which Mercurial is built are simple enough that it’s easy to understand how the software really works. Knowing this certainly isn’t necessary, but I find it useful to have a “mental model” of what’s going on." - http://hgbook.red-bean.com/hgbookch4.html I really like that, and in my opinion it is a great compliment to hg, for two reasons: 1) Hg is easy to understand 2) You don't have to understand it to use it And both are indications of a good design, the first of the core, the second of the UI. Best wishes, Arne -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- 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. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt |
||||||||
|
|
|
||||||||
|
|
In reply to this post
by Arne Babenhauserheide-2
|
||||||||
|
|
Am Montag 27 Oktober 2008 05:15:11 schrieb Leo Razoumov:
> > I created a head-to-head code_swarm of Mercurial and Git and it clearly > > shows that Mercurial development didn't slow down. > > I am not familiar with code swarms, sorry. My impressions are > subjective are thoroughly un-scientific:-) That's always the case with code_swarms. They only show the commit activity: How often how many files where changed. They aren't a fair comparision but a damn unfair battle relying strongly on development style, programming language (influences the style) and such. What you can see very clearly in them is how activity patterns _change_. And the Mercurial activity doesn't slow down. Instead in the beginning you can see them pacing each other, git always the bigger activity. There was a moment in may this year when git activity had receded to the point where it was equal to Mercurials activity, but it recovered from that. An artifact in Mercurial is that it took an almost two week break in July this year, but apart from that development always rolled on, and in august the commits where coming fast again. The smaller activity can for example be a result of a development style where changes are thouroughly discussed before they get implemented. > (1) Judging by the activity of mailing lists git community is several > times larger and more active in terms of actual submitted patches. This is something which didn't change. Git had higher activity from the start, yet Mercurials actual code paced it well and was faster at some things. Git still has higher activity, but that can simply stem from Mercurial being almost completely done in Python which need less code to do the same work. > (2) Hg forest extension is still not in the tree with outdated and > incorrect documentation in the wiki. For me it was biggest reason to > migrate from Hg to git. Why didn't you instead update the documentation in the wiki? I don't use the forest extension, so I can't judge whether it is fit for inclusion in the tree. But I wrote the group extension and learned that way that writing Mercurial extensions is far easier than I thought. And different from the shell, Python code is platform independent. Best wishes, Arne -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- 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. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt |
||||||||
|
In reply to this post
by Leo Razoumov
|
||||||||
|
|
In reply to this post
by Jakub Narebski
Am Montag 27 Oktober 2008 02:52:22 schrieb Jakub Narebski:
> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote: > > Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski: > > > I agree, and I think it is at least partially because of Git having > > > cleaner design, even if you have to understand more terms at first. > > > > What do you mean by "cleaner design"? > > Clean _underlying_ design. Git has very nice underlying model of graph > (DAG) of commits (revisions), and branches and tags as pointers to this > graph. > > > From what I see (and in my definition of "design"), Mercurial is designed > > as VCS with very clear and clean design, which even keeps things like > > streaming disk access in mind. > > I have read description of Mercurial's repository format, and it is not > very clear in my opinion. File changesets, bound using manifest, bound > using changerev / changelog. inodes and datanodes (the files in the store), organized in directories which keep many files (manifests) bound in changesets which keep additional data. > Mercurial relies on transactions and O_TRUNC support, while Git relies > on atomic write and on updating data then updating reference to data. For most operations Mercurial just relies on appending support. > I don't quite understand comment about streaming disk access... If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)", it is faster then if you tell it "give me files a k p q s t", because the filesystem can easier optimize that call. That's why for example Mercurial avoids hashing filenames. > Well, they have to a lot less than they used to, and there is > "git gc --auto" that can be put in crontab safely. relying on crontab which might not be available in all systems (I only use GNU/Linux, but what about friends of mine who have to use Windows?) > Explicit garbage collection was a design _decision_, not a sign of not > clear design. We can argue if it was good or bad decision, but one > should consider the following issues: > > * Rolling back last commit to correct it, or equivalently amending > last commit (for example because we forgot some last minute change, > or forgot to signoff a commit), or backing out of changes to the > last commit in Mercurial relies on transactions (and locking) and > correct O_TRUNC, while in Git it leaves dangling objects to be > garbage collected later. Linux. > * Mercurial relies on transaction support. Git relies on atomic write > support and on the fact that objects are immutable; those that are > not needed are garbage collected later. Beside IIRC some of ways of > implementing transaction in databases leads to garbage collecting. But Mercurial normally works on standard filesystems, so this isn't the case for normal operations. You culd say, though, that git implements a very simple transaction model: Keep all old data until it gets purged explicitely. > * Explicit packing and having two repository "formats": loose and > packed is a bit of historical reason: at the beginning there was > only loose format. Pack format was IIRC invented for network > transport, and was used for on disk storage (the same format!) for > better I/O patterns[1]. Having packs as 'rewrite to pack' instead > of 'append to pack' allows to prefer recency order, which result in > faster access as objects from newer commits are earlier in delta > chain and reduction in size in usual case of size growing with time > as recency order allows to use delete deltas. Also _choosing_ base > object allows further reduce size, especially in presence of > nonlinear history. Mercurial which doesn't need user interaction. > * From what I understand Mercurial by default uses packed format for > branches and tags; Git uses "loose" format for recent branches > (meaning one file per branch), while packing older references. > Using loose affects performance (and size) only for insane number of > references, and only for some operations like listing all references, > while using packed format is IMHO a bit error prone when updating. As far as I know, Mercurial got that "using packed format" right from the beginning. > * Git has reflogs which are pruned (expired) during garbage collecting > to not grow them without bounds; AFAIK Mercurial doesn't have > equivalent of this feature. > > (Reflogs store _local_ history of branch tip, noting commits, > fetches, merges, rewinding branch, switching branches, etc._ As far as I know Mercurial only tracks the state of the working directory, so it doesn't track your whole local history. But others can better tell you more about that in greater detail. > [1] You wrote about "streaming disk access". Git relies (for reading) > on good mmap implementation. > > > In git is has to check all changesets which affect the file. > > I don't understand you here... if I understand correctly above, > then you are wrong about Git. Might be that I remember incorrectly about what git does. Are its commits "the whole changed file" or "the diff of the changes"? If the latter, it needs to walk back all commits to the snapshot revision to get the file data. One story I experienced with that: My amd64 GNU/Linux box suffers from performance problems when it gets high levels of disk activity (something about the filesystem layer doesn't play well with amd64 - reported by others, too). When I pulled a the Linux kernel repository with git half a year ago, my disk started klicking and the whole computer slowed down to a crawl. When I pulled the same repository data from a Mercurial repository, the computer kept running smooth, the disk stayed silent and happily wrote the data. Mercurial felt smooth, while git felt damn clumsy (though not slow). > > 1) Hg is easy to understand > > Because it is simple... and less feature rich, c.f. multiple local > branches in single repository. That works quite well. People just don't use it very often, because the workflow of having multiple repositories is easier with hg. > > 2) You don't have to understand it to use it > > You don't have to understand details of Git design (pack format, index, > stages, refs,...) to use it either. I remember that to have been incorrect about half a year ago, when I stumbled over many problems in git whenever I tried to do something a bit nonstandard. It took me hours (and in the end asking a friend) to find out about "git checkout ." just to get back my deleted files. The answer I got when I asked why it's done that way was "this is because of the inner workings of git. You should know them if you use it". > > And both are indications of a good design, the first of the core, the > > second of the UI. > > Well, Git is built around concept of DAG of commits and branches as > references to it. Without it you can use Git, but it is hard. But > if you understand it, you can understand easily most advanced Git > features. > > I agree that Mercurial UI is better; as usually in "Worse is Better" > case... :-) Best wishes, Arne -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- 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. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt |
||||||||
|
In reply to this post
by Jakub Narebski
|
||||||||
|
|
In reply to this post
by Arne Babenhauserheide-2
|
||||||||
|
|
||||||||
|
|
In reply to this post
by Jakub Narebski
Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:
> > If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)", > > it is faster then if you tell it "give me files a k p q s t", because the > > filesystem can easier optimize that call. > > I would expect _good_ filesystem to be able to optimize this call as > well. As I said it looks like Mercurial and Git are optimized for > different cases: Git relies on filesystem for caching, and optimizes > for warm cache performance. The problem is by which knowledge the filesystem should optimize this call when it is storing the files in the first place. > > relying on crontab which might not be available in all systems (I only > > use GNU/Linux, but what about friends of mine who have to use Windows?) > > But that doesn't matter in the context of this discussion, which is > DragonflyBSD; worse or better support for MS Windows doesn't matter > here, does it? It only matters, if some developers are forced to work on WIndows machines at times. > > But Mercurial normally works on standard filesystems, so this isn't the > > case for normal operations. > > Mercurial implements transactions as a way to keeping operations atomic. > So I don't know what you mean by "normally works on standard filesystem" > here. I just meant "databases are a bit off topic" :) > > You could say, though, that git implements a very simple transaction > > model: Keep all old data until it gets purged explicitely. > > Git just uses different way to keep operations atomic, different way > of implementing transactions. That's what I wanted to express. > And probably requires transactions and locks for that. Git simply uses > atomic write solution for atomic update of references. Doesn't atomic write also need locks, though on a lower level (to ensure atomicity)? > Behind the scenes, at a lower level, Git does necessary delta resolving. > Delta chains in packs have limited length (as they have in Mercurial). So both do snapshots - they seem more and more similar to me :) > The answer usually is: did you have this repository packed? I admit > that it might be considered one of disadvantages of git, this having > to do garbage collection from time to time... just like in C ;-) I cloned from the official repositories. I hope Linus had his repository packed :) > Well, understanding "git checkout ." doesn't require understanding > inner workings of git. Your friend was incorrect here. I'll agree > though that it is a bit of quirk in UI[1] (but I use usually > "git reset --hard" to reset to last committed state). Damn - one more way how I could have archieved what I wanted... one more way I didn't find. > Just Google for "Worse is Better". But what I actually mean that Git > feature set and UI has evolved from very bare-bones plumbing, adding > features and UI _as needed_, instead of being designed according to > what designer thought it was needed. And that's how it feels to me. A great testing ground, but it developed too many stumbling blocks which keep me from trying things. When I now use git, I only do the most basic operations: clone, pull, push, add, commit, checkout. When anything else arises, I check if it is worth the risk of having to read up for hours - and since that wasn't the case for the last few months, I then just ignore the problem or ask someone else if he can fix it. As a contrast, when I encounter a problem with Mercurial, I simply check the commands for a moment and then try to solve it, and normally I have what I wanted within seconds to minutes. Git instead bit me once too often. I know that this isn't something which hits everyone and that it is subjective, but since it hit me, I'm wary of git, because in my view it isn't something for the majority of people - and you almost always have someone from that "majority" in your project. I don't want people getting afraid of solving their own problems, so I avoid systems which bite so often, that they create fear (for example of losing much time on something which should be a side issue). All in all it's a UI issue - while the git UI bit me quite often, the Mercurial UI just works. Best wishes, Arne -- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :) -- 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. -- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt |
||||||||
|
|
In reply to this post
by Benoit Boissinot
|
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
