Michael Widenius writes:
> K> In this case, Joe will instead have to do this:
>
> K> bzr branch lp:maria # or bzr pull lp:maria into an existing clean
> clone
> K> bzr merge ../branch-with-patch
> K> bzr commit -m"merged with trunk"
> K> bzr push lp:maria
>
> K> Then the resulti
Hi!
> "Kristian" == Kristian Nielsen writes:
Kristian> Kristian Nielsen writes:
>> Following up on this, I just learned about the bzr option
>> append_revisions_only that can be set on a branch.
Kristian> Any opinions on this?
Kristian> Having thought more on this, I really think we shou
Hi!
> "Kristian" == Kristian Nielsen writes:
K> Following up on this, I just learned about the bzr option
K> append_revisions_only that can be set on a branch.
K> This option can be used to enforce that the main history (sequence of
K> primary/left-hand parents from the tip) correctly refl
Kristian Nielsen writes:
> Following up on this, I just learned about the bzr option
> append_revisions_only that can be set on a branch.
Any opinions on this?
Having thought more on this, I really think we should enable
append_revisions_only.
There are many tools (and people as well) that dep
Following up on this, I just learned about the bzr option
append_revisions_only that can be set on a branch.
This option can be used to enforce that the main history (sequence of
primary/left-hand parents from the tip) correctly reflects the series of
pushes into the public tree.
So assume this s
Hi!
> "Kristian" == Kristian Nielsen writes:
Kristian> I noticed a difference between Bitkeeper and Bzr merges.
Thanks for the analyse and thinking about this!
First, in Sun when we switched to bzr, we didn't care about the
difference and continued as if nothing had changed. We did get
"Oleksandr \"Sanja\" Byelkin" writes:
> Since we switched to bazaar I do it in such way (to reduce merge commit
> size):
>
> 1) bzr branch
> 2) cd
> 3) bzr meerge ../
> 4) build/test
> 5) bzr gcommit
> 6) bzr push (or merge) to (or with) and so on
Yes, I see. I like this way, I think I will
Hi!
Kristian Nielsen пишет:
[skip]
> Just wanted to hear if there are any other opinions on this?
Since we switched to bazaar I do it in such way (to reduce merge commit
size):
1) bzr branch
2) cd
3) bzr meerge ../
4) build/test
5) bzr gcommit
6) bzr push (or merge) to (or with) and so on
I noticed a difference between Bitkeeper and Bzr merges.
In Bitkeeper, merge parents are essentially unordered. The two parents of a
merge are completely equal, and there is no way from the Bitkeeper to history
to say whether one parent was merged into the other or vise versa. The actual
order in
9 matches
Mail list logo
