Python Goes Mercurial

  • Thread starter Lawrence D'Oliveiro
  • Start date
L

Lawrence D'Oliveiro

andrew said:
i haven't read the article you link to, but compared to what i've read on
dev "strong antipathies" sounds a bit over-hyped.

That was the phrase used by GvR.
 
T

Terry Reedy

Lawrence said:

The relevant PEP is http://www.python.org/dev/peps/pep-0374/
To some Pythonic eyes, the git command syntax in the examples given is
less graceful.

Another thing mentioned in the py-dev thread. Git apparently allows
'changing history' by changing the underlying directed acyclic graph.
Some like that, some do not. (I do not completely understand this, but
you asked...)

tjr
 
L

Lawrence D'Oliveiro


Useful link, though it seems incomplete.

Interesting phrase "To make up for svn's lack of cheap branching"--it's not the branching that's the problem in Subversion, it's the merging. :)
Git apparently allows 'changing history' by changing the underlying
directed acyclic graph.

Every object in a Git repository is identified by the SHA-1 hash of its entire contents. For a commit object, that includes the references to its parent commit(s). Thus,
there's no way <http://wlug.org.nz/VeryImpossible> to change these while preserving the identity of the commit object.

Yes, it's easy with the low-level Git commands to go back and synthesize past history, but you can't hide the fact that you've done so. One of the design goals of Git
was guaranteeing the integrity of the entire commit history.
 
P

Paul Rubin

Terry Reedy said:

Interesting. I'm on a project that switched from Mercurial to Git
recently. I don't have much of a sense of the relevant differences
but other people on the project seemed to prefer Git rather strongly.
Git does seem to faster, contrary to the measurements in that PEP.
 
C

Chris Rebert

Apparently Mercurial had it's own hate club, and the reaction on
python-dev was so severe GvR backtracked on his decision.

Trying to appease a least common denominator, he changed his mind and
Python is going with SCCS instead.

This is why I hate staying up late on March 31st...

Cheers,
Chris
 
P

Paul Boddie

Interesting.  I'm on a project that switched from Mercurial to Git
recently.  I don't have much of a sense of the relevant differences
but other people on the project seemed to prefer Git rather strongly.
Git does seem to faster, contrary to the measurements in that PEP.

From what I've seen by browsing the blogs of various large
communities, there always seems to be large numbers of Git advocates
(although "fanboys" might be a more accurate term in numerous cases)
ready to crowd out blog comments with single line insistences that
projects switch to Git. Indeed, I've even seen something resembling an
advocacy site for Git where there's a comparison to Mercurial and
Bazaar, although the benchmarks seem to be done with a certain amount
of honesty. Consequently, many projects seem to choose Git either on
the basis of what other people have supposedly done, or on the "hacker
cred" supposedly conferred through its association with Linus
Torvalds.

I've also heard various tales of Git usage where "strong antipathies"
would be a fairly accurate summary of user experiences, and this is
where such experiences can be contrasted with solid experiences with
other version control systems. And I've heard stories of "bait and
switch" with Git: "you can do XYZ with Git but not with ..." followed
by the discovery that you can't realistically do XYZ with Git, either.
Such advocacy makes me deeply cynical about Git.

To be fair, Git usability has apparently come some way since, say,
2006 when I first encountered Git and Mercurial, with the former being
recommended by the guys who develop itools (whose judgement I
generally trust) but with the caveat that one used the Cogito front-
end at that time, and the latter by the guys who develop MoinMoin
(whose judgement I also trust). The difference between the two DVCSs
as far as I have seen is that Mercurial has always been as usable as
it is today without additional tools. In addition, there seems to be
more honesty from the Mercurial community about what Mercurial can and
cannot support, as opposed to the disinformation cloud (or perhaps
uninformation cloud) that seems to surround Git.

As for the performance of these tools, you wouldn't think Mercurial
was written in Python (admittedly with some C) and Git was written in
C looking at various benchmarks. For what it's worth, this BDFL
decision is one I actually agree with.

Paul
 
T

