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

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

Version Control Software

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

Contents

  Version Control Software cutems93 <ms2597@cornell.edu> - 2013-06-12 16:27 -0700
    Re: Version Control Software Mark Janssen <dreamingforward@gmail.com> - 2013-06-12 16:36 -0700
    Re: Version Control Software Joel Goldstick <joel.goldstick@gmail.com> - 2013-06-12 19:52 -0400
    Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-13 10:04 +1000
    Re: Version Control Software Tim Chase <python.list@tim.thechases.com> - 2013-06-12 21:41 -0500
    Re: Version Control Software Ben Finney <ben+python@benfinney.id.au> - 2013-06-13 12:30 +1000
      Re: Version Control Software rusi <rustompmody@gmail.com> - 2013-06-13 04:54 -0700
      Re: Version Control Software Grant Edwards <invalid@invalid.invalid> - 2013-06-13 17:06 +0000
        Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-14 07:26 +1000
          Re: Version Control Software Grant Edwards <invalid@invalid.invalid> - 2013-06-13 21:53 +0000
            Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-14 07:59 +1000
            Re: Version Control Software Zero Piraeus <schesis@gmail.com> - 2013-06-13 18:20 -0400
            Re: Version Control Software Terry Reedy <tjreedy@udel.edu> - 2013-06-13 20:09 -0400
        Re: Version Control Software Fábio Santos <fabiosantosart@gmail.com> - 2013-06-13 23:15 +0100
        Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-14 08:17 +1000
        Re: Version Control Software Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-06-13 15:24 -0700
        Re: Version Control Software Neil Hodgson <nhodgson@iinet.net.au> - 2013-06-14 08:53 +1000
    Re: Version Control Software Tim Chase <python.list@tim.thechases.com> - 2013-06-12 21:48 -0500
    Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-12 22:51 -0400
      Re: Version Control Software Rui Maciel <rui.maciel@gmail.com> - 2013-06-13 13:43 +0100
    Re: Version Control Software cutems93 <ms2597@cornell.edu> - 2013-06-12 23:00 -0700
      Re: Version Control Software rusi <rustompmody@gmail.com> - 2013-06-12 23:43 -0700
      Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-13 07:08 -0400
      Re: Version Control Software MRAB <python@mrabarnett.plus.com> - 2013-06-13 12:26 +0100
        Re: Version Control Software rusi <rustompmody@gmail.com> - 2013-06-13 04:46 -0700
      Re: Version Control Software Anssi Saari <as@sci.fi> - 2013-06-14 15:06 +0300
        Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-14 08:32 -0400
          Re: Version Control Software Grant Edwards <invalid@invalid.invalid> - 2013-06-14 14:24 +0000
            Re: Version Control Software Dave Angel <davea@davea.name> - 2013-06-14 16:55 -0400
            Re: Version Control Software Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-06-14 20:26 -0400
            Re: Version Control Software Tim Delaney <timothy.c.delaney@gmail.com> - 2013-06-15 15:39 +1000
            Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-15 15:53 +1000
              Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-15 10:16 -0400
                Re: Version Control Software Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com> - 2013-06-15 15:29 +0000
                  Re: Version Control Software Dan Sommers <dan@tombstonezero.net> - 2013-06-15 18:29 +0000
                    Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-16 09:01 +1000
                  Re: Version Control Software Tim Delaney <timothy.c.delaney@gmail.com> - 2013-06-16 07:49 +1000
                Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-16 09:14 +1000
                  Re: Version Control Software rusi <rustompmody@gmail.com> - 2013-06-15 20:55 -0700
                    Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-16 14:13 +1000
                      Re: Version Control Software Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-06-16 05:20 +0000
                        Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-16 15:29 +1000
                        Re: Version Control Software Terry Reedy <tjreedy@udel.edu> - 2013-06-16 05:15 -0400
                        Re: Version Control Software Chris Angelico <rosuav@gmail.com> - 2013-06-16 19:51 +1000
                Re: Version Control Software Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-06-16 15:30 +0200
                  Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-16 09:50 -0400
                    Re: Version Control Software Lele Gaifax <lele@metapensiero.it> - 2013-06-16 17:48 +0200
                    Re: Version Control Software Terry Reedy <tjreedy@udel.edu> - 2013-06-16 13:02 -0400
                Re: Version Control Software Jason Swails <jason.swails@gmail.com> - 2013-06-16 12:39 -0400
    Re: Version Control Software Serhiy Storchaka <storchaka@gmail.com> - 2013-06-13 10:20 +0300
    Re: Version Control Software Tim Chase <python.list@tim.thechases.com> - 2013-06-13 07:34 -0500
      Re: Version Control Software Roy Smith <roy@panix.com> - 2013-06-13 08:52 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#47901

