On 2009-02-26 00:35, Mark Hammond wrote:

...

There's an option missing in that survey:

[ ] I don't see a need to switch to a DVCS at all.

To be fair, the survey isn't asking about a switch, just how they compare against svn.

But I must admin that seems a little strange; while I just answered that I believe hg and bzr are better than svn (I abstained re git), that *doesn't* necessarily imply I would vote that they should replace svn for Python - I might, but I might not - that is a much harder question than the one presented.

Indeed, but doesn't the survey sort of imply that as a given ?

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Feb 26 2009)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Feb 25, 2009 6:46pm, Brett Cannon <brett@python.org> wrote:

On Wed, Feb 25, 2009 at 15:35, Mark Hammond mhammond@skippinet.com.au>
wrote:

...

There's an option missing in that survey:

...

...

[ ] I see a need to switch to a DVCS at all.

To be fair, the survey isn't asking about a switch, just how they compare

against svn.

But I must admin that seems a little strange; while I just answered that I

believe hg and bzr are better than svn (I abstained re git), that
*doesn't*

necessarily imply I would vote that they should replace svn for Python - I

might, but I might not - that is a much harder question than the one

presented.

I guess I didn't make it clear enough in the survey. This is meant to
gauge whether you think the DVCSs would be improvement over the status
quo for us, which happens to be svn. I have changed the options to make
it a comparison against the status quo and not svn specifically. If
anyone wants to change their vote based on this clarification let me know
and I will delete your initial answers.

So in MAL's case, you would say you think all the DVCS would be worse
than the status quo as a way to vote that you don't want any change
because the status quo is fine.

I am not going to delve any deeper into making a fancier survey because
it just gets too convoluted in terms of how to present the questions,
mining the data, dealing with bias and how people are just not built to
rate things, etc.

-Brett

Yeah, but the "Anything but subversion" option isn't there!

jesse

[Brett writes]

I guess I didn't make it clear enough in the survey. This is meant to gauge whether you think the DVCSs would be improvement over the status quo for us, which happens to be svn. I have changed the options to make it a comparison against the status quo and not svn specifically. If anyone wants to change their vote based on this clarification let me know and I will delete your initial answers.

I'm afraid the above explanation still isn't quite clear to me: you are saying that we are actually voting on if we would 'approve' of an actual move of Python's SVN to that named DVCS?

If so, please do withdraw my vote; I need to think more about that...

Cheers,

Mark

On 2009-02-26 00:46, Brett Cannon wrote:

On Wed, Feb 25, 2009 at 15:35, Mark Hammond <mhammond@skippinet.com.au>wrote:

...

...

There's an option missing in that survey:

[ ] I see a need to switch to a DVCS at all. To be fair, the survey isn't asking about a switch, just how they compare against svn.

But I must admin that seems a little strange; while I just answered that I believe hg and bzr are better than svn (I abstained re git), that *doesn't* necessarily imply I would vote that they should replace svn for Python - I might, but I might not - that is a much harder question than the one presented.

I guess I didn't make it clear enough in the survey. This is meant to gauge whether you think the DVCSs would be improvement over the status quo for us, which happens to be svn. I have changed the options to make it a comparison against the status quo and not svn specifically. If anyone wants to change their vote based on this clarification let me know and I will delete your initial answers.

So in MAL's case, you would say you think all the DVCS would be worse than the status quo as a way to vote that you don't want any change because the status quo is fine.

Note that I have abstained from voting on any of the DVCSes - simply because I have no experience with them to make an educated decision, ie. I can't say bzr is better or worse than svn.

That said, I don't have any major issues with the existing Subversion setup and believe that adding bridges to DVCS systems is the more appropriate approach to a project of this size than to switch the version control system over completely.

Subversion was certainly a technical improvement over CVS which had serious problems with branches, tagging and locks. The move to a DVCS doesn't look as attractive as Subversion did at the time.

Looking at the PEP 374, the DVCSes don't appear to make life easier for common repo tasks (they each require more or less the same number of commands), so the argument for using a DVCS is more about giving non-core developers access to a version control system they can use to track their patches. However, this appears to be already solved using the bzr mirror.

I am not going to delve any deeper into making a fancier survey because it just gets too convoluted in terms of how to present the questions, mining the data, dealing with bias and how people are just not built to rate things, etc.

At least to me, the survey looks biased already - namely that it puts the second question before the first: "do we have a need to change the system ?".

Perhaps you should do a survey on this question first ?!

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Feb 26 2009)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 25, 2009, at 6:35 PM, Mark Hammond wrote:

