Slashdot Mirror

Let's not forget the other contender for replacing Bitkeeper: Mercurial. We will also be celebrating its 10th year anniversary next week during the Pycon sprints.

Mmph. If you have sub-repositiories, it is really easy to get a Mercurial repository into a bad state that takes much voodoo to get consistent again.

Let's not forget the other contender for replacing Bitkeeper: Mercurial. We will also be celebrating its 10th year anniversary next week during the Pycon sprints.

Python 3.x has no relation to Windows Unicode filename support... Also, Python 3.x has proven significantly slower in almost all benchmarks that matter to us, especially start-up time.

(source)

Mercurial is missing a few key features that make it less appropriate for solving some difficult collaboration problems, and some of those turn out to be important to people outside of Linux kernel development too. That's the technical part underneath what you're dismissing as a fanboy phenomenon.

Allowing octopus merges and making it easy to rewrite/rebase local branches are two such important features. The way those fit together into git's remote tracking branch concept is a particularly useful mental model for widely distributed development. And the way git (but not Mercurial) forces explicit branch naming and sharing gets people thinking in a way that usefully leads toward using these features for collaborative development. Mercurial vs Git; it’s all in the branches covers most of the important area usefully.

Basically, git includes some weird features that were built specifically for the style of distributed development done by the Linux kernel. But those turn out to be similarly powerful for other widespread collaborative software efforts too. These things aren't really appreciated by people until they've used git seriously for a while, and therefore they don't show up on most of these formal "which DVCS should we switch to" documents done by people still evaluating their options. That link I just referenced goes over how Google completely missed out on that in their comparison. You can't just compare the opinion of new users. The interesting thing to compare is what git is capable of on a project with some number of serious git users involved.

Once you've gotten used to things like git's remote tracking branches, good rebasing practices for code sharing, and malleable history when in tough spots, it's impossible to take Mercurial seriously for some of those jobs. Eventually Mercurial got some of the rebasing features, but by that point it had already lost quite a bit of the mind share war. They still are struggling with how the branch name model mismatches what some people want.

I see Git and SVN mentioned a lot, in positive and negative sense. I would suggest Mercurial, but is better than SVN (i.e. distributed) but easier to use for most SVN people than Git.

there must be something better

Mercurial

You should give Mercurial a try. The thing that got me to use it in 2005, when it was pre-1.0, was how clean and obvious the command line interface was. I don't generally use graphical tools for development work, so I can't gauge the various GUIs available for it, but I do know that a lot of people like TortoiseHG.

I've used Perforce as well, and it has its strange quirks and complexities too, though I agree that git's command line interface leaves a great deal to be desired in comparison. I think Mercurial's command line interface is more intuitive and clearer than Perforce's.

Mercurial is just as free, and just as easy to set up. Code hosting repositories are about someone else managing your connectivity, storage and backups for you, not about them building DVCS software for you.

Likely the best websites from the US Government...are the Library of Congress site and the Supreme Court site. Both of them are extremely informative, and have a massive wealth of information that is readily available.

Development of legislation is quite byzantine and revision (mis)management during the drafting can make for some very serious readability problems. Currently it is nearly impossible to have time, even for a full-time politician with staff, to have time for their team to individually work through all changes and revisions of a draft of a bill.

Using a version control system (CVS, Subversion, Mercurial, Git) makes it very easy to track individual changes and who made them. It also makes it trivially easy to integrate all the changes and show a snapshot of the current draft or one from any arbitrarily earlier version.

Code bases for large software projects are unwieldy, constantly changing and have many authors yet need full transparency and accountability to succeed. So are drafts of legislation. Using a versioning system in our legislative process is long overdue.

Off the top of my hand, a Git feature for which I don't know a Mercurial equivalent -- git-cherry-pick. Want to rewrite history a bit? Create a new branch from sometime before the commits you want to change, then cherry-pick (point-and-click simple in gitk) the commits you want, in the order you want, ignoring the ones you don't. When you're ready, clobber master with your new branch.

hg transplant

I mean, quilt (hg mq) is cool and all, but how easy is it to rewrite history if you weren't in a quilt to begin with?