Thank you everyone for such helpful responses! Actually, I have one more question. Does anybody have experience with closed source version control software? If so, why did you buy it instead of downloading open source software? Does closed source vcs have some benefits over open source in some part? 

Thanks!
MinS

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

#47909

On Jun 13, 11:00 am, cutems93 <ms2...@cornell.edu> wrote:
> Thank you everyone for such helpful responses! Actually, I have one more question. Does anybody have experience with closed source version control software? If so, why did you buy it instead of downloading open source software? Does closed source vcs have some benefits over open source in some part?
>
> Thanks!
> MinS

Not too many people who buy expensive software use it.
Those who use it, have usually not been party to buying it.

The first are usually called 'boss'.
The second, 'programmer' or some euphemism for that like 'software-
engineer.'

As to your question about vcs, there is also fossil:
http://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki

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

#47935

In article <2644d0de-9a81-41aa-b27a-cb4535964b58@googlegroups.com>,
 cutems93 <ms2597@cornell.edu> wrote:

> Thank you everyone for such helpful responses! Actually, I have one more 
> question. Does anybody have experience with closed source version control 
> software? If so, why did you buy it instead of downloading open source 
> software? Does closed source vcs have some benefits over open source in some 
> part? 

This really doesn't have anything to do with python.  Someplace like 
http://en.wikipedia.org/wiki/Comparison_of_version_control_systems would 
be a good starting point for further research.

If I were to buy a closed-source VCS today, I would look at Perforce 
(www.perforce.com).  I used it for several years.  For small teams, you 
can download and use it for free, so you can play with it without 
commitment.

Perforce tries to solve a somewhat larger problem than just version 
control.  They also do configuration management.  You can set up a 
config-spec which says, "Give me this bunch of files from branch A, that 
bunch of files from branch B, and some third bunch of files which have 
some specific tag.  And, while you're at it, remap the path names so the 
directory structure looks like I want it to".

This configuration management can be a powerful tool when working on a 
huge project.  We threw *everything* into our p4 repo, including the all 
the compilers, development toolchains, and pre-built binaries for all 
the third-party libraries we used.  We also used a single repo shared by 
all the development groups (many 100's of developers on three 
continents).  I would never want to do that in a system like git or hg; 
every developer would have to drag down 100's of GB of crap they didn't 
need.  With p4, we could build people config-specs so they got just the 
parts they needed.

It is also a bit of a steep learning curve to figure out.  Only a few 
people were trusted to do things like build config-specs and create 
shared branches.

As a company, Perforce is a dream to work with.  Their tech support was 
pretty awesome.  I would shoot off an email to support@perforce.com, and 
I don't think it ever took more than 5 or 10 minutes for me to get a 
response back from somebody.  And that somebody would inevitably be 
somebody who knew enough to solve my problem, not just some first-line 
support drone.

The costs aren't outrageous, either.  The pricing is a little 
complicated (initial license, annual renewal, various support options, 
of them on a sliding scale based on quantity).  I seem to remember it 
working out to about $100/developer/year for us, but we were buying in 
fairly large quantities.

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

#47937

On 13/06/2013 07:00, cutems93 wrote:
> Thank you everyone for such helpful responses! Actually, I have one
> more question. Does anybody have experience with closed source
> version control software? If so, why did you buy it instead of
> downloading open source software? Does closed source vcs have some
> benefits over open source in some part?
>
I've used Microsoft SourceSafe. I didn't like it (does anyone? :-)).

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

#47938

On Jun 13, 4:26 pm, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 13/06/2013 07:00, cutems93 wrote:> Thank you everyone for such helpful responses! Actually, I have one
> > more question. Does anybody have experience with closed source
> > version control software? If so, why did you buy it instead of
> > downloading open source software? Does closed source vcs have some
> > benefits over open source in some part?
>
> I've used Microsoft SourceSafe. I didn't like it (does anyone? :-)).

It seems to me that even MS is realizing that SourceSafe's time is
over:

http://techcrunch.com/2013/01/30/microsoft-announces-git-support-for-visual-studio-team-foundation-server-and-service/

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

