-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/03/11 22:20, Nick Coghlan wrote:
> There's a third option (which is what I've been doing):
>
> 6. Pull
> 7. Merge the heads on the oldest branch that now has multiple heads
> 8. Merge that branch to the next branch in line as usual.
> 9. Repeat
On Wed, Mar 23, 2011 at 11:30 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 12:30:17 +0900
> "Stephen J. Turnbull" wrote:
>> Antoine Pitrou writes:
>>
>> > Now, "hg strip" should definitely be absent of any recommended or even
>> > suggested workflow. It's a power user tool for the experiment
On Wed, 23 Mar 2011 12:30:17 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > Now, "hg strip" should definitely be absent of any recommended or even
> > suggested workflow. It's a power user tool for the experimented
> > developer/admin. Not the average hg command.
>
> So wha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/03/11 18:38, Jesus Cea wrote:
> Most of our problems are related to trying to keep a lineal history, and
> races with pull-patch-commit-push cycle. I propose the following workflow.
The points of my proposal are:
1. The hg.python.org repository
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 1:23 PM, Dirkjan Ochtman wrote:
> On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
> wrote:
>> Just as an aside, and I might be wrong. But reading through what strip
>> does, (and from my knowledge of the disk layout) it can't actually b
On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
wrote:
> Just as an aside, and I might be wrong. But reading through what strip
> does, (and from my knowledge of the disk layout) it can't actually be
> atomic. So if you kill it at the wrong time, it will have corrupted your
> repository.
>
> At
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 4:30 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>
> > Now, "hg strip" should definitely be absent of any recommended or even
> > suggested workflow. It's a power user tool for the experimented
> > developer/admin. Not the
On Wed, Mar 23, 2011 at 1:43 PM, wrote:
>
> Nick> 7. Merge the heads on the oldest branch that now has multiple heads
>
> Two more stupid questions:
>
> 1. Don't all branches have multiple heads? Every time I execute hg heads I
> see many.
The branches we mainly care about should general
Nick> 7. Merge the heads on the oldest branch that now has multiple heads
Two more stupid questions:
1. Don't all branches have multiple heads? Every time I execute hg heads I
see many.
2. Oldest in what way? Pythonically (2.6 is older than 2.7 though it might
have more recent c
> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.
Pretty average: http://mercurial.selenic.com/wiki/PruningDeadBran
Antoine Pitrou writes:
> Now, "hg strip" should definitely be absent of any recommended or even
> suggested workflow. It's a power user tool for the experimented
> developer/admin. Not the average hg command.
So what you're saying is that Mercurial by itself can't support the
recommended workf
On Wed, 23 Mar 2011 10:39:01 +0900
"Stephen J. Turnbull" wrote:
> Executive summary:
>
> If we're really serious about serializing the public branches, mq
> seems to be the way to go.
I really think that at this point we should continue practicing with
the current setup before deciding on refine
Executive summary:
If we're really serious about serializing the public branches, mq
seems to be the way to go.
Jesus Cea writes:
> 6. Use "hg strip" (dangerous!) to delete the local merges to 3.2 and
> "default". Leave the original commit in "3.1" alone.
I would suggest "hg strip --keep" whi
On 3/22/2011 1:38 PM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.
All branches (except 2.7) MUST be merged to default, all the t
On Wed, Mar 23, 2011 at 3:38 AM, Jesus Cea wrote:
> Now we have two options.
>
> The easier and "mercurial" way would be:
>
> 6. Pull.
> 7. Merge the two heads.
> 8. Merge that merge to the other branches, as necessary. Since the two
> heads were already merged to other branches, this merge should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Most of our problems are related to trying to keep a lineal history, and
races with pull-patch-commit-push cycle. I propose the following workflow.
All branches (except 2.7) MUST be merged to default, all the time. This
must be enforced by the push ho
16 matches
Mail list logo
