Weekly Edition
Return to the Development page
| |||||||||||||||||||
Mercurial 2.0 released
This is a regularly-scheduled feature release, we've just rolled over from 1.9 to 2.0. Full details here: http://mercurial.selenic.com/wiki/WhatsNew Available for download at: http://mercurial.selenic.com/release/mercurial-2.0.tar.gz Binaries releases to follow shortly. Thanks to everyone who's helped develop and test this release. New code contributors in this release include: Alexander Krauss Andrew Pritchard Andrzej Bieniek Ben Hockey Etienne Desautels Hao Lian Jakob Krainz Jordi Gutiérrez Hermoso Kirill Elagin Marc Simpson Na'Tosha Bard Nikolaj Sjujskij Pang Yan Han Peer Stritzinger Robert Jones Steffen Daode Nurpmeso Steve Streeting Vasily Titskiy Wujek Srujek -- Mathematics is the supreme nostalgia of our time. (Log in to post comments)
Mercurial 2.0 released Posted Nov 2, 2011 20:11 UTC (Wed) by chojrak11 (guest, #52056) [Link]
Did they fix UTF-8 file names at last? I had to drop Mercurial because it was incappable of handling file names that contained non-ASCII characters.
Mercurial 2.0 released Posted Nov 2, 2011 20:22 UTC (Wed) by pboddie (subscriber, #50784) [Link]
From recent discussions on the mailing list, it wasn't so much the UTF-8 aspect of filenames that people had problems with, but that beyond an extension aimed at the Windows platform, there's no established logic for converting filenames (which are just bundles of bytes to Mercurial) to a specific character sequence that Windows wants to use when being asked to write files with specific names.
I'm not sure if the discussion has moved further forward since I last paid it any attention, however.
Mercurial 2.0 released Posted Nov 3, 2011 1:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
It's more complicated.
On Linux things are simple - you store a sequence of bytes as a filename and in general you'll get it exactly the same when you read it back.
On Windows filenames are stored in UCS-2. So when you use 8-bit API the names must be transcoded from 16-bit to 8-bit encodings. By default the system encoding is used which is usually a legacy fixed 8-bit encoding. So you lose some filename information.
Windows Posted Nov 3, 2011 1:45 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
Internally in the NT kernel, filenames are arbitrary sequences of 16-bit code units (just as the Linux filenames are arbitrary sequences of 8-bit code units ie bytes) which don't mean anything.
However people who want software for "Windows" most often want it to run in the Win32 environment. The Win32 environment enforces a whole bunch of semantics for the names of files. You can cut past it, and talk to the NT kernel, but on the whole this will tend to cause confusion.
The Win32 semantics assume filenames are UTF-16 (not UCS-2 which is now obsolete) and that they are case-insensitive, according to a case-matching table embedded into each specific NTFS filesystem. They also ban a whole bunch of possible names that were felt to be confusing for users, or interacted poorly with 1980s DOS software.
I have no idea why Mercurial would be using the non-Unicode APIs. Those are deprecated, and using them in new code seems like a recipe for disaster. Does Mercurial intend to run on the long obsolete Windows 95? If not, the non-Unicode APIs serve only to make life needlessly complicated.
Windows Posted Nov 3, 2011 12:53 UTC (Thu) by cesarb (subscriber, #6266) [Link]
> I have no idea why Mercurial would be using the non-Unicode APIs. Those are deprecated, and using them in new code seems like a recipe for disaster. Does Mercurial intend to run on the long obsolete Windows 95? If not, the non-Unicode APIs serve only to make life needlessly complicated.
Most Unix-based software will end up using the "ANSI" (8-bit) APIs by default when ported to Win32.
For instance, most Unix programmers, when writing portable code, will store file names in arrays of "char". On all the Win32 C runtimes I have seen (another difference from Unix - Win32 does not have a standard C runtime, each compiler is supposed to have its own C runtime), the file system functions which receive a "const char *" (for instance, fopen) map to the "ANSI" APIs (for instance, CreateFileA).
The best way around that would be to write your own file system functions, which on most operating systems simply call the corresponding functions in the C runtime, but on Win32 treat the parameter as UTF-8 (converting via MultiByteToWideChar) and call the Win32 "Unicode" functions (for instance, CreateFileW) directly. I believe msysgit (the most popular Win32 port of git) is going in that direction.
Windows Posted Nov 3, 2011 20:12 UTC (Thu) by Fowl (subscriber, #65667) [Link] >Most Unix-based software will end up using the "ANSI" (8-bit) APIs by default when ported to Win32. Eww.
Windows Posted Nov 4, 2011 13:40 UTC (Fri) by pboddie (subscriber, #50784) [Link]
I'm not sure what level of support Python (specifically CPython 2.x) has for the "Unicode" filesystem functions on Windows. For example, if you pass a Unicode object to os.listdir as the directory name, the resulting list of filenames should contain Unicode objects for those names that can be converted to a Unicode representation, but I haven't looked to see which API they use to achieve this.
I imagine that in Python 3, basic functions like open have to confront this issue because of the Unicode nature of the string type - in Python 2, one can just wave the issue away and not do anything special for Unicode objects passed to open - but I haven't looked at what they do here, either.
Mercurial 2.0 released Posted Nov 2, 2011 22:37 UTC (Wed) by juliank (subscriber, #45896) [Link]
So, they created a rudimentary version of something like git-annex for hg and included it?
Mercurial 2.0 released Posted Nov 3, 2011 9:40 UTC (Thu) by jubal (subscriber, #67202) [Link] So, they included it in the mainline extension bundle, which means that it will be available with all mercurial 2.0+ installations. It's not that hard to actually read the release announcement, y'know.
Mercurial 2.0 released Posted Nov 3, 2011 10:44 UTC (Thu) by juliank (subscriber, #45896) [Link]
I don't see that I wrote anything different.
Mercurial 2.0 released Posted Nov 4, 2011 8:11 UTC (Fri) by oblio (guest, #33465) [Link]
First of all, your are trolling.
But as xkcd says, "someone is wrong on the internet" and I need to fix this :p So I want to know why the Mercurial extension is "rudimentary"? If you are making a claim, back it up with facts...
Secondly, their extension is included with the base package, which makes it much easier to get/use for regular users. It also helps administrators.
Thirdly, from what I can see git-annex is newer than the largefiles extension. largefiles is derived from a project named hg-bfiles, started in 2009 (http://hg.gerg.ca/hg-bfiles/shortlog/296?revcount=480).
Of course, a normal human being would just say that they have the same problem and reached the same solution. Plus, being Open Source projects, the whole point is to use them and borrow good ideas...
Mercurial 2.0 released Posted Nov 4, 2011 13:58 UTC (Fri) by juliank (subscriber, #45896) [Link]
The hg one is just slightly more integrated and more centralised. IIRC, git-annex can pull one file from A, and one from B, and move files around (or copy them between repositories). I did not look at it closely, I just know that git-annex exists and that the hg thing looks similar.
Mercurial 2.0 released Posted Nov 4, 2011 17:36 UTC (Fri) by robert_s (subscriber, #42402) [Link]
Having used both git and mercurial, I actually find git generally makes more assumptions about your workflow. Of course, not that it actually stops you from being able to work how you want, but git is full of obscure shortcuts that assume something about your working style, which I find very annoying.
Mercurial 2.0 released Posted Nov 4, 2011 20:45 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
> I actually find git generally makes more assumptions about your workflow.
Such as? I'd like an example, as I have gone through a few workflows with git and haven't noticed this. Sure, there are defaults if you don't specify all the arguments of commands and no relevant configs are set (usually involving origin, master, HEAD, stash@{0}, the index, and the working tree).
Mercurial 2.0 released Posted Nov 5, 2011 0:18 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
it's less that git makes assumptions about your workflow than it is that people have submitted shortcuts to make their workflow better. there are such shortcuts for multiple different workflwos, and they git team are willing to accept shortcuts for other workflows as well.
Mercurial 2.0 released Posted Nov 4, 2011 18:56 UTC (Fri) by joey (subscriber, #328) [Link]
I did not know about the mercurial extension when I wrote git-annex.
The models used by the two are different in significant ways, I discussed differences here: <http://news.ycombinator.com/item?id=3187578>
|
|||||||||||||||||||