...

There's an option missing in that survey:

[ ] I see a need to switch to a DVCS at all.

To be fair, the survey isn't asking about a switch, just how they
compare against svn.

But I must admin that seems a little strange; while I just answered
that I believe hg and bzr are better than svn (I abstained re git), that
*doesn't* necessarily imply I would vote that they should replace svn for
Python - I might, but I might not - that is a much harder question than the one presented.

Note that not switching from svn on the backend, but still allowing
access with bzr, hg, and git is also an option. And there are two
subcategories of that: we provide mirrors of svn branches in the
native format, and we do nothing, allowing the dvcs's use their svn- bridges to access the branches. Although I think in either case we
could provide hosting support for core committers.

Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaXcSXEjvBPtnXfVAQLreQP/c06y3vUTLqhGJrKgiWvajWy6p96kqQ8o 6WcYp9XXXoDRHsZNFRm8z3Ck+aRCEEB3CmINHSCYdMxR9m43YhwHO/IEjtq6/+WG c0LtqXt+BrpfX2UvwG5LVmA4YMR35tnEzMlPNJaWLd8s2NbKyK8Gamnzc6aNhDap ltNiwPlMDew= =w48j -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 26, 2009, at 2:54 AM, Martin v. Löwis wrote:

...

Note that not switching from svn on the backend, but still allowing access with bzr, hg, and git is also an option. And there are two subcategories of that: we provide mirrors of svn branches in the
native format, and we do nothing, allowing the dvcs's use their svn- bridges to access the branches. Although I think in either case we could
provide hosting support for core committers.

That's already the case, for bzr, right?

Correct, in that there are native bzr branches on code.python.org,
which I am currently trying to improve.

If we go this route though, then I think we should evaluate providing
the same level of support for other DVCSs people want. I'm not
volunteering to maintain the hg or git repos, but if volunteers came
forward, we should reorganize the url space and authentication stuff
so that they can easily be pulled from c.p.o.

Alternatively, we continue to provide the svn masters and let other
hosting facilities mirror the native branches (con: there will be a
delay) or let people use their <dvcs>-svn bridges, e.g. bzr-svn.

Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSaaYXnEjvBPtnXfVAQJ9ogP/atF6CV+OfjtgMoTd4fFYcu8yy2xTBxry 7W8uHbP93mMNHMy15R4sC16E7t/S7CX3IsA+DeTOPOUUb06ZGF9mcwo8FB2veUxB UP97TCMr+y7mNCgBLw+Ljjg4N6j9J1dlqGRbA7CekGD8DPIlXY8yYCuDAGM1YyQO r9kU2qiSuYw= =jh/i -----END PGP SIGNATURE-----

Hi,

I'm no trying to advocate switching to a DVCS, but really:

I think that's a much better approach and one that reduces the load on the python.org repo sys-admins.

How does having 4 more-or-less supported VCSes, rather than 1, lighten the load on the sysadmins? Even though the DVCSes are theoretically handled by separate people, they have needs which must be fulfilled by the sysadmins (e.g. for Mercurial, mod_wsgi had to be installed for the Web front-end; and we see how much cooperation Bazaar support seems to require from the sysadmins).

Another aspect to consider is that Subversion uses copy-on-write, so that creating a branch with only a few changes doesn't take up much space in the repo.