hg qimport has a '-r' option which allows you to "place existing revisions under mq control" (from hg help qimport)

With modern distributed revision control systems this situation can be handled pretty effectively. But, of course, a distributor is under no obligation to provide the revision control history.

I sort of think that should change, at least in the case of code that's in a Mercurial (or some other tool like it) repository. Or at least it should be considered the polite thing to do.

Mercurial for...

Windows

MacOS

For linux it should be in standard repos.

This way you can make changes on any of your systems and move them around as required, merging only when needed.

I have built a version controlled document management system around mercurial for my wife's architectural practice. I have found it very difficult to convince users to follow the conventions we use for software. They are too used to putting version and project information in file names. It means nothing for them to rename a file from a.dxf to a_new.dxf and commit it.

The formal structure of software tends to keep this behaviour in check. The environment we are talking about here may be formal and controlled enough for this to work, but it is going to take training and enforcement to get it to work.

I wish they would stop using CVS and start using Mercurial or something other reasonably decent DVCS so I felt like I could contribute maybe.

Git is certainly interesting, but I doubt half the people who use it really understand how it works. Maybe if it was started in less a dire situation it could have been more user friendly.

Thats where Mercurial comes in.

Within OSS there were these cascading projects. With Arch close to the beginning. Along the way different things are tried and the DSCM field is refined. I think git is a step along the way.

I use Mercurial, and I don't know why it wasn't mentioned along with the other three.

But in the end you still have many copies of documents, and you're always trying to keep changes synced across them. This approach breaks down when you have multiple sources of change... conflict resolution will always jump up to bite you.

There are already good solutions to this problem: it is called revision control and the Subversion system is a high-quality open source solution to most common version control / sharing scenarios. Visual Source Safe wishes that it could be as good as Subversion, but the open source crowd beat them to it.

The problem with generic revision control systems is that rich document formats like odf and ms doc are not inherently mergeable without knowledge of file formats. Some tools (mercurial being one) can invoke external merge tools which in theory allow users to manually merge documents. But it never works as well as plain text source code.

Use Mercurial or Bzr:

http://www.selenic.com/mercurial/wiki/
http://bazaar-vcs.org/

