Switching to bzr: what remains to be done?

Switching to bzr: what remains to be done?

[Karl Fogel]

[repost -- sorry, I accidentally put this in another thread before]

We've been planning to switch to bzr, but haven't really done so yet.
What's still blocking this?

I'll serve as a conduit/organizer in bringing the reasons to bzr
developers, if necessary.  (It's related to my work anyway.)

-Karl

Re: Switching to bzr: what remains to be done?

[Dan Nicolaescu]

Karl Fogel <kfogel@red-bean.com> writes:

  > [repost -- sorry, I accidentally put this in another thread before]
  > 
  > We've been planning to switch to bzr, but haven't really done so yet.
  > What's still blocking this?
  > 
  > I'll serve as a conduit/organizer in bringing the reasons to bzr
  > developers, if necessary.  (It's related to my work anyway.)

Plese convey to the bzr developers that the "log" command could use some
improvements:

1. it only takes a single file as argument
2. bzr log SUBDIR 
does not seem to DTRT, it should show the logs for all things in that
subdir, instead it seems to show only one entry

Also the headers for "diff" should show the versions, if you do a C-x v =
for 2 random versions, then save that buffer, there's no way to see what
versions the diff came from.  IMHO this is crucial to have.

I only have bzr 1.7 so maybe things have improved meanwhile...

Re: Switching to bzr: what remains to be done?

[Karl Fogel]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Plese convey to the bzr developers that the "log" command could use some
> improvements:
>
> 1. it only takes a single file as argument
> 2. bzr log SUBDIR 
> does not seem to DTRT, it should show the logs for all things in that
> subdir, instead it seems to show only one entry

Thanks!  I'll try to make sure that these either fixed or explained
(there might be some workflow reason for those behaviors, but if there
is, then it would be good to know why, and what the workaround is).

See below for details on the current state of the above in bzr 1.11dev.

> Also the headers for "diff" should show the versions, if you do a C-x v =
> for 2 random versions, then save that buffer, there's no way to see what
> versions the diff came from.  IMHO this is crucial to have.
>
> I only have bzr 1.7 so maybe things have improved meanwhile...

Not much, I think.  Below is a transcript showing the behavior of

   - bzr log SUBDIR1 SUBDIR2
   - bzr log -v SUBDIR
   - bzr diff

inside bzr's own source tree.  What I especially don't understand is why
the output of 'bzr log -v SUBDIR' shows only two changes worth of
output, one of which apparently didn't touch anything in SUBDIR and the
other of which did (while 'bzr log -v' by itself in the top level
produces gobs and gobs of output, as one would expect).  I'm still
learning bzr, and have not yet finished reading the manual, though, so
perhaps those behaviors will make more sense later.

Here's the transcript:

---------------------------------------------------------------------------
$ bzr --version
Bazaar (bzr) 1.11dev
  from bzr checkout /home/kfogel/src/bzr/bzr.dev
    revision: 3826
    revid: kfogel@floss-20081208171704-ghs5h0icwb8x2ovp
    branch nick: bzr.dev
  Python interpreter: /usr/bin/X11/python 2.5.2
  Python standard library: /usr/lib/python2.5
  bzrlib: /home/kfogel/src/bzr/bzr.dev/bzrlib
  Bazaar configuration: /home/kfogel/.bazaar
  Bazaar log file: /home/kfogel/.bzr.log

Copyright 2005, 2006, 2007, 2008 Canonical Ltd.
http://bazaar-vcs.org/

bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and
you may use, modify and redistribute it under the terms of the GNU
General Public License version 2 or later.

$ bzr info
Standalone tree (format: pack-0.92)
Location:
  branch root: .

Related branches:
  parent branch: http://bazaar-vcs.org/bzr/bzr.dev/
$ bzr log doc man1
bzr: ERROR: extra argument to command log: man1
$ bzr log -v doc
------------------------------------------------------------
revno: 1390
committer: Robert Collins <robertc@robertcollins.net>
timestamp: Tue 2005-09-27 17:24:40 +1000
message:
  pair programming worx... merge integration and weave
added:
  bzrlib/graph.py
  bzrlib/revisionspec.py
  bzrlib/selftest/HTTPTestUtil.py
  bzrlib/selftest/test_bad_files.py
  bzrlib/selftest/test_revision_info.py
  bzrlib/selftest/testgraph.py
  bzrlib/selftest/testmerge.py
  bzrlib/selftest/testremotebranch.py
modified:
  Makefile
  NEWS
  TODO
  bzr
  bzr-man.py
  bzrlib/__init__.py
  bzrlib/add.py
  bzrlib/atomicfile.py
  bzrlib/branch.py
  bzrlib/builtins.py
  bzrlib/changeset.py
  bzrlib/commands.py
  bzrlib/commit.py
  bzrlib/delta.py
  bzrlib/diff.py
  bzrlib/errors.py
  bzrlib/externalcommand.py
  bzrlib/fetch.py
  bzrlib/help.py
  bzrlib/info.py
  bzrlib/intset.py
  bzrlib/inventory.py
  bzrlib/lock.py
  bzrlib/mdiff.py
  bzrlib/merge.py
  bzrlib/merge_core.py
  bzrlib/meta_store.py
  bzrlib/missing.py
  bzrlib/msgeditor.py
  bzrlib/osutils.py
  bzrlib/patch.py
  bzrlib/remotebranch.py
  bzrlib/revfile.py
  bzrlib/revision.py
  bzrlib/selftest/__init__.py
  bzrlib/selftest/blackbox.py
  bzrlib/selftest/test_ancestry.py
  bzrlib/selftest/test_commit.py
  bzrlib/selftest/test_commit_merge.py
  bzrlib/selftest/test_merge_core.py
  bzrlib/selftest/test_parent.py
  bzrlib/selftest/test_smart_add.py
  bzrlib/selftest/testbranch.py
  bzrlib/selftest/testfetch.py
  bzrlib/selftest/testhashcache.py
  bzrlib/selftest/testinv.py
  bzrlib/selftest/testlog.py
  bzrlib/selftest/testrevision.py
  bzrlib/selftest/testrevisionnamespaces.py
  bzrlib/selftest/teststatus.py
  bzrlib/selftest/teststore.py
  bzrlib/selftest/versioning.py
  bzrlib/selftest/whitebox.py
  bzrlib/shellcomplete.py
  bzrlib/status.py
  bzrlib/store.py
  bzrlib/textinv.py
  bzrlib/trace.py
  bzrlib/weavefile.py
  bzrlib/weavestore.py
  bzrlib/xml.py
  contrib/newinventory.py
  setup.py
  testsweet.py
  tutorial.txt
    ------------------------------------------------------------
    revno: 1185.1.29
    committer: Robert Collins <robertc@robertcollins.net>
    timestamp: Mon 2005-09-19 16:05:19 +1000
    message:
      merge merge tweaks from aaron, which includes latest .dev
    modified:
      TODO
      bzrlib/__init__.py
      bzrlib/branch.py
      bzrlib/builtins.py
      bzrlib/changeset.py
      bzrlib/commands.py
      bzrlib/graph.py
      bzrlib/merge.py
      bzrlib/revision.py
      bzrlib/revisionspec.py
      bzrlib/selftest/__init__.py
      bzrlib/selftest/blackbox.py
      bzrlib/selftest/test_merge_core.py
      bzrlib/selftest/test_revision_info.py
      bzrlib/selftest/testgraph.py
      bzrlib/selftest/testmerge.py
      bzrlib/trace.py
      testsweet.py
------------------------------------------------------------
revno: 6
committer: mbp@sourcefrog.net
timestamp: Wed 2005-03-09 04:51:05 +0000
message:
  import all docs from arch
added:
  doc/
  doc/adoption.txt
  doc/bitkeeper.txt
  doc/changelogs.txt
  doc/cherry-picking.txt
  doc/cmdref.txt
  doc/common-format.txt
  doc/compared-aegis.txt
  doc/compared-codeville.txt
  doc/compared-cvsnt.txt
  doc/compared-opencm.txt
  doc/compared-prcs.txt
  doc/compared-teamware.txt
  doc/compression.txt
  doc/config-specs.txt
  doc/conflicts.txt
  doc/costs.txt
  doc/darcs.txt
  doc/deadly-sins.txt
  doc/design.txt
  doc/extra-commands.txt
  doc/faq.txt
  doc/formats.txt
  doc/hashes.txt
  doc/index.txt
  doc/interrupted.txt
  doc/intro.txt
  doc/inventory.txt
  doc/join-branches.txt
  doc/kill-version.txt
  doc/layers.txt
  doc/library-interface.txt
  doc/merge.txt
  doc/mirroring.txt
  doc/monotone.txt
  doc/news.txt
  doc/optional-edit.txt
  doc/partial-commit.txt
  doc/pool.txt
  doc/purpose.txt
  doc/python.txt
  doc/quickref.txt
  doc/quilt.txt
  doc/random.txt
  doc/requirements.txt
  doc/revision-syntax.txt
  doc/roadmap.txt
  doc/rollup.txt
  doc/scalability.txt
  doc/security.txt
  doc/shared-branches.txt
  doc/short-demo.txt
  doc/supportability.txt
  doc/svk.txt
  doc/tagging.txt
  doc/taxonomy.txt
  doc/testing.txt
  doc/thanks.txt
  doc/todo-from-arch.txt
  doc/unchanged.txt
  doc/unrelated-merge.txt
  doc/usability.txt
  doc/use-cases.txt
  doc/web-interface.txt
  doc/work-order.txt
  doc/workflow.txt
  doc/yaml.txt
$ bzr diff
=== modified file 'bzr'
--- bzr	2008-11-28 06:31:17 +0000
+++ bzr	2008-12-08 19:36:41 +0000
@@ -18,6 +18,10 @@
 
 """Bazaar -- a free distributed version-control tool"""
 
+### Look, I'm changing bzr to test bzr!  Also, I often search for the
+### word "search", and I spend a lot of my time in Emacs editing Emacs.
+### Why is my life always like this? 
+
 import os
 import sys
 

$ 

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> Plese convey to the bzr developers that the "log" command could use some
> improvements:
> 1. it only takes a single file as argument
> 2. bzr log SUBDIR 
> does not seem to DTRT, it should show the logs for all things in that
> subdir, instead it seems to show only one entry

There's a long standing Trac ticket for that.  There doesn't seem to be
much interest in fixing it, somehow.  The Trac ticket is
https://bugs.launchpad.net/bzr/+bug/211852 and I see that
I misunderstood at that point thinking that "SUBDIR" worked whereas it
indeed doesn't (basically it only gives info about the changes to the
dir itself, i.e. when it was created and maybe when it was moved or when
its access rights were changed).
I'm pretty sure I saw a bug report about that at some point but can't
find it now.  Feel free to look for it and add your voice to it, or file
a new one.

> Also the headers for "diff" should show the versions, if you do a C-x v =
> for 2 random versions, then save that buffer, there's no way to see what
> versions the diff came from.  IMHO this is crucial to have.

The corresponding Trac ticket is https://bugs.launchpad.net/bzr/+bug/130588.
Making noise there can't hurt.


        Stefan

Re: Switching to bzr: what remains to be done?

[Karl Fogel]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Plese convey to the bzr developers that the "log" command could use some
>> improvements:
>> 1. it only takes a single file as argument
>> 2. bzr log SUBDIR 
>> does not seem to DTRT, it should show the logs for all things in that
>> subdir, instead it seems to show only one entry
>
> There's a long standing Trac ticket for that.  There doesn't seem to be
> much interest in fixing it, somehow.  The Trac ticket is
> https://bugs.launchpad.net/bzr/+bug/211852 and I see that
> I misunderstood at that point thinking that "SUBDIR" worked whereas it
> indeed doesn't (basically it only gives info about the changes to the
> dir itself, i.e. when it was created and maybe when it was moved or when
> its access rights were changed).
> I'm pretty sure I saw a bug report about that at some point but can't
> find it now.  Feel free to look for it and add your voice to it, or file
> a new one.