#48122

cutems93 <ms2597@cornell.edu> writes:

> Thank you everyone for such helpful responses! Actually, I have one more question. Does anybody have experience with closed source version control software? If so, why did you buy it instead of downloading open source software? Does closed source vcs have some benefits over open source in some part? 

I have some experience with ClearCase. I don't know why anyone would buy
it since it's bloated and slow and hard to use and likes to take over
your computer. I was very happy to dump it when my team was allowed to
use whatever we wanted but then we were not doing software either.

ClearCase is also admin heavy for the above reasons. I guess big
businesses buy things like that because other big businesses buy things
like that. Presumably they keep it because it's cheaper to pay
maintenance than move all source to some other system.

Now granted, Linux development went to commercial Bitkeeper for a while
since Linus Torvalds found it superior to CVS sometime over a decade
ago. When the agreement ended, Torvalds himself developed Git to be what
he needs. Other projects sprang up around the same time to get that job,
this means at least Mercurial if Wikipedia is to be believed.

Oh, as far as I know, commercial software vendors always ban their
customers from publishing any kinds of benchmarks or other comparisons
so it's unlikely you can find anything concrete for your commercial
vs. free choice.

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

#48129

In article <vg3obb899rk.fsf@coffee.modeemi.fi>, Anssi Saari <as@sci.fi> 
wrote:

> I have some experience with ClearCase. I don't know why anyone would buy
> it since it's bloated and slow and hard to use and likes to take over
> your computer.

ClearCase was the right solution to certain specific problems which 
existed 20 years ago.  It does have a couple of cool features.

1) Every revision of every file exists simultaneously in the file system 
namespace (CC exports its repo as a quasi-NFS file system).  That means 
you can look at every revision with all your normal command-line tools 
(diff, grep, whatever).

2) It ships with an integrated build tool which can automatically learn 
your dependency graph.  This is paired with a feature called "winking 
in".  Let's say I'm building a humungous C++ project which takes hours 
to compile.  And I'm part of a team of 50 developers, all working on the 
same code.

If I need foo.o, and some other developer has already compiled a foo.o 
with exactly the same dependency graph (including what versions of the 
toolchain and option flags), I just instantly and transparently get a 
copy of their file instead of having to build it myself.  This can 
potentially save a huge amount of build time. 

All that being said, it is, as Anssi points out, a horrible, bloated, 
overpriced, complicated mess which requires teams of specially trained 
ClearCase admins to run.  In other words, it's exactly the sort of thing 
big, stupid, Fortune-500 companies buy because the IBM salesperson plays 
golf with the CIO.

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

#48155

On 2013-06-14, Roy Smith <roy@panix.com> wrote:

> All that being said, it is, as Anssi points out, a horrible, bloated,
> overpriced, complicated mess which requires teams of specially
> trained ClearCase admins to run.  In other words, it's exactly the
> sort of thing big, stupid, Fortune-500 companies buy because the IBM
> salesperson plays golf with the CIO.

Years ago, I worked at one largish company where a couple of the
embedded development projects used ClearCase.  The rest of us used CVS
or RCS or some other cheap commercial systems.  Judging by those
results, ClearCase requires a full-time administrator for every 10 or
so users.  The other systems seemed to require almost no regular
administration, and what was required was handled by the developers
themselves (mayby a couple hours per month).  The cost of ClearCase
was also sky-high.

-- 
Grant Edwards               grant.b.edwards        Yow! VICARIOUSLY experience
                                  at               some reason to LIVE!!
                              gmail.com            

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

#48217

On 06/14/2013 10:24 AM, Grant Edwards wrote:
> On 2013-06-14, Roy Smith <roy@panix.com> wrote:
>
>> All that being said, it is, as Anssi points out, a horrible, bloated,
>> overpriced, complicated mess which requires teams of specially
>> trained ClearCase admins to run.  In other words, it's exactly the
>> sort of thing big, stupid, Fortune-500 companies buy because the IBM
>> salesperson plays golf with the CIO.
>
> Years ago, I worked at one largish company where a couple of the
> embedded development projects used ClearCase.  The rest of us used CVS
> or RCS or some other cheap commercial systems.  Judging by those
> results, ClearCase requires a full-time administrator for every 10 or
> so users.  The other systems seemed to require almost no regular
> administration, and what was required was handled by the developers
> themselves (mayby a couple hours per month).  The cost of ClearCase
> was also sky-high.
>