They are obscure and scary, but have much lower start up costs than subversion (and they aren't that hard to use), and compared to a hypothetical system, they are available today.

Have you put together a clear, serious, constructive proposal for an alternative that spells out the pros and cons? If you haven't, its your own fault really. But if you have, and they don't listen, then yeah, "shit" about sums things up. At any other time, I'd say find better bosses and quit in that situation, but few have that option at the moment.

Yes I spent two years running the CM system. Before I moved into that area I did some investigation into migrating from CVS to bitkeeper. When the BK license issues became apparent I started trialling Mercurial, building migration infrastructure and using it for areas where a DSCM is a big help. I pushed for an open evaluation of tools we could move to and got pushed out of tha role as a result.

How about Mercurial (hg). For my personal projects it beats the heck out of subversion...

Mercurial aka. hg is another distributed VCS/SCM. It has much in common with git (although git *might* be a little more kick-assier in places), but may come in handy as a better SVN replacement because it does work well on Windows, brings very nice Explorer integration through TortoiseHg and is supported by Trac, too, so your toolbox might look pretty much the same. Don't know about integration into Eclipse and others, though.

After using distributed version control for a very short time, I decided I will never go back to something centralized like Subversion. Only with a DVCS do I can:

- Get work done, with complete repository access, anywhere. On a train. In the rain. In a box. With a fox. Anywhere, any time, even when the network goes down or while I'm thirty thousand feet above an ocean.

- Create as many experimental branches/clones as I like, without making them visible to anyone else or cluttering up any shared namespace. (This is especially nice for capturing checkpoints when I have a lot of large, interdependent changes to make and the project won't work until they're all finished.)

- Get perfect, complete, automatic repository backups as a side-effect of working on a project. It's as hassle-free as I could ask for, and restoring is equally easy.

After quite a bit of reading, I ended up choosing Mercurial. After a year or so of using it regularly, and occasionally checking in on the other DVCS systems, I have always been glad of my choice.

Git was a contender, but is notoriously non-intuitive and awkward to use, and has never been a good fit on Windows. (I try to avoid Windows, but some of my colleagues still use it, and some of our projects are necessarily cross-platform.) Mercurial is similar to git in design, features, and speed, and is also very easy to use and works well on every major platform. Linus even called it out in his version control rant.

Bazaar was a contender, and I like their sponsor (Canonical), but didn't seem focused on performance enough for my liking.

More points for Mercurial:
- The folks on the email list are very knowledgeable, friendly, and helpful.
- It is very easy to extend.
- It has the blessing of some very large, high-profile projects. (e.g. Mozilla, OpenSolaris, Java's OpenJDK)

To the git users who use the gitk GUI for browsing revisions, Mercurial has a clone:
http://www.selenic.com/mercurial/wiki/index.cgi/HgkExtension

To the user who posted about the Tortoise GUI for Subversion, here's a link for Mercurial's equivalent:
http://tortoisehg.sourceforge.net/

To the user who posted about Trac integration, Mercurial will work too:
http://trac.edgewall.org/wiki/TracMercurial

Also of note, Version Control Blog occasionally links to some interesting articles:
http://www.versioncontrolblog.com/

I would generally not choose git because I think it is harder to use than several other distributed SCMs based on a very similar model. It is true that last I checked git was faster than any other one, but there is one that is pretty close to git in performance and is much easier to understand and use, and that's Mercurial.

Ooh, repositories... holy war turf!

Before committing to Subversion :) you may want to check out Mercurial (think of it as git-done-properly)

Mercurial does "merge tracking," though its not listed as that, it is just inherently part of the system.
You can use something like the graphlog plugin (hg glog) to see a commit history with graphed merges.

I also like using the GUI log viewer (hg view) to view commits, branches, merges, and the details of each commit
(it runs a program called 'hgk', which is similar to or related to 'gitk')

I've only scratched the surface of what can be done with Mercurial. I'd love to hear from some more advanced users on useful repository management methodology, and useful plugins/extensions for Mercurial.

Mercurial:
http://en.wikipedia.org/wiki/Mercurial_(software)
http://www.selenic.com/mercurial/

Comparison of Subversion, CVS, Bazaar, and Mercurial:
http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html?page=1

Graphlog for Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension

Ooh, repositories... holy war turf!

Before committing to Subversion :) you may want to check out Mercurial (think of it as git-done-properly)

Mercurial does "merge tracking," though its not listed as that, it is just inherently part of the system.
You can use something like the graphlog plugin (hg glog) to see a commit history with graphed merges.

I also like using the GUI log viewer (hg view) to view commits, branches, merges, and the details of each commit
(it runs a program called 'hgk', which is similar to or related to 'gitk')

I've only scratched the surface of what can be done with Mercurial. I'd love to hear from some more advanced users on useful repository management methodology, and useful plugins/extensions for Mercurial.

Mercurial:
http://en.wikipedia.org/wiki/Mercurial_(software)
http://www.selenic.com/mercurial/

Comparison of Subversion, CVS, Bazaar, and Mercurial:
http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html?page=1

Graphlog for Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/GraphlogExtension

You're going to eventually anyway. It's slow, the model is seriously constraining, and it has a bunch of extra features that really aren't all that useful.

Consider using something like Mercurial (my favorite) or git instead. They are much better suited for collaborative development, especially if the teams are loosely coupled.

I don't know whether you were speaking from experience or just making a general comment, but have you tried looking into Mercurial as an alternative? It's a distributed SCMS, meaning everybody commits to their own copy of the repository and then pushes those commits to a central repository (if you go with a CVS/SVN-like centralized setup). The Mercurial interface is designed to work more or less like CVS and Subversion, and it uses patchsets and repository-wide versioning like Subversion, but it has this nifty command called "rollback" that lets you undo your most recent commit, provided you haven't pushed the commit anywhere else yet. I switched a 200k-line project over from CVS recently--avoiding Subversion for exactly the reason you give--and it's worked fine for me so far; I even stopped mirroring my commits back to the old CVS repository because it was so much easier to roll back accidental commits in Mercurial. Being able to commit individual changes when I'm on the road without a net connection, rather than saving them all for when I get home and trying to separate out the changes afterward, is a nice bonus as well. (And I have to admit, I like how Mercurial names its "annotate" command "annotate" rather than Subversion's immature-sounding "blame", though admittedly not all the documentation is up to quite the same standard.)