Bug https://bugs.edge.launchpad.net/bzr/+bug/97715 is about case (2) above.

-Karl

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> We've been planning to switch to bzr, but haven't really done so yet.
> What's still blocking this?
> I'll serve as a conduit/organizer in bringing the reasons to bzr
> developers, if necessary.  (It's related to my work anyway.)

I've been using Bzr for my own local branch (on which I do most of my
work, after which I get a diff and move it to CVS to commit it).
Its performance has been acceptable (not mind-blowing, but not
worse than CVS), so I think the main remaining issue to switch is a good
repository to start from.  Jason Earl <jearl@notengoamigos.org> has been
working on this but hasn't had yet the expected success.

Part of the problem is that it seems that depending on the tool we use
for the conversion we get some of th desired features, but we can't get
them all, it seems:
- incremental (the repository at
  http://bzr.notengoamigos.org/emacs-merges/trunk/ is incremental and is
  the one I've been using).
- includes merge info between various branches (the above repository
  doesn't include it.  There's another that was based on the Git
  repository, which did have the merge info but could not be updated
  incrementally).
- includes renames.  Apparently none of the conversion tools provide
  that since the info is only available in the Arch repository right
  now, but that has commits that bundle up several CVS commit into one.
- is complete.  The http://bzr.notengoamigos.org/emacs-merges/trunk/
  seems to have some missing elements (IIRC a few CVS tags were
  missing).

Another issue that AFAIK nobody has worked on, is how are we going to
handle the Gnus<->Emacs synchronization in the future.  I expect this to
be doable somehow, maybe by still going through Arch, but of course it
would probably be preferable to do it directly within Bzr, and in any
case it will require for someone to figure it out.

We have lived without any renaming or merge info in our CVS, so these
are not crucial, but since some of that data is available in Arch, it
would really be good if we could somehow bring it over to Bzr.

Also, being able to update the Bzr repository incrementally from
subsequent updates in the CVS is not indispensable, but it would
be helpful to make the transition easier.


        Stefan

Re: Switching to bzr: what remains to be done?

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Another issue that AFAIK nobody has worked on, is how are we going to
 > handle the Gnus<->Emacs synchronization in the future.  I expect this to
 > be doable somehow, maybe by still going through Arch, but of course it
 > would probably be preferable to do it directly within Bzr, and in any
 > case it will require for someone to figure it out.

Sorry I can't help with the actual work, but I have some related
experience to describe.

cvs2svn did a great job for me converting the XEmacs repo to git's
fastimport format.  The XEmacs repo is an unholy mess, too, I was
quite surprised at how well cvs2svn handled this.  It has some kind of
update facility (AIUI fastimport is just a format for describing
commits).  I'm not sure if bzr has bulletproof fastimporter yet, but I
know this has come up on the list lately.  Anyway, I recommend a look
at cvs2svn, and maybe encouraging bzr work on fastimport.

tailor is another option, but I've found tailor to require a lot of
care and feeding, at least at first.  The receiving backend was
Mercurial which was implemented as a plugin from the libraries, not by
invoking hg itself.  However the command line interface is more
stable, which seems to be the source of my difficulties.

 > We have lived without any renaming or merge info in our CVS,

Going through git or another VCS that does automatic rename detection
might be an option.

 > Also, being able to update the Bzr repository incrementally from
 > subsequent updates in the CVS is not indispensable, but it would
 > be helpful to make the transition easier.

I think pretty much all popular tools can do this.

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> I have successfully converted the Emacs repository using cvs2svn
> fastimport format.  It was missing merge information, that is available
> from Andreas' git repo.

Actually, the info comes from the Arch repository.  Are you extracting
it from Andreas's Git repository or from Arch (using Andreas's tools)?


        Stefan

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> Actually the repository that is incremental is:
> http://bzr.notengoamigos.org/emacs/trunk/

