A new major release of the Mercurial source code management system is out.
New features can be seen on the
Mercurial "what's new" page; they include some new branching options,
more flexible importing of patches, XML log templates, and more. The download directory
contains the source.
(Log in to post comments)
Downloading
Posted Mar 8, 2010 10:31 UTC (Mon) by epa (subscriber, #39769)
[Link]
Odd that the summary links to the 'download directory' - surely the canonical way to get the software these days is to pull a particular revision from the upstream repository. Or is that too chicken and egg in this case? I can't imagine anyone using a Linux distribution that doesn't already package hg.
Downloading
Posted Mar 8, 2010 12:24 UTC (Mon) by lkundrak (subscriber, #43452)
[Link]
As far as I have heard, Mercurial is used on other platforms where GIT was not working well enough. At the very least on Windows, where sane packaging systems are unheard of.
Downloading
Posted Mar 8, 2010 12:30 UTC (Mon) by epa (subscriber, #39769)
[Link]
True, but tar and gzip are not packaged with Windows either. And who installs software on Windows by building it from source?
Downloading
Posted Mar 8, 2010 13:26 UTC (Mon) by tzafrir (subscriber, #11501)
[Link]
Packaging for distributions is normally built on top of tarballs.
Downloading
Posted Mar 9, 2010 10:49 UTC (Tue) by mpr22 (subscriber, #60784)
[Link]
Windows's own built-in archive-extraction support doesn't support .tar.gz, but popular third-party (de-)compression tools for Windows do.
Downloading
Posted Mar 8, 2010 15:21 UTC (Mon) by tseaver (subscriber, #1544)
[Link]
> surely the canonical way to get the software these days is to pull a particular revision from the upstream repository
Surely not. A tarball of a specific release is vastly more useful for nearly any purpose other than ongoing development. Most consumers of software are not developers (or at least are not developers of everything they consume).
When was the last time you built everything on your system from sources you pulled from a VCS?
Downloading
Posted Mar 10, 2010 12:00 UTC (Wed) by epa (subscriber, #39769)
[Link]
Why is a tarball more useful? More familiar, yes. But apart from 'we have always done it that way', what is the advantage to getting a certain collection of bits by uncompressing a tarball, compared to getting exactly the same bits using a pull command? Indeed, pulling a particular SHA-signed revision gives you a much stronger guarantee you're getting the right thing rather than some trojaned version.
Downloading
Posted Mar 10, 2010 16:44 UTC (Wed) by mpr22 (subscriber, #60784)
[Link]
Getting the sources as a tarball: Click link in web browser. Save tarball. Unpack tarball with archiver.
Getting the sources of a VCS tool with a VCS tool: Egg, meet chicken.
Getting the sources of a general app whose VCS system isn't one I have the tool for installed on my system: Why should I install a VCS tool I'm not actually going to use for version control just so I can build this app's supposed production-quality release from source?
Slurping from VCS is fine for developers, and for users wanting to run the bleeding-edge it-compiles-on-my-machine-honest-guv versions of things, but for people wanting to install the latest production version of something that their distro doesn't have a recent package of and the authors don't package as binaries, I think "tarball" wins over "slurp from VCS" every time.
Downloading
Posted Mar 9, 2010 10:46 UTC (Tue) by mpr22 (subscriber, #60784)
[Link]
Software distributors who ask me to install supposedly "production" software by pulling a specified VCS revision are rude. If it's a production release, put it in a .tar.gz or a .zip or something.
Downloading
Posted Mar 13, 2010 2:39 UTC (Sat) by nlucas (subscriber, #33793)
[Link]
Many source packages are not the same as what is on the source repository at
a given revision/tag.
For example, the configure script is usually pre-generated on the tarball
and not present on the repository.
Many other generated content is not present on the repository. One usual
case is the repository to have SVG files, but not the target PNG files used
by the application. The user could generate those but it would probably
require other software not needed for simple program compilation.