That said, Mercurial's toolset isn't nearly as full-fledged as Subversion's. In particular, there doesn't seem to be an explicit equivalent to Subversion's dump/load process, so if you want to obliterate a commit other than the last one you're pretty much out of luck (though it might work to hg export everything but the problem patch and then hg import to an empty repository). You also have to deal with the fact that "revision numbers" are no longer constant except within a single copy of the repository, and you have to refer to hexadecimal node names if you want to talk about a specific patchset with anyone else. For my project, I treat the revision numbers of the central repository as canonical, and when building the project, I include the node name as part of the build ID when building from any other repository.

By Hg do you mean Mercurial?

What is there about it that makes developers better or worse at merging?

I'm assuming that you're not agreeing that CVS would solve this particular problem, since it merges much like SVN does?

The teams working on the new round of decentralized SCMs[*] have done deep rethinking of source control problems and challenges, and the results are generally brilliant. These problems aren't esoteric -- administration and day-to-day usage really is easier with the new stuff. After a while using git, Bazaar, etc., the crufty old SCM tools seem like doing image editing in a hex editor instead of a GUI app.

You're painting this far too black and white.

Distributed systems have their own set of limitations, some of which centralized tools don't have. Some development processes cannot be implemented with distributed tools, pretty much the same way as processes such as how the Linux kernel is developed cannot be implemented by centralized tools.

For example:

Let's say I wanted to make sure that any change going into my project enters the main line, or "trunk", first, and is then applied to release branches if necessary. This makes sure that I have one common place to log all changes ever entering my code base. That's very simple requirement, right? This approach is used by many projects, e.g. by all the BSDs, and by Subversion itself. Let's say I picked Mercurial as my tool for the job.

So I have a changeset on my trunk, and I want to merge it into my 1.x and my 2.x release branches. I will first need to pull the change from trunk into my branch, right?

hg pull [-u] [-f] [-r REV]... [-e CMD] [--remotecmd CMD] [SOURCE]
-r --rev a specific revision up to which you would like to pull

Wait... why does it say "up to which"? I just want that one change!

Darn, turns out that in Mercurial, changesets depend on all their ancestors in order to guarantee integrity of all changes I pull from another clone of my repo. You cannot pull a change without having around its parent, since revisions are identified by hashes in order to be globally unique across all clones. The hash of a revision is derived partly from the hashes of its parent revisions (they are included in the manifest).

So I need all parent revisions of my changeset in my branch. Since I've forked off my branch from trunk, and have not yet made changes to the branch itself (remember that all changes to the branch should be coming in via trunk), Mercurial will see no conflicting heads and simply forward my release branch to the latest head of trunk. So I can either pull every change I've made on trunk since forking the release branch (not much point in that), or manually apply a patch to the release branch (i.e. side-step the tool).

Well, great. With Subversion 1.5, all you need to do to get a changeset, say rev 42, from trunk to a release branch is

cd branch-working-copy
svn merge -c42 http://url-to-trunk/