Sorry, that was a typo, yes.

>> - includes renames.  Apparently none of the conversion tools provide
>> that since the info is only available in the Arch repository right
>> now, but that has commits that bundle up several CVS commit into one.

> I do have an import of the Arch repository, but I wouldn't recommend it
> as it throws away most of the CVS revision history.  I have no idea how
> you would go about trying to merge the Arch information into one of the
> other repositories.

I don't either.  Andreas somehow manages to extract the merge info from
the Arch archive and mix it up with the CVS data to generate&update its
Git repository.  Not sure if something similar can be done for the renames.

>> - is complete.  The http://bzr.notengoamigos.org/emacs-merges/trunk/
>> seems to have some missing elements (IIRC a few CVS tags were
>> missing).
> I think that this could easily be fixed.  Could you give an example from
> emacs-merges?

I meant the http://bzr.notengoamigos.org/emacs/trunk/ branch, sorry.
As far as I can tell the emacs-merges branch is complete.

>> Another issue that AFAIK nobody has worked on, is how are we going to
>> handle the Gnus<->Emacs synchronization in the future.  I expect this to
>> be doable somehow, maybe by still going through Arch, but of course it
>> would probably be preferable to do it directly within Bzr, and in any
>> case it will require for someone to figure it out.
> I don't know how this works so it is hard to comment :).