Other systems like Mercurial (and I'd be surprised if the others didn't have that option as well) also use copy-on-write when creating clones of a repository. You shouldn't assume that SVN has optimizations that the others don't have. SVN is actually quite crappy performance-wise (at least compared to Mercurial, which I'm used to).

BTW: You can avoid the extra checkout of the branch in Subversion by first locally copying the trunk checkout to a new dir (using e.g. cp -al) and then running a "svn switch" on it.

That means you only work on one feature at a time, though (since you can't locally commit your changes). Besides, every time you switch the source URL you have to "make distclean", which makes builds quite a bit longer.

Le jeudi 26 février 2009 à 15:54 +0100, Fredrik Lundh a écrit :

"that" was referring to "other hosting facilities", not other repositories on the python.org servers:

Ok. Sounds like a regression, but anyway.

On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

...

BTW: You can avoid the extra checkout of the branch in Subversion by first locally copying the trunk checkout to a new dir (using e.g. cp -al) and then running a "svn switch" on it.

That means you only work on one feature at a time, though (since you can't locally commit your changes). Besides, every time you switch the source URL you have to "make distclean", which makes builds quite a bit longer.

you can work on (at least) one feature for each distinct workspace you have on your machine. the "cp / switch" combo is just a quick way to create a new workspace and associate it with a given branch/url, without having to pull the whole thing from the server.

switching on active workspaces isn't a good idea (unless you're mostly generating trivial patches in a drive-by fashion, perhaps, but even in this case, you probably want something like quilt [1] to preserve your sanity).

</F>

1. http://savannah.nongnu.org/projects/quilt

Le jeudi 26 février 2009 à 16:10 +0100, M.-A. Lemburg a écrit :

I didn't know that and was under the impression that those other systems simply hook up to the svn repo via the standard Subversion interfaces.

They hook up to the svn repo for mirroring purposes, true. But they also have their own wire protocol, and some of them also have Web-based browsing facilities (which, in the case of Mercurial, are actually two sides of the same coin: the same base URL is used for human-readable browsing and for read-only HTTP-based cloning of the repository (the writeable cloning variant, as with SVN, uses an SSH-based protocol instead)).

However, it is often said that branches in DVCS system are so much better to work with. Subversion supports these as well, it's just that we currently don't make much use of them and that's what I wanted to point out.

Perhaps because they are not really practical? For example, I don't know how often you use svnmerge, but it's surprisingly slow even for small merges. It also seems to transfer lots of information over the network.

I don't understand that comment. Of course, you can commit whatever changes you make to the branch.

Ok, sorry, I misunderstood your comment.

By contrast, the reasons for switching from CVS to Subversion were mostly technical ones - we often had problems with locks and tagging was very slow.

There are also technical reasons to prefer a DVCS: fast logging, fast annotation, fast (and supposedly smarter, although I'm not really knowledgeable on this) merges, and in some cases a nifty Web front-end.

Why is that ? You need to do that for patches that change the build system or configuration, but for patches to a single C file, that's normally not needed.

Ok, but the point is that if many files have changed (or a single file in the Include directory :-)), the rebuild process is longish each time you "svn switch". Not so if you use a separate directory for each line of work.

Le jeudi 26 février 2009 à 10:50 -0500, Richard Tew a écrit :

If the SVN hosting went away and the chosen DVCS solution did not have a good Windows UI (like TortoiseSVN), then I would have to make sad faces.

Perhaps you can try TortoiseHG (http://bitbucket.org/tortoisehg/stable/wiki/Home) with one of the mirrors on http://code.python.org/hg and tell us your observations? This would certainly enlighten other Windows developers here.

(the mirrors are read-only, but you can still do local changes and commits of course, just not push the changes to the mirrors)

Cheers

Antoine.

On Thu, Feb 26, 2009 at 8:00 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Le jeudi 26 février 2009 à 10:50 -0500, Richard Tew a écrit :

...

If the SVN hosting went away and the chosen DVCS solution did not have a good Windows UI (like TortoiseSVN), then I would have to make sad faces.

Perhaps you can try TortoiseHG (http://bitbucket.org/tortoisehg/stable/wiki/Home) with one of the mirrors on http://code.python.org/hg and tell us your observations? This would certainly enlighten other Windows developers here.

I've been using TortoiseHG with another repository for a while, and the functionality is basically as good as TortoiseSVN except that about 10% of the time it hangs on push and I have to kill it and restart the machine.

Steve

I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

On 2009-02-26 16:36, Antoine Pitrou wrote:

Le jeudi 26 février 2009 à 16:10 +0100, M.-A. Lemburg a écrit :

...

I didn't know that and was under the impression that those other systems simply hook up to the svn repo via the standard Subversion interfaces.

They hook up to the svn repo for mirroring purposes, true. But they also have their own wire protocol, and some of them also have Web-based browsing facilities (which, in the case of Mercurial, are actually two sides of the same coin: the same base URL is used for human-readable browsing and for read-only HTTP-based cloning of the repository (the writeable cloning variant, as with SVN, uses an SSH-based protocol instead)).

So just to get this right: The Subversion admins on python.org do not have to setup anything special for DVCS mirror sites to hook up to the main Subversion repo.

...

However, it is often said that branches in DVCS system are so much better to work with. Subversion supports these as well, it's just that we currently don't make much use of them and that's what I wanted to point out.

Perhaps because they are not really practical? For example, I don't know how often you use svnmerge, but it's surprisingly slow even for small merges. It also seems to transfer lots of information over the network.

This is probably a matter of Internet connection bandwidth then. I have no idea how much data gets transferred, but it doesn't "feel" slow.

...

I don't understand that comment. Of course, you can commit whatever changes you make to the branch.

Ok, sorry, I misunderstood your comment.

...

By contrast, the reasons for switching from CVS to Subversion were mostly technical ones - we often had problems with locks and tagging was very slow.

There are also technical reasons to prefer a DVCS: fast logging, fast annotation, fast (and supposedly smarter, although I'm not really knowledgeable on this) merges, and in some cases a nifty Web front-end.

IMHO, those are all feel-good factors which can easily be had by installing a local Subversion repo copy (sync'ed using svnsync (*)), except perhaps regarding merging - but I don't know anything about in what way the DVCSes are better than Subversion.

(*) This provides fast reads. Writes will still have to to the main repo site. See http://subversion.tigris.org/svn_1.5_releasenotes.html#webdav-proxy

...

Why is that ? You need to do that for patches that change the build system or configuration, but for patches to a single C file, that's normally not needed.

Ok, but the point is that if many files have changed (or a single file in the Include directory :-)), the rebuild process is longish each time you "svn switch". Not so if you use a separate directory for each line of work.

Right, which is what I was describing... you copy your local trunk copy and then switch that copy to the new branch. If you use cp -al for this, that's a very fast operation on Unixes and avoids most of the network traffic.

Then you work in the new local branch dir. Finally, you merge back the changes to trunk and delete the local branch dir (and probably also the one in the repo).

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Feb 26 2009)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

Le jeudi 26 février 2009 à 17:10 +0100, M.-A. Lemburg a écrit :

This is probably a matter of Internet connection bandwidth then.

Not really. To give a point of comparison, when I clone (using Mercurial) the Python trunk at http://code.python.org/hg/trunk, it takes 2 minutes 50 seconds. That's for the whole trunk history from 1990 to today, and bandwidth is around 500 KB/s (sustained) during the downloading.

So, having svnmerge take one minute or more from a machine hosted at the same place as code.python.org points to a really slow merge implementation IMO.

I have no idea how much data gets transferred, but it doesn't "feel" slow.

It definitely feels slow when you merge from e.g. trunk to py3k.

IMHO, those are all feel-good factors which can easily be had by installing a local Subversion repo copy (sync'ed using svnsync (*)), except perhaps regarding merging - but I don't know anything about in what way the DVCSes are better than Subversion.

I've never used svnsync, but I have already tried svk and it was a PITA (that's what led me to try Mercurial, and then write hgsvn).

Georg Brandl wrote:

It doesn't only *feel* slow, it *is* slow. And not only compared to merging with a DVCS, which doesn't need network. Half a minute to merge a three-line change is not productive.

Don't forget that *blocking* a revision with svnmerge seems to take nearly as long as actually merging it does (the only part that seems to save time is the fact that you don't need to build and/or run the test suite afterwards).

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Frankly, there are very few people who routinely (like Benjamin) or even only sometimes (like me) merge larger amounts of stuff between our four branches. While that's no surprise, given how clumsy svnmerge makes it, others shouldn't just dismiss the merging problem with "we have svnmerge".

That's why I keep arguing that the committers making the original commits should also merge their changes, individually, into the respective branches. That way

• commits become separate, and reverting them becomes possible
• the load is shared across all committers

Regards, Martin

Antoine Pitrou wrote:

Le dimanche 01 mars 2009 à 00:11 +0100, "Martin v. Löwis" a écrit :

...

That's why I keep arguing that the committers making the original commits should also merge their changes, individually, into the respective branches. That way

• commits become separate, and reverting them becomes possible
• the load is shared across all committers

It doesn't really make svnmerge less annoying, though.

Depends on what you are annoyed by. If it is that you get tons of conflicts when you run it, and that it takes forever, and that it combines many small changes into a single one - those will be gone with that change in policy.

Regards, Martin

2009/3/1 Nick Coghlan <ncoghlan@gmail.com>:

Martin v. Löwis wrote:

...

and that it takes forever

Not sure about that - I *do* port my own changes, and while the merges are quicker than a full recompile or running the test suite, they're still far, far, slower than applying an equivalent patch or doing an svn update.

Given that "svnmerge block" is pretty slow as well, my suspicion is that the property calculations and the auto-generation of the commit message are less than lightning fast. (I don't how much that could be improved by speeding up the underlying svn metadata retrieval - wasn't the server updated to svn 1.5 fairly recently?)

It seems to me most of the time is spent in fetching the log for the commit message, and that's something Subversion is notoriously slow at. (You can see what commands svnmerge.py is using with the "-s" flag.)

-- Regards, Benjamin

Le dimanche 01 mars 2009 à 21:08 +0100, "Martin v. Löwis" a écrit :

I meant that as a relative qualification indeed (merging a single revision specified on the command line as opposed to merging all available versions).

I just measured merging r70081, and it took 42s.

After the merge from io-c to py3k, where svnmerge seems to have "forgotten" a couple of changes which I have had to fix manually, I want to say that svnmerge has more than simply performance issues... ;-)

Regards

Antoine.

On Thu, Feb 26, 2009 at 08:10, M.-A. Lemburg <mal@egenix.com> wrote:

On 2009-02-26 16:36, Antoine Pitrou wrote:

...

Le jeudi 26 février 2009 à 16:10 +0100, M.-A. Lemburg a écrit :

...

I didn't know that and was under the impression that those other systems simply hook up to the svn repo via the standard Subversion interfaces.

They hook up to the svn repo for mirroring purposes, true. But they also have their own wire protocol, and some of them also have Web-based browsing facilities (which, in the case of Mercurial, are actually two sides of the same coin: the same base URL is used for human-readable browsing and for read-only HTTP-based cloning of the repository (the writeable cloning variant, as with SVN, uses an SSH-based protocol instead)).

So just to get this right: The Subversion admins on python.org do not have to setup anything special for DVCS mirror sites to hook up to the main Subversion repo.

...

...

However, it is often said that branches in DVCS system are so much better to work with. Subversion supports these as well, it's just that we currently don't make much use of them and that's what I wanted to point out.

Perhaps because they are not really practical? For example, I don't know how often you use svnmerge, but it's surprisingly slow even for small merges. It also seems to transfer lots of information over the network.

This is probably a matter of Internet connection bandwidth then. I have no idea how much data gets transferred, but it doesn't "feel" slow.

Feels slow to me, especially when you have to do it three separate times that all feel slow.

...

...

I don't understand that comment. Of course, you can commit whatever changes you make to the branch.

Ok, sorry, I misunderstood your comment.

...

By contrast, the reasons for switching from CVS to Subversion were mostly technical ones - we often had problems with locks and tagging was very slow.

There are also technical reasons to prefer a DVCS: fast logging, fast annotation, fast (and supposedly smarter, although I'm not really knowledgeable on this) merges, and in some cases a nifty Web front-end.

IMHO, those are all feel-good factors which can easily be had by installing a local Subversion repo copy (sync'ed using svnsync (*)), except perhaps regarding merging - but I don't know anything about in what way the DVCSes are better than Subversion.

(*) This provides fast reads. Writes will still have to to the main repo site. See http://subversion.tigris.org/svn_1.5_releasenotes.html#webdav-proxy

Performance is a perk, not a reason to switch, true.

...

...

Why is that ? You need to do that for patches that change the build system or configuration, but for patches to a single C file, that's normally not needed.

Ok, but the point is that if many files have changed (or a single file in the Include directory :-)), the rebuild process is longish each time you "svn switch". Not so if you use a separate directory for each line of work.

Right, which is what I was describing... you copy your local trunk copy and then switch that copy to the new branch. If you use cp -al for this, that's a very fast operation on Unixes and avoids most of the network traffic.

What cp are you talking about, the command or svn cp? Either way the help for both commands don't list -a or -l as flags on OS X under their help.

Then you work in the new local branch dir. Finally, you merge back the changes to trunk and delete the local branch dir (and probably also the one in the repo).

But what about the non-core developer? While all of us can do svn copy to make any branch we want and all that, the poor guy who doesn't have commit privs can't do that.

As an example, let's say Antoine was getting help from someone for his io rewrite that was not a core developer. That guy would have to either have to live without being able to do local commits to checkpoint his work and hope he never reached a situation where he needed to revert some of his work, generate patch files to simulate checkins, or have to learn how to convert the io C branch for a DVCS and work from that.

Or we can use a DVCS to make sure non-core developers don't have to feel like second-class citizens and jump through extra hoops in order to do something as basic as commits of their work.

The DVCS switch is not about us (at least not entirely). It's about the people who want to help out but have not earned checking rights. It's about giving them the best tools available to empower them to contribute to Python in the easiest, best way possible.

-Brett

On Fri, Feb 27, 2009 at 2:59 AM, Fredrik Lundh <fredrik@pythonware.com>wrote: ...

$ cp --help ... Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY. ... Mandatory arguments to long options are mandatory for short options too. -a, --archive same as -dpR ... -l, --link link files instead of copying

Sounds like you need to upgrade to a real OS ;-)

if you want the feature-laden gnu-style version of basic utilities, instead of the simpler unix-style one that MacOSX (and most all BSDs, OpenSolaris, etc) come with, it's typically simple to download and install the gnu-style one; on MacOSX, the simplest way is probably via http://coreutils.darwinports.com/ .

Alex

Brett, We really appreciate your work on this PEP, but I wonder if the process itself isn't causing some of this friction:

Can you guys please let me finish the PEP before you start worrying about whether we are going to switch? At least give me the chance to make a decision on whether I think it is reasonable to switch and what to switch to. And then we can have a reasonable conversation where I update the PEP to address any questions that come up.

It sounds like you want people to hold feedback until you have finished the PEP - which will come complete with a *decision* about what to switch to, or not to switch at all?

It may be that people are concerned that if the PEP will be presented as a decision being made, the opportunity for meaninful input will have passed.

Could you clarify for me: how binding will your PEP be? ie, will it be closer to a recommendation, or will the final PEP be a final decision about what will (or will not) happen?

Thanks,

Mark

It may be that people are concerned that if the PEP will be presented as a decision being made, the opportunity for meaninful input will have passed.

That is not the idea of the PEP process. Instead, it works like this: an enhancement is proposed, and people can discuss it and give feedback. They can indicate support, or suggest improvements, or indicate rejection. After some revisions, the PEP is proposed to the BDFL, who will pronounce. Traditionally, the BDFL has also considered the community view (unless he has a strong opinion on his own).

Could you clarify for me: how binding will your PEP be? ie, will it be closer to a recommendation, or will the final PEP be a final decision about what will (or will not) happen?

If the PEP process is followed (which I recommend it is), then it will be a decision. Notice, however, that the PEP can be rejected (and several PEPs *have* been rejected in the past, including some I wrote).

I'm strongly in favor of this process, even though I'm also opposed to the likely proposition of the PEP (namely, to use something else than subversion - else there would not need to be a PEP). It is *very important* that the PEP provides a complete specification right from the start, or else discussion will revolve around the open issues, with no conclusion. So I'd rather have the PEP suggest that we switch to bzr (say), so that I can vote that down, instead of giving options in its final form.

Regards, Martin

Brett Cannon wrote:

It ain't going to be wishy-washy; there will be a very obvious suggestion of

I know I haven't said much in this discussion, mostly because I don't really care which one we pick. It's just a tool, I'll use whatever.

But, I did want to say thanks to Brett for sticking his face in this fan. :-) It's a task of practically religious-war-proportions, and obviously is something there are a lot of opinions and concerns over. Thanks for working on this.

Sean

Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

What's Hg:s story on Svn integration? To what extent can you use it with a Svn master repo?

(Btw, I would have said that Git is probably the one that's moving the fastest right now, and where the most interesting work is being done - but their Windows story is a tragedy (at least last time I checked) and I agree that the portions of the "community" that shows up in public places isn't always helping... I'm also a big fan of dogfooding, so picking a good-enough Python-powered Vcs definitely makes sense to me. If we need to pick one, that is. I'm still not convinced...)

</F>

On Feb 28, 2009 1:06 AM, "Guido van Rossum" <guido@python.org> wrote:

On Fri, Feb 27, 2009 at 3:41 PM, Sean Reifschneider <jafo@tummy.com> wrote:

But, I did want to say... Thanks to Brett in deed.

Would it help if I made a pronouncement? Let me express my personal feelings. Note that I can still be swayed many ways, so don't consider this a pronouncement, but perhaps it can serve as a catalyst for the decision making process.

• Mercurial: IMO we can't go wrong with this. I've tried it a bit for small projects, and it's very easy to learn for a SVN user. I've talked to Bryan O'Sullivan, and I'm impressed by the customer list, which includes Mozilla and Sun.

• Bazaar: Probably okay, but I'm lukewarm about it. It is also apparently still slower than Hg. It is married to Launchpad whose UI continues to confuse and frustrate me (e.g. why is the "report a bug" link so much more prominent on the overview page than the "download" link?). I also am a little worried that Canonical is a little too eager to get us as a "high profile customer". The good news is that Bzr and Hg are so compatible that Bzr fans will be able to use Bzr even if the master repository (probably on Benjamin's hard drive :-) uses Hg.