So in practice, people using Mercurial end up fixing problems on their release branches, and merge the fixes to their main line later. And yes, it seems like you have to manually apply a fix to all your release branches separately (at least I haven't yet found another way).

In all fairness, there is in fact an extension that allows Mercurial to "transplant" a changeset from one branch to another without requiring you to also merge all the parents of the changeset: http://www.selenic.com/mercurial/wiki/index.cgi/TransplantExtension

This extension maintains a special file mapping local changeset hashes to remote ones. You have to bet your luck on not ever creating the same hash for two different revisions, though, otherwise your project's history is borked (I have no idea how likely this is).

Certainly, maintaining a separate list of changeset ids is not something intended in the original design, which focused on providing distributed branching and merging. The design does a very good job at this no doubt. By making sure that all bran

Even for simple diff/commit purposes I find Mercurial much easier to use than either CVS or SVN. And I find CVS easier to use for such purposes than SVN. The biggest reason for this is that Mercurial is blindingly fast in comparison to SVN or CVS.

IMHO, SVN is a very poor tool who's only real advantage over CVS is that it happens to work whereas CVS fails to in several important cases.

Seeing that netqmail is distributed legally as a qmail distribution plus patches with a script which applies the patches, I wonder if I could get away with releasing a patched qmail as a repository in a DSCM tool like mercurial since that just maintains the base version plus optional patches.

As I mentioned the other day, I will not be contributing to Mercurial development for a while. Several people have asked me why.

        At my workplace, we use a commercial SCM tool called BitKeeper to manage a number of source trees. Last week, Larry McVoy (the CEO of BitMover, which produces BitKeeper) contacted my company's management.

        Larry expressed concern that I might be moving BitKeeper technology into Mercurial. In a phone conversation that followed, I told Larry that of course I hadn't done so.

        However, Larry conveyed his very legitimate worry that a fast, stable open source project such as Mercurial poses a threat to his business, and that he considered it "unacceptable" that an employee of a customer should work on a free project that he sees as competing.

        To avoid any possible perception of conflict, I have volunteered to Larry that as long as I continue to use the commercial version of BitKeeper, I will not contribute to the development of Mercurial.

        As such, Mercurial can stand entirely on its own merits in comparison to BitKeeper. This, I am sure, is a situation that we would all prefer.

The former. I was able to load the article, but can't get it back now. He said something like it's "good enough" for many people, but no one's really excited about SVN. To me, that's crap. SVN does what it does very well. What more could you really want from a centrally-managed versioning system?

Yes, you could use svk... but why, when its competition is easier to use or faster and more space-efficient and has useful things like dumb server support?

Cvs is already done right. These would-be improvements are pointless.

I manage a 7 GB CVS repository serving 200 developers and you are totally wrong. If I could get buy-in from the 10 or 20 relevant stakeholders I would change to mercurial in a pinch.

Mercurial seems to have quite a bit of traction these days, more than any of the other d-sccm tools out there from what i can tell (inside sources tell me sun has mandated mercurial, so there should be quite good tool integration soon). Mercurial is also very fast, and has a good ui, and a really nice http interface too (rss no less).

svn is indeed gold plated shit
cvs is indeed past it

My favorite, of course, is Mercurial. My main draw is that I had been interested in distributed SCMs for years, but had never found one that made any sense to me whatsoever. I was on the hunt again and stumbled on Mercurial, and I've been hooked ever since.

Of the various distributed SCMs, Mercurial is the easiest to use one I've found. And it's pretty fast, though not quite as fast as git (though I have some ideas on how to fix that). And since it's written in Python with only a very small C component it runs on many platforms.

Although Subversion does a great job of being a better CVS than CVS, yes, it is hard to use. Let me clarify: It is easy to use for a small project with just a few developers. But for large projects with many developers scattered all over, it, or any centralized revision control system becomes a nightmare (to me, anyway). The biggest problem I have with Subversion/CVS-type systems is that eventually managing the branches becomes a nightmare, and it becomes really easy to screw stuff up.

My work became a lot easier when I started using distributed revision control systems. My favorite is Mercurial, a very fast and lightweight system written in Python. The main reason that I like it is that is by far the easiest to use revision control system that I have worked with. In addition to being fast, intuitive, supporting completely disconnected operation, and other great features, branching and merging is a breeze. And, most importantly, it makes it very easy for the developers on the large projects I work on to keep from stepping on each other's toes because everything is a branch . Whenever I checkout ("clone") the repository that we consider the "central" (or "trunk") repository, all of my commits happen in my local mirror of the repository, and when I am finished I "hg push" those changes back, merging them back into the "trunk". (My explanation may seem a little confusing, but the Mercurial development model is explained pretty well here.) The great thing about this model is that branching is the most natural thing in the world (in fact, everyone essentially always works on their own "branch") so it actually gets used. I have experienced too many cases with CVS or Subversion where something should have happened on its own branch but didn't because it was too confusing, too slow (with the bottleneck of the central server), etc.

Although Mercurial is still pretty young, it is mature enough that some very large projects (e.g., Mozilla) have moved to it. I urge everyone who is looking for a powerful, but intuitive and easy-to-use revision control system to take a look at it. I have used several revision control systems and Mercurial is the first one that really makes me feel more productive.

Although Subversion does a great job of being a better CVS than CVS, yes, it is hard to use. Let me clarify: It is easy to use for a small project with just a few developers. But for large projects with many developers scattered all over, it, or any centralized revision control system becomes a nightmare (to me, anyway). The biggest problem I have with Subversion/CVS-type systems is that eventually managing the branches becomes a nightmare, and it becomes really easy to screw stuff up.

My work became a lot easier when I started using distributed revision control systems. My favorite is Mercurial, a very fast and lightweight system written in Python. The main reason that I like it is that is by far the easiest to use revision control system that I have worked with. In addition to being fast, intuitive, supporting completely disconnected operation, and other great features, branching and merging is a breeze. And, most importantly, it makes it very easy for the developers on the large projects I work on to keep from stepping on each other's toes because everything is a branch . Whenever I checkout ("clone") the repository that we consider the "central" (or "trunk") repository, all of my commits happen in my local mirror of the repository, and when I am finished I "hg push" those changes back, merging them back into the "trunk". (My explanation may seem a little confusing, but the Mercurial development model is explained pretty well here.) The great thing about this model is that branching is the most natural thing in the world (in fact, everyone essentially always works on their own "branch") so it actually gets used. I have experienced too many cases with CVS or Subversion where something should have happened on its own branch but didn't because it was too confusing, too slow (with the bottleneck of the central server), etc.

Although Mercurial is still pretty young, it is mature enough that some very large projects (e.g., Mozilla) have moved to it. I urge everyone who is looking for a powerful, but intuitive and easy-to-use revision control system to take a look at it. I have used several revision control systems and Mercurial is the first one that really makes me feel more productive.

I keep my config files in a directory structure in my home directory on my laptop which mirrors the structure of the systems I maintain. I use the mercurial DSCM for version control and push revisions to a user account on each server. From there I run a script as root which recursively copies the files into the target directory tree.

Well, the postscript example is possible to exploit in a context that's not quite so contrived...

In Mercurial, revisions are identified with hashes of their contents. So, you can submit a change to something like a postscript file that nobody will review the source of. Then, later, you can trick someone involved in the project from pulling a repository copy from you that has the evil version of the Postscript file. With any luck, you can get the evil version to infect the project with nobody realizing it until someone notices the strange behavior.

The problem is that the submission is likely to eventually be traced back to you once the strange behavior is noticed. But the reputation of the project would be severely tarnished and you might be able to get access to the systems of various people who used it.

It would be surprisingly hard to exorcise the bad version from the various distributed repositories. You'd have to just replace the file and state that any version before X is potentially infected. And even then a badly done merge might easily re-introduce the file.

This is basically a trickier way to get someone else to sign something for you.

And the case of a certificate authority is interesting too. The very nature of a CA is to sign documents made by someone else.

But, no, I can't really think of situations in which its really useful unless the attacker is in some way getting someone else to lend their authority or reputation to the attacker.

Having the process without the software is much, much harder.

I've been using Mercurial to manage my own projects. I figure I can always figure out how to expand it later if I get another developer. I wanted something simple, lightweight, and hackable, yet still with all the features of, say, SVN or CVS, even making the commandline look similar, so that people coming from other systems aren't immediately lost. I think this is the best we've got as far as that goes.

IBM is just full of it. If OpenSolaris were not for real do you think they would have gone to the trouble of changing their source code control system from the in-house Teamware stuff to Mercurial (see this ).

No, that is the kind of wrenching and disruptive change that you do if you're really serious about pulling in developers outside the corporate WAN. If it were a facade they could have built a more impressive facade much more quickly.

Progress is slow on OpenSolaris because unlike Linux in 1991, Solaris is already a mission-critical operating system in many enterprises, and because they are trying to pull in non-employee contributions whilst maintaining quality. This is actually difficult.

Disclaimer: I was on the invite-only OpenSolaris pilot program and got some free t-shirts (none of which fit).

I used to work at Sun, and it's a company with a slow-moving internal culture. Pretty much any organisation that contains 30,000 people will necessarily not be zippy. The lack of speed says nothing about their intentions, though. For example, I've been talking to a number of Sun people over the past several months as they've been choosing a revision control system for OpenSolaris to use, and they've been keenly aware of the benefits of both doing things in an open manner and doing them carefully. They ended up choosing a wonderful revision control tool called Mercurial, but first they spent a few months evaluating the alternatives and, even better, writing up their evaluations and posting them in public. This is a very useful service to the open source community, as few people have time to evaluate tools in such depth, much less write in detail about why they did or not choose any of half a dozen alternatives.

You jest, but VI made me hate all coding for about a day.

I was trying to contribute to a project using Mercurial, when lo and behold! It dumped me into VIM.

Apparently, all I *really* was supposed to do here was enter a line of text describing my patch, save, and quit. But damned if I couldn't find a single menu to do that. The mouse was useless, and the menus were unnavigable.

By the time I figured out :wq, I'd messed up my entire Mercurial depository and had to reinstall and manually patch the whole damn project because I'd botched it. Frigging :wq...

However, I have heard that the newer Linksys WRT54G router (v. 5), the one that now uses Linux instead of VxWorks, does not perform as well. I am not talking about its complete incompatibility with Linux, but rather it's every-day consumer use. Wind River convinced Linksys (and others) that they could save money by licensing VxWorks and lower their parts cost through reduced memory requirements, but it doesn't really pan out that way, in the end.

Linksys realized this, and continued to produce the older WRT54G, renaming it the WRT54GL, but now charges more money for it. But the price difference is small in comparisor to what you get. Really, though, I don't think that the Linksys is as good as it could be, because you are stuck with their Broadcom wifi chipset. While there is now an open-source driver for it, there are features in Atheros chipsets that aren't in Broadcom's (open-source or proprietary) which are important for some applications. Since the newer WRT54Gs have all their wifi chips integrated, there is no longer the option of replacing the broadcom card with an Atheros. Luckily, there are other routers that have more ram, and use an atheros wifi chipset on a mini-pci card. Too bad such routers are in short supply.

Yes, Linux does need some slimming. Or perhaps GCC has to produce smaller kernels. But the problem isn't really as bad as some would say. Take a look at what the Linux-Tiny people have been able to accomplish - a bootable and usable Kernel 2.6 system which will fit inside of 2MB (I have no connection to this project other than being a fan).

Reading between the lines it seems to be a reward for inducing BitMover to drop their free service for Linux.

Given subsequent events with mercurial I think this is probably a Good Thing (tm)

It's unlikely that I will have time to devote to it. I sent a link to a friend of mine who may have time to devote to it, but I'm not sure. I also don't have any really good ways of running Windows at home.

All of my Open Source time right now is being taken up by my own projects or by Mercurial.

If you are truly sincere about getting it ported someday, look into using SDL (Simple Direct media Layer) rather than DirectX for graphics and sound. That will greatly assist anybody who wants to try to port things in the future.

If you like Git but you want to use multiple platforms try Mercurial: http://www.selenic.com/mercurial/wiki/index.cgi Performance is excellent, it is written in Python. So far version 0.7, but projects is very active.

The Consumer Electronics Linux Forum (CELF), a California Non-Profit Corporation, is focused on the advancement of Linux as an open source platform for consumer electronics (CE) devices. The CELF intends to operate completely within the letter and the spirit of the open source community. The CELF is a place to come and discuss various issues that are of particular importance to the CE industry. Through an open process, the CELF members will clarify and codify certain requirements to be addressed in open source software. Thereafter, the CELF will evaluate any open source submissions as to their effectiveness and responsiveness to the requirements. Open source submissions accepted by the CELF Architecture Group and Steering Committee will be incorporated into the CELF source tree, which itself is open to the public.

There's some interesting stuff coming out of CELF, if you're interested in that sort of thing. IIRC, Matt Mackall (the author of the linux tiny set of patches) is now working for CELF. From other CELF members I've talked to, I can say that they seem to be a pretty techically oriented bunch. The individual CELF members aren't marketing types trying to push OSS developers to do their work for them, they're developers who have a real interest in pitching in and helping to make Linux a useful OS for consumer electronics.