I think it works pretty much as follows (except in Arch).  To set things
up, the following was done once:

  - cd .../emacs
  - bzr pull
  - bzr merge bzr://.../gnus
  - tons of random bogus conflicts, resolve them somehow

at this point, the VCS (i.e. hopefully Bzr can do it, Arch clearly does)
has figure out that Gnus's "lisp/gnus.el" corresponds to Emacs's
"lisp/gnus/gnus.el" and things like that, so you can then subsequently
treat the two repositories as two branches of the same code, just where
one holds a lot more files than the other.  So you can do

  - bzr merge bzr://.../gnus

and changes will properly get merged into the right files.
Now of course, I don't know how the two-way sync can work, I'm not even
sure how Miles does it for Arch.

> Unfortunately updating from CVS and getting the merge info seem to be
> mutually exclusive.

Clearly Andreas manages to do it, so there should be a way to do that
for Bzr as well.


        Stefan

Re: Switching to bzr: what remains to be done?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't either.  Andreas somehow manages to extract the merge info from
> the Arch archive and mix it up with the CVS data to generate&update its
> Git repository.

I didn't use Arch.  The merge information was automatically extracted
from the commit messages, then manually fixed up.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> OK, I have some ideas on how to make this work.  I will do a bit of
> experimenting and see what I can come up with.  I've played around with
> branches where I have moved files around and bzr merges that just fine.
> This should (hopefully) just be an extreme example.

