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 <fred...@pythonware.com> wrote: > On Fri, Feb 27, 2009 at 4:21 AM, Brett Cannon <br...@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> >
_______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
