[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Making the tarball with bzr data,
Giorgos Keramidas <=