Re: Emacs-diffs Digest, Vol 53, Issue 105

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Richard Stallman]

I made a few changes in the EMACS_22_BASE branch.
Can someone please transfer them to the trunk?

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Glenn Morris]

Richard Stallman wrote:

> I made a few changes in the EMACS_22_BASE branch.
> Can someone please transfer them to the trunk?

It looks like you are just talking about this tiny, tiny change, is
that right? Plus the FOR-RELEASE stuff I have already asked about in a
separate mail.


+2007-04-25  Richard Stallman  <address@hidden>
+
+       * hi-lock.el (hi-lock-file-patterns-policy): Default to `ask'.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Richard Stallman]

    > I made a few changes in the EMACS_22_BASE branch.
    > Can someone please transfer them to the trunk?

    It looks like you are just talking about this tiny, tiny change, is
    that right? Plus the FOR-RELEASE stuff I have already asked about in a
    separate mail.

I cannot tell you a list of everything I installed.  It is plausible that
it was only this one.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Glenn Morris]

Richard Stallman wrote:

> I made a few changes in the EMACS_22_BASE branch.
> Can someone please transfer them to the trunk?

For the record, I think Miles did this with some merge script thing.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
>> I made a few changes in the EMACS_22_BASE branch.
>> Can someone please transfer them to the trunk?
>
> For the record, I think Miles did this with some merge script thing.

And I will continue to do so daily (unless someone tells me to stop).

-miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Richard Stallman]

    > For the record, I think Miles did this with some merge script thing.

    And I will continue to do so daily (unless someone tells me to stop).

The script requires manual supervision, because it can go wrong.  In
etc/NEWS it copied in an insertion I had already made, producing two
duplicate entries which I just removed.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Richard Stallman]

    > I made a few changes in the EMACS_22_BASE branch.
    > Can someone please transfer them to the trunk?

    For the record, I think Miles did this with some merge script thing.

Thanks to whoever did it.

I am now set up to install in both places myself.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Stefan Monnier]

>> I made a few changes in the EMACS_22_BASE branch.
>> Can someone please transfer them to the trunk?

>     For the record, I think Miles did this with some merge script thing.

> Thanks to whoever did it.

> I am now set up to install in both places myself.

Better not: since the script copies changes from the branch to the trunk,
it's better to install changes only on one or the other, but not on both,
otherwise you'll end up with spurious conflicts and/or duplicated changes.


        Stefan

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Nick Roberts]

 > > I am now set up to install in both places myself.
 > 
 > Better not: since the script copies changes from the branch to the trunk,
 > it's better to install changes only on one or the other, but not on both,
 > otherwise you'll end up with spurious conflicts and/or duplicated changes.

I've commited a change to the trunk, so while it won't get copied to the
branch, if I commit it there, the script will presumably try to copy it back
again to the trunk.  Also, I guess there may be changes to the trunk which we
don't want on the branch, so it's probably not a good idea to extend the script
to copy from the trunk to the branch.

In a normal world, the list of bugs would be in a file on the trunk and few
changes would be made on the branch, in which case it would be best to remove
the script.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Miles Bader]

Nick Roberts <nickrob@snap.net.nz> writes:
> I've commited a change to the trunk, so while it won't get copied to the
> branch, if I commit it there, the script will presumably try to copy it back
> again to the trunk.

That's generally not a problem:  usually duplicate changes are dropped,
and I manually check the result to catch cases that weren't properly
handled automatically.  The duplicate change Richard mentioned was
simply one I missed.  Typically such errors occur in text files like
NEWS where they aren't that big a deal in the short term (given that
they're on the trunk with no impeding release about to be made from it).

So please commit your change to the branch if it is appropriate.

BTW, referring to it as a "script" is slightly misleading I think.
Though I'm using tools that make it easier, it's definitely a manual
process which I invoke by hand, and I check the results.

-Miles

-- 
Next to fried food, the South has suffered most from oratory.
  			-- Walter Hines Page

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Glenn Morris]

Stefan Monnier wrote:

> Better not: since the script copies changes from the branch to the
> trunk, it's better to install changes only on one or the other, but
> not on both, otherwise you'll end up with spurious conflicts and/or
> duplicated changes.

If it's really that fragile, is that acceptable?

I for one have been installing things in both places, largely because
it's very little extra effort, and I like to get a "proper" CVS log
entry. Eg this:

  (hi-lock-file-patterns-policy): Default to `ask'.

rather than all this:
    
    Merge from emacs--rel--22
    
    Patches applied:
    
     * emacs--rel--22  (base, patch 1-2)
    
       - tag of emacs@sv.gnu.org/emacs--devo--0--patch-709
       - Sync to CVS tag EMACS_22_BRANCHPOINT
       - Sync to CVS branch EMACS_22_BASE
    
    2007-04-25  Richard Stallman  <rms@gnu.org>
    
       * lisp/hi-lock.el (hi-lock-file-patterns-policy): Default to `ask'.
    
    2007-04-24  Richard Stallman  <rms@gnu.org>
    
       * lispref/text.texi (Special Properties): Add xref to Overlay
         Properties.
    
       * lispref/display.texi (Overlay Properties): Add xref to Special
         Properties.
    
    Revision: emacs@sv.gnu.org/emacs--devo--0--patch-716

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Miles Bader]

Glenn Morris <rgm@gnu.org> writes:
> I for one have been installing things in both places, largely because
> it's very little extra effort, and I like to get a "proper" CVS log
> entry.

Feel free to keep doing this, it's really not a big deal.  The point of
back-merging like this is to catch the things people forget -- if
_everbody_ commits their changes in both places, nothing will end up
being back-merged.

-Miles

-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Glenn Morris]

Miles Bader wrote:

> Feel free to keep doing this, it's really not a big deal.  The point of
> back-merging like this is to catch the things people forget -- if
> _everbody_ commits their changes in both places, nothing will end up
> being back-merged.

Thanks, I get it now.

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Richard Stallman]

    Better not: since the script copies changes from the branch to the trunk,
    it's better to install changes only on one or the other, but not on both,
    otherwise you'll end up with spurious conflicts and/or duplicated changes.

That would be one way of doing it -- but then what use is it to have
the separate branch?  And what about cases where we want to make
different changes in the branch and the trunk (such as timeclock.el)?

Re: Emacs-diffs Digest, Vol 53, Issue 105

[Stefan Monnier]

>     Better not: since the script copies changes from the branch to the
>     trunk, it's better to install changes only on one or the other, but
>     not on both, otherwise you'll end up with spurious conflicts and/or
>     duplicated changes.

> That would be one way of doing it -- but then what use is it to have
> the separate branch?

The sync is not done both ways.  It just makes sure that if we install a fix
for Emacs-22.1 it won't come and bite us again in Emacs-23 because we forgot
to also install it on the trunk.

> And what about cases where we want to make different changes in the branch
> and the trunk (such as timeclock.el)?

I don't see any problem either:
- install the change on the branch
- merge into the trunk
- improve the change on the trunk
or
- install both changes on their respective branches
- when the branch gets merged onto the trunk you'll get a conflict
  which you resolve by simply selecting the trunk's code.


        Stefan