emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patch vs. overwrite in bzr [was: Next pretest, and regressions polic


From: Eli Zaretskii
Subject: Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy]
Date: Thu, 05 Apr 2012 18:53:27 +0300

> From: Bastien <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 05 Apr 2012 09:13:09 +0200
> 
> I have a local "emacs-merge" branch, stemming from hotfix.  This local
> branch has a directory "emacs" that reproduce part of the hierarchy of
> Emacs files, that part which contains Org files.
> 
> doc
>  misc
>   ChangeLog
>   org.texi
> etc
>  org
>   OrgOdtContentTemplate.xml
>   OrgOdtStyles.xml
>   README
>  refcards
>   orgcard.pdf
>   orgcard.tex
> lisp
>  org
>   ChangeLog
>   [org/ob..el]x109
> 
> Then the sync process is this:
> 
> 1. Check for org-related changes in Emacs trunk
> 
> 2. Backport them to the hotfix branch
> 
> 3. Copy the files from the hotfix branch to the emacs dir in my local
>    emacs-merge branch, and get a diff from there.
> 
> 4. Clean up the patch so that it applies correctly in Emacs trunk.
> 
> 5. Fix merge conflicts in the hotfix branch and go back to 3 if needed.
> 
> 6. Commit the diff on the "org" bzr branch (bound to the remote Emacs
>    trunk) when things look fine.
> 
> Suggestions against this workflow are welcome.

Well, I'm not sure I get all the details of your setup, so it's
possible that I will say something silly; apologies in advance.  But
IIUC, you could get away with less branches and less manual work.  So
here we go:

Setup:

  . A bound bzr branch, let's call it emacs-trunk, where you don't
    make any changes, just merge before committing upstream, to the
    Emacs master repository.

  . A local bzr branch, let's call it emacs-org, which will be the
    branch that you sync with one of your git branches.  From this
    branch you will merge to emacs-trunk before committing upstream.

  . A git branch that corresponds to emacs-org, I think this could be
    your hotfix branch, as I don't understand why you need the
    emacs-merge branch.

Below I assume that you have the bzr-tiplog plugin installed.  It
provides the functionality similar to git-reflog, and lets you skip
the error-prone step of remembering or keeping notes about the last
bzr revision you sync'ed with (see below); the only revision id's you
will ever need to remember is tip:0 and tip:1.

The sync process proceeds in cycles.  Each cycle begins when you sync
from Emacs repo to Org as follows:

  cd emacs-trunk
  bzr update
  cd ../emacs-org
  bzr merge --pull ../emacs-trunk

Now emacs-org is synchronized with the Emacs trunk.  Next, produce the
org-related changes since your last synchronization:

  bzr diff -r tip:1..tip:0 lisp/org > patches

(If there are files outside lisp/org that you are interested in,
perhaps etc/NEWS or doc/misc/org.texi, mention them as well; bzr will
produce diffs only for those files and directories, leaving out stuff
you don't care about.)

The file `patches' produced above includes files that are added,
removed, and renamed, but not in the form of diffs (I think).  So to
make sure you don't miss those changes, do also this:

  bzr status -r tip:1..tip:0 lisp/org

(again, add any other directories you are interested in), and examine
the output for any non-text changes.

Now sync your git branch, by (a) applying `patches' with Patch, and
(b) performing any file operations.  The latter should be done by
hand, or you could perhaps write some simple script to parse the
output of "bzr status" and do it for you.

After this, you develop Org normally.  I understand you have other
branches, so you probably will wish to use git commands to merge the
changes into them as well, and then back to the branch that you will
later sync with bzr.

I suggest to perform the steps above as frequent as you can, to avoid
diverging too much from the Emacs trunk.  That will make the second
part of the cycle easier.  I'd expect that more often than not, you
will find that no changes were done that pertain to Org, so I don't
think the burden will be too heavy.  The advantage is that your code
will be very similar to what the Emacs trunk has, so all your testing
will not need to be redone when you merge with the latest trunk below.

So time passes, and you decide you are ready to commit to the Emacs
repo.  Then, just overwrite the files in emacs-org with the
corresponding files in your git branch (using rsync or some such), and
type these bzr commands:

  cd emacs-org
  bzr commit -m "sync'ed with git revision 12345abcd"

You now have a bzr branch that is synchronized with your git branch.

Now find out how much you diverged from the trunk since the last
resync:

  cd ../emacs-trunk
  bzr update
  bzr diff -r branch:../emacs-org.. lisp/org

If the diffs this shows are insignificant enough, you can simply merge
into trunk and commit:

  bzr merge ../emacs-org
  bzr ci -m "Merge from Org repo."

If, however, enough time has passed since the last sync, and the diffs
are non-trivial, you will have to merge back to emacs-org and retest:

  cd ../emacs-org
  bzr merge ../emacs-trunk
  # build and test
  cd ../emacs-trunk
  bzr merge ../emacs-org
  bzr ci -m "Merge from Org repo."

This completes the cycle, and you are ready to begin the next one.

HTH



reply via email to

[Prev in Thread] Current Thread [Next in Thread]