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