• Keeping Subversion: This would sadden me, because merging really sucks, even with the 1.5 merge tracking feature.

• Git: Too complex, and I've heard that a negative attitude prevails in the Git community.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

_______________________________________________ python-committers mailing list python-committers@pyt...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 27, 2009, at 7:06 PM, Guido van Rossum wrote:

• Mercurial: IMO we can't go wrong with this. I've tried it a bit for small projects, and it's very easy to learn for a SVN user. I've talked to Bryan O'Sullivan, and I'm impressed by the customer list, which includes Mozilla and Sun.

Except of course for MySQL (own by Sun), which uses Bazaar. :)

• Bazaar: Probably okay, but I'm lukewarm about it. It is also apparently still slower than Hg. It is married to Launchpad whose UI continues to confuse and frustrate me (e.g. why is the "report a bug" link so much more prominent on the overview page than the "download" link?).

Bazaar isn't really dependent on Launchpad at all, although Launchpad
is dependent on Bazaar. Two very different things. Although I'd love
to explore your frustrations with LP at another time, I do think it's
important to keep the two separate. Python won't be using any
Launchpad services, so Launchpad's usability doesn't really matter.
Bazaar has plugins to e.g. expose an lp: url scheme for branches and -- fixes, but I'm sure the same could be done for a py: scheme integrated
with code.python.org and Roundup.

