[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoiding slowdown in trunk development
From: |
Chong Yidong |
Subject: |
Re: Avoiding slowdown in trunk development |
Date: |
Wed, 02 Feb 2011 11:52:45 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
Paul Eggert <address@hidden> writes:
>>> > if that commit fails due to a nearly-simultaneous
>>> > trunk commit by someone else, I typically just revert my copy of the
>>> > trunk and start over.
>> I hope by "revert" you meant "bzr up", not "bzr revert". The short
>> time window for the kind of race condition that could happen in this
>> situation will rarely cause changes in parts that are related to your
>> changes.
>
> Near-simultaneous changes have caused problems for me.
> bzr may be good at merging, but its errors are common enough to be of
> concern to me. So I take a more cautious approach using "bzr revert".
> This approach has not caused problems.
For stuff like the gnulib merge, it would be easier for you to work in a
branch. No need to worry about using "bzr revert".
If I'd realized the gnulib changes would have broken the Windows build
for so long, I would have recommended doing them in a branch on
savannah.gnu.org first. Then Eli could have fixed the Windows
compilation problems in the branch, before the new code was merged into
the trunk.