all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Stephen J. Turnbull" <stephen@xemacs.org>
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: Tue, 01 Dec 2009 11:20:29 +0900	[thread overview]
Message-ID: <87einfwi36.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <e01d8a50911301327x4efb5d3ftfd041db17f0c008@mail.gmail.com>

Lennart Borgman writes:

 > Why do I have to copy the files? Why can't this setup be done with
 > the already existing files?

Basically, because Bazaar is not git.  In git, each object is
summarized with an SHA1 hash, and so you can verify that you have a
clean tree (with very high probability) without actually comparing the
file content.  Bazaar uses a different, history-dependent method to
track files, assigning a globally unique, *permanent* ID to each
file.  So in order to verify that you have the right files for the
version Bazaar believes to be there, Bazaar must diff every single
file.  If you think about it, you'll see any other behavior would make
Bazaar a very unreliable tool.

There no savings in network transport (Bazaar can't send only the
content of the version you check out), and no savings in local file IO
(in the best case, every file differs in the first byte so you check
them all out anyway), by reusing existing files.

N.B. Reuse of an existing tree is a theoretical possibility only in
git.  AFAIK it has not been implemented.

In Bazaar, I suspect you can do the following:

1.  bzr branch --treeless <Emacs trunk URL> tmp
2.  mv tmp/.bzr <existing Emacs tree top directory>

But this doesn't save any network transport (you still get all the
branch data), and not much time locally since bzr will need to diff
all the files to determine which ones to commit (it will believe they
have *all* changed based on timestamp).

Probably the best procedure is

1.  bzr branch <Emacs trunk URL> bzr-emacs
2.  rsync <options> old-emacs bzr-emacs

assuming that rsync has appropriate options to ensure that it won't
change the stat data (specifically size and timestamp, IIRC) that bzr
uses to check if a file has been changed.

 > I have put my little elisp library nXhtml at Launchpad so you can
 > download it with bzr. However a lot of people already have nXhtml
 > installed, but it was not checked out from Launchpad. It came from a
 > zip file or similar.
 > 
 > Now I believed that since bzr is a new modern system it would of
 > course have thought of that kind of situation.

No, because Bazaar is a new modern system it assumes you have a new
modern network connection with which to download the Bazaar metadata
and revision history reasonably quickly.  This is a one-time cost per
project you work on if you use the workflow recommended in
BzrForEmacsDevs.

 > Maybe my believe is crazy. Maybe this should not be possible for some
 > reason. But I do not understand why.

It is possible -- with git.  Emacs isn't using git.  And there are
things that Bazaar can do (eg, tracking renames efficiently) that git
cannot.  Unfortunately, tracking renames depends exactly on the
feature I described above (tracking files in bzr vs. tracking content
in git).  (In theory you could do both and get the best of both
worlds, but this hasn't been implemented in any VCS AFAIK.)




  parent reply	other threads:[~2009-12-01  2:20 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 [this message]
2009-12-01  2:40         ` Óscar Fuentes
2009-12-04 18:47       ` Giorgos Keramidas
  -- 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=87einfwi36.fsf@uwakimon.sk.tsukuba.ac.jp \
    --to=stephen@xemacs.org \
    --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.