-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
> We have a few of those (svn:externals) as well... Brett, another
> question for your DVCS champions!
Sun uses a Mercurial extension, Forest, to manage JDK.
Mercurial forest:
http://www.selenic.com/mercurial/wiki/index.cgi/Forest
> 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
-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
2009/3/1 Nick Coghlan :
> 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
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 bloc
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
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 reve
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
> 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 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 actua
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 ta
> What on earth happened between May and June 2008? The number of
> "visits" went down dramatically (at least 3x), and stayed at that
> level ever since.
As we don't have the log files anymore, it's hard to tell. My guess
is that it is some automated procedure that completed or got turned
off. For
Nick Coghlan wrote:
> Bob Ippolito wrote:
>> I have more or less the same opinion as Guido regarding svn merge. It
>> sucks. We bump up against problems with svn merge tracking on a
>> regular basis at work. We'd have switched to a DVCS by now if it
>> wasn't for tool support (trac mostly) and the
s...@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
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
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
___
python-committers mail
On Sat, Feb 28, 2009 at 1:35 AM, "Martin v. Löwis" wrote:
> Fredrik Lundh wrote:
>> Btw, one of my concerns is that a move away from Svn breaks the process
>> for people who pull sources from Svn to build their own Pythons. I know
>> a few teams that do that, and switching to another system isn't
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 ne
Bob Ippolito wrote:
> I have more or less the same opinion as Guido regarding svn merge. It
> sucks. We bump up against problems with svn merge tracking on a
> regular basis at work. We'd have switched to a DVCS by now if it
> wasn't for tool support (trac mostly) and the fact that we use a lot
> o
Why not add a requirement to the PEP such that if a DVCS is chosen
then a read-only SVN mirror or gateway should be maintained? Would
that be a reasonable compromise?
I have more or less the same opinion as Guido regarding svn merge. It
sucks. We bump up against problems with svn merge tracking on
Fredrik Lundh wrote:
> Btw, one of my concerns is that a move away from Svn breaks the process
> for people who pull sources from Svn to build their own Pythons. I know
> a few teams that do that, and switching to another system isn't just an
> apt-get away for them. Do we have enough log info to b
Btw, one of my concerns is that a move away from Svn breaks the process for
people who pull sources from Svn to build their own Pythons. I know a few
teams that do that, and switching to another system isn't just an apt-get
away for them. Do we have enough log info to be able to determine how commo
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 check
The bias is that the framing of the survey doesn't distinguish between
"better in absolute terms" and "better given that we already have a working
system and that there's a cost for *lots* of people if we switch". I'm
surprised that you can claim that everything's ok even though several people
that
jnol...@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
On Fri, Feb 27, 2009 at 15:41, Sean Reifschneider 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
On Fri, Feb 27, 2009 at 16:04, Fredrik Lundh wrote:
> No need for a long answer - just explain what the purpose of the survey is,
>
To see what committers think about the various DVCSs and if one happens to
be disliked by a majority of developer when compared to svn as a baseline.
> and why it
The survey isn't biased. You have a value "the same /worse than the status
quo" - wherein the status quo is subversion. If you hate DVCes, you mark it
as "same/worse than the status quo" and we move on.
No one is suggesting we accept *less* functionality than subversion: in
fact we're looki
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,
especiall
On Fri, Feb 27, 2009 at 3:41 PM, Sean Reifschneider 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 t
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" wrote:
Martin v. Löwis schrieb:
>> Could you clarify for me: how binding will your PEP be? ie, will it >> be
No need for a long answer - just explain what the purpose of the survey is,
and why it isn't as biasad as it appears to be. A process where you're
actively discouraging people with a certain opinion from getting involved
isn't much of a process.
On Feb 27, 2009 9:24 PM, "Brett Cannon" wrote:
I
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 fac
-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,
eithe
> 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 th
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 d
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 D
On Fri, Feb 27, 2009 at 14:13, "Martin v. Löwis" 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
[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 oppo
> 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.
On Fri, Feb 27, 2009 at 13:57, Mark Hammond wrote:
> 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? A
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 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 chan
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 p
On Fri, Feb 27, 2009 at 2:59 AM, Fredrik Lundh wrote:
...
> $ cp --help
> ...
> Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.
> ...
> Mandatory arguments to long options are mandatory for short options too.
> -a, --archivesame as -dpR
> ...
> -l, --link
On Fri, Feb 27, 2009 at 4:21 AM, Brett Cannon 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
On Thu, Feb 26, 2009 at 08:10, M.-A. Lemburg 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 S
On Thu, Feb 26, 2009 at 8:00 AM, Antoine Pitrou 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
> 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
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 fo
-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 hosti
>> 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 ac
-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 D
-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
-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 re
-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
-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 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
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) wi
On Thu, Feb 26, 2009 at 10:36 AM, Antoine Pitrou 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
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 the
On Thu, Feb 26, 2009 at 4:15 PM, Fredrik Lundh 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
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
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, lighte
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.
___
python-committers mailing list
pytho
On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou 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 ti
On Thu, Feb 26, 2009 at 3:50 PM, Antoine Pitrou 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, lig
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
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 -svn bridges
-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 abou
-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 t
On 2009-02-26 00:46, Brett Cannon wrote:
> On Wed, Feb 25, 2009 at 15:35, 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
> 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
On Wed, Feb 25, 2009 at 16:13, wrote:
> On Feb 25, 2009 6:46pm, Brett Cannon wrote:
> >
> >
> > On Wed, Feb 25, 2009 at 15:35, Mark Hammond mhamm...@skippinet.com.au>
> wrote:
> >
> > > There's an option missing in that survey:
> >
> > >
> >
> > > [ ] I see a need to switch to a DVCS at all.
> >
On Wed, Feb 25, 2009 at 16:16, Mark Hammond wrote:
> [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
[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 specific
On Feb 25, 2009 6:46pm, Brett Cannon wrote:
On Wed, Feb 25, 2009 at 15:35, Mark Hammond mhamm...@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 th
-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 th
On Wed, Feb 25, 2009 at 15:35, 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
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 jus
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 Consulti
> 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
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 D
83 matches
Mail list logo
