* Switching to bzr: what remains to be done?
@ 2008-12-08 16:32 Karl Fogel
0 siblings, 0 replies; 25+ messages in thread
From: Karl Fogel @ 2008-12-08 16:32 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Switching to bzr: what remains to be done?
@ 2008-12-08 18:59 Karl Fogel
2008-12-08 19:29 ` Dan Nicolaescu
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Karl Fogel @ 2008-12-08 18:59 UTC (permalink / raw
To: emacs-devel
[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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 18:59 Switching to bzr: what remains to be done? Karl Fogel
@ 2008-12-08 19:29 ` Dan Nicolaescu
2008-12-08 19:51 ` Karl Fogel
2008-12-08 21:44 ` Stefan Monnier
2008-12-08 19:54 ` Stefan Monnier
2008-12-09 2:45 ` Dan Nicolaescu
2 siblings, 2 replies; 25+ messages in thread
From: Dan Nicolaescu @ 2008-12-08 19:29 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
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...
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 19:29 ` Dan Nicolaescu
@ 2008-12-08 19:51 ` Karl Fogel
2008-12-08 21:44 ` Stefan Monnier
1 sibling, 0 replies; 25+ messages in thread
From: Karl Fogel @ 2008-12-08 19:51 UTC (permalink / raw
To: emacs-devel
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
$
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 18:59 Switching to bzr: what remains to be done? Karl Fogel
2008-12-08 19:29 ` Dan Nicolaescu
@ 2008-12-08 19:54 ` Stefan Monnier
2008-12-09 0:59 ` Stephen J. Turnbull
[not found] ` <87hc5ef9mf.fsf@notengoamigos.org>
2008-12-09 2:45 ` Dan Nicolaescu
2 siblings, 2 replies; 25+ messages in thread
From: Stefan Monnier @ 2008-12-08 19:54 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 19:29 ` Dan Nicolaescu
2008-12-08 19:51 ` Karl Fogel
@ 2008-12-08 21:44 ` Stefan Monnier
2008-12-11 22:43 ` Karl Fogel
1 sibling, 1 reply; 25+ messages in thread
From: Stefan Monnier @ 2008-12-08 21:44 UTC (permalink / raw
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 19:54 ` Stefan Monnier
@ 2008-12-09 0:59 ` Stephen J. Turnbull
[not found] ` <878wqqf8gr.fsf@notengoamigos.org>
[not found] ` <87hc5ef9mf.fsf@notengoamigos.org>
1 sibling, 1 reply; 25+ messages in thread
From: Stephen J. Turnbull @ 2008-12-09 0:59 UTC (permalink / raw
To: Stefan Monnier; +Cc: Karl Fogel, emacs-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 18:59 Switching to bzr: what remains to be done? Karl Fogel
2008-12-08 19:29 ` Dan Nicolaescu
2008-12-08 19:54 ` Stefan Monnier
@ 2008-12-09 2:45 ` Dan Nicolaescu
2008-12-11 20:23 ` Karl Fogel
2 siblings, 1 reply; 25+ messages in thread
From: Dan Nicolaescu @ 2008-12-09 2:45 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
[not found] ` <878wqqf8gr.fsf@notengoamigos.org>
@ 2008-12-09 3:16 ` Stefan Monnier
0 siblings, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2008-12-09 3:16 UTC (permalink / raw
To: Jason Earl; +Cc: Karl Fogel, Stephen J. Turnbull, emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
[not found] ` <87hc5ef9mf.fsf@notengoamigos.org>
@ 2008-12-09 3:32 ` Stefan Monnier
2008-12-09 9:33 ` Andreas Schwab
[not found] ` <87zlj5dvij.fsf@notengoamigos.org>
0 siblings, 2 replies; 25+ messages in thread
From: Stefan Monnier @ 2008-12-09 3:32 UTC (permalink / raw
To: Jason Earl; +Cc: Karl Fogel, emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-09 3:32 ` Stefan Monnier
@ 2008-12-09 9:33 ` Andreas Schwab
[not found] ` <87zlj5dvij.fsf@notengoamigos.org>
1 sibling, 0 replies; 25+ messages in thread
From: Andreas Schwab @ 2008-12-09 9:33 UTC (permalink / raw
To: Stefan Monnier; +Cc: Karl Fogel, Jason Earl, emacs-devel
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."
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
[not found] ` <87zlj5dvij.fsf@notengoamigos.org>
@ 2008-12-09 19:55 ` Stefan Monnier
0 siblings, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2008-12-09 19:55 UTC (permalink / raw
To: Jason Earl; +Cc: Karl Fogel, emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-09 2:45 ` Dan Nicolaescu
@ 2008-12-11 20:23 ` Karl Fogel
2008-12-17 22:59 ` Karl Fogel
0 siblings, 1 reply; 25+ messages in thread
From: Karl Fogel @ 2008-12-11 20:23 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-08 21:44 ` Stefan Monnier
@ 2008-12-11 22:43 ` Karl Fogel
0 siblings, 0 replies; 25+ messages in thread
From: Karl Fogel @ 2008-12-11 22:43 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-11 20:23 ` Karl Fogel
@ 2008-12-17 22:59 ` Karl Fogel
2008-12-18 8:00 ` Tassilo Horn
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Karl Fogel @ 2008-12-17 22:59 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-17 22:59 ` Karl Fogel
@ 2008-12-18 8:00 ` Tassilo Horn
2008-12-18 16:28 ` Karl Fogel
2008-12-19 8:29 ` Giorgos Keramidas
2008-12-18 20:26 ` Dan Nicolaescu
2009-01-05 0:00 ` Tom Tromey
2 siblings, 2 replies; 25+ messages in thread
From: Tassilo Horn @ 2008-12-18 8:00 UTC (permalink / raw
To: emacs-devel
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!
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-18 8:00 ` Tassilo Horn
@ 2008-12-18 16:28 ` Karl Fogel
2008-12-19 8:22 ` Tassilo Horn
2008-12-19 8:29 ` Giorgos Keramidas
1 sibling, 1 reply; 25+ messages in thread
From: Karl Fogel @ 2008-12-18 16:28 UTC (permalink / raw
To: emacs-devel
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
$
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-17 22:59 ` Karl Fogel
2008-12-18 8:00 ` Tassilo Horn
@ 2008-12-18 20:26 ` Dan Nicolaescu
2009-01-05 0:00 ` Tom Tromey
2 siblings, 0 replies; 25+ messages in thread
From: Dan Nicolaescu @ 2008-12-18 20:26 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-18 16:28 ` Karl Fogel
@ 2008-12-19 8:22 ` Tassilo Horn
0 siblings, 0 replies; 25+ messages in thread
From: Tassilo Horn @ 2008-12-19 8:22 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-18 8:00 ` Tassilo Horn
2008-12-18 16:28 ` Karl Fogel
@ 2008-12-19 8:29 ` Giorgos Keramidas
1 sibling, 0 replies; 25+ messages in thread
From: Giorgos Keramidas @ 2008-12-19 8:29 UTC (permalink / raw
To: emacs-devel
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.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2008-12-17 22:59 ` Karl Fogel
2008-12-18 8:00 ` Tassilo Horn
2008-12-18 20:26 ` Dan Nicolaescu
@ 2009-01-05 0:00 ` Tom Tromey
2009-01-05 2:14 ` Stefan Monnier
2 siblings, 1 reply; 25+ messages in thread
From: Tom Tromey @ 2009-01-05 0:00 UTC (permalink / raw
To: Karl Fogel; +Cc: emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2009-01-05 0:00 ` Tom Tromey
@ 2009-01-05 2:14 ` Stefan Monnier
2009-01-05 2:42 ` Tom Tromey
0 siblings, 1 reply; 25+ messages in thread
From: Stefan Monnier @ 2009-01-05 2:14 UTC (permalink / raw
To: Tom Tromey; +Cc: Karl Fogel, emacs-devel
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2009-01-05 2:14 ` Stefan Monnier
@ 2009-01-05 2:42 ` Tom Tromey
2009-01-05 4:04 ` Stefan Monnier
2009-01-06 0:01 ` Richard M Stallman
0 siblings, 2 replies; 25+ messages in thread
From: Tom Tromey @ 2009-01-05 2:42 UTC (permalink / raw
To: Stefan Monnier; +Cc: Karl Fogel, emacs-devel
>>>>> "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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2009-01-05 2:42 ` Tom Tromey
@ 2009-01-05 4:04 ` Stefan Monnier
2009-01-06 0:01 ` Richard M Stallman
1 sibling, 0 replies; 25+ messages in thread
From: Stefan Monnier @ 2009-01-05 4:04 UTC (permalink / raw
To: Tom Tromey; +Cc: Karl Fogel, emacs-devel
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Switching to bzr: what remains to be done?
2009-01-05 2:42 ` Tom Tromey
2009-01-05 4:04 ` Stefan Monnier
@ 2009-01-06 0:01 ` Richard M Stallman
1 sibling, 0 replies; 25+ messages in thread
From: Richard M Stallman @ 2009-01-06 0:01 UTC (permalink / raw
To: Tom Tromey; +Cc: karl.fogel, monnier, emacs-devel
Please report these slownesses (and any other bzr problems) to the
maintainers of bzr!
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2009-01-06 0:01 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-08 18:59 Switching to bzr: what remains to be done? Karl Fogel
2008-12-08 19:29 ` Dan Nicolaescu
2008-12-08 19:51 ` Karl Fogel
2008-12-08 21:44 ` Stefan Monnier
2008-12-11 22:43 ` Karl Fogel
2008-12-08 19:54 ` Stefan Monnier
2008-12-09 0:59 ` Stephen J. Turnbull
[not found] ` <878wqqf8gr.fsf@notengoamigos.org>
2008-12-09 3:16 ` Stefan Monnier
[not found] ` <87hc5ef9mf.fsf@notengoamigos.org>
2008-12-09 3:32 ` Stefan Monnier
2008-12-09 9:33 ` Andreas Schwab
[not found] ` <87zlj5dvij.fsf@notengoamigos.org>
2008-12-09 19:55 ` Stefan Monnier
2008-12-09 2:45 ` Dan Nicolaescu
2008-12-11 20:23 ` Karl Fogel
2008-12-17 22:59 ` Karl Fogel
2008-12-18 8:00 ` Tassilo Horn
2008-12-18 16:28 ` Karl Fogel
2008-12-19 8:22 ` Tassilo Horn
2008-12-19 8:29 ` Giorgos Keramidas
2008-12-18 20:26 ` Dan Nicolaescu
2009-01-05 0:00 ` Tom Tromey
2009-01-05 2:14 ` Stefan Monnier
2009-01-05 2:42 ` Tom Tromey
2009-01-05 4:04 ` Stefan Monnier
2009-01-06 0:01 ` Richard M Stallman
-- strict thread matches above, loose matches on Subject: below --
2008-12-08 16:32 Karl Fogel
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.