[python-win32] DVCS options for pywin32

[Tim Golden]

On 07/02/2011 22:54, Mark Hammond wrote:
> I've been quite a laggard with source control for pywin32 - we are still
> on CVS and I've been waiting for a sign from above about which dvcs to
> move to - and with the current CVS outage at sourceforge and their plan
> to end-of-life CVS services, I really need to bite the bullet.
>
> For a while hg was the only option, then bzr and git joined the crowd.
> With Python still targeting a move to hg from svn, that seems like the
> obvious choice - but I've been a bit unhappy with my hg experiences and
> with some of the discussions about how Python's workflow needs to change
> to accommodate it. I initially struggled to get my head around git, but
> now that I am becoming more familiar with it I like it alot. Windows
> support for both is currently fairly reasonable - especially if you
> don't care too much about "tortoise" style shell integration - which I
> don't. Both hg and git finally seem to have workable options to support
> Windows line-endings in files.
>
> Does anyone else in pywin32-land have any opinions about this? Does
> anyone feel strongly one way or another?

I have no strong feelings: I've toyed with Hg (basically because
Python and pywin32 had both announced plans to move that way). I've
used git recently because I wanted to pull some stuff from github.
I've never used bzr, but would if someone advertised a
bzr-based project I was interested in using. We continue to use
svn at work and I continue to host my personal projects via
svn.

Something which I think makes a difference but which hasn't been
mentioned is the needs of a particular project when making this
choice -- as opposed to the intrinsic merits and established
userbase of any one of of the contenders. pywin32 has a very
small developer community and a very simple development process.
The nature of the code makes that unlikely to change. It doesn't
have, therefore, the same issues that the Python codebase is facing:
quite a few developers, each applying long-established workflows
which don't quite map on to the Hg worldview.

There is a certain symmetry in that the hg codebase itself uses
pywin32... so pywin32 might as well use hg. On the other hand,
that might be a cause of problems as the two trip over each other's
feet :)

I say: go for Hg as it is broadly acceptable by many people and
aligns, current wrangling notwithstanding, with the choice made
by the Python development community.

TJG