Weekly Edition
Return to the Development page
| |||||||||||||
Elijah Newren on what's happening in the VCS world
GNOME hacker Elijah Newren has put up a survey of recent developments in version control systems. "I have often found it somewhat strange that mercurial doesnt have more active vocal proponents. Usually one hears from the git or bzr proponents, but not so much from mercurial. Yet it has always had many of the advantages of both (and, in some ways seems to have the most svn-like UI, and would seem a more natural transition for svn converts). I guess its a case where having most of the advantages or capabilities of other systems (even multiple other systems) yet not clearly standing out in one particular area will rob you of the active advocates that you could otherwise have."
On a related note, it appears that Emacs will be moving to Bzr, not for a specific technical reason, but because Bzr is becoming a GNU project. (Log in to post comments)
Mercurial! Posted Mar 4, 2008 17:30 UTC (Tue) by tekNico (guest, #22) [Link] What Elijiah said. Mercurial *is* da bomb. :-)
Mercurial! Posted Mar 4, 2008 19:10 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link] you should read his article. he says that he had the 'ah-ha' moment with git and doesn't know how he would live without some of it's unique capabilities.
Mercurial! Posted Mar 4, 2008 19:32 UTC (Tue) by tekNico (guest, #22) [Link] I did read the article, thank you. :-P I am a Mercurial "active vocal proponent", and since Elijah said there are not many of us, I am at least making myself heard. :-) I won't let Elijah final preferences stand in the way of some good fanboyism. ;-)
Mercurial! Posted Mar 4, 2008 21:12 UTC (Tue) by chema (subscriber, #32636) [Link] Moreover, just to show mercurial "market", it is worth to take a glance over Projects using Mercurial Yet Another Mercurial Fan :)
Repository Structure Posted Mar 4, 2008 18:40 UTC (Tue) by larryr (guest, #4030) [Link] For me the litmus test of a revision control system is the simplicity and transparency of its repository structure, and the specification for it, as long as it has sufficient support for complexity, performance, and reliability. From there, any behavioral/interaction model can be implemented on top of it. This was something I liked about git from the beginning; I felt that without any source code I could pretty quickly implement a compatible interface to a git repository. The opposite end of the spectrum for me is a repository defined in terms of an API, with the repository structure hidden behind/inside it. This seemed to be where svn was going, and that put me off from the beginning. Larry@Riedel.org
Repository Structure Posted Mar 4, 2008 19:25 UTC (Tue) by intgr (subscriber, #39733) [Link] If you're looking for "simplicity and transparency of its repository structure" and "performance and reliability", you should have a glance at Mercurial; its revlog and index files are append-only, and transaction rollback just involves truncating files. Performance-wise it tends to come second after git. While not as featureful as git, many of its extensions provide similar functionality.
Repository Structure Posted Mar 5, 2008 0:28 UTC (Wed) by MisterIO (guest, #36192) [Link] If performance-wise it's second after git and it's not as featureful as git, why should we use Mercurial instead of git?
Repository Structure Posted Mar 5, 2008 2:49 UTC (Wed) by larryr (guest, #4030) [Link] I like its Python affinity. If somehow it wins the mindshare battle with git, I would not mind; if only Google were to declare it the preferred product... (-: Larry@Riedel.org
Google uses perforce Posted Mar 5, 2008 8:26 UTC (Wed) by khim (subscriber, #9252) [Link] Google used perforce year ago and I'm pretty sure nothing changed since then: you don't introduce brand-new tool tied to VCS only to retire that VCS half-year later. Now it's quite possible that Google with switch to some other VCS: cvn, git, etc. But why the hell will it even consider Mercurial? Mercurial lost mindshare war long ago and the only salvation can be some features unemulable on git... I don't know about such features (and no "simple repository model" don't count - unless it can keep handle terabytes of data it's a no-go for large company like Google). As for what Google endorses... It's SVN, of course! Why? Of, it's easy: SVN only allow you to get to the repository via API so you can easily change repository format and guys at Google did just that. I think it'll be hard to do with git, and even harder with Mercurial, so SVN it is... P.S. Funny how the one thing which you declared as "no go" for VCS was exactly the thing to sway Google to this VCS :)
Google uses perforce Posted Mar 5, 2008 18:00 UTC (Wed) by larryr (guest, #4030) [Link] Funny how the one thing which you declared as "no go" for VCS was exactly the thing to sway Google to this VCS :) Hmm... maybe another way to look at it would be they consider it essential with their revision control systems that they not only understand the repository structure, but control it, so they created their own, and wrote an SVN API-compatible wrapper on top of it. In other words the repository structure was the most important thing to them. They are able to implement any behavioral/interaction model on top of it, and the SVN wrapper is evidence of that. But anyway what they use internally is not important; it's what they say is the cool thing to do. ^_^ Larry@Riedel.org
Repository Structure Posted Mar 6, 2008 19:35 UTC (Thu) by vmole (guest, #111) [Link] If performance-wise it's second after git and it's not as featureful as git, why should we use Mercurial instead of git? Because the UI is sane? C++ is faster and more featureful than Python, but I know which I'd rather use. Anyway, performance beyond "fast enough" is pointless. Yes, if you're managing the linux kernel, it makes a difference. Most projects won't notice it.
Elijah Newren on what's happening in the VCS world Posted Mar 5, 2008 17:57 UTC (Wed) by hmh (subscriber, #3838) [Link] Elijah has some very good blog posts about VCS. The one about the "limbo" was particularly interesting. Maybe some of that should go into the VCS manuals (especially git's)? It sure would have helped me grok git faster, not that git was particularly difficult to learn (the basics, at least).
|
|||||||||||||