The main issue is that the two branches will probably not share a common
ancestor at first.  Typically the problem is keeping track of file
identities: in the Gnus repository lisp/gnus.el will have one identity
and in Emacs's lisp/gnus/gnus.el will have another, so convincing Bzr
that those two files correspond to each other may simply be impossible
(in Arch, the identity is user-visible, set in the "arch-tag:" line or
in the .arch-ids-<file>.id file, so matching the two is not difficult).


        Stefan

Re: Switching to bzr: what remains to be done?

[Dan Nicolaescu]

Karl Fogel <kfogel@red-bean.com> writes:

  > [repost -- sorry, I accidentally put this in another thread before]
  > 
  > We've been planning to switch to bzr, but haven't really done so yet.
  > What's still blocking this?
  > 
  > I'll serve as a conduit/organizer in bringing the reasons to bzr
  > developers, if necessary.  (It's related to my work anyway.)

Here's another one:


Assume that bar and baz are registered under bzr, foo is not.

Running the command below (-v -S is what emacs uses for the vc-dir
command):

bzr status -v -S foo bar baz

results in:

bzr: ERROR: Path(s) do not exist: foo

nothing is shown about the other 2 files.


this can occur in practice when using vc-dir, when removing an
unregistered file, and then doing a refresh.

Reference for this bug:
https://bugs.launchpad.net/bzr/+bug/306394

Re: Switching to bzr: what remains to be done?

[Karl Fogel]

Dan Nicolaescu <dann@ics.uci.edu> writes:
> Here's another one:
>
> Assume that bar and baz are registered under bzr, foo is not.
>
> Running the command below (-v -S is what emacs uses for the vc-dir
> command):
>
> bzr status -v -S foo bar baz
>
> results in:
>
> bzr: ERROR: Path(s) do not exist: foo
>
> nothing is shown about the other 2 files.
>
> this can occur in practice when using vc-dir, when removing an
> unregistered file, and then doing a refresh.
>
> Reference for this bug:
> https://bugs.launchpad.net/bzr/+bug/306394

Thank you.

Everyone: I'm sort of dividing this thread into two kinds of issues:

   1) One-time conversion issues.

   2) Problems with bzr even assuming a perfect conversion.

Both are important, but I'm in a better position to work on (2), and it
seems like various people here are giving lots of thought to (1) anyway.

Now I'll go try to match up this thread with the bzr bug database, to
make sure there's a bug for each (1)-type problem we've listed.

Re: Switching to bzr: what remains to be done?

[Karl Fogel]

