Survey about DVCSs compared to svn
To see if people actually want to switch off of svn to a DVCS, I have put together a survey for everyone to state for each DVCS if they think it is better, worse, or equal to svn (and an option to not say anything if you have no experience with the DVCS):
http://spreadsheets.google.com/viewform?formkey=cDVkUElEeEM5MGdBa29fcFZoU1Y2..... The survey is not anonymous so that I can make sure no one games this; I can check for duplicate usernames in the answers. But I will not give out any information beyond aggregate data, so identifiable information stops at me.
I plan to keep this open for a week before I begin to seriously look at the data.
-Brett
On 2009-02-25 23:31, Brett Cannon wrote:
To see if people actually want to switch off of svn to a DVCS, I have put together a survey for everyone to state for each DVCS if they think it is better, worse, or equal to svn (and an option to not say anything if you have no experience with the DVCS):
http://spreadsheets.google.com/viewform?formkey=cDVkUElEeEM5MGdBa29fcFZoU1Y2..... The survey is not anonymous so that I can make sure no one games this; I can check for duplicate usernames in the answers. But I will not give out any information beyond aggregate data, so identifiable information stops at me.
I plan to keep this open for a week before I begin to seriously look at the data.
There's an option missing in that survey:
[ ] I see a need to switch to a DVCS at all.
IMHO, Subversion works perfectly fine.
-- 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/
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.
Mark
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 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 Wed, Feb 25, 2009 at 15:35, Mark Hammond mhammond@skippinet.com.auwrote:
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
-----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-----
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 Wed, Feb 25, 2009 at 16:16, Mark Hammond mhammond@skippinet.com.auwrote:
[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?
Basically, yes. If I said, "we are switching to XXX", would you be grumbling about it because you thought svn was better, happy because you think it would be an improvement or svn, or just shrug your shoulders at it.
If so, please do withdraw my vote; I need to think more about that...
Deleted. But this is for me to make a more informed decision; there is obviously not enough in this to lead to a switch being made purely on the voting results. At best a DVCS will be taken out of the running because it was consistently disliked.
-Brett
On Wed, Feb 25, 2009 at 16:13, jnoller@gmail.com wrote:
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!
Yes it is; just vote that all three are better than the status quo.
-Brett
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?
Regards, Martin
On 2009-02-26 00:46, Brett Cannon wrote:
On Wed, Feb 25, 2009 at 15:35, Mark Hammond mhammond@skippinet.com.auwrote:
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 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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 6:03 AM, M.-A. Lemburg wrote:
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.
For core devs, I do think things like revision blocking and cherry
picking would be easier with the branches in a native DVCS.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSaaYynEjvBPtnXfVAQJuYgP/a1ZlDK80EnnAbSKIy6gHFT6pETtgPpcb nd+hj1Nvda8Q2p5fovaVn6kpeaDvU7D753zj30nEz0kKtiQxt0TyYMpk9gBPiTA/ dWGJP8DBQnJnRCE5FEJFTWhMS5TKHyAhtGtibBJa8eP+c+/Yo25i1niBs4rVryow gb/Ow/NZDcc= =F332 -----END PGP SIGNATURE-----
On 2009-02-26 14:25, Barry Warsaw wrote:
[providing DVCS facilities instead of switching over the main system] 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.
I think that's a much better approach and one that reduces the load on the python.org repo sys-admins.
It would also permit fans of all discussed DVCS systems to use their favorite tool, provided there are volunteers to do the hosting.
On 2009-02-26 14:27, Barry Warsaw wrote:
On Feb 26, 2009, at 6:03 AM, M.-A. Lemburg wrote:
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.
For core devs, I do think things like revision blocking and cherry picking would be easier with the branches in a native DVCS.
AFAIK, svnmerge provides these two functions for Subversion.
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.
It would certainly be possible to setup a repo structure having many core-dev private branches, e.g.
/branches/<coredevname>/issue0001 /branches/<coredevname>/issue0002 /branches/<coredevname>/issue0003
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. To clean out any local modification, you can then additionally run "svn revert -R ."
-- 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/
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.
On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou solipsis@pitrou.net wrote:
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
"that" was referring to "other hosting facilities", not other repositories on the python.org servers:
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.
I think that's a much better approach and one that reduces the load on the python.org repo sys-admins.
</F>
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>
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.
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).
I wasn't trying to imply that the other system don't support this.
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.
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).
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.
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.
Besides, every time you switch the source URL you have to "make distclean", which makes builds quite a bit longer.
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.
-- 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/
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, and not to mention the oh-shiny factor). However, it's highly questionable if any of them is better if we take also *users* of the Python source code tree into account. SVN is ubiquitous in industry on all platforms. The others, not so much. And the set of people capable of installing any of the others but not SVN is probably non-existent.
</F>
On Wed, Feb 25, 2009 at 11:31 PM, Brett Cannon brett@python.org wrote:
To see if people actually want to switch off of svn to a DVCS, I have put together a survey for everyone to state for each DVCS if they think it is better, worse, or equal to svn (and an option to not say anything if you have no experience with the DVCS): http://spreadsheets.google.com/viewform?formkey=cDVkUElEeEM5MGdBa29fcFZoU1Y2..... The survey is not anonymous so that I can make sure no one games this; I can check for duplicate usernames in the answers. But I will not give out any information beyond aggregate data, so identifiable information stops at me. I plan to keep this open for a week before I begin to seriously look at the data. -Brett
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
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>
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.
On Thu, Feb 26, 2009 at 10:36 AM, Antoine Pitrou solipsis@pitrou.net wrote:
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.
On the note of SVN bandwidth usage during merges, the merge of the changes between the Python 3.0 and 3.0.1 tagged revisions into the corresponding Stackless Python branch, used up almost exactly two gigabytes according to Tortoise SVN. This was a trial merge and then the real merge, at a gigabyte a piece.
Regarding this DVCS survey in general, Stackless Python is hosted in the svn.python.org repository. As we are a distinct project from Python itself, I don't really have a stake in a choice which affects Python and haven't filled the survey in. 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.
Cheers, Richard.
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 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/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 9:27 AM, M.-A. Lemburg wrote:
It would also permit fans of all discussed DVCS systems to use their favorite tool, provided there are volunteers to do the hosting.
There are. I think this approach will also allow Brett to save on the
astronomical cost of asbestos underwear.
For core devs, I do think things like revision blocking and cherry picking would be easier with the branches in a native DVCS.
AFAIK, svnmerge provides these two functions for Subversion.
Right. It seems like more of a hack than a basic feature to me.
Still, it might be good enough.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSabHxXEjvBPtnXfVAQLKPgP/awxzNzdi7lzOu2sGO5yHe9Oc73lkL6u2 qrPy5z/4OsYBIqCBV/OlNHXJbwgD0FuNWOfSgIQnpaVe4UqqYhEvQDo2qj8ozx6a yCt3/UpoIxlgsavDxFpQnpy1QQIiMdArp0dwt7j4dPsGAX3Cm/ynHKLH60SD951t pQ9bUVjqvtM= =Gjet -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 10:04 AM, Antoine Pitrou wrote:
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.
It's not a regression for the status quo. Ideally, we as an
organization could handle the administrative overhead of self-hosting
the DVCS branches. But if not, there are certainly hosting facilities
that can handle high fidelity imports of the svn masters.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSabIXnEjvBPtnXfVAQLF7QQAgbpPO3kFuh20bvwXDYmZJPwPBWV81SNY OIZb1RKYphdGlyZ/UrzO0CXF+CEl+smnW94JMNStHSQZLwXMm6S+XxoAWZNkawo1 OZ54j7h9amXbigPKAT3eeFWKtGEaOp2eoap+6p77ri1QCbSrJDgwMtWEBoIICzge din0wWYUfJs= =pOoO -----END PGP SIGNATURE-----
-----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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 11:00 AM, Antoine Pitrou wrote:
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)
I feel compelled to point out that there's a TortoiseBZR as well.
http://bazaar-vcs.org/Download
You can also push Bazaar branches to Launchpad as lots of people are
already doing:
https://code.launchpad.net/python
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSabKcHEjvBPtnXfVAQJQXgQAkVyFzxDSOevPJlxOHhZGOqebDY6hvmqk tbR2xBPAKCT1JIr15WlnkT2fNwxrAfbzXWp3OVPsDBA6DH7OrP7EGxlcQMyfOgSg qpl6Kx/IID1+qturAzP/LHfExBavPfEAzN7Wwq45Wmofv/H9t7XMSVFXiUTlMYQ7 /FVVCGCGQFE= =fsyI -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 11:10 AM, M.-A. Lemburg wrote:
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.
True. If we wanted to host the DVCS branches on python.org, we'd have
to set up the update scripts, either cron or something else. We'd
probably also want to set up the ViewDVCS web server.
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
Writes are the biggest problem to me. I want full access to all my
VCS features, even when I'm disconnected from the net.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSabLLnEjvBPtnXfVAQLSDQQAlMuMHqvvJomwCy4WjUMV1lyt6L6wv5EQ au5wJWZsYHn1InG1d6Het5Ew0j7iVP/uE3MvYolVioLwnm//DP+Pv/sTt2nKPSQ0 0UtMTBIncyCT662SfOOc0y+yc6pzHxYhYael4wbQrL4Lm0+qgIUv45k/2k9vJ66M aWoFLhZj9dU= =3PYA -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Feb 26, 2009, at 12:10 PM, Martin v. Löwis wrote:
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)
Right. I have a few branches up there.
Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSabOlXEjvBPtnXfVAQJcewQAksBRG691E9zSOqpW4DY8vHuG6Wtgk1Fu P78BTb+ckv/3ppvBnSxCne80kiS2uw1escH9LQkAdIFlYz4/SX/PiXIr2/H2N59o qMGel4k30QnG7e1WPUqNtux82kiANQ5H6v5kkygz1k4gy7vJ7/bSL/Pxkc2/6+1e ZNGMZnAjoV0= =G8XG -----END PGP SIGNATURE-----
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).
Regarding this DVCS survey in general, Stackless Python is hosted in the svn.python.org repository. As we are a distinct project from Python itself, I don't really have a stake in a choice which affects Python and haven't filled the survey in. 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.
Be assured that this won't happen. Perhaps the /python folder would get removed from projects repository; svn.python.org would continue to work (it is also needed to host the website and the PyPI sources). It doesn't cost anything to continue to run svn. (perhaps if all the other projects except for stackless left svn, I would ask you to "volunteer" some admin time into its operation).
Regards, Martin
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 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 4:21 AM, Brett Cannon brett@python.org wrote:
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.
$ 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 ;-)
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.
So the hypothetical requirements of one hypothetical developer is reason enough for breaking the current process for *everyone*, including core developers and non-development repository users (see my earlier mail)? Given that all major DVCS:es seem to have solid support for *pulling* from an SVN master repository (and at least Git makes it easy to commit too), why not just let developers to use whatever tools they want when working on individual features, as long as they can provide a straightforward patch (or commit) at the end?
</F>
On Fri, Feb 27, 2009 at 2:59 AM, Fredrik Lundh fredrik@pythonware.comwrote: ...
$ 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
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.
I had a long reply all written out, but instead I decided to discard it so as to not continue to drag this discussion out. Why? The DVCS PEP is not even finished yet!
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.
-Brett
On Fri, Feb 27, 2009 at 02:59, Fredrik Lundh fredrik@pythonware.com wrote:
On Fri, Feb 27, 2009 at 4:21 AM, Brett Cannon brett@python.org wrote:
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.
$ 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 ;-)
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.
So the hypothetical requirements of one hypothetical developer is reason enough for breaking the current process for *everyone*, including core developers and non-development repository users (see my earlier mail)? Given that all major DVCS:es seem to have solid support for *pulling* from an SVN master repository (and at least Git makes it easy to commit too), why not just let developers to use whatever tools they want when working on individual features, as long as they can provide a straightforward patch (or commit) at the end?
</F>
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
On Fri, Feb 27, 2009 at 13:57, Mark Hammond mhammond@skippinet.com.auwrote:
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?
It's my recommendation. The only person who could force python-dev to switch is the BDFL. The point of the PEP is so someone (namely me) examines what our options are, figures out which one is the best DVCS for us, see if the switch seems worth it and if it is figure out how to go about it, and then present the results to python-dev just like any other PEP.
-Brett
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
[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
On Fri, Feb 27, 2009 at 14:13, "Martin v. Löwis" martin@v.loewis.de wrote:
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.
It ain't going to be wishy-washy; there will be a very obvious suggestion of what to switch to if a switch were to take place.
-Brett
On 2009-02-27 20:56, Georg Brandl wrote:
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.
I am not saying that. Just suggesting that this is possible with Subversion as well, so it's not a technical argument for changing the main repo system.
For those who want to use local commits, it's probably easier to just go with one of the DVCS systems hooked up to the central SVN repo.
... and in two years, when DVCS 2.0 will be new and shiny, interested developers can then use those systems to hook up to the central SVN repo ;-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Feb 27 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/
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.
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.
Regards, Martin
-----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-----
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
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...
</F>
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/...
On Fri, Feb 27, 2009 at 3:41 PM, Sean Reifschneider jafo@tummy.com wrote:
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.
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/)
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/...
On Fri, Feb 27, 2009 at 15:41, Sean Reifschneider jafo@tummy.com wrote:
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. :-)
You're welcome.
It's a task of practically religious-war-proportions, and obviously is something there are a lot of opinions and concerns over.
I think people take me seriously now when I say this has become the vim/Emacs war as of late.
Thanks for working on this.
Just don't let me do something like this again for a VERY LONG TIME. Thanks to the support of various people I will stick this out, but I am so close to burn-out that sheer determination is about the only thing keeping me going on this.
-Brett
jnoller@gmail.com wrote:
The fact is is that DVCes *are* an improvement over subversion, especially around patch/branching/etc.
I think the core of the problem/discussion is that many (including me) don't accept this as a fact. It has not been *demonstrated* to me that they are better, and I don't accept word-of-mouth as a proof. My own personal experience tells me git and bzr are much worse than subversion (each in different respects).
Regards, Martin
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...
Le samedi 28 février 2009 à 10:09 +0100, Fredrik Lundh a écrit :
What's Hg:s story on Svn integration? To what extent can you use it with a Svn master repo?
hgsubversion is supposed to allow bidirectional integration: http://www.selenic.com/mercurial/wiki/index.cgi/HgSubversion
If you just need a one-way bridge (and are ready to accept manually commiting patches to the SVN repo, which is what I'm doing with Python), there are a bunch of possibilities besides hgsubversion: the builtin "hg convert" command, hgsvn, and probably others.
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
Brett Cannon schrieb:
I had a long reply all written out, but instead I decided to discard it so as to not continue to drag this discussion out. Why? The DVCS PEP is not even finished yet!
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.
What I would *like* to see in the PEP is a discussion of support tools for these systems. For CVS, I have used pcl-cvs in XEmacs, and psvn.el for SVN. I guess there is a Tortoise variant available for all these DVCSs, but for example (haven't tried it myself) weak support for mercurial in XEmacs.
Thanks, Thomas
skip@pobox.com wrote:
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.
As I said: I refrain from commenting at this point, as much as I can. When (if) the PEP reaches a final form, I can start discussing its content.
Regards, Martin
Antoine Pitrou schrieb:
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.
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.
Not to mention the various other problems with svnmerge, e.g. having to pack several merges into "batch" commits which then are atomic on the merged-to branch (which bites us merging from 3.1 to 3.0). (And no, merging each commit individually is not an option, because it takes even *longer*.)
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".
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.
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
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.
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
Nick Coghlan schrieb:
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).
Even worse, svnmerge makes concurrent merging impossible. You get a conflict every time two people are merging the same time. In the Python project we don't see the issue often but at work I could hear a frustrated scream at least once a day. We've started a "manual merge lock" by yelling "merge" from one developer room to the other.
Totally annoying, though.
Christian
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?)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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
-----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 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.
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.
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?)
Indeed. However, I had not upgraded the repository itself. I did now "svnadmin upgrade", and "svn-populate-node-origins-index" on the projects repository. Unfortunately, the same merge operation now takes 2m42. So I reverted the format upgrade (I had made a tar file before).
If anybody wants to experiment with that: help would be appreciated.
Regards, Martin
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.
Antoine Pitrou schrieb:
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... ;-)
I ran into similar trouble during the merge of the long running math branch. After two failed attempts I decided to merge the changes manually. I couldn't figure out why svnmerge was failing because I hadn't had enough spare time.
Christian
participants (20)
-
"Martin v. Löwis" -
Alex Martelli -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Fredrik Lundh -
Georg Brandl -
Guido van Rossum -
jnoller＠gmail.com -
M.-A. Lemburg -
Mark Hammond -
Nick Coghlan -
Raymond Hettinger -
Richard Tew -
Sean Reifschneider -
skip＠pobox.com -
Steven Bethard -
Thomas Heller