On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull step...@xemacs.org wrote:
No, software engineering scales up to a point, then it breaks and you
need a serialization scheme. The problem is not the DVCS, it's the
demand for a *centralized*, authoritative, safe, stable version. DVCS
can
Stephen This won't be pleasant if people are sprinting and lots of
Stephen commits are coming, because you're likely to repeatedly lose
Stephen the push race. But in those conditions, nothing is guaranteed
Stephen to work in decentralized fashion (that's one reason why the
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions that will actually be added to the
repository, and perhaps notice system-level anomolies before pushing.
hg does not
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions that will actually be added to the
repository, and perhaps notice system-level
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never existed in
any developer's workspace.
I can't understand how you draw this conclusion
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 10:44 AM, Martin v. Löwis wrote:
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never
Stephen It would be possible for the svn-based workflow to require that
Stephen after testing in one's workspace, one does an svn update, and
Stephen if any changes are made to files in the workspace, the whole
Stephen build and test procedure must be repeated. I don't see that
On Mon, Mar 21, 2011 at 7:44 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If you do an svn up, it merges local changes with remote changes;
if that works without conflicts, it tells you what files it merged,
but lets you commit.
Still, in this case, the merge result did exist in the sandbox
On Mon, Mar 21, 2011 at 9:14 PM, s...@pobox.com wrote:
I believe it runs counter to the professed intention of the switch away from
a centralized version control system, to make it easier for more people to
contribute to Python. It certainly seems harder for this old dog.
I agree it's harder
Martin v. Löwis writes:
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never existed in
any developer's workspace.
I can't understand how
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions
s...@pobox.com writes:
I believe it runs counter to the professed intention of the switch
away from a centralized version control system, to make it easier
for more people to contribute to Python. It certainly seems harder
for this old dog.
Well, you may be an old dog, but you're also
On 03/21/2011 01:34 PM, Stephen J. Turnbull wrote:
Subversion never ever creates versions in the repository that
didn't before exist in some working copy.
John Arbash-Meinel disagrees with you, so I think I'll go with his
opinion
Besides, it's easy to confirm:
# create a repository
On 2011-03-21 14:40, R. David Murray wrote:
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on
On Mar 21, 2011, at 06:14 AM, s...@pobox.com wrote:
It, however requires every developer to become facile, if not expert, with
the ins and outs of the Python/Mercurial workflow. This discourages casual
or intermittent contributions. My main contribution to the Python codebase
over the past
On Mon, 21 Mar 2011 11:25:31 -0400
Barry Warsaw ba...@python.org wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized workflow (which is entirely valid imo), can they set up
On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 11:25:31 -0400
Barry Warsaw ba...@python.org wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized
Thanks for the example, Hrvoje.
Hrvoje This automatic merging often causes people who migrate to a DVCS
Hrvoje to feel that they have to go through an unnecessary extra step
Hrvoje in their workflows. But once you grasp the hole in the svn
Hrvoje workflow, what svn does (and
Barry Warsaw writes:
Actually, I meant something like 'bzr checkout':
No. Of the DVCSes, only bzr has that.
This would allow individual developers to treat the repository in a
centralized way like they did for svn, but still allowing other
developers to work in a distributed way.
I
On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized workflow (which is entirely valid imo), can they set up their
local workspace to
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann adr...@cadifra.com wrote:
On 2011-03-21 14:40, R. David Murray wrote:
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 10:55 AM, Stephen J. Turnbull wrote:
s...@pobox.com writes:
I believe it runs counter to the professed intention of the switch
away from a centralized version control system, to make it easier
for more people to contribute to
On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
So you are worried about the small window between me doing an 'svn up',
seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate
concern, but considering the fact that if the same thing happens in hg,
the only difference is
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net wrote:
We cannot emulate svnmerge for porting between branches, though - and
I doubt bzr can do it. That's because merges in common DVCSes are based
on the DAG, while svnmerge is a prettily ad-hoc free-form thing.
The
Le lundi 21 mars 2011 à 11:33 -0700, Daniel Stutzbach a écrit :
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net
wrote:
We cannot emulate svnmerge for porting between branches,
though - and
I doubt bzr can do it. That's because merges in common
On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I don't think that is the main source of complexity.
The more difficult and fragile part of the workflows are:
* requiring commits to be cross-linked between branches
* and wanting changesets to be collapsed
It does so at the *tree* level, not at an individual file level.
Thanks - I stand corrected. I was thinking about the file level only (at
which it doesn't do server-side merging - right?).
Regards,
Martin
___
Python-Dev mailing list
On Tue, 22 Mar 2011 07:32:33 +1000
Nick Coghlan ncogh...@gmail.com wrote:
As far as the second point goes, I'm coming to the view that we should
avoid rebase/strip/rollback when intending to push to the main
repository, and do long term work in *separate* cloned repositories.
Then an rdiff
I don't think that is the main source of complexity.
The more difficult and fragile part of the workflows are:
* requiring commits to be cross-linked between branches
* and wanting changesets to be collapsed or rebased
(two operations that destroy and rewrite history).
I think there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/03/11 19:59, Raymond Hettinger wrote:
I think if we're going to require a complex workflow, then we're
going to have to expect a lot of questions. And those questions
shouldn't be brushed-off with go read the tutorial, we have no time
for
What you felt like doing after doing the rest;-?
I believe your question and its answers have helped me understand hg
better for when I dive in. Thanks.
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
Jesus Cea writes:
I think we are doing some antipatterns with our current approach,
battling the tools instead of joining them.
Yes. That is deliberate; see PEP 0374. I admit I personally didn't
foresee the issues Nick describes with the flow of patches from one
branch to another. Also,
On Mon, 21 Mar 2011 03:44:34 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
I'm coming to the conclusion that those who say that Mercurial
documentation should be found at the Mercurial project are wrong. I
+1. I think the dev docs should explain anything needed to do the
basic Python
Stephen Subversion merges create new versions in the repository that
Stephen *never existed in any developer's workspace* and therefore was
Stephen never tested before committing. This is somewhat mitigated by
Stephen buildbot testing, but that is mostly unit testing and
Terry What you felt like doing after doing the rest;-?
I still f*cked everything up. R. David Murray came to my rescue. Even he
muffed it and had to backtrack I think, at least based on one of the
comments I saw on one of the involved tracker issues.
Skip
On Sun, Mar 20, 2011 at 12:40 PM, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 21 Mar 2011 03:44:34 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
I'm coming to the conclusion that those who say that Mercurial
documentation should be found at the Mercurial project are wrong. I
Le 20/03/2011 02:59, Ned Deily a écrit :
On a Unix-y system, here is one way to do it (no warranty on the
installation instructions!):
With all due respect, the instructions are overly complicated, and may
also run afoul of the system conventions (sudo will put files in
directories that should
In article 4d86be29.8070...@netwok.org,
Éric Araujo mer...@netwok.org wrote:
Le 20/03/2011 02:59, Ned Deily a écrit :
On a Unix-y system, here is one way to do it (no warranty on the
installation instructions!):
With all due respect, the instructions are overly complicated, and may
also
s...@pobox.com writes:
Stephen interactions across modules. That is, it's not that Subversion
Stephen provided a simpler way of doing the work. Rather, it hid the
Stephen fact that certain work was not being done at all. hg exposes
Stephen this fact.
Can you provide
I have a trivial little documentation patch for csv.rst. I committed it
locally, then I pulled and merged:
cpython% hg pull
pulling from ssh://h...@hg.python.org/cpython
searching for changes
adding changesets
adding manifests
adding file changes
added 94 changesets
hg heads showed my changeset:
changeset: 68585:c63d7374b89a
user:Skip Montanaro s...@pobox.com
date:Sat Mar 19 09:09:30 2011 -0500
summary: Mention RFC 4180. Based on input by Tony Wallace in issue
11456.
I committed. Now:
changeset:
On Sat, 19 Mar 2011 09:25:07 -0500, s...@pobox.com wrote:
I have a trivial little documentation patch for csv.rst. I committed it
locally, then I pulled and merged:
Note that if you want doc changes to appear in all the current doc sets
(2.7, 3.2, dev), then you should start with patching
On Sat, 19 Mar 2011 09:25:07 -0500
s...@pobox.com wrote:
I have a trivial little documentation patch for csv.rst. I committed it
locally, then I pulled and merged:
cpython% hg pull
pulling from ssh://h...@hg.python.org/cpython
searching for changes
adding changesets
I have a trivial little documentation patch for csv.rst. I committed
it locally, then I pulled and merged:
RDM Note that if you want doc changes to appear in all the current doc
RDM sets (2.7, 3.2, dev), then you should start with patching 3.2 and
RDM merge it into
On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
On Sat, 19 Mar 2011 09:25:07 -0500
s...@pobox.com wrote:
The dev guide says something about collapsing changesets. Is that
collapsing commits within a changeset or collapsing multiple changesets
(whatever that might be)? Do I need this
Antoine == Antoine Pitrou solip...@pitrou.net writes:
Antoine On Sat, 19 Mar 2011 09:25:07 -0500
Antoine s...@pobox.com wrote:
I have a trivial little documentation patch for csv.rst. I committed it
locally, then I pulled and merged:
cpython% hg pull
I think if we're going to require a complex workflow, then we're
going to have to expect a lot of questions. And those questions
shouldn't be brushed-off with go read the tutorial, we have no time
for you or words to that effect.
And indeed, I think this (asking questions) is just about the
On Sun, Mar 20, 2011 at 5:05 AM, s...@pobox.com wrote:
Sorry, this workflow is still new and hugely confusing to me. To make a
simple edit to csv.rst I needed to do a couple pulls and merges, local
commits, resolve the same conflict multiple times, get rebuffed when I first
pushed because
On Sat, Mar 19, 2011 at 12:55 PM, Martin v. Löwis mar...@v.loewis.de wrote:
So I'd encourage everybody to keep asking questions, and request that
they are answered in a polite manner, even if the one answering thinks
that the same question is already answered in some documentation.
Thanks. I
On Sat, 19 Mar 2011 16:32:53 -0700
Guido van Rossum gu...@python.org wrote:
remote: File /data/buildbot/master/master.cfg, line 87, in
perspective_addChange
remote: changedict['category'] = branch_to_category[changedict['branch']]
remote: exceptions.KeyError: '2.5'
remote: ]
That's
On Sun, Mar 20, 2011 at 9:32 AM, Guido van Rossum gu...@python.org wrote:
+1. Just as I hope for the Python 3-4 transition, I hope that whatever
comes along next has a better transition strategy. That would make it
really hot.
Given that the hardest part of any transition is updating
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
On Sat, 19 Mar 2011 09:25:07 -0500
s...@pobox.com wrote:
The dev guide says something about collapsing changesets. Is that
collapsing commits within a
Skip wrote:
Antoine wrote:
94 changesets? If you want to avoid risking conflicts, you should hg
pull and hg up (or hg pull -u) before you start working on
something (just like you svn up'ed before working on something).
Sorry, this workflow is still new and hugely confusing to me. To
I made a test change to the 2.5 README and merged it into 2.6 and 2.7.
Then I pushed. It *seems* to have worked, but I also got some
traceback:
Oops. I wouldn't have expected that tracebacks propagate that far back.
This was your hg client talking to the remote hg client executing a
post-push
Am 20.03.2011 00:39, schrieb Antoine Pitrou:
On Sat, 19 Mar 2011 16:32:53 -0700
Guido van Rossum gu...@python.org wrote:
remote: File /data/buildbot/master/master.cfg, line 87, in
perspective_addChange
remote: changedict['category'] = branch_to_category[changedict['branch']]
remote:
In article
aanlktiktvxsrmlw0z8ifvz3lkaedv8vui_a4f-oci...@mail.gmail.com,
Nick Coghlan ncogh...@gmail.com wrote:
Mercurial isn't really all that different, but it's distributed nature
means it want to keep track of even minor things like the local
whitespace fixes and the merger of your
On Sat, 19 Mar 2011 13:53:11 -0500, s...@pobox.com wrote:
I have a trivial little documentation patch for csv.rst. I committed
it locally, then I pulled and merged:
RDM Note that if you want doc changes to appear in all the current doc
RDM sets (2.7, 3.2, dev), then you
57 matches
Mail list logo