if I remember rightly, it was about two-thousand dollars per seat.  And 
the people I saw using it were using XCOPY to copy the stuff they needed 
onto their local drives, then disabling the ClearCase service so they 
could get some real work done.  Compiles were about 10x slower with the 
service active.

Now that was on Windows NT, when Clearcase was first porting from Unix. 
  So perhaps things have improved.


-- 
DaveA

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

#48234

On Fri, 14 Jun 2013 16:55:20 -0400, Dave Angel <davea@davea.name>
declaimed the following in gmane.comp.python.general:

> 
> if I remember rightly, it was about two-thousand dollars per seat.  And 
> the people I saw using it were using XCOPY to copy the stuff they needed 
> onto their local drives, then disabling the ClearCase service so they 
> could get some real work done.  Compiles were about 10x slower with the 
> service active.
>
	My previous employer had standardized on ClearCase... Probably
because the cost could be billed to the customer as part of the contract
(and a customer that probably feels comfortable with big commercial
version control and /reporting/ tool).

	RCS, Update [really old -- as I recall, it required columns 72-80 to
store its versioning data; and how many people worry about a 72 column
limit even in FORTRAN?], and the like tend to (my experience) fall apart
if given binary files -- not just source (text) files. I believe that
program used ClearCase to also archive each /build/, rather than just
the status of the sources and makefiles needed to recreate the build.
 
> Now that was on Windows NT, when Clearcase was first porting from Unix. 
>   So perhaps things have improved.

	Well... I actually had an unofficial (the "free" version) of
GNAT/GPS installed on my system at work (nice of GNAT to have an
"install for current user" that didn't need admin)[If I really pushed, I
could maybe have gotten the $$$$ support version -- we were paying for
the support for Solaris&SunOS]. I'd found that GPS ran faster, accessing
ClearCase internally, for editing files than running GPS on the Sun
boxes... I did have to do the build on the Sun, but that was done by
just opening an X session on the Sun next to my WinXP box and invoking
clearmake.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#48251

[Multipart message — attachments visible in raw view] — view raw

On 15 June 2013 06:55, Dave Angel <davea@davea.name> wrote:

> On 06/14/2013 10:24 AM, Grant Edwards wrote:
>
>> On 2013-06-14, Roy Smith <roy@panix.com> wrote:
>>
>>  All that being said, it is, as Anssi points out, a horrible, bloated,
>>> overpriced, complicated mess which requires teams of specially
>>> trained ClearCase admins to run.  In other words, it's exactly the
>>> sort of thing big, stupid, Fortune-500 companies buy because the IBM
>>> salesperson plays golf with the CIO.
>>>
>>
>> Years ago, I worked at one largish company where a couple of the
>> embedded development projects used ClearCase.  The rest of us used CVS
>> or RCS or some other cheap commercial systems.  Judging by those
>> results, ClearCase requires a full-time administrator for every 10 or
>> so users.  The other systems seemed to require almost no regular
>> administration, and what was required was handled by the developers
>> themselves (mayby a couple hours per month).  The cost of ClearCase
>> was also sky-high.
>>
>>
> if I remember rightly, it was about two-thousand dollars per seat.  And
> the people I saw using it were using XCOPY to copy the stuff they needed
> onto their local drives, then disabling the ClearCase service so they could
> get some real work done.  Compiles were about 10x slower with the service
> active.
>

I can absolutely confirm how much ClearCase slows things down. I completely
refused to use dynamic views for several reasons - #1 being that if you
lost your network connection you couldn't work at all, and #2 being how
slow they were. Static views were slightly better as you could at least
hijack files in that situation and keep working (and then be very very
careful when you were back online).

And then of course there was ClearCase Remote Client. I was working from
home much of the time, so I got to use CCRC. It worked kinda well enough,
and in that situation was much better than the native client. Don't ever
ever try to use ClearCase native over a non-LAN connection. I can't stress
this enough. The ClearCase protocol is unbelievably noisy, even if using
static views.

CCRC did have one major advantage over the native client though. I had the
fun task when I moved my local team from CC to Mercurial of keeping the
Mercurial and CC clients in sync. Turns out that CCRC was the best option,
as I was able to parse its local state files and work out what timestamp
ClearCase thought its files should be, set it appropriately from a
Mercurial extension and convince CCRC that really, only these files have
changed, not the thousand or so that just had their timestamp changed ...
CCRC at least made that possible, even if it was a complete accident by the
CCRC developers.

