|
osdir.com mailing list archive F.A.Q. -since 2001! |
|
|
|
Subject: bzr 1.17rc1 released! - msg#00362List: bazaar
by Date: Prev Next Date Index by Thread: Prev Next Thread Index
Bazaar continues to blaze a straight and shining path to the 2.0 release and
the elevation of the ``2a`` beta format to the full glory of "supported and stable". Highlights in this release include greatly reduced memory consumption during commits, faster ``ls``, faster ``annotate``, faster network operations if you're specifying a revision number and the final destruction of those annoying progress bar artifacts. The Bazaar team is happy to announce availability of a new release of the bzr adaptive version control system. Bazaar is part of the GNU system <http://gnu.org/>. Thanks to everyone who contributed patches, suggestions, and feedback. Bazaar is now available for download from http://bazaar-vcs.org/Download as a source tarball; packages for various systems will be available soon. Compatibility Breaks ******************** * ``bzr register-branch`` from the Launchpad plugin now refers to "project" instead of "product" which is the correct Launchpad terminology. The --product option is deprecated and users should switch to using --project. (Neil Martinsen-Burrell, #238764) New Features ************ * ``bzr push`` now aborts if uncommitted changes (including pending merges) are present in the working tree (if one is present) and no revision is speified. The configuration option ``push_strict`` can be used to set the default for this behavior. (Vincent Ladeuil, #284038, #322808, #65286) * ``bzr revno`` and ``bzr revision-info`` now have a ``--tree`` option to show revision info for the working tree instead of the branch. (Matthew Fuller, John Arbash Meinel) * ``bzr send`` now aborts if uncommitted changes (including pending merges) are present in the working tree and no revision is specified. The configuration option ``send_strict`` can be used to set the default for this behavior. (Vincent Ladeuil, #206577) Bug Fixes ********* * Accept uppercase "Y/N" to prompts such as from break lock. (#335182, Tim Powell, Martin Pool) * Add documentation about diverged branches and how to fix them in the centralized workflow with local commits. Mention ``bzr help diverged-branches`` when a push fails because the branches have diverged. (Neil Martinsen-Burrell, #269477) * Annotate would sometimes 'latch on' to trivial lines, causing important lines to be incorrectly annotated. (John Arbash Meinel, #387952) * Automatic format upgrades triggered by default stacking policies on a 1.16rc1 (or later) smart server work again. (Andrew Bennetts, #388675) * Avoid progress bar artifacts being left behind on the screen. (Martin Pool, #321935) * Better message in ``bzr split`` error suggesting a rich root format. (Neil Martinsen-Burrell, #220067) * ``Branch.set_append_revisions_only`` now works with branches on a smart server. (Andrew Bennetts, #365865) * By default, ``bzr branch`` will fail if the target directory exists, but does not already have a control directory. The flag ``--use-existing-dir`` will allow operation to proceed. (Alexander Belchenko, #307554) * ``bzr ls DIR --from-root`` now shows only things in DIR, not everything. (Ian Clatworthy) * Fetch between repositories does not error if they have inconsistent data that should be irrelevant to the fetch operation. (Aaron Bentley) * Fix ``AttributeError`` exception when reconfiguring lightweight checkout of a remote repository. (Jelmer Vernooij, #332194) * Fix bug in decoding v3 smart server messages when receiving multiple lots of excess bytes after an end-of-message. (Andrew Bennetts) * Force deletion of readonly files during merge, update and other tree transforms. (Craig Hewetson, Martin Pool, #218206) * Force socket shutdown in threaded http test servers to avoid client hangs (pycurl). (Vincent Ladeuil, #383920). * ``LRUCache`` will maintain the linked list pointers even if a nodes cleanup function raises an exception. (John Arbash Meinel, #396838) * Progress bars are now suppressed again when the environment variable ``BZR_PROGRESS_BAR`` is set to ``none``. (Martin Pool, #339385) * Reduced memory consumption during ``bzr commit`` of large files. For pre 2a formats, should be down to ~3x the size of a file. For ``--2a`` format repositories, it is down to the size of the file content plus the size of the compressed text. Related to bug #109114. (John Arbash Meinel) * Set hidden attribute on .bzr directory below unicode path should never fail with error. The operation should succeed even if bzr unable to set the attribute. (Alexander Belchenko, related to bug #335362). * Stacking will no longer accept requests to stack on the same branch/repository. Existing branches that incorrectly reference the same repository in a stacking configuration will now raise UnstackableLocationError when the branch is opened. This can be fixed by removing the stacking location inside ``.bzr/branch``. (Robert Collins, #376243) * The ``log+`` decorator, useful in debugging or profiling, could cause "AttributeError: 'list' object has no attribute 'next'". This is now fixed. The log decorator no longer shows the elapsed time or transfer rate because they're available in the log prefixes and the transport activity display respectively. (Martin Pool, #340347) * Unshelve works correctly when multiple zero-length files are present on the shelf. (Aaron Bentley, #363444) * Progress bars no longer show the network transport scheme or direction. (Martin Pool) * launchpad-login now respects the 'verbose' option. (Jonathan Lange, #217031) Internals ********* * ``bzrlib.user_encoding`` is now officially deprecated. It is not possible to write a deprecation wrapper, but the variable will be removed in the near future. Use ``bzrlib.osutils.get_user_encoding()`` instead. (Alexander Belchenko) * Command lookup has had hooks added. ``bzrlib.Command.hooks`` has three new hook points: ``get_command``, ``get_missing_command`` and ``list_commands``, which allow just-in-time command name provision rather than requiring all command names be known a-priori. (Robert Collins) * ``get_app_path`` from win32utils.py now supports REG_EXPAND_SZ data type and can read path to wordpad.exe. (Alexander Belchenko, #392046) * ``graph.KnownGraph`` has been added. This is a class that can give answers to ``heads()`` very quickly. However, it has the assumption that the whole graph has already been loaded. This is true during ``annotate`` so it is used there with good success (as much as 2x faster for files with long ancestry and 'cherrypicked' changes.) (John Arbash Meinel, Vincent Ladeuil) * OS file locks are now taken out using ``CreateFile`` rather than ``LockFileEx`` on Windows. The locking remains exclusive with ``LockFileEx`` but now it also works on older versions of Windows (such as Win98). (Martin <gzlist>) * pack <=> pack fetching is now done via a ``PackStreamSource`` rather than the ``Packer`` code. The user visible change is that we now properly fetch the minimum number of texts for non-smart fetching. (John Arbash Meinel) * ``VersionedFiles._add_text`` is a new api that lets us insert text into the repository as a single string, rather than a list of lines. This can improve memory overhead and performance of committing large files. (Currently a private api, used only by commit). (John Arbash Meinel) Improvements ************ * ``bzr annotate`` can now be significantly faster. The time for ``bzr annotate NEWS`` is down to 7s from 22s in 1.16. Files with long histories and lots of 'duplicate insertions' will be improved more than others. (John Arbash Meinel, Vincent Ladeuil) * ``bzr ls`` is now faster. On OpenOffice.org, the time drops from 2.4 to 1.1 seconds. The improvement for ``bzr ls -r-1`` is more substantial dropping from 54.3 to 1.1 seconds. (Ian Clatworthy) * Improve "Path(s) are not versioned" error reporting for some commands. (Benoît PIERRE) * Initial commit performance in ``--2a`` repositories has been improved by making it cheaper to build the initial CHKMap. (John Arbash Meinel) * Resolving a revno to a revision id on a branch accessed via ``bzr://`` or ``bzr+ssh://`` is now much faster and involves no VFS operations. This speeds up commands like ``bzr pull -r 123``. (Andrew Bennetts) * ``revision-info`` now properly aligns the revnos/revids in the output and doesn't traceback when given revisions not in the current branch. Performance is also significantly improved when requesting multiple revs at once. (Matthew Fuller, John Arbash Meinel) * Tildes are no longer escaped by Transports. (Andy Kilner) Documentation ************* * Avoid bad text wrapping in generated documentation. Slightly better formatting in the user reference. (Martin Pool, #249908) * Minor clarifications to the help for End-Of-Line conversions. (Ian Clatworthy) API Changes *********** * Removed overspecific error class ``InvalidProgressBarType``. (Martin Pool) * The method ``ProgressView._show_transport_activity`` is now ``show_transport_activity`` because it's part of the contract between this class and the UI. (Martin Pool)
Thread at a glance:
Previous Message by Date:Re: RFC/discuss get_missing_command fires too often2009/7/13 Robert Collins <robertc@xxxxxxxxxxxxxxxxx>: > On Mon, 2009-07-13 at 11:39 +1000, Martin Pool wrote: >> >> > I think it would be better to modify the default command >> > suppliers (plugin_cmds and the buitins scanner) inside bzrlib to >> instead >> > note whether the particular registration has requested decoration at >> > command object creation time. As our built in suppliers are ordered >> and >> > the first things registered we can reasonably expect this to be >> robust. >> >> What do you mean by that? > > I'll put a patch together this week to improve the get_missing_command > docs. > > In the above paragraph I mean that _get_plugin_command should check > whether an existing command had been found (command lookup works as a > pipeline). If one was found and there is a registered plugin command of > the same name, it should *at that point* perform the policy check for > 'are we overriding' - rather than doing it at the 'register_command' > step. I wonder if it should pass the previously-found, typically builtin command to the constructor of the plugin command, so that it can either complain or decorate it. That would be a way around the problem of plugins, which often want to do decoration, forcing the builtin commands to be loaded. Or maybe there's already some solution for this? -- Martin <http://launchpad.net/~mbp/> Next Message by Date:Re: RFC/discuss get_missing_command fires too oftenOn Mon, 2009-07-13 at 11:59 +1000, Martin Pool wrote: > > In the above paragraph I mean that _get_plugin_command should check > > whether an existing command had been found (command lookup works as a > > pipeline). If one was found and there is a registered plugin command of > > the same name, it should *at that point* perform the policy check for > > 'are we overriding' - rather than doing it at the 'register_command' > > step. > > I wonder if it should pass the previously-found, typically builtin > command to the constructor of the plugin command, so that it can > either complain or decorate it. That would be a way around the > problem of plugins, which often want to do decoration, forcing the > builtin commands to be loaded. Or maybe there's already some solution > for this? Thats what happens now, I think. Maybe I don't get quite what you mean. There are two separate things that happen. One thing is that _get_bzr_command, which is called by the get_command_hook, only knows how to scan an entire module (bzrlib.builtins), rather than just doing e.g. getattr(bzrlib.builtins, 'cmd_%s' % name, None) to get the command class. One of the problems with trying to change this is how way aliases are defined and maintained - we can't predict what command we need until we introspect potentially all the builtins. The other thing, is that get_cmd_object, which invokes the get_command hook, calls all the hook callbacks in series, piping the output of the first into the second, and so on. So if we change the _get_bzr_command to do less work, the interface doesn't need to change - we'd still ask _get_bzr_command for the specific command, but that could potentially load a single command, and fail cleanly in that commands absence. -Rob signature.asc Description: This is a digitally signed message part Previous Message by Thread:RFC/discuss get_missing_command fires too oftenCommands.hooks['get_missing_command'] currently fires whenever a command is not found. However some parts of the command infrastructure itself would benefit by being able to probe without triggering a missing-lookup. In particular things that want to generate an error at registration time if a given name is already registered. Now, we want to be more lazy about work performed during startup, so checking that nothing provides a given name isn't really all that desirable. I think it would be better to modify the default command suppliers (plugin_cmds and the buitins scanner) inside bzrlib to instead note whether the particular registration has requested decoration at command object creation time. As our built in suppliers are ordered and the first things registered we can reasonably expect this to be robust. This would: - move errors about duplicate command names from startup to execution - notable 'bzr FOO' where FOO is duplicated, and 'bzr help commands' or 'bzr help FOO'. I don't think we gain a lot of protection with the current system, but perhaps it is worth keeping? If its worth keeping, then I propose to tweak the get_cmd_object function to support a parameter controlling whether get_missing_command fires. Thoughts? -Rob signature.asc Description: This is a digitally signed message part Next Message by Thread:Re: bzr 1.17rc1 released!Hiya Anybody have any idea what the status of the nested trees feature is? Will that be in 1.17 or is it way off? Thanks Patrick On Mon, Jul 13, 2009 at 14:11, Jonathan Lange<jml@xxxxxxxxx> wrote: > Bazaar continues to blaze a straight and shining path to the 2.0 release and > the elevation of the ``2a`` beta format to the full glory of "supported and > stable". > > Highlights in this release include greatly reduced memory consumption during > commits, faster ``ls``, faster ``annotate``, faster network operations if > you're specifying a revision number and the final destruction of those > annoying progress bar artifacts. > > The Bazaar team is happy to announce availability of a new release of > the bzr adaptive version control system. Bazaar is part of the GNU > system <http://gnu.org/>. > > Thanks to everyone who contributed patches, suggestions, and feedback. > > Bazaar is now available for download from > http://bazaar-vcs.org/Download as a source tarball; packages for > various systems will be available soon. >
blog comments powered by Disqus
|
|