Re: Avoiding slowdown in trunk development

[Chong Yidong]

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.