Tim Delaney

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

#48253

On Sat, Jun 15, 2013 at 3:39 PM, Tim Delaney
<timothy.c.delaney@gmail.com> wrote:
> I can absolutely confirm how much ClearCase slows things down. I completely
> refused to use dynamic views for several reasons - #1 being that if you lost
> your network connection you couldn't work at all...

And that right there is why modern source control systems are
distributed, not centralized. It's so much easier with git; we lost
our central hub at one point, and another dev and I simply pulled from
each other for a bit until we got a new Scaphio online. With
centralized version control, that would have basically meant a
complete outage until the new box was up.

ChrisA

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

#48298

In article <mailman.3359.1371275633.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sat, Jun 15, 2013 at 3:39 PM, Tim Delaney
> <timothy.c.delaney@gmail.com> wrote:
> > I can absolutely confirm how much ClearCase slows things down. I completely
> > refused to use dynamic views for several reasons - #1 being that if you lost
> > your network connection you couldn't work at all...
> 
> And that right there is why modern source control systems are
> distributed, not centralized. It's so much easier with git; we lost
> our central hub at one point, and another dev and I simply pulled from
> each other for a bit until we got a new Scaphio online. With
> centralized version control, that would have basically meant a
> complete outage until the new box was up.
> 
> ChrisA

The advantage of DVCS is that everybody has a full copy of the repo.  
The disadvantage of the DVCS is that every MUST have a full copy of the 
repo.  When a repo gets big, you may not want to pull all of that data 
just to get the subtree you need.

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

#48310

On 2013-06-15, Roy Smith wrote:

>> And that right there is why modern source control systems are
>> distributed, not centralized. It's so much easier with git; we lost
>> our central hub at one point, and another dev and I simply pulled from
>> each other for a bit until we got a new Scaphio online. With
>> centralized version control, that would have basically meant a
>> complete outage until the new box was up.
>> 
>> ChrisA
>
> The advantage of DVCS is that everybody has a full copy of the repo.  
> The disadvantage of the DVCS is that every MUST have a full copy of the 
> repo.  When a repo gets big, you may not want to pull all of that data 
> just to get the subtree you need.

Also, is working without connection to the server such big an issue? One
would expect that losing access to the central server would indicate
significant problems that would impact development anyway.

-- 
Real (i.e. statistical) tennis and snooker player rankings and ratings:
http://www.statsfair.com/ 

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

#48347

On Sat, 15 Jun 2013 15:29:27 +0000, Giorgos Tzampanakis wrote:

> Also, is working without connection to the server such big an issue?
> One would expect that losing access to the central server would
> indicate significant problems that would impact development anyway.

Everyone and every device is connected to the internet all the time, or
else the universe comes to an end.

Get off my lawn!  ;-)

Being able to work remotely is a huge win.  Anarchy is not.  Somewhere
in between, reality sets in, and I can work appropriately for different
use cases.

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

#48383

On Sun, Jun 16, 2013 at 4:29 AM, Dan Sommers <dan@tombstonezero.net> wrote:
> On Sat, 15 Jun 2013 15:29:27 +0000, Giorgos Tzampanakis wrote:
>
>> Also, is working without connection to the server such big an issue?
>> One would expect that losing access to the central server would
>> indicate significant problems that would impact development anyway.
>
> Everyone and every device is connected to the internet all the time, or
> else the universe comes to an end.
>
> Get off my lawn!  ;-)

So some of us think that version control is a single-player game, but
CVS-Box One thinks always-on gaming is a reasonable thing?

*ducks*

ChrisA

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

#48377

[Multipart message — attachments visible in raw view] — view raw

On 16 June 2013 01:29, Giorgos Tzampanakis <giorgos.tzampanakis@gmail.com>wrote:

> On 2013-06-15, Roy Smith wrote:
>
> Also, is working without connection to the server such big an issue? One
> would expect that losing access to the central server would indicate
> significant problems that would impact development anyway.
>

I work almost 100% remotely (I chose to move back to a country town). Most
of the time I have a good internet connection. But sometimes my clients are
in other countries (I'm in Australia, my current client is in the US) and
the VPN is slow or doesn't work (heatwaves have taken down their systems a
few times). Sometimes I'm on a train going to Sydney and mobile internet is
pretty patchy much of the way. Sometimes my internet connection dies - we
had a case where someone put a backhoe through the backhaul and my backup
mobile internet was also useless.