Progress report on the 4 bugs we've highlighted as blockers:

   1) 'bzr log' only takes a single file argument
       (https://bugs.launchpad.net/bzr/+bug/211852)

       Developer vila has commented in the bug, but there is no
       timeline to fix it.  I'm asking vila whether he plans to.

   2) 'bzr log SUBDIR' doesn't show all changes under SUBDIR
       (https://bugs.edge.launchpad.net/bzr/+bug/97715)

       Developer abentley has commented that this is hard (at least,
       that's how I interpret "This isn't really practical without
       changes to the inventory format.")  Is this one definitely a
       blocker for us, or just a nice-to-have?

   3) 'bzr status -v -S NON_EXISTENT VERSIONED_1 VERSIONED_2' fails
       (https://bugs.launchpad.net/bzr/+bug/306394)

       I'm working on this; see the ticket for details.

   4) 'bzr diff' headers should show the version
       (https://bugs.launchpad.net/bzr/+bug/130588)

       I'm planning to work on this, after #306394.
       If no one beats me to it :-).

       Note that the ticket starts off being about a slightly different
       thing (showing the command-line in the diff header), but then
       Stefan's comment points out that revision information should be
       included too.  That's actually the more important of the two,
       from our point of view, I think.

Other than those, is anything (besides one-time conversion issues)
preventing us from switching to bzr?

For reference (since the mailing list software doesn't add archive URLs
to the headers, oh well), this whole thread is:

   http://lists.gnu.org/archive/html/emacs-devel/2008-12/threads.html#00326

-Karl

Re: Switching to bzr: what remains to be done?

[Tassilo Horn]

Karl Fogel <karl.fogel@canonical.com> writes:

Hi Karl,

> Progress report on the 4 bugs we've highlighted as blockers:
>
>    1) 'bzr log' only takes a single file argument
>        (https://bugs.launchpad.net/bzr/+bug/211852)
>
>        Developer vila has commented in the bug, but there is no
>        timeline to fix it.  I'm asking vila whether he plans to.
>
>    2) 'bzr log SUBDIR' doesn't show all changes under SUBDIR
>        (https://bugs.edge.launchpad.net/bzr/+bug/97715)
>
>        Developer abentley has commented that this is hard (at least,
>        that's how I interpret "This isn't really practical without
>        changes to the inventory format.")  Is this one definitely a
>        blocker for us, or just a nice-to-have?

I don't have any bzr repository checked out currently, so I couldn't
test my assertion.  But reading the docs of bzr-1.10 it seems to me that
`bzr diff' only accepts files as arguments (no directories), too.

Maybe that could make syncing parts that also have an external
repository difficult.  One candidate suffering from that could be
org-mode, which resides at lisp/org/.

Bye,
Tassilo
-- 
A child of five could understand this! Fetch me a child of five!

Re: Switching to bzr: what remains to be done?

[Karl Fogel]

Tassilo Horn <tassilo@member.fsf.org> writes:
> I don't have any bzr repository checked out currently, so I couldn't
> test my assertion.  But reading the docs of bzr-1.10 it seems to me that
> `bzr diff' only accepts files as arguments (no directories), too.
>
> Maybe that could make syncing parts that also have an external
> repository difficult.  One candidate suffering from that could be
> org-mode, which resides at lisp/org/.

Looks like diff can take directories:

  $ bzr --version
  Bazaar (bzr) 1.11dev
    from bzr checkout /home/kfogel/src/bzr/bzr.dev
      revision: 3829
      revid: kfogel@red-bean.com-20081218162441-eeo4vscle7li1ami
      branch nick: bzr.dev
    Python interpreter: /usr/bin/X11/python 2.5.2
    Python standard library: /usr/lib/python2.5
    bzrlib: /home/kfogel/src/bzr/bzr.dev/bzrlib
    Bazaar configuration: /home/kfogel/.bazaar
    Bazaar log file: /home/kfogel/.bzr.log
  
  Copyright 2005, 2006, 2007, 2008 Canonical Ltd.
  http://bazaar-vcs.org/
  
  bzr comes with ABSOLUTELY NO WARRANTY.  bzr is free software, and
  you may use, modify and redistribute it under the terms of the GNU
  General Public License version 2 or later.
  
  $ pwd
  /home/kfogel/src/bzr/bzr.dev
  $ ls
  BRANCH.TODO  bzrlib/		generate_docs.pyc  profile_imports.py  tools/
  build/	     contrib/		INSTALL		   README
  bzr*	     COPYING.txt	Makefile	   setup.py*
  bzr.1	     doc/		man1/		   sigh.diff
  bzr.ico      generate_docs.py*	NEWS		   TODO
  $ echo "small change to NEWS" >> NEWS
  $ echo "small change to default.css" >> doc/default.css
  $ echo "small change to riodemo.py" >> tools/riodemo.py
  $ bzr status
  modified:
    NEWS
    doc/default.css
    tools/riodemo.py
  $ bzr diff
  === modified file 'NEWS'
  --- NEWS	2008-12-17 10:21:38 +0000
  +++ NEWS	2008-12-18 16:25:26 +0000
  @@ -7624,3 +7624,4 @@
   
   ..
      vim: tw=74 ft=rst ff=unix
  +small change to NEWS
  
  === modified file 'doc/default.css'
  --- doc/default.css	2008-02-07 07:05:13 +0000
  +++ doc/default.css	2008-12-18 16:25:20 +0000
  @@ -162,3 +162,4 @@
   span, th.field-name {
     white-space: nowrap;
   }
  +small change to default.css
  
  === modified file 'tools/riodemo.py'
  --- tools/riodemo.py	2005-11-28 08:03:42 +0000
  +++ tools/riodemo.py	2008-12-18 16:26:03 +0000
  @@ -58,3 +58,4 @@
               raise NotImplementedError()
           inv.add(ie)
       return inv
  +small change to riodemo.py
  
  $ bzr diff doc
  === modified file 'doc/default.css'
  --- doc/default.css	2008-02-07 07:05:13 +0000
  +++ doc/default.css	2008-12-18 16:25:20 +0000
  @@ -162,3 +162,4 @@
   span, th.field-name {
     white-space: nowrap;
   }
  +small change to default.css
  
  $ bzr diff doc tools
  === modified file 'doc/default.css'
  --- doc/default.css	2008-02-07 07:05:13 +0000
  +++ doc/default.css	2008-12-18 16:25:20 +0000
  @@ -162,3 +162,4 @@
   span, th.field-name {
     white-space: nowrap;
   }
  +small change to default.css
  
  === modified file 'tools/riodemo.py'
  --- tools/riodemo.py	2005-11-28 08:03:42 +0000
  +++ tools/riodemo.py	2008-12-18 16:26:03 +0000
  @@ -58,3 +58,4 @@
               raise NotImplementedError()
           inv.add(ie)
       return inv
  +small change to riodemo.py
  
  $ 

Re: Switching to bzr: what remains to be done?

[Tassilo Horn]

Karl Fogel <karl.fogel@canonical.com> writes:

Hi Karl,

> Tassilo Horn <tassilo@member.fsf.org> writes:
>> I don't have any bzr repository checked out currently, so I couldn't
>> test my assertion.  But reading the docs of bzr-1.10 it seems to me that
>> `bzr diff' only accepts files as arguments (no directories), too.
>>
>> Maybe that could make syncing parts that also have an external
>> repository difficult.  One candidate suffering from that could be
>> org-mode, which resides at lisp/org/.
>
> Looks like diff can take directories:

Great, then that's not an issue.

Bye,
Tassilo

Re: Switching to bzr: what remains to be done?

[Giorgos Keramidas]

On Thu, 18 Dec 2008 09:00:00 +0100, Tassilo Horn <tassilo@member.fsf.org> wrote:
> Karl Fogel <karl.fogel@canonical.com> writes:
>
> Hi Karl,
>
>> Progress report on the 4 bugs we've highlighted as blockers:
>>
>>    1) 'bzr log' only takes a single file argument
>>        (https://bugs.launchpad.net/bzr/+bug/211852)
>>
>>        Developer vila has commented in the bug, but there is no
>>        timeline to fix it.  I'm asking vila whether he plans to.
>>
>>    2) 'bzr log SUBDIR' doesn't show all changes under SUBDIR
>>        (https://bugs.edge.launchpad.net/bzr/+bug/97715)
>>
>>        Developer abentley has commented that this is hard (at least,
>>        that's how I interpret "This isn't really practical without
>>        changes to the inventory format.")  Is this one definitely a
>>        blocker for us, or just a nice-to-have?
>
> I don't have any bzr repository checked out currently, so I couldn't
> test my assertion.  But reading the docs of bzr-1.10 it seems to me that
> `bzr diff' only accepts files as arguments (no directories), too.
>
> Maybe that could make syncing parts that also have an external
> repository difficult.  One candidate suffering from that could be
> org-mode, which resides at lisp/org/.

It may affect `vc-dir' too.  I am using `C-x v d' to check parts of the
workspace with Mercurial branches, but I haven't tried it with bzr branches.

Re: Switching to bzr: what remains to be done?

[Dan Nicolaescu]

Karl Fogel <karl.fogel@canonical.com> writes:

  > Progress report on the 4 bugs we've highlighted as blockers:
  > 
  >    1) 'bzr log' only takes a single file argument
  >        (https://bugs.launchpad.net/bzr/+bug/211852)
  > 
  >        Developer vila has commented in the bug, but there is no
  >        timeline to fix it.  I'm asking vila whether he plans to.
  > 
  >    2) 'bzr log SUBDIR' doesn't show all changes under SUBDIR
  >        (https://bugs.edge.launchpad.net/bzr/+bug/97715)
  > 
  >        Developer abentley has commented that this is hard (at least,
  >        that's how I interpret "This isn't really practical without
  >        changes to the inventory format.")  Is this one definitely a
  >        blocker for us, or just a nice-to-have?

Some parts of emacs are maintained in a different place, (Gnus and org
come to mind, but probably there's more).  Not being able to do a bzr log on
a subdir might be a big problem for those projects (or for Miles that
handles merging).  You might want to ask them directly.

Now _IMHO_, a VCS that cannot do a log operation on a subdirectory is a
non-starter for anything that has subdirectories.

Re: Switching to bzr: what remains to be done?

[Tom Tromey]

>>>>> "Karl" == Karl Fogel <karl.fogel@canonical.com> writes:

Karl> Other than those, is anything (besides one-time conversion issues)
Karl> preventing us from switching to bzr?

Today I gave bzr a whirl.  I tried cloning, and I was really surprised
by the time it took:

opsy. time bzr clone http://bzr.notengoamigos.org/emacs/trunk/
Branched 95250 revision(s).                                                    

real    55m20.938s
user    11m8.756s
sys     0m19.971s


I'm using the bzr from F9:

opsy. rpm -q bzr
bzr-1.9-1.fc9.i386


Is this expected?  One hour to check out Emacs seems excessive.

Tom

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

Karl> Other than those, is anything (besides one-time conversion issues)
Karl> preventing us from switching to bzr?

> Today I gave bzr a whirl.  I tried cloning, and I was really surprised
> by the time it took:

> opsy. time bzr clone http://bzr.notengoamigos.org/emacs/trunk/
> Branched 95250 revision(s).                                                    

> real    55m20.938s
> user    11m8.756s
> sys     0m19.971s


> I'm using the bzr from F9:

> opsy. rpm -q bzr
> bzr-1.9-1.fc9.i386

> Is this expected?  One hour to check out Emacs seems excessive.

I think it's pretty much expected, yes.  Bzr is not a speed daemon, and
the initial checkout is a case in point.  Luckily, this is not a common
occurrence, and it can be sped up in all kinds of ways (e.g. provide
a tarball snapshot of the checked out tree).


        Stefan

Re: Switching to bzr: what remains to be done?

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Is this expected?  One hour to check out Emacs seems excessive.

Stefan> I think it's pretty much expected, yes.  Bzr is not a speed daemon, and
Stefan> the initial checkout is a case in point.  Luckily, this is not a common
Stefan> occurrence, and it can be sped up in all kinds of ways (e.g. provide
Stefan> a tarball snapshot of the checked out tree).

I wonder why bzr can't do that itself.


An update is also is quite slow:

opsy. time bzr pull
Using saved parent location: http://bzr.notengoamigos.org/emacs/trunk/
 M  INSTALL                                                                    
 M  admin/notes/copyright
 M  lib-src/ChangeLog
 M  lib-src/ebrowse.c
 M  lib-src/etags.c
 M  lib-src/rcs2log
 M  lisp/ChangeLog
 M  lisp/net/tramp.el
 M  lisp/version.el
 M  nextstep/ChangeLog
 M  nextstep/Cocoa/Emacs.base/Contents/Info.plist
 M  nextstep/Cocoa/Emacs.base/Contents/Resources/English.lproj/InfoPlist.strings
 M  nextstep/GNUstep/Emacs.base/Resources/Info-gnustep.plist
All changes applied successfully.                                              
Now on revision 95259.

real    1m17.355s
user    0m8.825s
sys     0m0.520s

That is a lot of time for a pretty small change.

Tom

Re: Switching to bzr: what remains to be done?

[Stefan Monnier]

> An update is also is quite slow:

I find it comparable to update via CVS (of course, YMMV; tho it
probably depends on your connection and your CPU).


        Stefan

Re: Switching to bzr: what remains to be done?

[Richard M Stallman]

Please report these slownesses (and any other bzr problems) to the
maintainers of bzr!

Switching to bzr: what remains to be done?

[Karl Fogel]

We've been planning to switch to bzr, but haven't really done so yet.
What's still blocking this?

I'll serve as a conduit/organizer in bringing the reasons to bzr
developers, if necessary.  (It's related to my work anyway.)

-Karl