emacs-devel
[Top][All Lists]
Advanced

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

Re: Making the tarball with bzr data


From: Giorgos Keramidas
Subject: Re: Making the tarball with bzr data
Date: Fri, 04 Dec 2009 20:47:28 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix)

On Mon, 30 Nov 2009 22:27:00 +0100, Lennart Borgman <address@hidden> wrote:
> On Mon, Nov 30, 2009 at 8:35 PM, Óscar Fuentes <address@hidden> wrote:
>> Well, a brute force solution is to setup your personal bzr Emacs branch
>> and then simply copy everything from your CVS checkout over the bzr
>> branch, or in Windows parlance, copy the contents of the folder
>> lennarts_CVS_checkout over lennarts_bzr_branch, overwriting
>> everythin. You can remove the CVS directories on the bzr branch, as they
>> would be useless once the switch at Savannah is complete.
>
> I am grateful for the explanations you and others have given for this.
> I am just surprised that I have to copy the files. It certainly makes
> the process slower in several ways. I have to do more. And there will
> be more network traffic etc.

Hi Lennard,

You will have to copy a bzr-based trunk, but this is something you will
only have to do the first time.  The cost of subsequent merges with the
Emacs upstream is significantly lower than the first copy.

Once you go through the initial 'pain' of having to branch from the
Emacs trunk, there are a few things to gain too:

  * You get to merge with the Emacs upstream branch as many times as you
    want.  All the merges are shown explicitly in the history of your
    local branch, so it is easier to reason about questions like "When
    was the last time my merge worked fine?" or to move between two
    different merge points, even if one of them is arbitrarily old.

  * Your w32 branch will be visible to others too, including its full
    merge history with the Emacs upstream.  You can publish your w32
    branch either on Launchpad or on your own web server, and other
    people can look at the changes, submit their own extra changes, and
    so on.

  * Once you commit your local changes to a bzr branch, it is much safer
    to experiment with *more* changes, since the already committed
    patches will not go away even if you wipe all the files in the
    working copy.  If you accidentally modify a file and break your
    local w32 copy in some annoying way, you can just check-out a fresh
    copy from bzr.





reply via email to

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