all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, emacs-devel@gnu.org
Subject: Re: Making the tarball with bzr data
Date: Fri, 04 Dec 2009 20:47:28 +0200	[thread overview]
Message-ID: <87638mfuf3.fsf@kobe.laptop> (raw)
In-Reply-To: <e01d8a50911301327x4efb5d3ftfd041db17f0c008@mail.gmail.com> (Lennart Borgman's message of "Mon, 30 Nov 2009 22:27:00 +0100")

On Mon, 30 Nov 2009 22:27:00 +0100, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Mon, Nov 30, 2009 at 8:35 PM, Óscar Fuentes <ofv@wanadoo.es> 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.





  parent reply	other threads:[~2009-12-04 18:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-30 18:11 Making the tarball with bzr data (was: bzr repository ready?) grischka
2009-11-30 18:15 ` Lennart Borgman
2009-11-30 19:35   ` Making the tarball with bzr data Óscar Fuentes
2009-11-30 21:27     ` Lennart Borgman
2009-11-30 21:50       ` Stefan Monnier
2009-11-30 22:33         ` Lennart Borgman
2009-12-01  3:24           ` Stefan Monnier
2009-11-30 22:44       ` Óscar Fuentes
2009-12-01  2:20       ` Stephen J. Turnbull
2009-12-01  2:40         ` Óscar Fuentes
2009-12-04 18:47       ` Giorgos Keramidas [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-10-30 23:38 bzr repository ready? Andreas Schwab
2009-11-20 19:22 ` Karl Fogel
2009-11-21 19:01   ` Glenn Morris
2009-11-22 23:41     ` Karl Fogel
2009-11-23  4:36       ` Eli Zaretskii
2009-11-23  5:11         ` Óscar Fuentes
2009-11-23  5:50           ` Stefan Monnier
2009-11-23  7:35             ` Stephen J. Turnbull
2009-11-23 14:39               ` Stefan Monnier
2009-11-24  2:56                 ` Making the tarball with bzr data (was: bzr repository ready?) Óscar Fuentes
2009-11-30 16:34                   ` Lennart Borgman
2009-11-30 18:46                     ` Making the tarball with bzr data Óscar Fuentes
2009-11-30 18:52                     ` Jason Earl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87638mfuf3.fsf@kobe.laptop \
    --to=keramida@ceid.upatras.gr \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.