Tim Daneliuk

Carl said:
Apparently Mercurial had it's own hate club, and the reaction on
python-dev was so severe GvR backtracked on his decision.

Trying to appease a least common denominator, he changed his mind and
Python is going with SCCS instead.


Carl Banks

;)


A few years ago I had a very large client - many multi-billions of
dollars in revenue annually - that ran their entire custom IT
system from a home grown variant of SCCS. It did work, but when
I suggested that better open source tools existed, they kindly
explained their complete lack of interest in moving several millions
of lines of code to anything new. Go figure.
 
L

Lawrence D'Oliveiro

,,, when I suggested that better open source tools existed, they kindly
explained their complete lack of interest in moving several millions
of lines of code to anything new.

What was their explanation?
 
L

Lawrence D'Oliveiro

In message <7a1dd0d8-1978-470b-
And I've heard stories of "bait and
switch" with Git: "you can do XYZ with Git but not with ..." followed
by the discovery that you can't realistically do XYZ with Git, either.

Cite?
 
T

Tim Daneliuk

Lawrence said:
What was their explanation?

Their entire internal workflow from development through final release
and deployment was built around these ancient/nonstandard toolset. It
was economically infeasible to retool both the technology and the
processes for millions of lines of code under version control - there
just wasn't an ROI for it. This is not uncommon in large legacy
environments in my experience.
 
P

Paul Boddie

In message <7a1dd0d8-1978-470b-



Cite?

Well, I "heard" stories rather than read them, so I can't cite them,
but I believe that one argument crafted to favour Git was that it is
great for history editing, but it turns out that it isn't so great, as
the following commentary points out:

"You can do it, but as soon as you go to merge with another repo that
had the unedited commit history, you’ll bump into weirdness (and
probably invalidate your whole reason for rebasing, which was to clean
up the history)."

- http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/

I'm sure other people have their own tales of a similar nature.

Paul
 
D

David Cournapeau

"You can do it, but as soon as you go to merge with another repo that
had the unedited commit history, you’ll bump into weirdness (and
probably invalidate your whole reason for rebasing, which was to clean
up the history)."

 - http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/

I'm sure other people have their own tales of a similar nature.

It is explained in this article why rebase can't be used for something
which will be the base for upcoming merges; not all branches are
intended this way (but most public ones are). I would say this shows
one feature which I think matters a lot in git, more than rebasing
itself: multiple branches in a repo, and very cheap branching (in CPU
cost, space and workflow) so that you can use private branches for
experimentation.

cheers,

David
 
K

Kay Schluehr

In message <35d429fa-5d13-4703-




There are lots of GUI- and Web-based front ends to Git. And look at on-line
services like GitHub and Gitorious. The level of support for it is huge.

Ironically Mercurials most popular UI frontend Tortoise is going to
crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
for about a year and more and the developers are not inclined to fix
it. This doesn't really increase my trust that Mercurials UI tools are
of a higher quality than Git's no matter which platform is used.
 
D

David Smith

Kay said:
Ironically Mercurials most popular UI frontend Tortoise is going to
crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
for about a year and more and the developers are not inclined to fix
it. This doesn't really increase my trust that Mercurials UI tools are
of a higher quality than Git's no matter which platform is used.

The conflict between TortoiseHg and Wing IDE can be fixed by simply
uninstalling the Tortoise Overlays. You loose the graphic overlay on
folders, but otherwise everything works.

--David
 
K

Kay Schluehr

The conflict between TortoiseHg and Wing IDE can be fixed by simply
uninstalling the Tortoise Overlays. You loose the graphic overlay on
folders, but otherwise everything works.

--David

Good to know. Uninstalling a major feature that enhances usability
just to make it usable isn't much less ironic though.
 
K

Kay Schluehr

Meh. Use the command line like God intended.

I'm sorry to say this Rhodri but there is probably no god ;)

The reason I like overlays is that they are data displays that
highlight changes without letting me do any action. The VCS works for
me before I'm doing any work with it and that's a good thing because
I'm *always* lazy.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top