Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #68569 > unrolled thread

Re: Question about Source Control

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-20 18:15 +1100
    Re: Question about Source Control Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-21 11:19 +1300
      Re: Question about Source Control Chris Angelico <rosuav@gmail.com> - 2014-03-21 09:34 +1100
      Re: Question about Source Control albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-03-22 17:53 +0000

#68569 — Re: Question about Source Control

On Thu, Mar 20, 2014 at 5:48 PM, Frank Millman <frank@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

[toc] | [next] | [standalone]

#68634

Chris Angelico wrote:
> You can then offer a non-source-control means of downloading that
> specific revision.

Just keep in mind the downside that you can't then
push or pull your changes directly back into the main
repository. You can generate a patch file for the
project maintainer to apply, however. Hg makes it
very easy to produce a patch file between any two
revisions.

Also, unless the project is truly ancient, the
whole history might not be as big as you expect.
The code presumably grew to its present size
incrementally, in an approximately monotonic
manner, so the sum of all the diffs is probably
about the same order of magnitude as the current
code size.

As an experiment, I just cloned a copy of the
CPython repository, and it's about 300MB. A
tarball of Python 3.2 that I downloaded and
compiled earlier is about 75MB. That's a ratio
of about 4, and CPython is a pretty ancient
project!

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#68636

On Fri, Mar 21, 2014 at 9:19 AM, Gregory Ewing
<greg.ewing@canterbury.ac.nz> wrote:
> Chris Angelico wrote:
>>
>> You can then offer a non-source-control means of downloading that
>> specific revision.
>
> Just keep in mind the downside that you can't then
> push or pull your changes directly back into the main
> repository. You can generate a patch file for the
> project maintainer to apply, however. Hg makes it
> very easy to produce a patch file between any two
> revisions.

Yes, but a lot of people just want to get the software, they don't
actually need to generate patch files :)

> Also, unless the project is truly ancient, the
> whole history might not be as big as you expect.
> The code presumably grew to its present size
> incrementally, in an approximately monotonic
> manner, so the sum of all the diffs is probably
> about the same order of magnitude as the current
> code size.
>
> As an experiment, I just cloned a copy of the
> CPython repository, and it's about 300MB. A
> tarball of Python 3.2 that I downloaded and
> compiled earlier is about 75MB. That's a ratio
> of about 4, and CPython is a pretty ancient
> project!

Yep! But cloning requires that you have Mercurial installed and, more
importantly, know how to use it. We don't have a huge proliferation of
source control systems these days, but if someone says "Our code is
available via Perforce", I'm going to just look for a tarball
download, rather than figure out a source control system I don't know.

ChrisA

[toc] | [prev] | [next] | [standalone]

#68785

In article <bp17s6Fbs18U1@mid.individual.net>,
Gregory Ewing  <greg.ewing@canterbury.ac.nz> wrote:
>Chris Angelico wrote:
>> You can then offer a non-source-control means of downloading that
>> specific revision.
>
>Just keep in mind the downside that you can't then
>push or pull your changes directly back into the main
>repository. You can generate a patch file for the
>project maintainer to apply, however. Hg makes it
>very easy to produce a patch file between any two
>revisions.
>
>Also, unless the project is truly ancient, the
>whole history might not be as big as you expect.
>The code presumably grew to its present size
>incrementally, in an approximately monotonic
>manner, so the sum of all the diffs is probably
>about the same order of magnitude as the current
>code size.
>
>As an experiment, I just cloned a copy of the
>CPython repository, and it's about 300MB. A
>tarball of Python 3.2 that I downloaded and
>compiled earlier is about 75MB. That's a ratio
>of about 4, and CPython is a pretty ancient
>project!

This post made me worry for the first time about one project of
mine (ciforth). It started in 2000 with an msdos assembler file,
and after several hundreds version it has accumulated doc's and test's
and is now usable on linux, windows whatnot.

Since 2000 the cvs style archive has grown to 2 megabyte,
for a current version of 400 kbyte. I kept the smallest of changes,
and at times was very happy I did.

Bottom line, the grow of a source archive cannot keep up
with LAN and Internet speeds and hard disk sizes.

>
>--
>Greg

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web