But so long as at some point I can sync the repositories, I can work away
(on things that are not dependent on something new from upstream).

Tim Delaney

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

#48386

On Sun, Jun 16, 2013 at 12:16 AM, Roy Smith <roy@panix.com> wrote:
> The advantage of DVCS is that everybody has a full copy of the repo.
> The disadvantage of the DVCS is that every MUST have a full copy of the
> repo.  When a repo gets big, you may not want to pull all of that data
> just to get the subtree you need.

Yeah, and depending on size, that can be a major problem. While git
_will_ let you make a shallow clone, it won't let you push from that,
so it's good only for read-only repositories (we use git to manage
software deployments at work - shallow clones are perfect) or for
working with patch files.

Hmm. ~/cpython/.hg is 200MB+, but ~/pike/.git is only 86MB. Does
Mercurial compress its content? A tar.gz of each comes down, but only
to ~170MB and ~75MB respectively, so I'm guessing the bulk of it is
already compressed. But 200MB for cpython seems like a lot.

Anyway, this problem is a good reason for dividing a repository up
into logically-separate parts. If you'll often want only one subtree,
maybe that shouldn't be a subtree of a monolithic repository.

ChrisA

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

#48406

On Jun 16, 4:14 am, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Jun 16, 2013 at 12:16 AM, Roy Smith <r...@panix.com> wrote:
> > The advantage of DVCS is that everybody has a full copy of the repo.
> > The disadvantage of the DVCS is that every MUST have a full copy of the
> > repo.  When a repo gets big, you may not want to pull all of that data
> > just to get the subtree you need.
>
> Yeah, and depending on size, that can be a major problem. While git
> _will_ let you make a shallow clone, it won't let you push from that,
> so it's good only for read-only repositories (we use git to manage
> software deployments at work - shallow clones are perfect) or for
> working with patch files.
>
> Hmm. ~/cpython/.hg is 200MB+, but ~/pike/.git is only 86MB. Does
> Mercurial compress its content? A tar.gz of each comes down, but only
> to ~170MB and ~75MB respectively, so I'm guessing the bulk of it is
> already compressed. But 200MB for cpython seems like a lot.

[I am assuming that you have run  "git gc --aggressive" before giving
those figures]

Your data would tell me that python is about twice as large a project
as pike in terms of number of commits. Isn't this a natural conclusion?

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

#48409

On Sun, Jun 16, 2013 at 1:55 PM, rusi <rustompmody@gmail.com> wrote:
> On Jun 16, 4:14 am, Chris Angelico <ros...@gmail.com> wrote:
>> On Sun, Jun 16, 2013 at 12:16 AM, Roy Smith <r...@panix.com> wrote:
>> > The advantage of DVCS is that everybody has a full copy of the repo.
>> > The disadvantage of the DVCS is that every MUST have a full copy of the
>> > repo.  When a repo gets big, you may not want to pull all of that data
>> > just to get the subtree you need.
>>
>> Yeah, and depending on size, that can be a major problem. While git
>> _will_ let you make a shallow clone, it won't let you push from that,
>> so it's good only for read-only repositories (we use git to manage
>> software deployments at work - shallow clones are perfect) or for
>> working with patch files.
>>
>> Hmm. ~/cpython/.hg is 200MB+, but ~/pike/.git is only 86MB. Does
>> Mercurial compress its content? A tar.gz of each comes down, but only
>> to ~170MB and ~75MB respectively, so I'm guessing the bulk of it is
>> already compressed. But 200MB for cpython seems like a lot.
>
> [I am assuming that you have run  "git gc --aggressive" before giving
> those figures]

They're both clones done for the purpose of building, so I hadn't run
any sort of garbage collect.

> Your data would tell me that python is about twice as large a project
> as pike in terms of number of commits. Isn't this a natural conclusion?

I didn't think there would be that much difference, tbh. Mainly, I'm
just seeing cpython as not being 200MB of history, or so I'd thought.
Pike has ~30K commits (based on 'git log --oneline|wc -l'); CPython
has roughly 80K (based on 'hg log|grep changeset|wc -l' - there's
likely an easier way but I don't know Mercurial). So yeah, okay, it's
been doing more. But I still don't see 200MB in that. Seems a lot of
content.

ChrisA

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web