On Thu, Mar 20, 2014 at 5:48 PM, Frank Millman <fr...@chagford.com> wrote: > One thing still confuses me. Over the lifetime of a project, there could be > many thousands of changesets. Some of those could be tagged as 'major > releases'. Someone wishing to clone the project from scratch may want to > start from the latest major release, and not download every changeset since > the project started. > > How is this handled in practice?
There are several ways, but the most common is to simply tag a revision along the way; Pike does this, and I do the same in Gypsum. Pike 7.8.700 is commit 1ace5c: http://pike-git.lysator.liu.se/gitweb.cgi?p=pike.git;a=commit;h=1ace5c8e7c5c14fcaeeefd307b1ec99b80560311 Gypsum 1.1.0 is commit d937bf: https://github.com/Rosuav/Gypsum/tree/v1.1.0 You can then offer a non-source-control means of downloading that specific revision. Github does this for me automatically: https://github.com/Rosuav/Gypsum/archive/v1.1.0.zip Pike goes further and publishes binaries for various systems, too, and the source archive isn't quite a pure snapshot of git at that point (it has some intermediate files so as to reduce dependencies), but the effect is the same - if you want to get Pike 7.8.700, you don't need all the changes: http://pike.lysator.liu.se/download/pub/pike/latest-stable/ Python also snapshots like that, but with a much more complicated history than either of the above; the Python download pages offer you source tarballs and compiled binaries. If you want to find version 3.3.1 in source control, just look that up in the .hgtags file, which says that "v3.3.1" is d9893d. (I'm not familiar with hg-web, so I can't provide a link. But it's effectively the same as I showed above.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list