[python-committers] Survey about DVCSs compared to svn

Brett Cannon brett at python.org
Fri Feb 27 04:21:09 CET 2009


On Thu, Feb 26, 2009 at 08:10, M.-A. Lemburg <mal at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20090226/4924f224/attachment-0001.htm>


More information about the python-committers mailing list