Re: GNU Emacs is on Bazaar now.

[Óscar Fuentes]

Karl Fogel <address@hidden> writes:

> Óscar Fuentes <address@hidden> writes:
>> Andreas Schwab <address@hidden> writes:
>>>> A separate question is, is this a *good* procedure for quick fixes?
>>>
>>> Just commit and push them.  There is no point in using a special branch.
>>
>> It depends on how quick your quickfix is.
>>
>> If you start editing the trunk mirror expecting to finish on a few
>> minutes, but you slowly realize that the issue is not so simple, or some
>> other urgent task arises ("you broke the build, fix it asap!" etc) you
>> will have to deal with a polluted gateway to upstream, which is a
>> inconvenience (move away your "quick" changes, revert modified files,
>> and later recover the changes. `bzr shelve' can be handy here, but I
>> don't recommend it to beginners.)
>
> This is one reason we recommended the separate 'quickfix' branch --
> because you never know when a one-commit quick fix will turn into an
> N-commit quick fix.

I think that Andread was proposing to use the local trunk mirror as the
place for editing the quickfixes. You and me agree that that is
undesirable.

>> Given the slow commit rate on the Emacs project, I see no problem using
>> the quickfixes branch on a CVS-like way: bind it to upstream and
>>
>> bzr update
>> <hack, hack, hack>
>> bzr update
>> <maybe solve conflicts>
>> bzr commit -m "fixed bug #2434"
>>
>> It is very likely that this works fine with VC.
>
> Did you see the part in http://www.emacswiki.org/emacs/BzrForEmacsDevs
> that says this?:
>
>   > It might occur to you to save some effort by just doing bzr push
>   > directly to the upstream master from inside the quickfixes branch:
>   > 
>   >   cd $DEVHOME/emacs/quickfixes
>   >   bzr push sftp://<membername>@bzr.savannah.gnu.org/srv/bzr/emacs/trunk/
>   > 
>   > *Do not do this* -- it can cause history to be displayed in a strange
>   > way in the upstream master, any mirrors or branches of it, and your own
>   > branch later. Search for the word "hidden" in this mail for more
>   > details.
>
> Is that relevant to what you are proposing above?

No, because you are committing to upstream, not pushing, i.e. every
commit just adds one history item to upstream on top of the previous,
without attached or "hidden" revisions, which is perfectly fine for
simple changes. Actually, it is the opposite scenario of the one
mentioned on the warning you quoted, as it keeps a synchronized linear
history between the involved branches.

See this hypothetical log entries on upstream trunk:

with commit on a bound quickfixes branch:

34823 fixed bug #2423

with commit on an unbound quickfixes branch + merge&commit on a bound
local mirror:

34823 fixed bug #2423  (that's the commit to upstream from the local mirror)
33823.33822 fixed bug #2423 (that's the merged local quickfixes commit)

The last example has one redundant (although hidden by default) log
entry, requires more commands and suffers from the "double commit"
nuisance that Kenichi Handa mentioned at the beginning of this thread.

-- 
Óscar