I also am a little worried that Canonical is a little too eager to get us as a "high profile customer".

I'm not quite sure where that's coming from. Canonical loves Python,
uses it everywhere. We'd like to give back to Python, and would
devote resources to making sure Bazaar meets the Python community's
needs.

The good news is that Bzr and Hg are so compatible that Bzr fans will be able to use Bzr even if the master repository (probably on Benjamin's hard drive :-) uses Hg.

Hmm, I'm not sure what this is referring to.

Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSarGuHEjvBPtnXfVAQKyZAP/d7YCFW1BfrWWMcImMSmI1UFZATe8RqNY GfRMjdK6cq0++unYDg7rKEfyuqcoisJxFbDAyFrCsEtKjBhGXJzXlmPPUZcs9EwO iq7q7kaBcnbkXyRs1xuuSYHimiDa0FQRRcpCsVCPoHEasS9YbAzFJr46VxrnoeR0 RtTax/litNs= =6Tk2 -----END PGP SIGNATURE-----

Martin v. Löwis schrieb:

...

Could you clarify for me: how binding will your PEP be? ie, will it be closer to a recommendation, or will the final PEP be a final decision about what will (or will not) happen?

If the PEP process is followed (which I recommend it is), then it will be a decision. Notice, however, that the PEP can be rejected (and several PEPs *have* been rejected in the past, including some I wrote).

However, in this case it should perhaps rather be deferred, since we cannot once and forever reject switching to a DVCS.

Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 27, 2009, at 6:23 PM, Martin v. Löwis wrote:

...

However, in this case it should perhaps rather be deferred, since
we cannot once and forever reject switching to a DVCS.

OTOH, we can't keep discussing forever whether we should switch,
either. If a decision is made not to switch, that decision should hold for a couple of years - as long as the reason(s) for not switching remain valid.

Originally, I had suggested considering the switch after the 2.6/3.0
release. I still think switching "soonish" after a major release is a
good time (soonish can be 3 months, like we're now considering). It
definitely would /not/ be a good idea to switch anytime before a major
release. So if we defer the decision now, I think we need to look at
the release calendar before choosing another window for the switch.

Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSah5Y3EjvBPtnXfVAQJobwP5AbNQQCZ6tJYqA4B9FfoSzSTriKe7s0nq DxGYA+Q5FOFXYhkxCxVwITaqoK3qBgnlG7QNpBv6AweTi3oFxnkqUuE3SJuPCrKp qQqaohStQKaOtitmobs+clkx2TYfd+klbkvjbyPkpzhbb/Vp8AATt533oqsG5EsK VDkNc1Hd9OY= =Q6sL -----END PGP SIGNATURE-----

I don't think that the implicit assumption "that something better may one
day come along" is something which negates action now. That's like
saying "something better than python may come along, so I'll stick with
$X". The fact is is that DVCes *are* an improvement over subversion,
especially around patch/branching/etc. I guess I'm spoiled with systems
which make branching/patching/merging eas(ier) tasks.

-jesse

On Feb 27, 2009 7:04pm, Fredrik Lundh <fredrik@pythonware.com> wrote:

On the other hand, given how quickly things move in the VC space, we
might as well end up in a situation where we don't need to do anything...

On Feb 27, 2009 11:47 PM, "Georg Brandl" g.brandl@gmx.net> wrote:

Martin v. Löwis schrieb:

...

...

Could you clarify for me: how binding will your PEP be? ie, will it be closer to a recommend...However, in this case it should perhaps
rather be deferred, since we cannot

once and forever reject switching to a DVCS.

Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall b... python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/...

Martin> My own personal experience tells me git and bzr are much worse
Martin> than subversion (each in different respects).

Perhaps you could relay these shortcomings to Brett or edit them into the PEP directly.

Skip

[Mark Hammond]

It sounds like you want people to hold feedback until you have finished the PEP - which will come complete with a *decision* about what to switch to, or not to switch at all?

It may be that people are concerned that if the PEP will be presented as a decision being made, the opportunity for meaninful input will have passed.

FWIW, I share that concern. These things can take on a life of their own even if that wasn't the original intent.

Raymond

M.-A. Lemburg schrieb:

IMHO, those are all feel-good factors which can easily be had by installing a local Subversion repo copy (sync'ed using svnsync (*)), except perhaps regarding merging - but I don't know anything about in what way the DVCSes are better than Subversion.

(*) This provides fast reads. Writes will still have to to the main repo site. See http://subversion.tigris.org/svn_1.5_releasenotes.html#webdav-proxy

So for merging we use svnmerge, for having a local repo we use svnsync. If we continue that way, perhaps there is a svnlocalcommit for on-the-fly committing, and so on.

But once you have to install, learn and maintain Subversion plus a handful of tools, just to get the same level of convenience you get for free with a DVCS, you can't tell me the former is easier than the latter.

Georg

-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 26, 2009, at 10:10 AM, M.-A. Lemburg wrote:

On 2009-02-26 15:50, Antoine Pitrou wrote:

...

Hi,

I'm no trying to advocate switching to a DVCS, but really:

...

I think that's a much better approach and one that reduces the load on the python.org repo sys-admins.

How does having 4 more-or-less supported VCSes, rather than 1,
lighten the load on the sysadmins? Even though the DVCSes are theoretically handled by separate people, they have needs which must be fulfilled
by the sysadmins (e.g. for Mercurial, mod_wsgi had to be installed for
the Web front-end; and we see how much cooperation Bazaar support seems
to require from the sysadmins).

I didn't know that and was under the impression that those other systems simply hook up to the svn repo via the standard Subversion interfaces.

Well, for Bazaar, there's a plugin that speaks svn. I really don't
think there's much ongoing maintenance other than setting up a cronjob
to sync the mirror to the svn master every minute or so. From then
on, it should just work. Most of the churn in the bzr branches hosted
on code.python.org is because it was an experiment we hacked together
at Pycon, so I'm mostly trying to consolidate, update and bring parts
of that in house.

I don't understand that comment. Of course, you can commit whatever changes you make to the branch. It's not done locally and then
forwarded, but that's not really a technical disadvantage, it's merely a
different way to work.

It is when you're on an 18 hour train ride and not on the net.

Barry

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSabJZnEjvBPtnXfVAQKj5gP7BOThbs2CD4F7h+ERpRHPRR/rNww12l/a sJON8U9N9YVTs7Yfzy267Zg204Dm8lE/lxVtu6Ial9RdqGC8rMjD3sDHNuBkFKyD PvtQbDohudzytGs2GW2as1FcqpQIBPfhXoPwzQxvjfoVegutRfmdieMh/4WZjRaG B23O9Wcicgw= =bJro -----END PGP SIGNATURE-----

...

That's already the case, for bzr, right?

Correct, in that there are native bzr branches on code.python.org, which I am currently trying to improve.

Furthermore, there is the option of hosting bzr branches on code.python.org, for committers, right? (not sure whether any committer makes active use of this service, though)

If we go this route though, then I think we should evaluate providing the same level of support for other DVCSs people want. I'm not volunteering to maintain the hg or git repos, but if volunteers came forward, we should reorganize the url space and authentication stuff so that they can easily be pulled from c.p.o.

Indeed. Before, I was worried about disk space. Now that we got a new machine, with plenty disk, RAM, CPU, we can offer hosting whatever people want to see - as you say, we would need a volunteer maintainer of such a service, though.

Regards, Martin

Slightly corrected :-)

On 2009-02-26 00:14, M.-A. Lemburg wrote:

There's an option missing in that survey:

[ ] I don't see a need to switch to a DVCS at all.

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Feb 26 2009)

...

...

Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

On Thu, Feb 26, 2009 at 4:15 PM, Fredrik Lundh <fredrik@pythonware.com> wrote:

Better, worse, or equal in what sense? Obviously, *all* of them are better in certain senses (patch-oriented instead of revision-oriented approach, higher (?) development velocity

to clarify: I meant tool development - especially GIT is moving faster than anything else, from what I can tell. (just wish they got their Windows support sorted out. any minute now...)

</F>