From bialix at ukr.net Fri Jul 1 06:42:59 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 01 Jul 2011 09:42:59 +0300 Subject: Anybody seen problems with TortoiseBzr in the latest 2.4 beta? In-Reply-To: References: <4E0CC1C2.9060905@ukr.net> Message-ID: <4E0D6C73.9070109@ukr.net> 01.07.2011 0:22, Patrick van der Velde ?????: > Hiya > > The log says: > > Fri 2011-07-01 09:22:02 +1200 > 0.047 bazaar version: 2.4b4 > 0.048 bzr arguments: [u'qversion'] > 0.073 looking for plugins in > C:/Users/Petrik/AppData/Roaming/bazaar/2.0/plugins > 0.074 looking for plugins in C:/Program Files (x86)/Bazaar/plugins > 0.111 encoding stdout as sys.stdout encoding 'cp850' > > Anything else you want? I assume it crashed. > > Thanks > > Patrick > > On Fri, Jul 1, 2011 at 06:34, Alexander Belchenko > wrote: > > 28.06.2011 2:35, Patrick van der Velde ?????: > > Hiya > > > > The error dialog is the standard Windows 7 crash dialog. It > basically > > says: "The application has stopped responding. Do you want to report > > this to Microsoft". There is no useful information in the dialog > > unfortunately. > > > > I can get a screenshot if you think that would help. But I > suspect it > > won't tell you anything useful. > > Could you please run `bzr qversion` and if it'll crash show the tail > of .bzr.log corresponding to that crash? > > From bialix at ukr.net Fri Jul 1 06:57:22 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 01 Jul 2011 09:57:22 +0300 Subject: Anybody seen problems with TortoiseBzr in the latest 2.4 beta? In-Reply-To: References: <4E0CC1C2.9060905@ukr.net> Message-ID: <4E0D6FD2.7040509@ukr.net> I can't reproduce your problem on my Windows XP. Maybe you need to re-install Bazaar, I have no good ideas, sorry. Can you try to install 2.4b2 again, check it works and then install 2.4b4? Have you installed 2.4b4 over 2.4b2 or you unistalled the old version before? 01.07.2011 0:22, Patrick van der Velde ?????: > Hiya > > The log says: > > Fri 2011-07-01 09:22:02 +1200 > 0.047 bazaar version: 2.4b4 > 0.048 bzr arguments: [u'qversion'] > 0.073 looking for plugins in > C:/Users/Petrik/AppData/Roaming/bazaar/2.0/plugins > 0.074 looking for plugins in C:/Program Files (x86)/Bazaar/plugins > 0.111 encoding stdout as sys.stdout encoding 'cp850' > > Anything else you want? > > Thanks > > Patrick > > On Fri, Jul 1, 2011 at 06:34, Alexander Belchenko > wrote: > > 28.06.2011 2:35, Patrick van der Velde ?????: > > Hiya > > > > The error dialog is the standard Windows 7 crash dialog. It > basically > > says: "The application has stopped responding. Do you want to report > > this to Microsoft". There is no useful information in the dialog > > unfortunately. > > > > I can get a screenshot if you think that would help. But I > suspect it > > won't tell you anything useful. > > Could you please run `bzr qversion` and if it'll crash show the tail > of .bzr.log corresponding to that crash? > > From petrikvandervelde at gmail.com Fri Jul 1 10:56:58 2011 From: petrikvandervelde at gmail.com (Patrick van der Velde) Date: Fri, 1 Jul 2011 22:56:58 +1200 Subject: Anybody seen problems with TortoiseBzr in the latest 2.4 beta? In-Reply-To: <4E0D6FD2.7040509@ukr.net> References: <4E0CC1C2.9060905@ukr.net> <4E0D6FD2.7040509@ukr.net> Message-ID: Alright will do. On Fri, Jul 1, 2011 at 18:57, Alexander Belchenko wrote: > I can't reproduce your problem on my Windows XP. > Maybe you need to re-install Bazaar, I have no good ideas, sorry. > Can you try to install 2.4b2 again, check it works and then install > 2.4b4? Have you installed 2.4b4 over 2.4b2 or you unistalled the old > version before? > > 01.07.2011 0:22, Patrick van der Velde ?????: > > Hiya > > > > The log says: > > > > Fri 2011-07-01 09:22:02 +1200 > > 0.047 bazaar version: 2.4b4 > > 0.048 bzr arguments: [u'qversion'] > > 0.073 looking for plugins in > > C:/Users/Petrik/AppData/Roaming/bazaar/2.0/plugins > > 0.074 looking for plugins in C:/Program Files (x86)/Bazaar/plugins > > 0.111 encoding stdout as sys.stdout encoding 'cp850' > > > > Anything else you want? > > > > Thanks > > > > Patrick > > > > On Fri, Jul 1, 2011 at 06:34, Alexander Belchenko > > wrote: > > > > 28.06.2011 2:35, Patrick van der Velde ?????: > > > Hiya > > > > > > The error dialog is the standard Windows 7 crash dialog. It > > basically > > > says: "The application has stopped responding. Do you want to > report > > > this to Microsoft". There is no useful information in the dialog > > > unfortunately. > > > > > > I can get a screenshot if you think that would help. But I > > suspect it > > > won't tell you anything useful. > > > > Could you please run `bzr qversion` and if it'll crash show the tail > > of .bzr.log corresponding to that crash? > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lekktu at gmail.com Fri Jul 1 14:40:49 2011 From: lekktu at gmail.com (Juanma Barranquero) Date: Fri, 1 Jul 2011 16:40:49 +0200 Subject: changelog_merge plugin Message-ID: The announcement for 2.4b1 included this: New Features ************ * Added ``changelog_merge`` plugin for merging changes to ``Changelog`` files in GNU format. See ``bzr help changelog_merge`` for details. (Andrew Bennetts) and the Launchpad page for changelog_merge (https://launchpad.net/bzr-changelog-merge) says: The changelog_merge plugin is included in bzr 2.4. If you have an earlier version you can install it with: bzr branch lp:bzr-changelog-merge ~/.bazaar/plugins/changelog_merge However, at least on Windows changelog_merge is nowhere in sight: C:\> bzr version Bazaar (bzr) 2.4b4 Python interpreter: C:\program files\bazaar\python26.dll 2.6.6 Python standard library: C:\program files\bazaar\lib\library.zip Platform: Windows-7-6.1.7601-SP1 bzrlib: C:\program files\bazaar\lib\library.zip\bzrlib Bazaar configuration: C:\Users\Juanma\AppData\Roaming\bazaar\2.0 Bazaar log file: C:\Users\Juanma\AppData\Roaming\bazaar\2.0\.bzr.log C:\> bzr plugins bzrtools 2.4.0 Various useful commands for working with bzr. colo 0.3.0dev Work with colocated branches using current technology. explorer 1.1.3 Version Control for Human Beings. fastimport 0.11.0dev FastImport Plugin launchpad 2.4b4 Launchpad.net integration plugin for Bazaar. loom 2.2.1dev Loom is a bzr plugin which adds new commands to manage a loom of patches. netrc_credential_store 2.4b4 Use ~/.netrc as a credential store for authentication.conf. news_merge 2.4b4 Merge hook for bzr's NEWS file. pipeline 1.1.0 Manage a series of branches as a pipeline. qbzr 0.21b1 QBzr - Qt-based frontend for Bazaar rewrite 0.7.0dev Rebase support. svn 1.1.0dev Support for Subversion branches upload 1.0.1dev Upload a working tree, incrementally. xmloutput 0.8.7 This plugin adds an option (--xml) to log and provides an xml version of some builtin commands. From mbp at canonical.com Fri Jul 1 16:34:17 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 1 Jul 2011 17:34:17 +0100 Subject: changelog_merge plugin In-Reply-To: References: Message-ID: That's strange; it comes up in 'bzr plugins -v' on unix. Martin From v.ladeuil+lp at free.fr Fri Jul 1 17:02:50 2011 From: v.ladeuil+lp at free.fr (Vincent Ladeuil) Date: Fri, 01 Jul 2011 18:02:50 +0100 Subject: changelog_merge plugin In-Reply-To: (Juanma Barranquero's message of "Fri, 1 Jul 2011 16:40:49 +0200") References: Message-ID: <87mxgy0w91.fsf@free.fr> That's probably a bug in the windows installer (may be because py2exe fails to detect the plugin as it's not loaded by default ?). Vincent From lekktu at gmail.com Fri Jul 1 17:28:27 2011 From: lekktu at gmail.com (Juanma Barranquero) Date: Fri, 1 Jul 2011 19:28:27 +0200 Subject: changelog_merge plugin In-Reply-To: <87mxgy0w91.fsf@free.fr> References: <87mxgy0w91.fsf@free.fr> Message-ID: On Fri, Jul 1, 2011 at 19:02, Vincent Ladeuil wrote: > That's probably a bug in the windows installer (may be because py2exe > fails to detect the plugin as it's not loaded by default ?). Perhaps. I've checked with 2.4b2 and it wasn't there either (I don't have 2.4b1 to check). Weird that nobody noticed until now. ? ? Juanma From bialix at ukr.net Fri Jul 1 18:00:42 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 01 Jul 2011 21:00:42 +0300 Subject: changelog_merge plugin In-Reply-To: <87mxgy0w91.fsf@free.fr> References: <87mxgy0w91.fsf@free.fr> Message-ID: <4E0E0B4A.9070704@ukr.net> 01.07.2011 20:02, Vincent Ladeuil ?????: > That's probably a bug in the windows installer (may be because py2exe > fails to detect the plugin as it's not loaded by default ?). It just hasn't been packaged into installer, because maintainers of the installer has missed new thing. From bialix at ukr.net Fri Jul 1 18:11:29 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 01 Jul 2011 21:11:29 +0300 Subject: changelog_merge plugin In-Reply-To: References: Message-ID: <4E0E0DD1.5080508@ukr.net> https://bugs.launchpad.net/bzr-windows-installers/+bug/804453 From john at arbash-meinel.com Fri Jul 1 18:23:49 2011 From: john at arbash-meinel.com (John Meinel) Date: Fri, 1 Jul 2011 20:23:49 +0200 Subject: changelog_merge plugin In-Reply-To: <87mxgy0w91.fsf@free.fr> References: <87mxgy0w91.fsf@free.fr> Message-ID: I think plugins have to be explicitly listed in the installer script. We prob just need to add it. John =:-> On Jul 1, 2011 6:03 PM, "Vincent Ladeuil" wrote: > That's probably a bug in the windows installer (may be because py2exe > fails to detect the plugin as it's not loaded by default ?). > > Vincent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben+bazaar at benfinney.id.au Mon Jul 4 01:44:26 2011 From: ben+bazaar at benfinney.id.au (Ben Finney) Date: Mon, 04 Jul 2011 11:44:26 +1000 Subject: Crash in =?utf-8?B?4oCYYnpyLXN2buKAmSw=?= but works with Subversion Message-ID: <87ei26kef9.fsf@benfinney.id.au> Howdy all, As discussed in IRC, a Subversion repository that was working fine a few days ago is now causing ?bzr-svn? to crash. ===== $ svn info svn+ssh://subversion/home/svn/empowered/trunk/ Path: trunk URL: svn+ssh://subversion/home/svn/empowered/trunk Repository Root: svn+ssh://subversion/home/svn/empowered Repository UUID: 58802371-0b19-4c69-acb7-7d0c5b422186 Revision: 3355 Node Kind: directory Last Changed Author: build Last Changed Rev: 3355 Last Changed Date: 2011-07-04 11:10:07 +1000 (Mon, 04 Jul 2011) $ bzr info svn+ssh://subversion/home/svn/empowered/trunk/ Repository branch (format: subversion) Location: shared repository: svn+ssh://subversion/home/svn/empowered/trunk/ repository branch: svn+ssh://subversion/home/svn/empowered/trunk/ $ bzr branch --bind svn+ssh://subversion/home/svn/empowered/trunk/ empowered/ bzr: ERROR: exceptions.StopIteration: Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 912, in exception_to_return_code return the_callable(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1112, in run_bzr ret = run(*run_argv) File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 690, in run_argv_aliases return self.run(**all_cmd_args) File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 705, in run return self._operation.run_simple(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in run_simple self.cleanups, self.func, *args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups result = func(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 1246, in run source_branch=br_from) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/remote.py", line 112, in sprout return super(SvnRemoteAccess, self).sprout(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 1257, in sprout result_repo.fetch(source_repository, revision_id=revision_id) File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 1740, in fetch find_ghosts=find_ghosts, fetch_spec=fetch_spec) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 1374, in fetch pack_hint = self._fetch_revisions(needed, pb) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 1301, in _fetch_revisions use_replay=self._use_replay) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 1271, in _fetch_revisions_nochunks parent_revmeta) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 1213, in _fetch_revision_switch report_inventory_contents(reporter, parent_revnum, start_empty) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/errors.py", line 141, in convert return unbound(*args, **kwargs) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 959, in report_inventory_contents reporter.finish() File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/transport.py", line 243, in update if self._last_progress > progress: File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/transport.py", line 243, in update if self._last_progress > progress: File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 325, in open_directory return self._open_directory(path, base_revnum) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 505, in _open_directory base_file_id = self.editor._get_old_id(self.old_id, path) File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 805, in _get_old_id return ret.next()[1] StopIteration bzr 2.2.1 on python 2.6.6 (Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick) arguments: ['/usr/bin/bzr', 'branch', '--bind', 'svn+ssh://subversion/home/svn/empowered/trunk/', 'empowered/'] encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_AU.UTF-8' plugins: bash_completion /usr/lib/python2.6/dist-packages/bzrlib/plugins/bash_completion [2.2.1] bzrtools /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzrtools [2.2.0] git /usr/lib/python2.6/dist-packages/bzrlib/plugins/git [0.5.2] hg /usr/lib/python2.6/dist-packages/bzrlib/plugins/hg [0.2.0dev] launchpad /usr/lib/python2.6/dist-packages/bzrlib/plugins/launchpad [2.2.1] netrc_credential_store /usr/lib/python2.6/dist-packages/bzrlib/plugins/netrc_credential_store [2.2.1] news_merge /usr/lib/python2.6/dist-packages/bzrlib/plugins/news_merge [2.2.1] pipeline /usr/lib/python2.6/dist-packages/bzrlib/plugins/pipeline [unknown] svn /usr/lib/python2.6/dist-packages/bzrlib/plugins/svn [1.0.3] *** Bazaar has encountered an internal error. This probably indicates a bug in Bazaar. You can help us fix it by filing a bug report at https://bugs.launchpad.net/bzr/+filebug including this traceback and a description of the problem. ===== Usual disclaimer, I'd love to post this as a bug report but don't have nor want a set of Launchpad credentials. I'm happy to answer more questions in order to get this fixed. -- \ ?The best way to get information on Usenet is not to ask a | `\ question, but to post the wrong information.? ?Aahz | _o__) | Ben Finney From ben+bazaar at benfinney.id.au Mon Jul 4 02:01:08 2011 From: ben+bazaar at benfinney.id.au (Ben Finney) Date: Mon, 04 Jul 2011 12:01:08 +1000 Subject: Crash in =?utf-8?B?4oCYYnpyLXN2buKAmSw=?= but works with Subversion References: <87ei26kef9.fsf@benfinney.id.au> Message-ID: <87aacukdnf.fsf@benfinney.id.au> Ben Finney writes: > Howdy all, > > As discussed in IRC, a Subversion repository that was working fine a few > days ago is now causing ?bzr-svn? to crash. Other, possibly relevant, information: ===== $ bzr version Bazaar (bzr) 2.2.1 Python interpreter: /usr/bin/python 2.6.6 Python standard library: /usr/lib/python2.6 Platform: Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick bzrlib: /usr/lib/python2.6/dist-packages/bzrlib Bazaar configuration: /home/benf/.bazaar Bazaar log file: /home/benf/.bzr.log ? $ bzr svn-import svn+ssh://subversion/home/svn/empowered/ empowered.bzr/ Using repository layout: trunk0 inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('547943 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('550491 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('550514 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) Use 'bzr checkout' to create a working tree in the newly created branches. ===== -- \ ?Prediction is very difficult, especially of the future.? | `\ ?Niels Bohr | _o__) | Ben Finney From john at arbash-meinel.com Mon Jul 4 07:18:19 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 04 Jul 2011 09:18:19 +0200 Subject: Crash in =?UTF-8?B?4oCYYnpyLXN2buKAmSwgYnV0IHdvcmtzIHdpdGggUw==?= =?UTF-8?B?dWJ2ZXJzaW9u?= In-Reply-To: <87aacukdnf.fsf@benfinney.id.au> References: <87ei26kef9.fsf@benfinney.id.au> <87aacukdnf.fsf@benfinney.id.au> Message-ID: <4E11693B.30807@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/4/2011 4:01 AM, Ben Finney wrote: > $ bzr version > Bazaar (bzr) 2.2.1 > Python interpreter: /usr/bin/python 2.6.6 > Python standard library: /usr/lib/python2.6 > Platform: Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick > bzrlib: /usr/lib/python2.6/dist-packages/bzrlib > Bazaar configuration: /home/benf/.bazaar > Bazaar log file: /home/benf/.bzr.log > ? > > $ bzr svn-import svn+ssh://subversion/home/svn/empowered/ empowered.bzr/ ... I filed it for you: https://bugs.launchpad.net/bzr-svn/+bug/805343 John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4RaToACgkQJdeBCYSNAAPM4gCgj12lCm2eBKOhEa2xMxz8cOQq F4MAoJ80NLwygvZYGYQjh55PTv8eLzuF =S+T8 -----END PGP SIGNATURE----- From loldrup at gmail.com Mon Jul 4 15:30:50 2011 From: loldrup at gmail.com (Jon Loldrup) Date: Mon, 4 Jul 2011 17:30:50 +0200 Subject: unsubscribe Message-ID: On 4 July 2011 14:00, wrote: > Send bazaar mailing list submissions to > bazaar at lists.canonical.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ubuntu.com/mailman/listinfo/bazaar > or, via email, send a message with subject or body 'help' to > bazaar-request at lists.canonical.com > > You can reach the person managing the list at > bazaar-owner at lists.canonical.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bazaar digest..." > > > Today's Topics: > > 1. Crash in ?bzr-svn?, but works with Subversion (Ben Finney) > 2. Re: Crash in ?bzr-svn?, but works with Subversion (Ben Finney) > 3. Re: Crash in ?bzr-svn?, but works with Subversion > (John Arbash Meinel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 04 Jul 2011 11:44:26 +1000 > From: Ben Finney > To: bazaar at lists.canonical.com > Subject: Crash in ?bzr-svn?, but works with Subversion > Message-ID: <87ei26kef9.fsf at benfinney.id.au> > Content-Type: text/plain; charset=utf-8 > > Howdy all, > > As discussed in IRC, a Subversion repository that was working fine a few > days ago is now causing ?bzr-svn? to crash. > > ===== > $ svn info svn+ssh://subversion/home/svn/empowered/trunk/ > Path: trunk > URL: svn+ssh://subversion/home/svn/empowered/trunk > Repository Root: svn+ssh://subversion/home/svn/empowered > Repository UUID: 58802371-0b19-4c69-acb7-7d0c5b422186 > Revision: 3355 > Node Kind: directory > Last Changed Author: build > Last Changed Rev: 3355 > Last Changed Date: 2011-07-04 11:10:07 +1000 (Mon, 04 Jul 2011) > > $ bzr info svn+ssh://subversion/home/svn/empowered/trunk/ > Repository branch (format: subversion) > Location: > shared repository: svn+ssh://subversion/home/svn/empowered/trunk/ > repository branch: svn+ssh://subversion/home/svn/empowered/trunk/ > > $ bzr branch --bind svn+ssh://subversion/home/svn/empowered/trunk/ > empowered/ > bzr: ERROR: exceptions.StopIteration: > > Traceback (most recent call last): > File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 912, in > exception_to_return_code > return the_callable(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1112, in > run_bzr > ret = run(*run_argv) > File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 690, in > run_argv_aliases > return self.run(**all_cmd_args) > File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 705, in > run > return self._operation.run_simple(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in > run_simple > self.cleanups, self.func, *args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in > _do_with_cleanups > result = func(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 1246, in > run > source_branch=br_from) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/remote.py", line > 112, in sprout > return super(SvnRemoteAccess, self).sprout(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/bzrdir.py", line 1257, in > sprout > result_repo.fetch(source_repository, revision_id=revision_id) > File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 1740, > in fetch > find_ghosts=find_ghosts, fetch_spec=fetch_spec) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 1374, in fetch > pack_hint = self._fetch_revisions(needed, pb) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 1301, in _fetch_revisions > use_replay=self._use_replay) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 1271, in _fetch_revisions_nochunks > parent_revmeta) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 1213, in _fetch_revision_switch > report_inventory_contents(reporter, parent_revnum, start_empty) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/errors.py", line > 141, in convert > return unbound(*args, **kwargs) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 959, in report_inventory_contents > reporter.finish() > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/transport.py", > line 243, in update > if self._last_progress > progress: > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/transport.py", > line 243, in update > if self._last_progress > progress: > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 325, in open_directory > return self._open_directory(path, base_revnum) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 505, in _open_directory > base_file_id = self.editor._get_old_id(self.old_id, path) > File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line > 805, in _get_old_id > return ret.next()[1] > StopIteration > > bzr 2.2.1 on python 2.6.6 > (Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick) > arguments: ['/usr/bin/bzr', 'branch', '--bind', > 'svn+ssh://subversion/home/svn/empowered/trunk/', 'empowered/'] > encoding: 'UTF-8', fsenc: 'UTF-8', lang: 'en_AU.UTF-8' > plugins: > bash_completion > /usr/lib/python2.6/dist-packages/bzrlib/plugins/bash_completion [2.2.1] > bzrtools > /usr/lib/python2.6/dist-packages/bzrlib/plugins/bzrtools [2.2.0] > git /usr/lib/python2.6/dist-packages/bzrlib/plugins/git > [0.5.2] > hg /usr/lib/python2.6/dist-packages/bzrlib/plugins/hg > [0.2.0dev] > launchpad > /usr/lib/python2.6/dist-packages/bzrlib/plugins/launchpad [2.2.1] > netrc_credential_store > /usr/lib/python2.6/dist-packages/bzrlib/plugins/netrc_credential_store > [2.2.1] > news_merge > /usr/lib/python2.6/dist-packages/bzrlib/plugins/news_merge [2.2.1] > pipeline > /usr/lib/python2.6/dist-packages/bzrlib/plugins/pipeline [unknown] > svn /usr/lib/python2.6/dist-packages/bzrlib/plugins/svn > [1.0.3] > > *** Bazaar has encountered an internal error. This probably indicates a > bug in Bazaar. You can help us fix it by filing a bug report at > https://bugs.launchpad.net/bzr/+filebug > including this traceback and a description of the problem. > ===== > > Usual disclaimer, I'd love to post this as a bug report but don't have > nor want a set of Launchpad credentials. I'm happy to answer more > questions in order to get this fixed. > > -- > \ ?The best way to get information on Usenet is not to ask a | > `\ question, but to post the wrong information.? ?Aahz | > _o__) | > Ben Finney > > > > > ------------------------------ > > Message: 2 > Date: Mon, 04 Jul 2011 12:01:08 +1000 > From: Ben Finney > To: bazaar at lists.canonical.com > Subject: Re: Crash in ?bzr-svn?, but works with Subversion > Message-ID: <87aacukdnf.fsf at benfinney.id.au> > Content-Type: text/plain; charset=utf-8 > > Ben Finney writes: > > > Howdy all, > > > > As discussed in IRC, a Subversion repository that was working fine a few > > days ago is now causing ?bzr-svn? to crash. > > Other, possibly relevant, information: > > ===== > $ bzr version > Bazaar (bzr) 2.2.1 > Python interpreter: /usr/bin/python 2.6.6 > Python standard library: /usr/lib/python2.6 > Platform: Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick > bzrlib: /usr/lib/python2.6/dist-packages/bzrlib > Bazaar configuration: /home/benf/.bazaar > Bazaar log file: /home/benf/.bzr.log > ? > > $ bzr svn-import svn+ssh://subversion/home/svn/empowered/ empowered.bzr/ > Using repository layout: trunk0 > inconsistent details in skipped record: > ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 > 0', ((),)) ('547943 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) > inconsistent details in skipped record: > ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 > 0', ((),)) ('550491 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) > inconsistent details in skipped record: > ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 > 0', ((),)) ('550514 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', > 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) > Use 'bzr checkout' to create a working tree in the newly created branches. > > ===== > > -- > \ ?Prediction is very difficult, especially of the future.? | > `\ ?Niels Bohr | > _o__) | > Ben Finney > > > > > ------------------------------ > > Message: 3 > Date: Mon, 04 Jul 2011 09:18:19 +0200 > From: John Arbash Meinel > To: Ben Finney > Cc: bazaar at lists.canonical.com > Subject: Re: Crash in ?bzr-svn?, but works with Subversion > Message-ID: <4E11693B.30807 at arbash-meinel.com> > Content-Type: text/plain; charset=UTF-8 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/4/2011 4:01 AM, Ben Finney wrote: > > $ bzr version > > Bazaar (bzr) 2.2.1 > > Python interpreter: /usr/bin/python 2.6.6 > > Python standard library: /usr/lib/python2.6 > > Platform: Linux-2.6.35-22-server-x86_64-with-Ubuntu-10.10-maverick > > bzrlib: /usr/lib/python2.6/dist-packages/bzrlib > > Bazaar configuration: /home/benf/.bazaar > > Bazaar log file: /home/benf/.bzr.log > > ? > > > > $ bzr svn-import svn+ssh://subversion/home/svn/empowered/ empowered.bzr/ > ... > > I filed it for you: https://bugs.launchpad.net/bzr-svn/+bug/805343 > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4RaToACgkQJdeBCYSNAAPM4gCgj12lCm2eBKOhEa2xMxz8cOQq > F4MAoJ80NLwygvZYGYQjh55PTv8eLzuF > =S+T8 > -----END PGP SIGNATURE----- > > > > ------------------------------ > > -- > bazaar mailing list > bazaar at lists.canonical.com > https://lists.ubuntu.com/mailman/listinfo/bazaar > > > End of bazaar Digest, Vol 77, Issue 3 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.ladeuil+lp at free.fr Tue Jul 5 16:38:30 2011 From: v.ladeuil+lp at free.fr (vila) Date: Tue, 05 Jul 2011 18:38:30 +0200 Subject: root-ids changing for some merges (was Re: [Merge] lp:~abentley/bzr/merge-into-empty into lp:bzr) In-Reply-To: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> (Aaron Bentley's message of "Thu, 09 Jun 2011 19:51:20 -0000") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> Message-ID: >>>>> Aaron Bentley writes: > The code in TreeTransform.fixup_new_roots seemed more suitable > than the code in Merger.fix_root, so I've switched to > fixup_new_roots and deprecated fix_root. > There is some behavioural difference between the > two. fixup_new_roots does not generate a conflict if a new root is > added and the old root is not deleted. It happily merges the > contents of the two roots. In such cases, the new root wins, > whereas fix_root would have the old root win. The drawback that I just realized is that it breaks 'merge -r0..nn ../unrelated-branch' by forcing the new root which in turn trigger a rename for all existing children of the old root (try merging 2.3 into trunk for a reproducing case encountered while fixing bug #805809). It's late here and I haven't a fix so far but I don't think we should release 2.4b5 without fixing this as the consequences sound a bit scary. While this may sound like an unusual use case, it's more than usual for UDD. > Still, the new behaviour is in keeping with Merge's tendency of > letting OTHER win in the case of ambiguity. It shouldn't apply to root-ids but can be special-cased for the empty *branch* which should also cover your case for the empty *tree*. > And reducing duplication between fixup_new_roots and fix_root is > also a win. Vincent From aaron at aaronbentley.com Tue Jul 5 16:57:55 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 05 Jul 2011 12:57:55 -0400 Subject: root-ids changing for some merges (was Re: [Merge] lp:~abentley/bzr/merge-into-empty into lp:bzr) In-Reply-To: References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> Message-ID: <4E134293.1010002@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-05 12:38 PM, vila wrote: > The drawback that I just realized is that it breaks 'merge -r0..nn > ../unrelated-branch' by forcing the new root which in turn trigger a > rename for all existing children of the old root That is the expected behaviour. Could you explain why that is a drawback? > > Still, the new behaviour is in keeping with Merge's tendency of > > letting OTHER win in the case of ambiguity. > > It shouldn't apply to root-ids Why? > but can be special-cased for the empty > *branch* The inputs to a three-way merge are the trees involved, so special-casing based on branch is a surprising idea. What do you have in mind? Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk4TQpMACgkQ0F+nu1YWqI3dxACYyx+dQFKXDf+0a8obTc+zcvZZ XwCeJOLu4at1zycswUsAYVQRvDzdN6U= =zgj+ -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Tue Jul 5 18:48:00 2011 From: v.ladeuil+lp at free.fr (vila) Date: Tue, 05 Jul 2011 20:48:00 +0200 Subject: root-ids changing for some merges In-Reply-To: <4E134293.1010002@aaronbentley.com> (Aaron Bentley's message of "Tue, 05 Jul 2011 12:57:55 -0400") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> Message-ID: >>>>> Aaron Bentley writes: > On 11-07-05 12:38 PM, vila wrote: >> The drawback that I just realized is that it breaks 'merge -r0..nn >> ../unrelated-branch' by forcing the new root which in turn trigger a >> rename for all existing children of the old root > That is the expected behaviour. It wasn't the behaviour *before* your patch, the root-id was preserved and the existing files in THIS weren't renamed. > Could you explain why that is a drawback? Seeing all the files present in the branch before the merge being renamed to the same name is quite surprising. May be my test case is wrong and falsely alarming, yet, it passed on 2.2 and 2.3 but fails on trunk. Did you look at it ? Vincent From aaron at aaronbentley.com Tue Jul 5 23:30:41 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 05 Jul 2011 19:30:41 -0400 Subject: root-ids changing for some merges In-Reply-To: References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> Message-ID: <4E139EA1.2070409@aaronbentley.com> On 05/07/2011 2:48 PM, vila wrote: >>>>>> Aaron Bentley writes: > > > On 11-07-05 12:38 PM, vila wrote: > >> The drawback that I just realized is that it breaks 'merge -r0..nn > >> ../unrelated-branch' by forcing the new root which in turn trigger a > >> rename for all existing children of the old root > > > That is the expected behaviour. > > It wasn't the behaviour *before* your patch, the root-id was preserved > and the existing files in THIS weren't renamed. This is true, but most branches do change behaviour. I pointed this change out when I proposed the merge, so by approving the proposal, Jelmer approved the change in behaviour. What's much more interesting is what behaviour do we want, and why? I felt that since there's a tie to break (a tree can't have two roots), it made a lot of sense to break the tie in favour of OTHER, since that's how merge usually breaks ties. You clearly prefer the old behaviour, so I'd like to know why. > > Could you explain why that is a drawback? > > Seeing all the files present in the branch before the merge being > renamed to the same name is quite surprising. Okay, so there's bad UI consequences. Anything else? > May be my test case is wrong and falsely alarming, yet, it passed on 2.2 > and 2.3 but fails on trunk. Did you look at it ? No. I couldn't parse what you were saying. Aaron From fullermd at over-yonder.net Wed Jul 6 03:56:26 2011 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Tue, 5 Jul 2011 22:56:26 -0500 Subject: root-ids changing for some merges In-Reply-To: <4E139EA1.2070409@aaronbentley.com> References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> Message-ID: <20110706035626.GV89895@over-yonder.net> On Tue, Jul 05, 2011 at 07:30:41PM -0400 I heard the voice of Aaron Bentley, and lo! it spake thus: > > I felt that since there's a tie to break (a tree can't have two > roots), it made a lot of sense to break the tie in favour of OTHER, > since that's how merge usually breaks ties. > > You clearly prefer the old behaviour, so I'd like to know why. For me, that's always wrong, because I use -r0..-1 merges all the time to bring in shared bits of code. I pretty well always want to discard OTHER's root wholesale, and just take [usually not even all of] the files. Generally, the case is a little special because it's difficult to refer to the root to tell it to change things around/back... -- Matthew Fuller (MF4839) | fullermd at over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From v.ladeuil+lp at free.fr Wed Jul 6 06:10:34 2011 From: v.ladeuil+lp at free.fr (vila) Date: Wed, 06 Jul 2011 08:10:34 +0200 Subject: root-ids changing for some merges In-Reply-To: <4E139EA1.2070409@aaronbentley.com> (Aaron Bentley's message of "Tue, 05 Jul 2011 19:30:41 -0400") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> Message-ID: >>>>> Aaron Bentley writes: > On 05/07/2011 2:48 PM, vila wrote: >>>>>>> Aaron Bentley writes: >> >> > On 11-07-05 12:38 PM, vila wrote: >> >> The drawback that I just realized is that it breaks 'merge -r0..nn >> >> ../unrelated-branch' by forcing the new root which in turn trigger a >> >> rename for all existing children of the old root >> >> > That is the expected behaviour. >> >> It wasn't the behaviour *before* your patch, the root-id was preserved >> and the existing files in THIS weren't renamed. > This is true, but most branches do change behaviour. I pointed > this change out when I proposed the merge, so by approving the > proposal, Jelmer approved the change in behaviour. Neither the submitter nor the reviewer are required to be perfect, errors happen. And Jelmer wasn't involved, that was jam and me and none of us caught the issue. But I'd rather continue to accept submissions and revert/fix them when needed than block them. > What's much more interesting is what behaviour do we want, and > why? The one we had was fine (bar the empty branch/tree merge bugs). > I felt that since there's a tie to break (a tree can't have two > roots), it made a lot of sense to break the tie in favour of > OTHER, since that's how merge usually breaks ties. > You clearly prefer the old behaviour, so I'd like to know why. I think both behaviors may be valid but we shouldn't switch if the new one introduce unwanted changes. Why the test suite didn't expose this in a more obvious way is another debate. >> > Could you explain why that is a drawback? >> >> Seeing all the files present in the branch before the merge being >> renamed to the same name is quite surprising. > Okay, so there's bad UI consequences. Yes and I'm saying they are bad enough to be fixed before we release 2.4b5. If we can't, then I'd rather revert this change. > Anything else? No idea yet. >> May be my test case is wrong and falsely alarming, yet, it passed on 2.2 >> and 2.3 but fails on trunk. Did you look at it ? > No. I couldn't parse what you were saying. vila trying mister boss, vila trying: class TestNoFinalPath(script.TestCaseWithTransportAndScript): def test_bug_805809(self): self.run_script(""" $ bzr init trunk Created a standalone tree (format: 2a) $ cd trunk $ echo trunk >file $ bzr add adding file $ bzr commit -m 'create file on trunk' 2>Committing to: .../trunk/ 2>added file 2>Committed revision 1. # Create a debian branch based on trunk $ cd .. $ bzr branch trunk -r 1 debian 2>Branched 1 revision(s). $ cd debian $ mkdir dir $ bzr add adding dir $ bzr mv file dir file => dir/file $ bzr commit -m 'rename file to dir/file for debian' 2>Committing to: .../debian/ 2>added dir 2>renamed file => dir/file 2>Committed revision 2. # Create an experimental branch with a new root-id $ cd .. $ bzr init experimental Created a standalone tree (format: 2a) $ cd experimental $ echo not-empty-branch >not-empty $ bzr add adding not-empty $ bzr commit -m 'Avoid merge into empty branch safeguard' 2>Committing to: .../experimental/ 2>added not-empty 2>Committed revision 1. # merge debian even without a common ancestor $ bzr merge ../debian -r0..2 2>+N dir/ 2>+N dir/file 2>- / 2>All changes applied successfully. $ bzr st Running this led to: Text attachment: traceback ------------ Traceback (most recent call last): File "/home/vila/lib/python/testtools/runtest.py", line 169, in _run_user return fn(*args, **kwargs) File "/home/vila/lib/python/testtools/testcase.py", line 540, in _run_test_method return self._get_test_method()() File "/home/vila/src/bzr/integration/trunk/bzrlib/tests/test_conflicts.py", line 1141, in test_bug_805809 """) File "/home/vila/src/bzr/integration/trunk/bzrlib/tests/script.py", line 517, in run_script null_output_matches_anything=null_output_matches_anything) File "/home/vila/src/bzr/integration/trunk/bzrlib/tests/script.py", line 212, in run_script self.run_command(test_case, cmd, input, output, error) File "/home/vila/src/bzr/integration/trunk/bzrlib/tests/script.py", line 231, in run_command raise AssertionError(str(e) + " in stdout of command %s" % cmd) AssertionError: texts not equal: - - + added: + dir/ + dir/file + renamed: + not-empty => not-empty + pending merge tips: (use -v to see all merge revisions) + jrandom at example.com 2011-07-06 rename file to dir/file for debian in stdout of command ['bzr', 'st'] The not-empty => not-empty is the surprising bit I was referring to. Vincent From v.ladeuil+lp at free.fr Wed Jul 6 08:19:33 2011 From: v.ladeuil+lp at free.fr (vila) Date: Wed, 06 Jul 2011 10:19:33 +0200 Subject: root-ids changing for some merges In-Reply-To: <4E139EA1.2070409@aaronbentley.com> (Aaron Bentley's message of "Tue, 05 Jul 2011 19:30:41 -0400") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> Message-ID: I've filed http://pad.lv/806356 with some more explanations. Vincent From aaron at aaronbentley.com Wed Jul 6 13:27:00 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Wed, 06 Jul 2011 09:27:00 -0400 Subject: root-ids changing for some merges In-Reply-To: References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> Message-ID: <4E1462A4.6020009@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-06 02:10 AM, vila wrote: >>>>>> Aaron Bentley writes: > > I pointed > > this change out when I proposed the merge, so by approving the > > proposal, Jelmer approved the change in behaviour. > > Neither the submitter nor the reviewer are required to be perfect, > errors happen. And Jelmer wasn't involved, that was jam and me and none > of us caught the issue. I'm sorry if I was vague or misleading, but I really did try to bring it to the reviewers' attention. It's very strange to see it called an unexpected behaviour now. > But I'd rather continue to accept submissions > and revert/fix them when needed than block them. > > > What's much more interesting is what behaviour do we want, and > > why? > > The one we had was fine (bar the empty branch/tree merge bugs). It's not helpful to repeat this without the *why*. > I think both behaviors may be valid but we shouldn't switch if the new > one introduce unwanted changes. And again, what are the unwanted changes, as opposed to the expected and deliberately introduced changes? > Why the test suite didn't expose this in a > more obvious way is another debate. It's not ideal, but not very surprising. Root ids are pretty unimportant most of the time, and we tend to hide them. For example, we don't bother telling the user when a tree root is newly-added (i.e. before the first commit). > > Okay, so there's bad UI consequences. > > Yes and I'm saying they are bad enough to be fixed before we release > 2.4b5. If we can't, then I'd rather revert this change. This seems like an overreaction to me. It is a beta, after all. But I will change the behaviour, and I expect it to be easy. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UYqAACgkQ0F+nu1YWqI2jzQCdGqWkJscwrODyI+70+OxcmkFl RiEAnijtNHdq9rL0dCwGHj3pSzH6j5H4 =PSZq -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Wed Jul 6 15:55:13 2011 From: v.ladeuil+lp at free.fr (vila) Date: Wed, 06 Jul 2011 17:55:13 +0200 Subject: root-ids changing for some merges In-Reply-To: <4E1462A4.6020009@aaronbentley.com> (Aaron Bentley's message of "Wed, 06 Jul 2011 09:27:00 -0400") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> <4E1462A4.6020009@aaronbentley.com> Message-ID: >>>>> Aaron Bentley writes: > On 11-07-06 02:10 AM, vila wrote: >>>>>>> Aaron Bentley writes: >> > I pointed >> > this change out when I proposed the merge, so by approving the >> > proposal, Jelmer approved the change in behaviour. >> >> Neither the submitter nor the reviewer are required to be perfect, >> errors happen. And Jelmer wasn't involved, that was jam and me and none >> of us caught the issue. > I'm sorry if I was vague or misleading, but I really did try to bring it > to the reviewers' attention. It's very strange to see it called an > unexpected behaviour now. Sorry about that, I really understood what was going on with these root-ids by first investigating bug http://pad.lv/805809 where I realized that debian brancheS were using one root-id and the ubuntu brancheS another. I wrote a test for that and it failed without the fix for 2.2 and succeed with the fix. Same thing for 2.3. But merging to trunk it failed with the fix and that's how I realized the impact of your change, not before. So at this point it became an unexpected behaviour because: - when doing merge-upstream we *may* want this behaviour, - when doing a "random" merge, we don't want it. >> The one we had was fine (bar the empty branch/tree merge bugs). > It's not helpful to repeat this without the *why*. Hence that test added at the end of the mail you're replying to so you can see for yourself: confusing and useless renames. I'd rather keep the root-id and avoid them completely. > And again, what are the unwanted changes, as opposed to the > expected and deliberately introduced changes? I think the unwanted change is that the new root-id is propagated in all cases (and triggers confusing renames as explained in http://pad.lv/806536) >> Why the test suite didn't expose this in a >> more obvious way is another debate. > It's not ideal, but not very surprising. When one realizes what is going on, it's not surprising anymore but that's not the case for the average user. > Root ids are pretty unimportant most of the time, and we tend to > hide them. Exactly, that's the main issue: since they are hidden there is no way for the user to modify them so we need to make sure we always do the right choice. AIUI, there are only two cases where we want to propagate the root-it: - merging into an empty tree, - merge-upstream. In all other cases, we've been fine *not* propagating it, that's what I meant initially in this thread. > For example, we don't bother telling the user when a tree root is > newly-added (i.e. before the first commit). And what if the empty tree had *no* root-id instead like the 'null:' revision tree ? Wouldn't that make it easier to recognize that case automatically ? merge-upstream can force it via the API (hand wawing), it doesn't so far but this can wait and be done later. >> > Okay, so there's bad UI consequences. >> >> Yes and I'm saying they are bad enough to be fixed before we release >> 2.4b5. If we can't, then I'd rather revert this change. > This seems like an overreaction to me. It is a beta, after all. Well, may be, but on the other hand we don't need this change nor do we want beta users losing their root-id with no way to restore them easily either, so the sooner we fix this, the better. > But I will change the behaviour, and I expect it to be easy. Cool, thanks, Vincent From aaron at aaronbentley.com Wed Jul 6 16:32:36 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Wed, 06 Jul 2011 12:32:36 -0400 Subject: root-ids changing for some merges In-Reply-To: References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> <4E1462A4.6020009@aaronbentley.com> Message-ID: <4E148E24.8070408@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-06 11:55 AM, vila wrote: >>>>>> Aaron Bentley writes: > > It's not helpful to repeat this without the *why*. > > Hence that test added at the end of the mail you're replying to so you > can see for yourself: confusing and useless renames. I'd rather keep the > root-id and avoid them completely. Yeah, but the repetition isn't helpful. I already knew what you wanted. "Confusing and useless renames" would have been an excellent "why", especially in the first email. > > And again, what are the unwanted changes, as opposed to the > > expected and deliberately introduced changes? > > I think the unwanted change is that the new root-id is propagated in all > cases (and triggers confusing renames as explained in http://pad.lv/806536) Propagating the the new root-id is the deliberately-introduced change. I can't think of a clean way of propagating the new root-id only some of the time, given a tree with two roots. > > >> Why the test suite didn't expose this in a > >> more obvious way is another debate. > > > It's not ideal, but not very surprising. > > When one realizes what is going on, it's not surprising anymore but > that's not the case for the average user. But the average user isn't running the test suite, so they wouldn't be surprised anyway. > > Root ids are pretty unimportant most of the time, and we tend to > > hide them. > > Exactly, that's the main issue: since they are hidden there is no way > for the user to modify them so we need to make sure we always do the > right choice. I don't think it's possible to always do the right thing. Either choice will be wrong some of the time. If we do it the way you propose, the user will never have the opportunity to select OTHER as their tree root. Really, we should conflict so that the user can select how they want to resolve it. > AIUI, there are only two cases where we want to propagate the root-it: > - merging into an empty tree, Merging into an empty tree is different, because there's no existing root. > > For example, we don't bother telling the user when a tree root is > > newly-added (i.e. before the first commit). > > And what if the empty tree had *no* root-id instead like the 'null:' > revision tree ? That is already the case. The empty tree is the null: revision tree. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4UjiQACgkQ0F+nu1YWqI0zywCghuUcnE6voP8u2inUv9pqUwxE fEQAnjlCGueKV3rMHUuomjzjf9hS1Mxu =coui -----END PGP SIGNATURE----- From mbp at canonical.com Thu Jul 7 00:02:41 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 7 Jul 2011 10:02:41 +1000 Subject: picking up bzr-usertest Message-ID: bzr-usertest is a macrobenchmark suite for bzr. It has been quite useful in the past but it's also been semi-orphaned since ianc left us, I think partly because it's a bit unobvious and manual to get meaningful results out of it. I'm going to pick it up and try to get it going again, with a short term goal of making it tell you whether there is any significant difference in performance between two versions of bzr (like tip vs 2.3). There is some somewhat crufty code internally that's specific to the csv format it currently produces, and on the whole I think it's not worth keeping this: I'm going to just break it and replace it with a more object oriented view of the results that will let us do more stuff in process. Martin From ben+bazaar at benfinney.id.au Thu Jul 7 02:05:39 2011 From: ben+bazaar at benfinney.id.au (Ben Finney) Date: Thu, 07 Jul 2011 12:05:39 +1000 Subject: =?utf-8?B?4oCYYnpyLXN2buKAmQ==?= reports inconsistency, then can't commit changes Message-ID: <87vcvej158.fsf@benfinney.id.au> Howdy all, ===== $ bzr init-repository svn/ Shared repository with trees (format: 2a) Location: shared repository: svn $ cd svn/ && bzr branch --bind svn+ssh://subversion/home/svn/empowered/trunk/ empowered/ inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('547943 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('550491 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2Fcommands', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) inconsistent details in skipped record: ('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719') ('2194473 253065 0 0', ((),)) ('550514 23 0 0', ((('719 at 58802371-0b19-4c69-acb7-7d0c5b422186:trunk%2Fwdyt%2Fsource%2Fwdyt%2Fprofile_modules%2Fmanagement%2F__init__.py', 'svn-v4:58802371-0b19-4c69-acb7-7d0c5b422186:trunk:719'),),)) Branched 3490 revision(s). New branch bound to svn+ssh://subversion/home/svn/empowered/trunk/ ===== Great! According to that's ?not an error, it's a warning?. So let's proceed by force-applying the changes I want (to eliminate the factor of the other Bazaar branch data being corrupt): ===== $ cd empowered/ $ (cd ../../devel/empowered.rt12430.confirm-reminder-email/ && bzr diff --revision ancestor:) | patch -p0 patching file shared/empcom/auth/user/models.py patching file wdyt/source/wdyt/reminder/management/commands/send_reminders.py patching file wdyt/source/wdyt/reminder/tests/test_reminder.py $ bzr commit --message "RT12430: Test and implement email confirmation reminders." bzr: ERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branch SvnBranch('svn+ssh://subversion/home/svn/empowered/trunk'). To commit to master branch, run update and then commit. You can also pass --local to commit to continue working disconnected. $ bzr update Tree is up to date at revision 3490 of branch svn+ssh://subversion/home/svn/empowered/trunk $ bzr commit --message "RT12430: Test and implement email confirmation reminders." bzr: ERROR: Bound branch BzrBranch7(file:///home/benf/projects/svn/empowered/) is out of date with master branch SvnBranch('svn+ssh://subversion/home/svn/empowered/trunk'). To commit to master branch, run update and then commit. You can also pass --local to commit to continue working disconnected. ===== What went wrong, and how can I fix it? (Ubuntu Maverick; Bazaar 2.2.4-0ubuntu1; ?bzr-svn? 1.0.3-1.) -- \ ?Spam will be a thing of the past in two years' time.? ?Bill | `\ Gates, 2004-01-24 | _o__) | Ben Finney From mbp at canonical.com Thu Jul 7 03:19:30 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 7 Jul 2011 13:19:30 +1000 Subject: =?windows-1252?Q?Re=3A_=91bzr=2Dsvn=92_reports_inconsistency=2C_then_can=27t_?= =?windows-1252?Q?commit_changes?= In-Reply-To: <87vcvej158.fsf@benfinney.id.au> References: <87vcvej158.fsf@benfinney.id.au> Message-ID: I don't know off hand. I filed https://bugs.launchpad.net/bzr-svn/+bug/806769 for you. From john at arbash-meinel.com Thu Jul 7 10:18:17 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Thu, 07 Jul 2011 12:18:17 +0200 Subject: picking up bzr-usertest In-Reply-To: References: Message-ID: <4E1587E9.80302@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/7/2011 2:02 AM, Martin Pool wrote: > bzr-usertest is a macrobenchmark suite for bzr. > > It has been quite useful in the past but it's also been semi-orphaned > since ianc left us, I think partly because it's a bit unobvious and > manual to get meaningful results out of it. > > I'm going to pick it up and try to get it going again, with a short > term goal of making it tell you whether there is any significant > difference in performance between two versions of bzr (like tip vs > 2.3). There is some somewhat crufty code internally that's specific > to the csv format it currently produces, and on the whole I think it's > not worth keeping this: I'm going to just break it and replace it with > a more object oriented view of the results that will let us do more > stuff in process. > > Martin > Sounds like a good plan. It would be nice to see the overall summaries again. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4Vh+kACgkQJdeBCYSNAAMD8wCg0MLFvrb3N5vvGM3qo67Zuen9 fmcAoJWKA3HpY6cf9Rm38GcxK9ueEZXN =Y444 -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Thu Jul 7 10:29:27 2011 From: v.ladeuil+lp at free.fr (vila) Date: Thu, 07 Jul 2011 12:29:27 +0200 Subject: root-ids changing for some merges In-Reply-To: <4E148E24.8070408@aaronbentley.com> (Aaron Bentley's message of "Wed, 06 Jul 2011 12:32:36 -0400") References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> <4E1462A4.6020009@aaronbentley.com> <4E148E24.8070408@aaronbentley.com> Message-ID: >>>>> Aaron Bentley writes: > On 11-07-06 11:55 AM, vila wrote: >>>>>>> Aaron Bentley writes: >> > It's not helpful to repeat this without the *why*. >> >> Hence that test added at the end of the mail you're replying to so you >> can see for yourself: confusing and useless renames. I'd rather keep the >> root-id and avoid them completely. > Yeah, but the repetition isn't helpful. I already knew what you > wanted. Why asking then ? > "Confusing and useless renames" would have been an excellent "why", > especially in the first email. Right, I would certainly have said it had I understood what was going on at this time. I was EODing and wanted to raise the issue before leaving. >> AIUI, there are only two cases where we want to propagate the root-it: >> - merging into an empty tree, > Merging into an empty tree is different, because there's no > existing root. Right, we weren't talking about the same kind of empty tree, an empty working tree *has* a root id. Hope this help clarify the misunderstandings and thanks for your prompt reaction and the patch that is now on pqm. Vincent From aaron at aaronbentley.com Thu Jul 7 13:30:33 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Thu, 07 Jul 2011 09:30:33 -0400 Subject: root-ids changing for some merges In-Reply-To: References: <20110609195114.12982.46862.launchpad@loganberry.canonical.com> <4E134293.1010002@aaronbentley.com> <4E139EA1.2070409@aaronbentley.com> <4E1462A4.6020009@aaronbentley.com> <4E148E24.8070408@aaronbentley.com> Message-ID: <4E15B4F9.8020804@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-07-07 06:29 AM, vila wrote: >>>>>> Aaron Bentley writes: > > > On 11-07-06 11:55 AM, vila wrote: > >>>>>>> Aaron Bentley writes: > > >> > It's not helpful to repeat this without the *why*. > >> > >> Hence that test added at the end of the mail you're replying to so you > >> can see for yourself: confusing and useless renames. I'd rather keep the > >> root-id and avoid them completely. > > > Yeah, but the repetition isn't helpful. I already knew what you > > wanted. > > Why asking then ? I was asking for the why. I was making the point that "It changes behaviour" isn't a good reason to revert a change. You kept saying "it changes behaviour", which made no sense to me. I expected it to change behaviour. I said it changed behaviour. You approved it, having seen that it would change behaviour. And most branches change behaviour. > Hope this help clarify the misunderstandings and thanks for your prompt > reaction and the patch that is now on pqm. No problem. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4VtPMACgkQ0F+nu1YWqI1FggCfbNSBnRjSfryfPOIY+ZqklSW3 pfwAnRgoP8doMSjm4siHbD8oVx7QFVaA =kiq4 -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Thu Jul 7 16:11:25 2011 From: v.ladeuil+lp at free.fr (vila) Date: Thu, 07 Jul 2011 18:11:25 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 Message-ID: Hi, Here comes the fifth and *last* beta for the 2.4 series. Let's try to have installers and packages ready for this last round of beta testing. This is also the time to freeze the API so plugin authors can start doing official releases: the API freeze should guarantee that no plugins will be broken by bug fixes until 2.4.0. We have two options here: - refuse proposals that break the API until trunk is opened again for 2.5, - target all bug fixes to lp:bzr/2.4 The later hasn't been create yet as I'd like some feedback about which solution is preferred (I'll tend to prefer a lp:bzr/2.4 branch myself and will ask for it to be created already even if we don't use it yet (rt #46766)). For now, lp:bzr is 2.4.dev6, I'll switch to 2.5dev0 when we open the trunk for API changes. See the Changelog at https://launchpad.net/bzr/2.4/2.4b5 for more details about what is included and for the tarball. I'll make the official announcement next Tuesday morning UTC (2011-07-12) with whatever packages/installers are available at this point. Have fun ! Vincent From john at arbash-meinel.com Thu Jul 7 16:37:31 2011 From: john at arbash-meinel.com (John Meinel) Date: Thu, 7 Jul 2011 18:37:31 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: References: Message-ID: Generally blocking trunk just makes people annoyed. So I vote for lp:bzr/2.4. Harder to make bug fixes, but avoids blocking anything. John =:-> On Jul 7, 2011 6:12 PM, "vila" wrote: > Hi, > > Here comes the fifth and *last* beta for the 2.4 series. > > Let's try to have installers and packages ready for this last round of > beta testing. > > This is also the time to freeze the API so plugin authors can start > doing official releases: the API freeze should guarantee that no plugins > will be broken by bug fixes until 2.4.0. > > We have two options here: > > - refuse proposals that break the API until trunk is opened again for > 2.5, > > - target all bug fixes to lp:bzr/2.4 > > The later hasn't been create yet as I'd like some feedback about which > solution is preferred (I'll tend to prefer a lp:bzr/2.4 branch myself > and will ask for it to be created already even if we don't use it yet > (rt #46766)). > > For now, lp:bzr is 2.4.dev6, I'll switch to 2.5dev0 when we open the > trunk for API changes. > > See the Changelog at https://launchpad.net/bzr/2.4/2.4b5 for more > details about what is included and for the tarball. > > I'll make the official announcement next Tuesday morning UTC (2011-07-12) > with whatever packages/installers are available at this point. > > Have fun ! > > Vincent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Fri Jul 8 00:34:00 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 8 Jul 2011 10:34:00 +1000 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: References: Message-ID: +1 more for branching off 2.4 now. If we change the rules for trunk over time people get confused about what's currently in effect. So just to be clear, on lp:bzr/2.4, when it exists, you can still land features that wouldn't qualify post-release, as long as they're reasonably safe and don't change APIs. Martin From petrikvandervelde at gmail.com Fri Jul 8 11:50:02 2011 From: petrikvandervelde at gmail.com (Patrick van der Velde) Date: Fri, 8 Jul 2011 23:50:02 +1200 Subject: Anybody seen problems with TortoiseBzr in the latest 2.4 beta? In-Reply-To: <4E0D6FD2.7040509@ukr.net> References: <4E0CC1C2.9060905@ukr.net> <4E0D6FD2.7040509@ukr.net> Message-ID: Hi guys I uninstalled 2.4b4, rebooted my computer and reinstalled it. It worked ok for a little while but it is stuffed again so I guess I'll wait for the 2.4b5 installers to be produced. Thanks for all the help Patrick On Fri, Jul 1, 2011 at 18:57, Alexander Belchenko wrote: > I can't reproduce your problem on my Windows XP. > Maybe you need to re-install Bazaar, I have no good ideas, sorry. > Can you try to install 2.4b2 again, check it works and then install > 2.4b4? Have you installed 2.4b4 over 2.4b2 or you unistalled the old > version before? > > 01.07.2011 0:22, Patrick van der Velde ?????: > > Hiya > > > > The log says: > > > > Fri 2011-07-01 09:22:02 +1200 > > 0.047 bazaar version: 2.4b4 > > 0.048 bzr arguments: [u'qversion'] > > 0.073 looking for plugins in > > C:/Users/Petrik/AppData/Roaming/bazaar/2.0/plugins > > 0.074 looking for plugins in C:/Program Files (x86)/Bazaar/plugins > > 0.111 encoding stdout as sys.stdout encoding 'cp850' > > > > Anything else you want? > > > > Thanks > > > > Patrick > > > > On Fri, Jul 1, 2011 at 06:34, Alexander Belchenko > > wrote: > > > > 28.06.2011 2:35, Patrick van der Velde ?????: > > > Hiya > > > > > > The error dialog is the standard Windows 7 crash dialog. It > > basically > > > says: "The application has stopped responding. Do you want to > report > > > this to Microsoft". There is no useful information in the dialog > > > unfortunately. > > > > > > I can get a screenshot if you think that would help. But I > > suspect it > > > won't tell you anything useful. > > > > Could you please run `bzr qversion` and if it'll crash show the tail > > of .bzr.log corresponding to that crash? > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denys.duchier at univ-orleans.fr Fri Jul 8 19:20:32 2011 From: denys.duchier at univ-orleans.fr (Denys Duchier) Date: Fri, 08 Jul 2011 21:20:32 +0200 Subject: bzr push one branch below another Message-ID: <871uy0bmv3.fsf@tiny.univ-orleans.fr> currently, it is possible to "bzr push" a branch into a subdirectory of another branch. should bzr complain? is it worth it? Cheers, --Denys From briandealwis at gmail.com Fri Jul 8 21:35:11 2011 From: briandealwis at gmail.com (Brian de Alwis) Date: Fri, 8 Jul 2011 17:35:11 -0400 Subject: bzr push one branch below another In-Reply-To: <871uy0bmv3.fsf@tiny.univ-orleans.fr> References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> Message-ID: On 8-Jul-2011, at 3:20 PM, Denys Duchier wrote: > currently, it is possible to "bzr push" a branch into a subdirectory of > another branch. should bzr complain? is it worth it? I don't think it should ? I regularly pull in branches from other components that are being used in my current project. There are a few plugins that have been built to automate this type of use (bzr-externals and scmproj spring to mind). Brian. From john at arbash-meinel.com Sat Jul 9 07:25:14 2011 From: john at arbash-meinel.com (John Meinel) Date: Sat, 9 Jul 2011 09:25:14 +0200 Subject: bzr push one branch below another Message-ID: It also gives you the opportunity to have a hierarchy of branches. So repo/2.0 can be the 2.0 release branch and repo/2.0/feature could be a branch targetted at 2.0. We had a thread a while back about removing it, but some people did like using it. (I like the idea, but don't actively use it myself) It is confusing if you have a working tree there, since it mixes branches with files. Though as mentioned you can create meta projects if you put libraries, etc into subdirs. John =:-> On Jul 8, 2011 11:35 PM, "Brian de Alwis" wrote: -------------- next part -------------- An HTML attachment was scrubbed... URL: From gordon at doxxx.net Sat Jul 9 13:38:23 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Sat, 09 Jul 2011 09:38:23 -0400 Subject: Traceback while generating docs In-Reply-To: References: Message-ID: <4E1859CF.5010909@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm getting an error when generating the documentation on Mac OS X 10.6: python tools/generate_docs.py -o doc/en/user-reference/index.txt rstx Traceback (most recent call last): File "tools/generate_docs.py", line 106, in main(sys.argv) File "tools/generate_docs.py", line 93, in main infogen_mod.infogen(options, outfile) File "bzrlib/doc_generate/autodoc_rstx.py", line 56, in infogen outfile.write(_get_body(params, topic_dir)) File "bzrlib/doc_generate/autodoc_rstx.py", line 69, in _get_body result.append(_get_commands_section(registry, output_dir=topic_dir)) File "bzrlib/doc_generate/autodoc_rstx.py", line 118, in _get_commands_section text = cmd_object.get_help_text(plain=False, see_also_as_links=True) File "/Users/gordon/Projects/bzr-mac-installers/trunk/bazaar.src/bzr/bzrlib/commands.py", line 492, in get_help_text i18n.install() # Install i18n only for get_help_text for now. File "/Users/gordon/Projects/bzr-mac-installers/trunk/bazaar.src/bzr/bzrlib/i18n.py", line 80, in install languages=lang.split(':'), AttributeError: 'NoneType' object has no attribute 'split' make: *** [doc/en/user-reference/index.txt] Error 1 I was able to workaround it by setting LANG=en in my shell before running the build, but I've never had to do that before. I think it would be a reasonable assumption for _get_current_locale() in bzrlib.i18n to assume 'en' if it cannot find any other locale information. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOGFnPAAoJEIrPJfWinA2ujlkH/jWbx/UX2sl/MhbJyW1PzP+W 9uIaO6o2NvY5auw6QpAiOQa3tOKMItsiSYjG0/1JMbrTvhC5ikG97D6shkonKVZQ gmw7FSVh9Hnu3tvx5HclZXqyRImwam8DC2vW5+Vab/Gd5lXa2w/puhKlbxuf2Egq ObdDLUDUoO5OM/ssDarpEEEiqafoAIuva0Z2BfNK2VyZKGzpilkE1qbnXDmM7jSf L12K8s07odcRCZ53u1mf+NudCvSnTm3dcYFEWO0Ac4x5SjtkuaaptXA4u6IQhf0a yyR445mwq3o8hJ6YBJICdXR+krIA4YuhTpLQrzgOFQMBXPKOvpzR/O9FeKWEc0U= =u6G0 -----END PGP SIGNATURE----- From mbp at canonical.com Sun Jul 10 21:09:50 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 11 Jul 2011 07:09:50 +1000 Subject: Traceback while generating docs In-Reply-To: <4E1859CF.5010909@doxxx.net> References: <4E1859CF.5010909@doxxx.net> Message-ID: On 9 July 2011 23:38, Gordon Tyler wrote: > I think it would be a reasonable assumption for _get_current_locale() in > bzrlib.i18n to assume 'en' if it cannot find any other locale information. I think so too, or more precisely it ought to assume en_US at UTF-8. I think there is a another bug asking for this in a different context. It needs to be consistent with get_user_encoding. m From v.ladeuil+lp at free.fr Mon Jul 11 09:18:53 2011 From: v.ladeuil+lp at free.fr (vila) Date: Mon, 11 Jul 2011 11:18:53 +0200 Subject: API freeze for 2.4 and trunk open for 2.5 Message-ID: Hi, 2.4.0 will be released soon (source freeze planned for 2011-08-04, formal announcement 2011-08-08) and got a dedicated branch: lp:bzr/2.4 To leave plugin authors the opportunity to release official versions targeted at 2.4, the API is now frozen for lp:bzr/2.4. To allow such API breaks (if required) the trunk (lp:bzr) is now the development focus for 2.5. There are ongoing discussions about getting rid of bzrlib.api_minimum_version in favor of letting people just check bzrlib.version_info. Reply to this thread with your thoughts on this decision and its fallouts. Happy hacking ! Vincent P.S.: I've landed a patch to fix news entries from 2.4 to 2.5 for patches landed after 2.4 fork. Feel free to backport the changes that were landed after the fork if you prefer them to be part of 2.4.0. From mbp at canonical.com Mon Jul 11 09:30:53 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 11 Jul 2011 19:30:53 +1000 Subject: API freeze for 2.4 and trunk open for 2.5 In-Reply-To: References: Message-ID: On 11 July 2011 19:18, vila wrote: > Hi, > > 2.4.0 will be released soon (source freeze planned for 2011-08-04, > formal announcement 2011-08-08) and got a dedicated branch: lp:bzr/2.4 > > To leave plugin authors the opportunity to release official versions > targeted at 2.4, the API is now frozen for lp:bzr/2.4. Thanks for looking after this. > > To allow such API breaks (if required) the trunk (lp:bzr) is now the > development focus for 2.5. > > There are ongoing discussions about getting rid of > bzrlib.api_minimum_version in favor of letting people just check > bzrlib.version_info. Just to be clear, I'm not considering doing anything in that regard that would affect the 2.4 release or branch. Anyhow, my thought is this: bzr 2.4 has a different api to bzr 2.3, and so on. It won't be vastly different, but some things change, so the api version has to increment on every major release. Even in cases where we don't intend to change the api, narrowly defined, there can be other changes in behaviour that mean plugins have to be retested against 2.4 and perhaps updated. I think when this was put in Robert had the idea of defining separate api versions per module or even per class, but I think in Python that would be more trouble than it's worth, because we'd be highly likely to miss dependencies that could only be found by testing. In short I suggest just setting api_minimum_version = version_info[:2] and be done. Martin From robertc at robertcollins.net Mon Jul 11 09:34:40 2011 From: robertc at robertcollins.net (Robert Collins) Date: Mon, 11 Jul 2011 21:34:40 +1200 Subject: API freeze for 2.4 and trunk open for 2.5 In-Reply-To: References: Message-ID: On Mon, Jul 11, 2011 at 9:30 PM, Martin Pool wrote: > I think when this was put in Robert had the idea of defining separate > api versions per module or even per class, but I think in Python that > would be more trouble than it's worth, because we'd be highly likely > to miss dependencies that could only be found by testing. > > In short I suggest just setting api_minimum_version = version_info[:2] > and be done. So IIRC there were two separate dimensions here, one was, as you say, handling regions of the API which haven't changed, the other was, if we don't break compat, being able to be compatible with older releases. I guess the new API compatibility policy for development speaks to the latter point, and the concept of submodules not breaking API in a release hasn't really been made use of. Anyhow, thats just data - I've no objection to this being simplified or removed. -Rob From john at arbash-meinel.com Mon Jul 11 13:30:24 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 11 Jul 2011 15:30:24 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: References: Message-ID: <4E1AFAF0.5000606@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/7/2011 6:11 PM, vila wrote: > Hi, > > Here comes the fifth and *last* beta for the 2.4 series. > > Let's try to have installers and packages ready for this last round of > beta testing. Windows bzr-2.4b5-1 installers built. I updated PyQt, but otherwise it is the same set of dependencies that was in 2.4b4. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4a+vAACgkQJdeBCYSNAAPFpgCgrrO7CYU/eY8oo5Fte44dff1L 5yEAoKP+eL4ap1NK8bFYJN5AE9WCb2WK =fPln -----END PGP SIGNATURE----- From bialix at ukr.net Mon Jul 11 16:45:50 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Mon, 11 Jul 2011 19:45:50 +0300 Subject: [ANN] Bazaar Explorer 1.1.4 released Message-ID: <4E1B28BE.2070303@ukr.net> I've just released Bazaar Explorer 1.1.4. This is maintenance release, and it will be mostly interested for windows users of Bazaar Explorer. Now windows installer for Bazaar Explorer has send2trash library bundled. Official standalone windows installer for 2.4b5 and higher should have the same fix soon. Downloads: https://launchpad.net/bzr-explorer/1.1/1.1.4 Alexander From marco.pantaleoni at gmail.com Mon Jul 11 17:13:47 2011 From: marco.pantaleoni at gmail.com (Marco Pantaleoni) Date: Mon, 11 Jul 2011 19:13:47 +0200 Subject: bzr push one branch below another In-Reply-To: <871uy0bmv3.fsf@tiny.univ-orleans.fr> References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> Message-ID: On Fri, Jul 8, 2011 at 9:20 PM, Denys Duchier wrote: > currently, it is possible to "bzr push" a branch into a subdirectory of > another branch. should bzr complain? is it worth it? > It's a feature that I use constantly, so I don't think bzr should complain :-) Ciao, Marco -- Marco Pantaleoni -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.bennetts at canonical.com Mon Jul 11 23:28:48 2011 From: andrew.bennetts at canonical.com (Andrew Bennetts) Date: Tue, 12 Jul 2011 09:28:48 +1000 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <20110711101338.6AE592000BB@balleny.canonical.com> References: <20110711101338.6AE592000BB@balleny.canonical.com> Message-ID: <20110711232848.GA23024@aihal.home.puzzling.org> Canonical.com Patch Queue Manager wrote: > revno: 6022 [merge] [?] > message: > (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 > fork (Vincent Ladeuil) But those two changes were meant to land on the 2.4 branch :( I even submitted the merge proposals to lp:bzr/2.4 without realising that lp:bzr/2.4 was at that time still the same as lp:bzr. I guess I need to backport them now? -Andrew. From matt_scarisbrick at cantab.net Tue Jul 12 08:12:29 2011 From: matt_scarisbrick at cantab.net (Matt Scarisbrick) Date: Tue, 12 Jul 2011 09:12:29 +0100 Subject: Bizare Bazaar Message-ID: <4E1C01ED.5010404@cantab.net> Dear All, I've been using Bazaar for 3 years now, but recently I've been seeing some odd behviour and wondered if anyone knows why. We operate with a master branch which I control and devs all have their own branch of that master. I merge their changes in and they merge back to get the up to date mainline. However, sometimes when I merge their changes I get a criss-cross merge, and looking in the log it shows that when they merged with the master branch it actually merged a couple of revisions behind the head of that branch at the time, which I suspect is what is causing the criss-cross. Has anyone seen this behviour before and how I can correct it? (We're all using v 2.x) - I can provide a screenshot if that's useful. Many thanks, Matt From john at arbash-meinel.com Tue Jul 12 08:37:39 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 12 Jul 2011 10:37:39 +0200 Subject: Bizare Bazaar In-Reply-To: <4E1C01ED.5010404@cantab.net> References: <4E1C01ED.5010404@cantab.net> Message-ID: <4E1C07D3.4040306@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/12/2011 10:12 AM, Matt Scarisbrick wrote: > Dear All, > > I've been using Bazaar for 3 years now, but recently I've been seeing > some odd behviour and wondered if anyone knows why. We operate with a > master branch which I control and devs all have their own branch of that > master. I merge their changes in and they merge back to get the up to > date mainline. However, sometimes when I merge their changes I get a > criss-cross merge, and looking in the log it shows that when they merged > with the master branch it actually merged a couple of revisions behind > the head of that branch at the time, which I suspect is what is causing > the criss-cross. Has anyone seen this behviour before and how I can > correct it? (We're all using v 2.x) - I can provide a screenshot if > that's useful. > > Many thanks, > Matt > Often people will have a local branch of "master" that they merge from. They may not have updated it after you updated the real master before they merge it. There are other ways to get criss-cross, such as by having 2 integration branches. If they both merge feature branches, then after 2 feature branches are merged, there is no longer a simple base to pick from for future merges. A screenshot could be helpful. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cB9MACgkQJdeBCYSNAAPe1ACePCiHl+RnG+/AABT221kJTT9Q SK0An2IYn2sjxMTUAYlK0r82Vg57gRhh =0AdN -----END PGP SIGNATURE----- From matt_scarisbrick at cantab.net Tue Jul 12 09:29:53 2011 From: matt_scarisbrick at cantab.net (Matt Scarisbrick) Date: Tue, 12 Jul 2011 10:29:53 +0100 Subject: Bizare Bazaar In-Reply-To: <4E1C07D3.4040306@arbash-meinel.com> References: <4E1C01ED.5010404@cantab.net> <4E1C07D3.4040306@arbash-meinel.com> Message-ID: <4E1C1411.5060509@cantab.net> On 12/07/2011 09:37, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/12/2011 10:12 AM, Matt Scarisbrick wrote: >> Dear All, >> >> I've been using Bazaar for 3 years now, but recently I've been seeing >> some odd behviour and wondered if anyone knows why. We operate with a >> master branch which I control and devs all have their own branch of that >> master. I merge their changes in and they merge back to get the up to >> date mainline. However, sometimes when I merge their changes I get a >> criss-cross merge, and looking in the log it shows that when they merged >> with the master branch it actually merged a couple of revisions behind >> the head of that branch at the time, which I suspect is what is causing >> the criss-cross. Has anyone seen this behviour before and how I can >> correct it? (We're all using v 2.x) - I can provide a screenshot if >> that's useful. >> >> Many thanks, >> Matt >> > > Often people will have a local branch of "master" that they merge from. > They may not have updated it after you updated the real master before > they merge it. > > There are other ways to get criss-cross, such as by having 2 integration > branches. If they both merge feature branches, then after 2 feature > branches are merged, there is no longer a simple base to pick from for > future merges. > > A screenshot could be helpful. Thanks for your reply. Please see the attached - master on the left, user Michael on the right. To me it looks like when Michael merged he got the master branch at revision 1583 when I would have expected him to get revision 1585. I then get a criss-cross merge at revision 1586 as there are two paths back to 1583. I'm pretty sure none of our devs have their own copy of the master branch - it's on a local server so we just merge down from that. Thanks, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: bizare-bazaar.png Type: image/png Size: 21797 bytes Desc: not available URL: From john at arbash-meinel.com Tue Jul 12 13:24:12 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 12 Jul 2011 15:24:12 +0200 Subject: Bizare Bazaar In-Reply-To: <4E1C1411.5060509@cantab.net> References: <4E1C01ED.5010404@cantab.net> <4E1C07D3.4040306@arbash-meinel.com> <4E1C1411.5060509@cantab.net> Message-ID: <4E1C4AFC.9090909@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... >> Often people will have a local branch of "master" that they merge from. >> They may not have updated it after you updated the real master before >> they merge it. >> >> There are other ways to get criss-cross, such as by having 2 integration >> branches. If they both merge feature branches, then after 2 feature >> branches are merged, there is no longer a simple base to pick from for >> future merges. >> >> A screenshot could be helpful. > > Thanks for your reply. Please see the attached - master on the left, > user Michael on the right. To me it looks like when Michael merged he > got the master branch at revision 1583 when I would have expected him to > get revision 1585. I then get a criss-cross merge at revision 1586 as > there are two paths back to 1583. > > I'm pretty sure none of our devs have their own copy of the master > branch - it's on a local server so we just merge down from that. > > Thanks, > Matt Right so the graph as seen certainly is a criss-cross. I don't have any reason to understand why 847.1.491 would have merged 1583 rather than 1585 other than a copy-of-master that was not up to date. There is nothing in the timestamps, etc that looks suspicious. Since you say that everything is "on a local server", I'm also guessing that there wouldn't be anything special about time zones. Certainly, if you were just doing "bzr merge bzr+ssh://.../trunk" we'll always pick the most recent revision. You'd have to explicitly use "-r" to get an older one. Which is why my best guess is an out-of-date mirror. Like if someone locally has a checkout of master, and doesn't do "bzr up" before they do "bzr merge ../trunk". John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cSvwACgkQJdeBCYSNAAMRLgCfdYzrG8w+0aAv16t/k/Ti4aTc c2UAn2UscduAzmoGgZzHbGIGE83nFoXe =0yfO -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Tue Jul 12 06:33:39 2011 From: v.ladeuil+lp at free.fr (Vincent Ladeuil) Date: Tue, 12 Jul 2011 08:33:39 +0200 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <20110711232848.GA23024@aihal.home.puzzling.org> (Andrew Bennetts's message of "Tue, 12 Jul 2011 09:28:48 +1000") References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> Message-ID: <87k4boc8jg.fsf@free.fr> >>>>> Andrew Bennetts writes: > Canonical.com Patch Queue Manager wrote: >> revno: 6022 [merge] > [?] >> message: >> (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 >> fork (Vincent Ladeuil) > But those two changes were meant to land on the 2.4 branch :( I > even submitted the merge proposals to lp:bzr/2.4 without realising > that lp:bzr/2.4 was at that time still the same as lp:bzr. Right, lp:bzr/2.4 wasn't properly redirected. I didn't want to step over toes by landing stuff that weren't targeted at 2.4. > I guess I need to backport them now? Yes, I sent a message to that effect when I opened 2.5.dev1. Vincent From john at arbash-meinel.com Tue Jul 12 14:01:36 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 12 Jul 2011 16:01:36 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: References: Message-ID: <4E1C53C0.7000501@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > I'll make the official announcement next Tuesday morning UTC (2011-07-12) > with whatever packages/installers are available at this point. > > Have fun ! > > Vincent > I think you missed this part. Probably because you are at a conference today. Maybe you can still do it on Wednesday. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cU8AACgkQJdeBCYSNAAPhAgCfeLR9QPKpuj11WyuX2DiB2cTa 264AoLodec1BWkr8Olx7qB/5ELP7XkPA =GAG2 -----END PGP SIGNATURE----- From john at arbash-meinel.com Tue Jul 12 14:06:14 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 12 Jul 2011 16:06:14 +0200 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <87k4boc8jg.fsf@free.fr> References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> <87k4boc8jg.fsf@free.fr> Message-ID: <4E1C54D6.3050109@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/12/2011 8:33 AM, Vincent Ladeuil wrote: >>>>>> Andrew Bennetts writes: > > > Canonical.com Patch Queue Manager wrote: > >> revno: 6022 [merge] > > [?] > >> message: > >> (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 > >> fork (Vincent Ladeuil) > > > But those two changes were meant to land on the 2.4 branch :( I > > even submitted the merge proposals to lp:bzr/2.4 without realising > > that lp:bzr/2.4 was at that time still the same as lp:bzr. > > Right, lp:bzr/2.4 wasn't properly redirected. > > I didn't want to step over toes by landing stuff that weren't targeted > at 2.4. > > > I guess I need to backport them now? > > Yes, I sent a message to that effect when I opened 2.5.dev1. > > Vincent > - From what I see, bzr.dev 6020 would be fine as the tip of the bzr/2.4 series. We'd still need the docs moved to NEW section rather than being part of bzr/2.4b5. "flush()" is technically a new api, but I feel it is safe enough to be in 2.4.0, since it is fully backwards compatible (code that doesn't use it runs just fine), and it is part of the test infrastructure. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4cVNYACgkQJdeBCYSNAANgBQCeMRkVqktTn9UJuVoxErBda6iy Nv8AniQPMe1yJUYKP/6eNx93nDolhGVR =6KTz -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Tue Jul 12 16:30:08 2011 From: v.ladeuil+lp at free.fr (Vincent Ladeuil) Date: Tue, 12 Jul 2011 18:30:08 +0200 Subject: [ANN] bzr 2.4b5 released Message-ID: Hi, Our fifth and **last** beta has been released: 2.4b5. 2.4.0 is planned to be released in August 2011. 2.4b5 contains all known bug fixes (including the ones we made for the previous stable releases). Thanks to all participants, whether you sent merge proposals, comments, suggestions and feedback, we very much appreciate all of them. Bazaar is now available for download from https://launchpad.net/bzr/2.4/2.4b4/ as a source tarball. Installers are available for windows and OSX. Reminder for people trying their first 2.4beta: since 2.4b3, we've stopped supporting python-2.4/2.5 (including Ubuntu Hardy) for the *betas*, the 2.3 stable series will maintain compatibility with python2.4. If you're a plugin author, please make sure you have a clearly identified release compatible with 2.4 (preferably with a dedicated series like http://pad.lv/p/qbzr does or at least a tag for the version you'd like to be to carried by the installers and the ppas). Whatever you decide, keep in touch with the packagers or just reply to this mail. There is no urgency but on the other hand packagers may not be able to carry the right version of your plugin when 2.4.0 will be packaged. The bzr API is frozen for the 2.4 series so what works today for your plugin should still work for 2.4.0, don't rush new features (you'll be able to do minor releases for the 2.4 series, but if you have a working version, just release it ;). And now for the gory details: External Compatibility Breaks ***************************** None. New Features ************ * New command ``verify-signatures`` to check if all commits or specified commits have digital signatures from trusted keys. Requires python-gpgme to be installed. * New option ``--signatures`` for ``bzr log`` to display digital signature verification results for each commit. * Config option acceptable_keys to list which GPG keys are verified as trusted. * Config option validate_signatures_in_log to always show signatures in ``bzr log``. Improvements ************ * ``Branch.open`` is now about 3x faster (about 2ms instead of 6.5ms). (Andrew Bennetts). Bug Fixes ********* * Display a proper error message when a config file content cannot be decoded as UTF-8 or when it cannot be parsed. (Vincent Ladeuil, #502060, #688677, #797246) * Generate a single conflict (instead of two) when merging a branch modifying and renaming a file in a branch that deleted it (or vice-versa). (Vincent Ladeuil, #688101) * Give a more helpful message when the bzr executable doesn't match the library. (This typically happens because of a misconfigured PYTHONPATH or half-installed bzr.) (Martin Pool, #804553) * Properly load utf8-encoded config files. (Vincent Ladeuil, #799212) * ``GraphThunkIdsToKeys.merge_sort`` now properly returns keys rather than ids. (Jelmer Vernooij, #799677) * ``TreeTransformBase.fixup_new_roots`` can now check that a tree root is present. (Jelmer Vernooij, #801257) API Changes *********** * New attributes ``WorkingTreeFormat.supports_versioned_directories`` and ``RepositoryFormat.supports_versioned_directories``. (Jelmer Vernooij, #765815) * The "revno" field type when using the python version-info format is now a string (to handle dotted revnos) (Beno?t Pierre, #796259) Internals ********* * Start implementing localization, starting with command help text (but not the command options themselves). This will allow bootstrapping the bzr internationalization process. (Inada Naoki) Testing ******* * Fix test failures when running as a homeless user (debian buildd). Tests leaking into ``${HOME}/.bzr.log`` should be detected properly now. (Vincent Ladeuil, #798698) From john at arbash-meinel.com Tue Jul 12 18:20:32 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 12 Jul 2011 20:20:32 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: <4E1AFAF0.5000606@arbash-meinel.com> References: <4E1AFAF0.5000606@arbash-meinel.com> Message-ID: <4E1C9070.8050900@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/11/2011 3:30 PM, John Arbash Meinel wrote: > On 7/7/2011 6:11 PM, vila wrote: >> Hi, > >> Here comes the fifth and *last* beta for the 2.4 series. > >> Let's try to have installers and packages ready for this last round of >> beta testing. > > Windows bzr-2.4b5-1 installers built. I updated PyQt, but otherwise it > is the same set of dependencies that was in 2.4b4. > > John > =:-> bzr-2.4b5-2 has been built. The only change is the inclusion of bzr-explore 1.1.4 instead of 1.1.3. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ckG8ACgkQJdeBCYSNAAO/lgCfS3yNiihUu4sV29caRJjUonkU RvoAn2JkkqlQaBtjahxmeXTY3ikRfFMc =jCOP -----END PGP SIGNATURE----- From andrew.bennetts at canonical.com Wed Jul 13 00:11:47 2011 From: andrew.bennetts at canonical.com (Andrew Bennetts) Date: Wed, 13 Jul 2011 10:11:47 +1000 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <87k4boc8jg.fsf@free.fr> References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> <87k4boc8jg.fsf@free.fr> Message-ID: <20110713001147.GA2518@aihal.home.puzzling.org> Vincent Ladeuil wrote: [?] > Right, lp:bzr/2.4 wasn't properly redirected. > > I didn't want to step over toes by landing stuff that weren't targeted > at 2.4. But they were targetted at 2.4! After all I did add news entries to doc/en/release-notes/bzr-2.4.txt, not out of reflex but because that's where I intended them to land. If I didn't think they were suitable for 2.4 I certainly wouldn't have done that. I think a quick inspection would have made it clear that those patches are safe for 2.4: they only affect selftest after all. > > I guess I need to backport them now? > > Yes, I sent a message to that effect when I opened 2.5.dev1. I didn't notice that part of the message, I guess I didn't pay attention to the ?p.s.? buried at the end. A direct heads up to people whose patches may have been affected would probably work better. Much like if I change an API that's likely to affect bzr-svn I try to tell Jelmer about it rather than let him discover it some time later the hard way :) It's not strictly necessary but it's a low effort action that helps us keep working smoothly. I've submitted a backport of those two patches now. It seems likely that all the other changes in that gap ought to be submitted too, after checking that their release-notes entries are still in the appropriate place. -Andrew. From mbp at canonical.com Wed Jul 13 00:27:29 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 13 Jul 2011 10:27:29 +1000 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <87k4boc8jg.fsf@free.fr> References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> <87k4boc8jg.fsf@free.fr> Message-ID: I think the key thing here for last time is that as near to possible as atomically we should: * tag a revision * branch from that exact revision onto the release branch * make that the series branch (there should not previously be any series branch) * announce this There is no freeze on trunk; trunk can always take api-changing patches for the next release. Therefore, after the last beta, there must be a separate release branch. m From v.ladeuil+lp at free.fr Wed Jul 13 06:56:23 2011 From: v.ladeuil+lp at free.fr (vila) Date: Wed, 13 Jul 2011 08:56:23 +0200 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: <20110713001147.GA2518@aihal.home.puzzling.org> (Andrew Bennetts's message of "Wed, 13 Jul 2011 10:11:47 +1000") References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> <87k4boc8jg.fsf@free.fr> <20110713001147.GA2518@aihal.home.puzzling.org> Message-ID: >>>>> Andrew Bennetts writes: > Vincent Ladeuil wrote: > [?] >> Right, lp:bzr/2.4 wasn't properly redirected. >> >> I didn't want to step over toes by landing stuff that weren't targeted >> at 2.4. > But they were targetted at 2.4! After all I did add news entries to > doc/en/release-notes/bzr-2.4.txt, As opposed to what ? bzr-2.5.txt wasn't existing ! You had no way to target 2.5 and I had no way to resolve the ambiguity after the fact. The safest was to let people do that by themselves while I was struggling with the rest. > not out of reflex but because that's where I intended them to > land. If I didn't think they were suitable for 2.4 I certainly > wouldn't have done that. Right, there was confusion, I trusted people to not land stuff on bzr.dev while losas were creating the pqm branch (with the associated lag), while I was encountering a transient error on pqm (http://pad.lv/807032) while landing 2.4b5 and lp:bzr/2.4 wasn't pointing to the right branch (which nobody realized until too late) and it was the end of the week... and the trunk was still not open for 2.5... > I think a quick inspection would have made it clear that those > patches are safe for 2.4: they only affect selftest after all. Right, that quick inspection was even quicker for people that landed them. Another kind of quick inspection would have told them that after a freeze, the trunk wasn't in the expected state and should not have been used for landing. Let's just fix the fallouts, the causes are known the solution obvious, pointing fingers doesn't provide a lot of value there I think. >> > I guess I need to backport them now? >> >> Yes, I sent a message to that effect when I opened 2.5.dev1. > I didn't notice that part of the message, .... > I guess I didn't pay attention to the ?p.s.? buried at the end. A > direct heads up to people whose patches may have been affected > would probably work better. Right, it's a bit hard to know who doesn't read what :) > I've submitted a backport of those two patches now. It seems > likely that all the other changes in that gap ought to be > submitted too, after checking that their release-notes entries are > still in the appropriate place. I think jam *did* a quick inspection and said a single submission would have been enough to address all of them ? No ? Vincent From v.ladeuil+lp at free.fr Wed Jul 13 07:02:32 2011 From: v.ladeuil+lp at free.fr (vila) Date: Wed, 13 Jul 2011 09:02:32 +0200 Subject: Rev 6022: (vila) Move news entries from 2.4 to 2.5 for patches landed after 2.4 in file:///home/pqm/archives/thelove/bzr/%2Btrunk/ In-Reply-To: (Martin Pool's message of "Wed, 13 Jul 2011 10:27:29 +1000") References: <20110711101338.6AE592000BB@balleny.canonical.com> <20110711232848.GA23024@aihal.home.puzzling.org> <87k4boc8jg.fsf@free.fr> Message-ID: >>>>> Martin Pool writes: > I think the key thing here for last time is that as near to possible > as atomically we should: That's the theory. 'Atomically' doesn't fly when a new pqm branch needs to be created or when pqm spuriously fail to accept a valid submission, that caused delays, aggravated by a week-end. > * tag a revision > * branch from that exact revision onto the release branch > * make that the series branch (there should not previously be any > series branch) > * announce this > There is no freeze on trunk; trunk can always take api-changing > patches for the next release. Therefore, after the last beta, > there must be a separate release branch. Indeed. And without a proper way to lock the branches involved, that cannot be done atomically, so everybody has to collaborate in case the atomicity can not be enforced. I left both lp:bzr/2.4 and lp:bzr in a state that allowed each branch to be fixed properly[1] and I would have fixed them myself when time permitted. I thought they will be fixed quicker by just mentioning the issue. Vincent [1]: The expedient alternative would have been to blindly land everything on 2.4 and ask people to *remove* the undeeded stuff. A longer alternative was to inspect the diff but I didn't have the time for this one. From v.ladeuil+lp at free.fr Wed Jul 13 11:22:09 2011 From: v.ladeuil+lp at free.fr (Vincent Ladeuil) Date: Wed, 13 Jul 2011 13:22:09 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: <4E1C53C0.7000501@arbash-meinel.com> (John Arbash Meinel's message of "Tue, 12 Jul 2011 16:01:36 +0200") References: <4E1C53C0.7000501@arbash-meinel.com> Message-ID: <87mxgi4e8u.fsf@free.fr> >>>>> John Arbash Meinel writes: > ... >> I'll make the official announcement next Tuesday morning UTC (2011-07-12) >> with whatever packages/installers are available at this point. >> >> Have fun ! >> >> Vincent >> > I think you missed this part. Almost, but I appreciate the heads-up nevertheless. > Probably because you are at a conference today. Yup. Vincent From john at arbash-meinel.com Wed Jul 13 12:16:54 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Wed, 13 Jul 2011 14:16:54 +0200 Subject: [ANN] bzr 2.4b5 has gone gold, API freeze for 2.4 In-Reply-To: <87mxgi4e8u.fsf@free.fr> References: <4E1C53C0.7000501@arbash-meinel.com> <87mxgi4e8u.fsf@free.fr> Message-ID: <4E1D8CB6.70200@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/13/2011 1:22 PM, Vincent Ladeuil wrote: >>>>>> John Arbash Meinel writes: > > > ... > > >> I'll make the official announcement next Tuesday morning UTC (2011-07-12) > >> with whatever packages/installers are available at this point. > >> > >> Have fun ! > >> > >> Vincent > >> > > > I think you missed this part. > > Almost, but I appreciate the heads-up nevertheless. Well you did say Tuesday *morning*, but sent it at 6pm. :) > > > Probably because you are at a conference today. > > Yup. > > Vincent John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4djLYACgkQJdeBCYSNAAPA6QCfVH5tq5E7A/vd2bJFnxBMrNjQ UJUAoKfnDJ4EaQYlvuriih7VY2tw9SME =Rrbh -----END PGP SIGNATURE----- From dbailey at hp.com Wed Jul 13 14:15:39 2011 From: dbailey at hp.com (Bailey, Darragh) Date: Wed, 13 Jul 2011 15:15:39 +0100 Subject: bzr fast-import/fast-export what's the importance of marks file when dealing with multiple branches Message-ID: <4E1DA88B.3010206@hp.com> While experimenting with using git-bzr-ng and import/export branches to git/from bzr I'm wondering what is the importance of using the same mark's files when handling related but unmerged branches from the same repository? The example on http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html indicates that one should do the following when exporting and import related branches: bzr fast-export --export-marks=marks.bzr project.dev | GIT_DIR=project/.git git-fast-import --export-marks=marks.git bzr fast-export --import-marks=marks.bzr -b other project.other | GIT_DIR=project/.git git-fast-import --import-marks=marks.git But nowhere can I find an indication of why this is important? Is this just a performance improvement, or is there a repository history integrity issue should it not be followed? -- Darragh "Nothing is foolproof to a sufficiently talented fool" - Unknown From john at arbash-meinel.com Wed Jul 13 14:29:47 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Wed, 13 Jul 2011 16:29:47 +0200 Subject: bzr fast-import/fast-export what's the importance of marks file when dealing with multiple branches In-Reply-To: <4E1DA88B.3010206@hp.com> References: <4E1DA88B.3010206@hp.com> Message-ID: <4E1DABDB.7000508@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/13/2011 4:15 PM, Bailey, Darragh wrote: > > While experimenting with using git-bzr-ng and import/export branches to > git/from bzr I'm wondering what is the importance of using the same > mark's files when handling related but unmerged branches from the same > repository? > > The example on > http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html > indicates that one should do the following when exporting and import > related branches: > > bzr fast-export --export-marks=marks.bzr project.dev | > GIT_DIR=project/.git git-fast-import --export-marks=marks.git > > bzr fast-export --import-marks=marks.bzr -b other project.other | > GIT_DIR=project/.git git-fast-import --import-marks=marks.git > > > But nowhere can I find an indication of why this is important? Is this > just a performance improvement, or is there a repository history > integrity issue should it not be followed? > bzr fast-import generates new revision information for every commit. If you specify a marks file, it will re-use the imports from the other branch. If you don't, the branches won't share common revisions. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dq9sACgkQJdeBCYSNAANk7ACfWnFt42vaF+UmXPnNGRba1sPE G68AoNVz5jFaARuOEhLBdGbU/Lkx/WSY =TtfT -----END PGP SIGNATURE----- From dbailey at hp.com Wed Jul 13 15:26:25 2011 From: dbailey at hp.com (Bailey, Darragh) Date: Wed, 13 Jul 2011 16:26:25 +0100 Subject: bzr fast-import/fast-export what's the importance of marks file when dealing with multiple branches In-Reply-To: <4E1DABDB.7000508@arbash-meinel.com> References: <4E1DA88B.3010206@hp.com> <4E1DABDB.7000508@arbash-meinel.com> Message-ID: <4E1DB921.70109@hp.com> On 13/07/11 15:29, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/13/2011 4:15 PM, Bailey, Darragh wrote: >> While experimenting with using git-bzr-ng and import/export branches to >> git/from bzr I'm wondering what is the importance of using the same >> mark's files when handling related but unmerged branches from the same >> repository? >> >> The example on >> http://doc.bazaar.canonical.com/plugins/en/fastimport-plugin.html >> indicates that one should do the following when exporting and import >> related branches: >> >> bzr fast-export --export-marks=marks.bzr project.dev | >> GIT_DIR=project/.git git-fast-import --export-marks=marks.git >> >> bzr fast-export --import-marks=marks.bzr -b other project.other | >> GIT_DIR=project/.git git-fast-import --import-marks=marks.git >> >> >> But nowhere can I find an indication of why this is important? Is this >> just a performance improvement, or is there a repository history >> integrity issue should it not be followed? >> > bzr fast-import generates new revision information for every commit. If > you specify a marks file, it will re-use the imports from the other > branch. If you don't, the branches won't share common revisions. > > John Sounds like what I thought it might be. Although some testing with exporting from bzr to git seems to suggest that git doesn't need to use to same marks file to correctly associate common revisions, or it might just be luck with what I've tested. Possibly something to do with how the sha-1's are calculated for each commit which means that git is managing to work out the history correctly anyway. Anyway I'll go poke the git devs on that. Thanks for the quick answer. -- Darragh "Nothing is foolproof to a sufficiently talented fool" - Unknown From john at arbash-meinel.com Wed Jul 13 16:25:41 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Wed, 13 Jul 2011 18:25:41 +0200 Subject: bzr fast-import/fast-export what's the importance of marks file when dealing with multiple branches In-Reply-To: <4E1DB921.70109@hp.com> References: <4E1DA88B.3010206@hp.com> <4E1DABDB.7000508@arbash-meinel.com> <4E1DB921.70109@hp.com> Message-ID: <4E1DC705.1080600@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > > Sounds like what I thought it might be. Although some testing with > exporting from bzr to git seems to suggest that git doesn't need to use > to same marks file to correctly associate common revisions, or it might > just be luck with what I've tested. > > Possibly something to do with how the sha-1's are calculated for each > commit which means that git is managing to work out the history > correctly anyway. Anyway I'll go poke the git devs on that. Thanks for > the quick answer. > In git, identity is determined entirely by content. So if you export 2 revisions that generate identical tree content and commit information, then they will be the same revision in git. That isn't true for bzr. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4dxwUACgkQJdeBCYSNAANxbACgix+goBS7nMl+dLVHQTnNAPBI 9qoAnioSiCSvYHkZi2zGJ1Pm/9lqh5qd =G48q -----END PGP SIGNATURE----- From aaron at aaronbentley.com Wed Jul 13 20:08:30 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Wed, 13 Jul 2011 16:08:30 -0400 Subject: RELEASE BzrTools 2.4.0 Message-ID: <4E1DFB3E.8030407@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm happy to announce BzrTools 2.4.0 This version is intended to be compatible with the 2.4.x Bazaar series. BzrTools is a plugin that provides miscellaneous useful and/or frivolous functionality for bazaar. For once, there are a number of real of changes: bzr shell: - Exceptions are logged quietly (Martin [gz]). - Readline is not required (Martin [gz]). bzr zap --store uses pipelines to store uncommitted changes. bzr export - tarballs with non-ascii filenames now work. - .tar.xz and .tar.lzma files are now supported (Jelmer). graph functionality migrated from bzrlib (Jelmer). API compatibility updates setup.py does not execute on import (Robert Collins). DiffWriter provides writelines method (Jelmer). For more information on BzrTools, please see http://wiki.bazaar.canonical.com/BzrTools BzrTools 2.4.0 is available at: http://launchpad.net/bzrtools/stable/2.4.0/+download/bzrtools-2.4.0.tar.gz http://launchpad.net/bzrtools/stable/2.4.0/+download/bzrtools-2.4.0.tar.gz.sig Enjoy! Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4d+z4ACgkQ0F+nu1YWqI2EQwCcDpggruroIgNYXlwPfK5K3vid FUkAn19kUlw5W7vOS+Z6wFu0Mr5Ot757 =P5Xp -----END PGP SIGNATURE----- From mbp at canonical.com Wed Jul 13 23:13:46 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 14 Jul 2011 09:13:46 +1000 Subject: [Bzr-windows] problem merging / rebasing with local sandbox - my workflow? (lp: message 1 of 20) In-Reply-To: References: Message-ID: On 14 July 2011 08:20, wrote: > One more question on this, sorry for not asking it earlier. > > I was of the understanding (probably incorrect) from reading the page > referenced below that given: > > local trunk as a branch of something remote > featureX & featureY as branches of the local trunk > > that changes to either of the feature branches should push to the remote > url. > > But, when running through this and using your suggestion, it seems to work > better if I instead: > > make & commit the changes to the feature branch > switch to and update my local trunk > pull or merge the changes from my feature into local trunk > push my local trunk to the remote url > > Doing this seems to prevent me from having any kind of out of sync > conflicts, even if X is way in front of Y, but I guess seemed backwards from > what I was thinking the guide was recommending. > > I just want to make sure I'm going about it correctly, any thoughts? If you > know of a post somewhere that explains this, I'd gladly welcome that. Either of those can work. If you do the latter, then your changes will always be seen as being merged into trunk, rather than trunk being replaced by the contents of the new branch. Can you point me to the part of the documentation that's unclear and we can see about improving it. m From v.ladeuil+lp at free.fr Thu Jul 14 17:25:37 2011 From: v.ladeuil+lp at free.fr (vila) Date: Thu, 14 Jul 2011 19:25:37 +0200 Subject: [ANN] bzr 2.3.4 has gone gold Message-ID: Hi, Time has come for a new stable release: 2.3.4. There are only a few bug fixes there but we need to get through the SRU process on Ubuntu Natty and it has been blocked on a potential regression between 2.3.1 and 2.3.3. See the Changelog at https://launchpad.net/bzr/2.3/2.3.4 for more details about what is included and for the tarball. I'll make the official announcement next Tuesday morning UTC (2011-07-18) with... whatever packages/installers are available at this point. Have fun ! Vincent From mbp at canonical.com Fri Jul 15 01:45:14 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 15 Jul 2011 11:45:14 +1000 Subject: bzr babune/oneiric build now up Message-ID: Vincent set up an Ubuntu Oneiric build in Babune: There are currently a few test failures, and I think gz has already put up a couple of fixes. It's also nice to see spiv's recent test suite improvement dropped the run time by about 10%. Martin From jriddell at ubuntu.com Mon Jul 18 10:39:07 2011 From: jriddell at ubuntu.com (Jonathan Riddell) Date: Mon, 18 Jul 2011 11:39:07 +0100 Subject: Patch Pilot 12 July Message-ID: <20110718103907.GZ8283@starsky.19inch.net> Me and JAM did some patch pilot reviews last week. (Is there a good way to track these after the time? This is all I found in my e-mail archives but I suspect it's missing a couple.) https://code.launchpad.net/~mbp/bzr/filter-tree/+merge/67408 tidying up file list filters approved, needs merged by mbp https://code.launchpad.net/~arnetheduck/bzr/bzr-log-author/+merge/63751 improved match support in bzr log merged https://code.launchpad.net/~jr/bzr/68501-gpg-signing-key/+merge/67210 Add a config option signature_key for setting which GPG key should be used to sign commits. merged https://code.launchpad.net/~johnf-inodes/bzr-email-notifier/bugfix_578685/+merge /25045 fixes typo in variable name approved, needs Nicholas Allen to merge Jonathan From john at arbash-meinel.com Mon Jul 18 12:44:09 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 18 Jul 2011 14:44:09 +0200 Subject: [ANN] bzr 2.3.4 has gone gold In-Reply-To: References: Message-ID: <4E242A99.7000406@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/14/2011 7:25 PM, vila wrote: > Hi, > > Time has come for a new stable release: 2.3.4. > > There are only a few bug fixes there but we need to get through the SRU > process on Ubuntu Natty and it has been blocked on a potential > regression between 2.3.1 and 2.3.3. > > See the Changelog at https://launchpad.net/bzr/2.3/2.3.4 for more > details about what is included and for the tarball. > > I'll make the official announcement next Tuesday morning UTC > (2011-07-18) with... whatever packages/installers are available at this > point. > > Have fun ! > > Vincent > bzr windows installers 2.3.4-1 have been uploaded. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4kKpkACgkQJdeBCYSNAAMa1ACdF4s/p2kRhztriFlf6MdURsoZ SncAn3RRTLEhdyT1uipwSuz7jw89nL+5 =GN+h -----END PGP SIGNATURE----- From gordon at doxxx.net Tue Jul 19 00:02:02 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 18 Jul 2011 20:02:02 -0400 Subject: [ANN] bzr 2.3.4 has gone gold In-Reply-To: References: Message-ID: <4E24C97A.1040801@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mac OS X 10.6 installer uploaded. On 7/14/2011 1:25 PM, vila wrote: > Hi, > > Time has come for a new stable release: 2.3.4. > > There are only a few bug fixes there but we need to get through the SRU > process on Ubuntu Natty and it has been blocked on a potential > regression between 2.3.1 and 2.3.3. > > See the Changelog at https://launchpad.net/bzr/2.3/2.3.4 for more > details about what is included and for the tarball. > > I'll make the official announcement next Tuesday morning UTC > (2011-07-18) with... whatever packages/installers are available at this > point. > > Have fun ! > > Vincent > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJMl5AAoJEIrPJfWinA2ufMMH/R2E5aP8GSsqZSbnILoq6IHJ 711iMTCfAFgbMcx2U305HT6bu4RZXraq4BCL3F2C0t3Za4GHsxxQPLKvCMO057X1 UeLvBJWfDaqvfj0FKrScRA8EdMP9agS4cP3nGqiqhWVGG4qB5oo5sDCnLLq1zPio JHZrbTZl+gQXQ/orNZqU4376NSM1U/AKWfRkY3gmY7KdBGQSV2ywTJ2g0IPi1O5/ Up05vYb38EpYbloSRE1ywkS3/8JwSoh2uHCUA6KZ7iaY1bGZ2L5ktxCKR5FX1TpW 6rpWiirlQUoq3E6s3F391yacLjpEUJL+6Ivj3HTJG6610IcEAd8biUJ/KzXxCtg= =68+o -----END PGP SIGNATURE----- From mbp at canonical.com Tue Jul 19 07:24:17 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 19 Jul 2011 17:24:17 +1000 Subject: Patch Pilot 12 July In-Reply-To: <20110718103907.GZ8283@starsky.19inch.net> References: <20110718103907.GZ8283@starsky.19inch.net> Message-ID: On 18 July 2011 20:39, Jonathan Riddell wrote: > Me and JAM did some patch pilot reviews last week. > > (Is there a good way to track these after the time? ?This is all I > found in my e-mail archives but I suspect it's missing a couple.) Well, you can look back at https://code.launchpad.net/bzr/+merges to see what was merged/touched recently, which should give you a clue. I see Ubuntu does it, but I don't think listing every patch you touched is really necessary worthwhile. If you want to prove you did some work ;) you can just say you helped with half a dozen patches or whatever. I think the interesting bits from the report are: * that we did it at all, which is worth having visible * if you accomplished something big by all means mention it, like finishing off a lot of patches * if other people need to be reminded to finish something up, like in this case apparently me :) then that's worth mentioning, and in fact more prominent if you don't list a lot of no-news-is-good-news items Martin > > https://code.launchpad.net/~mbp/bzr/filter-tree/+merge/67408 > tidying up file list filters > approved, needs merged by mbp > > https://code.launchpad.net/~arnetheduck/bzr/bzr-log-author/+merge/63751 > improved match support in bzr log > merged > > https://code.launchpad.net/~jr/bzr/68501-gpg-signing-key/+merge/67210 > Add a config option signature_key for setting which GPG key should be used to > sign commits. > merged > > https://code.launchpad.net/~johnf-inodes/bzr-email-notifier/bugfix_578685/+merge > /25045 > fixes typo in variable name > approved, needs Nicholas Allen to merge > > Jonathan > > From v.ladeuil+lp at free.fr Tue Jul 19 07:47:50 2011 From: v.ladeuil+lp at free.fr (vila) Date: Tue, 19 Jul 2011 09:47:50 +0200 Subject: Patch Pilot 12 July In-Reply-To: <20110718103907.GZ8283@starsky.19inch.net> (Jonathan Riddell's message of "Mon, 18 Jul 2011 11:39:07 +0100") References: <20110718103907.GZ8283@starsky.19inch.net> Message-ID: >>>>> Jonathan Riddell writes: > Me and JAM did some patch pilot reviews last week. Thanks for the report ! > (Is there a good way to track these after the time? This is all I > found in my e-mail archives but I suspect it's missing a couple.) There are two main sources: the first is 'bzr qlog' on trunk, from there you get hints pointing to https://code.launchpad.net/bzr/+merges?field.status=MERGED&field.status-empty-marker=1 The page order should help. You may miss some patches landed on stable branches from 'bzr qlog' but the lp page should remind you about them. Tangentially, looking at the milestone page for the next release keep you in touch with was has been cooked recently or is still cooking: https://launchpad.net/bzr/+milestone/2.4.0 At the time of this writing, the page above contains an 'In Progress' bug, which should be close to landing or already landing(aka cooking), the 'Fix Released' ones were landed recently as a consequence of our time-based releases cadence (aka cooked). Vincent From jelmer at samba.org Mon Jul 18 12:06:58 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Mon, 18 Jul 2011 14:06:58 +0200 Subject: Patch Pilot 12 July In-Reply-To: <20110718103907.GZ8283@starsky.19inch.net> References: <20110718103907.GZ8283@starsky.19inch.net> Message-ID: <1310990819.4859.5.camel@localhost6> On Mon, 2011-07-18 at 11:39 +0100, Jonathan Riddell wrote: > Me and JAM did some patch pilot reviews last week. > > (Is there a good way to track these after the time? This is all I > found in my e-mail archives but I suspect it's missing a couple.) There isn't a convenient way to find out all the merge reviews you have been involved with in the past. There is https://code.launchpad.net/bzr/+merges which lists all merge reviews for bzr, including ones that have been merged or approved. Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From nmb at wartburg.edu Tue Jul 19 14:51:55 2011 From: nmb at wartburg.edu (Neil Martinsen-Burrell) Date: Tue, 19 Jul 2011 09:51:55 -0500 Subject: Patch Pilot 12 July In-Reply-To: <7dbe7e6dce3f417d84d39bb05af8909d@MSEXCHHUB02.wartburg.edu> References: <20110718103907.GZ8283@starsky.19inch.net> <7dbe7e6dce3f417d84d39bb05af8909d@MSEXCHHUB02.wartburg.edu> Message-ID: On Tue, Jul 19, 2011 at 02:47, vila wrote: > There are two main sources: the first is 'bzr qlog' on trunk, from there > you get hints pointing to [...] > You may miss some patches landed on stable branches from 'bzr qlog' but > the lp page should remind you about them. Just a reminder that qlog can work together with colocated branches, so if you have a colocated workspace with branches for trunk, 2.4, 2.3, 2.2, etc. then you can do 'bzr qlog colo:trunk colo:2.4 colo:2.3 colo:2.2' with the attached as result. This should allow you to see patches that landed on trunk from the stable branches as well. -Neil -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2011-07-19 at 09.50.00 .png Type: image/png Size: 273316 bytes Desc: not available URL: From v.ladeuil+lp at free.fr Tue Jul 19 15:55:37 2011 From: v.ladeuil+lp at free.fr (vila) Date: Tue, 19 Jul 2011 17:55:37 +0200 Subject: [ANN] bzr 2.3.4 released Message-ID: 1 new stable release: 2.3.4 ;) This is a bugfix release and upgrading is recommended for all users of earlier 2.3 releases. Many thanks to everyone who contributed feedback, suggestions, bug reports and patches ! Bazaar is now available for download from https://launchpad.net/bzr/2.3/2.3.4 as a source tarball. On the same URL you'll also find installers for windows and OSX. Packages for Ubuntu are available from the stable PPA, https://launchpad.net/~bzr/+archive/ppa The SRU process for natty is underway so regular users should also get their update soon. FreeBSD ports have been upgraded too. More details below: bzr 2.3.4 ######### :2.3.4: 2011-07-14 This is a bugfix release. Upgrading is recommended for all users of earlier 2.3 releases. This mainly fixes bug #786980 which blocked the SRU process for Ubuntu Natty. External Compatibility Breaks ***************************** None. Bug Fixes ********* * Accept some differences for ``bound_location`` from the config files that were leading to a 'ReadOnlyError: A write attempt was made in a read only transaction' error. (Vincent Ladeuil, #786980) * Don't fail with traceback if `bzr serve` is running as a service on Windows, and there is no USERNAME, nor BZR_EMAIL or other whoami-related environment variables set. (Alexander Belchenko, Bug #660174) Documentation ************* * Updated the "Using stacked branches" section of the user guide to describe committing to stacked branches and expanded its discussion of pushing a stacked branch. (Andrew Bennetts) Testing ******* * Remove the deprecation decorators for ``failUnlessExists`` and ``failIfExists``. The deprecation "will" occur in 2.4, not before. Providing the wrappers is enough as far as 2.3 is concerned. (Vincent Ladeuil #794960) From davidsantospinheiro at gmail.com Wed Jul 20 15:36:46 2011 From: davidsantospinheiro at gmail.com (David Pinheiro) Date: Wed, 20 Jul 2011 16:36:46 +0100 Subject: Bazaar on linux, administration on windows? Message-ID: Hi everyone! Sorry for the basic question, but i can't find it online. Is there any option to use bazaar (server) on linux and administer it (users, permissions, LDAP authentication, repositories, ...) graphically on a windows terminal? Thanks in advance. David Pinheiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Thu Jul 21 01:48:14 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 21 Jul 2011 11:48:14 +1000 Subject: Bazaar on linux, administration on windows? In-Reply-To: References: Message-ID: Not totally, though you may be able to use qbzr's qconfig command against a remote server. On Jul 21, 2011 1:37 AM, "David Pinheiro" wrote: > Hi everyone! > > Sorry for the basic question, but i can't find it online. > > Is there any option to use bazaar (server) on linux and administer it > (users, permissions, LDAP authentication, repositories, ...) graphically on > a windows terminal? > > Thanks in advance. > David Pinheiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From bialix at ukr.net Thu Jul 21 08:23:06 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Thu, 21 Jul 2011 11:23:06 +0300 Subject: [ANN] QBzr 0.21 final released Message-ID: <4E27E1EA.5@ukr.net> On behalf of QBzr development team I'm happy to announce new release of QBzr 0.21 codenamed "Tilia". This release intended to be used as companion release for bzr 2.4, and might support bzr 2.3. I'd like to thank the people who have helped make this release awesome. Thank you. What's new in this release -------------------------- QBzr 0.21 is companion release for bzr 2.4, and compatible with bzr 2.3. New features in this release: Now you can select changes to shelve and unshelve your saved changes with new shiny qshelve and qunshelve dialogs. qdiff window has been reworked and all controls moved to a toolbar, similar to one in qannotate window. Also qdiff toolbar provides you new functions: text search within active pane and also knob to ignore whitespace changes (it's also available as command-line option). User can configure the tab width and this setting affects qdiff, qannotate and qcat windows. By default tab width equals to 8 characters, user can set new default value in bazaar.conf as ``tab_width = N`` (either via qconfig or editing [DEFAULT] section of bazaar.conf). Also user can set individual tab width for branches in their branch.conf. User can configure tab width via "View Options" menu in toolbars of qdiff, qannotate. QBzr provides support for new builtin feature of bzr: mergetools. Now you can easier configure your favorite diff/merge tool to be used from qconflicts or context menu in qbrowse (Working Tree browser in Bazaar Explorer). If you have python-gpgme installed and you have enabled gpg-signatures for your commits then you can see new messages regarding valid gpg-signatures available in qlog. Also you can run check of your signatures with new qverify-signatures command. Other changes include major rework of qinfo dialog (show the same information as CLI ``bzr info`` does), qcommit dialog now remembers state of "Show non-versioned" knob between runs, now it's possible to save old state of the file from qlog dialog (using context menu in file list), error dialogs has been improved (now also support apport if available) and several other improvements and bugfixes (see full changelog for details at the end of this mail). Downloads --------- Sources tarball and windows installer available to download from https://launchpad.net/qbzr/0.21/0.21 Release branch: lp:qbzr/0.21 About QBzr ---------- QBzr is a cross-platform GUI front end for Bazaar, based on Qt toolkit. QBzr provided GUI frontend for many core bzr commands and several universal dialogs and helper commands. Equivalents for core bzr commands has the same names as CLI commands but with prefix "q". QBzr is used as library of GUI dialogs in other products: * Bazaar Explorer * TortoiseBzr * QBzr-Eclipse QBzr at Launchpad: https://launchpad.net/qbzr Changelog --------- Changes after 0.21 beta 1: * qcat: * Fixed problem with viewing file from qbrowse. (Alexander Belchenko, Bug #776196) * qinfo: * Turned off word-wrap in location label: prevents strange path display if there are spaces in the path. (A. S. Budden, Bug #781040) * Fixed UnicodeError for non-ascii paths. (Alexander Belchenko, Bug #790138) * qdiff, qannotate: * Tab-width can be customised from the view menu. (Bug #490377, A. S. Budden) * qgetnew: * The target location no longer gets overwritten when the source location changes. (Andr?? Bachmann) * qlog: * File list context menu: added support to save content of a file of specific revision as a new file. (Andr?? Bachmann) * Show digital signature information for commits if python-gpgme is installed * Improved error dialogs on internal/other error, support for apport (if it's available). (Jonathan Riddell) * Branch/Checkout dialogs: * Fixed UnicodeDecodeError with non-ascii paths in target directory picker. (Alexander Belchenko, Bug #789083) * Use bzrlib.mergetools for managing and using external merge tools in qconfig and qconflicts. (Bug #489915, Gordon Tyler) * New qshelve / qunshelve dialogs. (IWATA Hidetaka) * New command qverify-signatures to show digital signature statuses for branch commits Changes in 0.21 beta 1: * qbranch: * Fixed problem with very small width of input fields in the dialog on Mac OSX. (Timothy Reaves, Bug #667090) * qbrowse: * Use `qcat --native` equivalent to allow opening copies of files from branches without working trees. (A. S. Budden, Bug #752422) * qcommit: * Remember "Show non-versioned" checkbox state. (Nick Sonneveld, Bug #258926) * qconflicts: * Fixed internal error when there is conflict in non-versioned file. (Alexander Belchenko, Bug #655451) * qdiff: * New toolbar with controls and options (similar to qannotate's toolbar). (Dorin Scutara??u) * Support for ignore whitespace differences in changes. This mode can be turned on from command-line (`qdiff -w` or `qdiff --ignore-whitespace`) and from GUI itself (in View Options). (Dorin Scutara??u, Glen Mailer, Bug #642000) * Added Find action to do text search within either pane. (Dorin Scutara??u, Bug #497832) * qinfo: * Significantly simpler implementation that shows the information provided by Bazaar. This fills in the gaps in the data shown by qinfo (such as details of checkouts) and means that changes to 'bzr info' will automatically be reflected in qinfo. (A. S. Budden, Bug #439624) * qsubprocess: * Reliable exception encoding to pass exception attributes from subprocess to the GUI process. (Martin [gz], Bug #686735) * qannotate, qdiff: * Find text box turns red if no matches are found. (A. S. Budden, Bug #772244) * qcat, qannotate, qdiff, qconfig: * Added ability to customise the tab-stop width (setting in qconfig, affects qcat, qannotate and qdiff). The setting is stored in [DEFAULT] section of bazaar.conf, and is named tab_width (it can also be configured with qconfig). Units are characters (so 4 means a tab should be displayed with the width of 4 spaces). The default value is 8. The setting can also be adjusted in branch.conf for specific branches. (Bug #490377, A. S. Budden) Alexander From bialix at ukr.net Thu Jul 21 09:51:22 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Thu, 21 Jul 2011 12:51:22 +0300 Subject: [ANN] Bazaar Explorer 1.2.0 released Message-ID: <4E27F69A.7000303@ukr.net> On behalf of the Bazaar Explorer Developers, I'm pleased to announce "Leif Ericson", our 1.2.0 release. Bazaar Explorer is a desktop application for using the Bazaar version control system, a modern VCS that supports both centralized and distributed version control. Our 1.1.1 release runs on GNU/Linux (both GNOME and KDE), Windows and OS X desktops and is available in many languages. Download -------- See page https://launchpad.net/bzr-explorer/1.2/1.2.0 for tarball and windows installer. Changelog --------- New features: * "Shelve changes" and "Unshelve changes" menu items have been added to Bazaar -> Work menu. Require QBzr 0.21 or later. (Alexander Belchenko) Improvements: * History, shared repository and branch views now refresh automatically when there are changes (Jonathan Riddell, Bug #792308) * Some performance improvements (Alexander Belchenko): * Faster creation of big lists with changes in Working Tree or changes against submit branch. * Don't refresh main view too often. Bug Fixes: * Use the parent branch in the submit pane when working with bound branches. (A. S. Budden, Bug #777108) * Improvements to tab names and tooltips when working with bound branches. Simplification of code that determines locations for all types of location. (A. S. Budden) * Remove use of deprecated shlex_split_unicode() (Jonathan Riddell, Bug #781204) Enjoy! Alexander P.S. I need somebody to help me maintain Bazaar Explorer and QBzr projects. Today I'm going on a vacation and won't be able to address urgent bugfixes within next 2 weeks. If you want to help just apply to membership in ~qbzr-dev and/or ~bzr-explorer-dev groups. From john at arbash-meinel.com Thu Jul 21 12:28:43 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Thu, 21 Jul 2011 14:28:43 +0200 Subject: Should Launchpad pre-fetch tagged revisions in preparation for bzr 2.4 Message-ID: <4E281B7B.2030107@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Now that bzr-2.4 is almost out, I was wondering if we want to write a script that runs through Launchpad branches, and tries to fill in tagged revisions in the development focus. My thoughts: 1) We did this manually for bzr, because we have a lot of revisions that are tagged but not on the mainline. And it made a very noticeable impact on the size and speed for new stacked branches. 2) I think people will migrate piecemeal to 2.4, and we'll start getting bug reports that it is slower and less efficient than 2.3. Which we'll be triaging one-by-one until they someone upgrades to 2.4 and does the push to their trunk. 3) Someone pushing to trunk can take arbitrarily long. Consider that for bzr, the only one with commit rights to trunk is a hard-to-upgrade robot. 4) The reason we didn't make a big deal of it, is because we didn't expect most branches to have a lot of tagged revisions, that weren't also in the development focus history. However, I just started investigating bug #388269 for gcc-linaro, and they have 2626 tags that are not in the development focus history. I think the issue is because it is a bzr-svn conversion. And creating a tag in svn *also* creates a commit. So almost every tag is going to not be in the history of the primary branch. 5) If I'm right about bzr-svn, this is probably a strong reason why we *want* to fetch tagged revisions, but also a strong reason why we are likely to see a lot of fallout from this change. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4oG3sACgkQJdeBCYSNAAOkzQCeMMMXnJ3FeRANonVQ1j8ZcFUj PBAAni0sstu6ni7zACfUPkWFViY4xvyu =WF85 -----END PGP SIGNATURE----- From robertc at robertcollins.net Thu Jul 21 20:03:29 2011 From: robertc at robertcollins.net (Robert Collins) Date: Fri, 22 Jul 2011 08:03:29 +1200 Subject: Should Launchpad pre-fetch tagged revisions in preparation for bzr 2.4 In-Reply-To: <4E281B7B.2030107@arbash-meinel.com> References: <4E281B7B.2030107@arbash-meinel.com> Message-ID: On Fri, Jul 22, 2011 at 12:28 AM, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Now that bzr-2.4 is almost out, I was wondering if we want to write a > script that runs through Launchpad branches, and tries to fill in tagged > revisions in the development focus. That could be very useful. Uhm, we may and|or want a reporting tool that just gets stats and tells us about problem cases. -Rob From v.ladeuil+lp at free.fr Fri Jul 22 08:48:42 2011 From: v.ladeuil+lp at free.fr (vila) Date: Fri, 22 Jul 2011 10:48:42 +0200 Subject: babune is now able to run -proposed for SRUs Message-ID: Hi, I just finished adding http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/ This job installs bzr from natty-proposed and run the full test suite for the installed bzr. This will be run every 24h from now (and be extended to other series). Vincent From john at arbash-meinel.com Fri Jul 22 09:07:57 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 22 Jul 2011 11:07:57 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: References: Message-ID: <4E293DED.20708@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/22/2011 10:48 AM, vila wrote: > Hi, > > I just finished adding > http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/ > > This job installs bzr from natty-proposed and run the full test suite > for the installed bzr. > > This will be run every 24h from now (and be extended to other series). > > Vincent > I like that we're running the test suite, but it doesn't feel quite right. My thoughts: 1) Aren't we running the test suite as part of building the package? So any given revision in natty-proposed has *already* passed the test suite on natty. 2) Development isn't being done in a "-proposed" branch. AIUI, it shouldn't get into the -proposed branch until we've released a stable version. Which means the testing should be done on our stable branches (which I think you're already doing). Anyway, I'm not against doing it, but I don't really see what benefit we get out of it, either. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4pPe0ACgkQJdeBCYSNAAPKTgCeO6lVTinWSxHH1Lvsi8MoJ9/d duYAn2BGt06sSLEivfgHEy1PD3/jO5Es =6NsD -----END PGP SIGNATURE----- From jelmer at samba.org Fri Jul 22 09:17:10 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Fri, 22 Jul 2011 11:17:10 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: <4E293DED.20708@arbash-meinel.com> References: <4E293DED.20708@arbash-meinel.com> Message-ID: <4E294016.3020302@samba.org> On 22/07/11 11:07, John Arbash Meinel wrote: > On 7/22/2011 10:48 AM, vila wrote: >> Hi, >> >> I just finished adding >> http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/ >> >> This job installs bzr from natty-proposed and run the full test suite >> for the installed bzr. >> >> This will be run every 24h from now (and be extended to other series). >> >> Vincent >> > I like that we're running the test suite, but it doesn't feel quite > right. My thoughts: > > 1) Aren't we running the test suite as part of building the package? So > any given revision in natty-proposed has *already* passed the test suite > on natty. Yep. > 2) Development isn't being done in a "-proposed" branch. AIUI, it > shouldn't get into the -proposed branch until we've released a stable > version. Which means the testing should be done on our stable branches > (which I think you're already doing). > > Anyway, I'm not against doing it, but I don't really see what benefit we > get out of it, either. The SRU process ( https://wiki.ubuntu.com/StableReleaseUpdates) requires that proposed packages (and the bugs they fix) are verified. Usually this happens by manually checking that each backported bugfix has not broken anything. For Bazaar, we are allowed to verify that the built packages are not broken by running the testsuite from the installed package on the target distroseries. Running the test suite from the package might catch some issues like incomplete installation. In the past we've forgotten to install some of our packages, resulting in a broken bzr when installed, when it ran fine from the source tree. Likewise, we have had bugs in the packaging that caused files to be installed in the wrong location. Cheers, Jelmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.ladeuil+lp at free.fr Fri Jul 22 09:31:20 2011 From: v.ladeuil+lp at free.fr (vila) Date: Fri, 22 Jul 2011 11:31:20 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: <4E293DED.20708@arbash-meinel.com> (John Arbash Meinel's message of "Fri, 22 Jul 2011 11:07:57 +0200") References: <4E293DED.20708@arbash-meinel.com> Message-ID: >>>>> John Arbash Meinel writes: > On 7/22/2011 10:48 AM, vila wrote: >> Hi, >> >> I just finished adding >> http://babune.ladeuil.net:24842/view/SRUs/job/selftest-chroot-natty-proposed/ >> >> This job installs bzr from natty-proposed and run the full test suite >> for the installed bzr. >> >> This will be run every 24h from now (and be extended to other series). >> >> Vincent >> > I like that we're running the test suite, but it doesn't feel quite > right. My thoughts: > 1) Aren't we running the test suite as part of building the > package? So any given revision in natty-proposed has *already* > passed the test suite on natty. The test suite during the build runs against the built version, this job runs against an installed version, different contexts. > 2) Development isn't being done in a "-proposed" branch. AIUI, it > shouldn't get into the -proposed branch until we've released a > stable version. Which means the testing should be done on our > stable branches (which I think you're already doing). The job doesn't run against a branch, it runs against the -proposed repository. > Anyway, I'm not against doing it, but I don't really see what > benefit we get out of it, either. Hope this clarifies, Vincent From john at arbash-meinel.com Fri Jul 22 10:37:13 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 22 Jul 2011 12:37:13 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: References: <4E293DED.20708@arbash-meinel.com> Message-ID: <4E2952D9.1030005@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> This will be run every 24h from now (and be extended to other series). > >> > >> Vincent > >> > > > I like that we're running the test suite, but it doesn't feel quite > > right. My thoughts: > > > 1) Aren't we running the test suite as part of building the > > package? So any given revision in natty-proposed has *already* > > passed the test suite on natty. > > The test suite during the build runs against the built version, this job > runs against an installed version, different contexts. So there is some benefit, though I wonder about running every 24-hrs. Certainly it only needs to be run when something changes? Which is approx 1/month at most. > > > 2) Development isn't being done in a "-proposed" branch. AIUI, it > > shouldn't get into the -proposed branch until we've released a > > stable version. Which means the testing should be done on our > > stable branches (which I think you're already doing). > > The job doesn't run against a branch, it runs against the -proposed > repository. I understood that. The main difference is that it runs against installed vs recently built. Also, does it start from a scratch Natty or does it just overwrite the previous install? I'm thinking we'll probably miss install dependency issues if we just overwrite. John =:-> > > > Anyway, I'm not against doing it, but I don't really see what > > benefit we get out of it, either. > > Hope this clarifies, > > Vincent -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4pUtkACgkQJdeBCYSNAAMCMwCg2DCK7bzIJzWBr3dWLPLioVWF rOsAoNIUQNpYYjuzya0R/w7V9nxe58nj =jZ0m -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Fri Jul 22 11:44:33 2011 From: v.ladeuil+lp at free.fr (vila) Date: Fri, 22 Jul 2011 13:44:33 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: <4E2952D9.1030005@arbash-meinel.com> (John Arbash Meinel's message of "Fri, 22 Jul 2011 12:37:13 +0200") References: <4E293DED.20708@arbash-meinel.com> <4E2952D9.1030005@arbash-meinel.com> Message-ID: >>>>> John Arbash Meinel writes: >> >> This will be run every 24h from now (and be extended to other series). >> >> >> >> Vincent >> >> >> >> > I like that we're running the test suite, but it doesn't feel quite >> > right. My thoughts: >> >> > 1) Aren't we running the test suite as part of building the >> > package? So any given revision in natty-proposed has *already* >> > passed the test suite on natty. >> >> The test suite during the build runs against the built version, this job >> runs against an installed version, different contexts. > So there is some benefit, though I wonder about running every 24-hrs. > Certainly it only needs to be run when something changes? Which is > approx 1/month at most. also, could we get them to run every 24h or so? poolie: what would be the point ? if we want to automate, I can look into checking the package version well, it means there's a fair chance there will be something up to date when i go to look at it rather than there being a guarantee i need to ask for a new build also, it's probably easier than scripting it? hmm right, let's start with every 24h >> >> > 2) Development isn't being done in a "-proposed" branch. AIUI, it >> > shouldn't get into the -proposed branch until we've released a >> > stable version. Which means the testing should be done on our >> > stable branches (which I think you're already doing). >> >> The job doesn't run against a branch, it runs against the -proposed >> repository. > I understood that. The main difference is that it runs against installed > vs recently built. > Also, does it start from a scratch Natty or does it just overwrite > the previous install? it overrides for now, the plan is to get closer to a really fresh install when time permits or it becomes necessary. > I'm thinking we'll probably miss install dependency issues if we > just overwrite. I trust apt there do you have a specific case in mind that apt won't cover ? Vincent From john at arbash-meinel.com Fri Jul 22 11:47:29 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 22 Jul 2011 13:47:29 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: References: <4E293DED.20708@arbash-meinel.com> <4E2952D9.1030005@arbash-meinel.com> Message-ID: <4E296351.109@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > it overrides for now, the plan is to get closer to a really fresh > install when time permits or it becomes necessary. > > > I'm thinking we'll probably miss install dependency issues if we > > just overwrite. > > I trust apt there do you have a specific case in mind that apt won't > cover ? > > Vincent bzr-2.3.3 has "Requires: python-foo" but bzr-2.3.4 does *not* have it. If you install bzr-2.3.3 first and then upgrade to bzr-2.3.4 then you'll still have python-foo. But someone installing bzr-2.3.4 from scratch will not. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4pY1EACgkQJdeBCYSNAAMEjQCgwfLmyuR9P+nQVvyqohCoOWJt p4EAn38HYR68nDt5Rr6/8ovOtsJ1hdPa =HmT2 -----END PGP SIGNATURE----- From v.ladeuil+lp at free.fr Fri Jul 22 14:27:32 2011 From: v.ladeuil+lp at free.fr (vila) Date: Fri, 22 Jul 2011 16:27:32 +0200 Subject: babune is now able to run -proposed for SRUs In-Reply-To: <4E296351.109@arbash-meinel.com> (John Arbash Meinel's message of "Fri, 22 Jul 2011 13:47:29 +0200") References: <4E293DED.20708@arbash-meinel.com> <4E2952D9.1030005@arbash-meinel.com> <4E296351.109@arbash-meinel.com> Message-ID: >>>>> John Arbash Meinel writes: > ... >> it overrides for now, the plan is to get closer to a really fresh >> install when time permits or it becomes necessary. >> >> > I'm thinking we'll probably miss install dependency issues if we >> > just overwrite. >> >> I trust apt there do you have a specific case in mind that apt won't >> cover ? >> >> Vincent > bzr-2.3.3 has "Requires: python-foo" but bzr-2.3.4 does *not* have > it. If you install bzr-2.3.3 first and then upgrade to bzr-2.3.4 > then you'll still have python-foo. But someone installing > bzr-2.3.4 from scratch will not. Right, given that SRUs are targeted at stable installations *and* that we are unlikely to tweak the dependencies on a stable series, I'm not that worried. Thanks for raising the issue nevertheless, Vincent From v.ladeuil+lp at free.fr Fri Jul 22 17:23:11 2011 From: v.ladeuil+lp at free.fr (vila) Date: Fri, 22 Jul 2011 19:23:11 +0200 Subject: [pilot] Summary July 22th Message-ID: Hi, My name is vila and I've been your Patch Pilot this week. My co-pilot was Jonathan Riddell and I confess he did so well I almost had a nap ;) We had a pleasant fly again, as the following pretty picture shows: http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-wip-reviews,bzr-merged-reviews.derivative%29 1789 ! Revolution ! As the time of this writing that's the overall number of reviews landed on bzr: http://webnumbr.com/bzr-merged-reviews who knows what will come next ? We'll see... In the mean time, this week, we observed (among others): * Jelmer boiling some water in preparation for more co-located branches support. * John giving us a nice way for UDD developers to activate a check about their package freshness when talking to launchpad (nag him (John, not lp) if you want this to be back-ported to 2.4 or 2.3). Thanks again for flying with us, I hope you'll enjoy your flight next week with Andrew[1], Vincent P.S.: Give him a round of applause for his last flight with us (for the foreseeable future, but who knows ;) From newsgroups at catchall.shelter13.net Fri Jul 22 18:11:02 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Fri, 22 Jul 2011 20:11:02 +0200 Subject: Binary file storage similar to Kiln Message-ID: Hi, Kiln is an extension to Mercurial which stores binary files on a server centrally, so clients can save a lot of storage space when binaries are used. Basically, certain files in the repository are marked as "large" and only the hashes are stored on the clients. When the file is required, it is transferred in full from the server. Server side, it seems to store the full data of each file for each revision. Is something like this planned for Bazaar? How invasive would such a change be? Can this be done with a plugin? (Naively, I would assume that all is needed is some way to mark files as large and do a pre-commit/post-checkout fixup client side and somehow abuse the transport layer. In particular, the repository could just store an UUID instead of the actual file contents and when checking out, the client would contact the server to retrieve the actual contents if an large file is encountered.) Cheers, Anteru From john at arbash-meinel.com Fri Jul 22 18:24:24 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 22 Jul 2011 20:24:24 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: References: Message-ID: <4E29C058.9060303@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/22/2011 8:11 PM, Anteru wrote: > Hi, > > Kiln is an extension to Mercurial which stores binary files on a server > centrally, so clients can save a lot of storage space when binaries are > used. Basically, certain files in the repository are marked as "large" > and only the hashes are stored on the clients. When the file is > required, it is transferred in full from the server. Server side, it > seems to store the full data of each file for each revision. > > Is something like this planned for Bazaar? How invasive would such a > change be? Can this be done with a plugin? > > (Naively, I would assume that all is needed is some way to mark files as > large and do a pre-commit/post-checkout fixup client side and somehow > abuse the transport layer. In particular, the repository could just > store an UUID instead of the actual file contents and when checking out, > the client would contact the server to retrieve the actual contents if > an large file is encountered.) > > Cheers, > Anteru > > You could write a content filter that would have the 'canonical' form be the hash of the file, and the 'convenient' form be the expanded content. I don't know how specifically efficient, etc it would be, but you could do it. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4pwFcACgkQJdeBCYSNAAPrkgCfaGoX+aOCjPwgLWv2nmIOAH+C 9rkAnj7Us0dgUneiGs1bF6yOeDUSCE/h =bUBu -----END PGP SIGNATURE----- From newsgroups at catchall.shelter13.net Fri Jul 22 20:47:07 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Fri, 22 Jul 2011 22:47:07 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E29C058.9060303@arbash-meinel.com> References: <4E29C058.9060303@arbash-meinel.com> Message-ID: <4E29E1CB.5080005@catchall.shelter13.net> Hi, > You could write a content filter that would have the 'canonical' form be > the hash of the file, and the 'convenient' form be the expanded content. thanks. I just browsed the docs, this seems at least like a good starting point. Is there some example of a content filter somewhere? I checked my locally installed plugins, and there doesn't seem to be any. Assuming I get the content filter working, I would change the read operation to fetch the actual file from the server and the write to store only the hash plus transferring the file contents if the hash is not yet known on the server side. For this, I need communication with the server. Is it possible to hook the bzr transport layer for this? Or should I make that completely separate and use my own transport method? Cheers, Anteru From mbp at canonical.com Fri Jul 22 21:54:28 2011 From: mbp at canonical.com (Martin Pool) Date: Sat, 23 Jul 2011 07:54:28 +1000 Subject: babune is now able to run -proposed for SRUs In-Reply-To: References: <4E293DED.20708@arbash-meinel.com> <4E2952D9.1030005@arbash-meinel.com> <4E296351.109@arbash-meinel.com> Message-ID: I hope we'll soon extend this to also test the beta and daily ppas, which will have a higher rate of change and so probably find more exciting results. Using a schroot snapshot to install into a minimal clean environment should be useful. I'd also like to use this to test whether bzr and its plugins are all simultaneously mutually installable and whether they pass their test suites. Martin From amanic at gmail.com Fri Jul 22 21:55:13 2011 From: amanic at gmail.com (Marius Kruger) Date: Fri, 22 Jul 2011 23:55:13 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E29E1CB.5080005@catchall.shelter13.net> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> Message-ID: On 22 July 2011 22:47, Anteru wrote: > Assuming I get the content filter working, I would change the read > operation to fetch the actual file from the server and the write to > store only the hash plus transferring the file contents if the hash is > not yet known on the server side. For this, I need communication with > the server. Is it possible to hook the bzr transport layer for this? Or > should I make that completely separate and use my own transport method? > bzrlib is a cool python library that you can and should use, including the transport parts. -- <>< Marius ><> -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at arbash-meinel.com Sat Jul 23 06:57:05 2011 From: john at arbash-meinel.com (John Meinel) Date: Sat, 23 Jul 2011 08:57:05 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E29E1CB.5080005@catchall.shelter13.net> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> Message-ID: http://Launchpad.net/bzr-keywords Uses the content filter code. I wonder if you'll actually rather have 2 files. Foo.meta and Foo.dat. And when we read/write Foo.meta you play with Foo.data which is otherwise ignored. It seems cleaner to me, at least. John =:-> On Jul 22, 2011 10:47 PM, "Anteru" wrote: > Hi, > >> You could write a content filter that would have the 'canonical' form be >> the hash of the file, and the 'convenient' form be the expanded content. > thanks. I just browsed the docs, this seems at least like a good > starting point. Is there some example of a content filter somewhere? I > checked my locally installed plugins, and there doesn't seem to be any. > > Assuming I get the content filter working, I would change the read > operation to fetch the actual file from the server and the write to > store only the hash plus transferring the file contents if the hash is > not yet known on the server side. For this, I need communication with > the server. Is it possible to hook the bzr transport layer for this? Or > should I make that completely separate and use my own transport method? > > Cheers, > Anteru -------------- next part -------------- An HTML attachment was scrubbed... URL: From newsgroups at catchall.shelter13.net Fri Jul 22 20:47:07 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Fri, 22 Jul 2011 22:47:07 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E29C058.9060303@arbash-meinel.com> References: <4E29C058.9060303@arbash-meinel.com> Message-ID: <4E29E1CB.5080005@catchall.shelter13.net> Hi, > You could write a content filter that would have the 'canonical' form be > the hash of the file, and the 'convenient' form be the expanded content. thanks. I just browsed the docs, this seems at least like a good starting point. Is there some example of a content filter somewhere? I checked my locally installed plugins, and there doesn't seem to be any. Assuming I get the content filter working, I would change the read operation to fetch the actual file from the server and the write to store only the hash plus transferring the file contents if the hash is not yet known on the server side. For this, I need communication with the server. Is it possible to hook the bzr transport layer for this? Or should I make that completely separate and use my own transport method? Cheers, Anteru From gordon at doxxx.net Sat Jul 23 14:11:49 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Sat, 23 Jul 2011 10:11:49 -0400 Subject: [ANN] bzr 2.3.4 released In-Reply-To: References: Message-ID: <4E2AD6A5.2040301@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've uploaded a new version of the bzr2.3.4 installer for Mac OS X that includes qbzr 0.20.2. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOKtalAAoJEIrPJfWinA2ulzgH/3IHSyY/I5rfAD2vho9xurzk KcMlt9lQ/ODyA8ebqG4jBemnx2mqYYGrGCc4GlMURsWtDkcrunQPUZJq6RHhHaFU 5DywkztR9fSjAmGcaZstU0ysWurkBRnOcAZAtJbJUpV3ZvlHotQMV07Zy/EKKBCN MREGOudper7zgl6j3U4PH3RvyBbcbBO/fHg+hMNBDV2NAjQeIwiOLvtOWfNm7/OB KvduOtxdrCoa6vW/3aM+SHa7v/nW8n+mjH5ub6daqs5lNI7oilehGo/5nUddRaUi gXXEBJay5En30lym3JgkJchVzUzFuVQ/Hpz6K0IWrpeKroCTZf1/7EhzianKF8U= =T0I5 -----END PGP SIGNATURE----- From amanic at gmail.com Sat Jul 23 16:49:57 2011 From: amanic at gmail.com (Marius Kruger) Date: Sat, 23 Jul 2011 18:49:57 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> Message-ID: On 23 July 2011 08:57, John Meinel wrote: > http://Launchpad.net/bzr-keywords > Uses the content filter code. > > I wonder if you'll actually rather have 2 files. Foo.meta and Foo.dat. And > when we read/write Foo.meta you play with Foo.data which is otherwise > ignored. > yes or Foo.data.meta or it could even go into a single file eg. .bzrmeta/bigfiles which contains lines the path and the hash of each big file. -- <>< Marius ><> -------------- next part -------------- An HTML attachment was scrubbed... URL: From newsgroups at catchall.shelter13.net Sat Jul 23 18:16:23 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sat, 23 Jul 2011 20:16:23 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> Message-ID: <4E2B0FF7.30807@catchall.shelter13.net> Hi, > or it could even go into a single file eg. > .bzrmeta/bigfiles > which contains lines the path and the hash of each big file. all right, thanks for the keywords link, that definitely looks like a starting point. So how do you suggest to start? By having some meta files storing the hash which are tracked "as usual" by bzr, and get hold of the binary file associated with it using content filters? I'm new to Bazaar, and I haven't written a plugin for it yet, so here's some guesswork: Wouldn't this break when the file is actually changed? I.e. let's assume I want a work-flow like this ... bzr add-big foo.bin // foo.bin.meta gets added to the repository bzr ci // foo.bin.meta is committed // foo.bin gets transferred using some method to the server // other machine bzr pull // foo.bin.meta is checked out // content filter recognizes the file and fetches foo.bin touch foo.bin bzr status // will show foo.bin.meta as untouched, right? bzr ci // won't update foo.bin.meta, will it? My plan is initially to store the large files locally on disk and just get the hooking part working (i.e. no server-side communication.) I think it's enough if every binary file gets hashed and gets stored under its hash, delta compression is not important here at first and could be possibly added later on anyway. That should be the easy part. I assume the hard part is to get the transport layer to transfer the files and get them stored server-side. Cheers, Anteru From john at arbash-meinel.com Sat Jul 23 19:15:19 2011 From: john at arbash-meinel.com (John Meinel) Date: Sat, 23 Jul 2011 21:15:19 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E2B0FF7.30807@catchall.shelter13.net> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> <4E2B0FF7.30807@catchall.shelter13.net> Message-ID: The transfer shouldn't be too bad. from bzrlib import transport t = transport.get_transport(central_url) t.put_bytes(hash_path, bytes) There are a few ways to configure everything. John =:-> On Jul 23, 2011 8:17 PM, "Anteru" wrote: > Hi, > >> or it could even go into a single file eg. >> .bzrmeta/bigfiles >> which contains lines the path and the hash of each big file. > all right, thanks for the keywords link, that definitely looks like a > starting point. So how do you suggest to start? By having some meta > files storing the hash which are tracked "as usual" by bzr, and get hold > of the binary file associated with it using content filters? > > I'm new to Bazaar, and I haven't written a plugin for it yet, so here's > some guesswork: Wouldn't this break when the file is actually changed? > I.e. let's assume I want a work-flow like this ... > > bzr add-big foo.bin > // foo.bin.meta gets added to the repository > bzr ci > // foo.bin.meta is committed > // foo.bin gets transferred using some method to the server > > // other machine > bzr pull > // foo.bin.meta is checked out > // content filter recognizes the file and fetches foo.bin > touch foo.bin > bzr status > // will show foo.bin.meta as untouched, right? > bzr ci > // won't update foo.bin.meta, will it? > > My plan is initially to store the large files locally on disk and just > get the hooking part working (i.e. no server-side communication.) I > think it's enough if every binary file gets hashed and gets stored under > its hash, delta compression is not important here at first and could be > possibly added later on anyway. That should be the easy part. I assume > the hard part is to get the transport layer to transfer the files and > get them stored server-side. > > Cheers, > Anteru > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From checker at d6.com Sat Jul 23 19:29:31 2011 From: checker at d6.com (Chris Hecker) Date: Sat, 23 Jul 2011 12:29:31 -0700 Subject: Binary file storage similar to Kiln In-Reply-To: <4E2B0FF7.30807@catchall.shelter13.net> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> <4E2B0FF7.30807@catchall.shelter13.net> Message-ID: <4E2B211B.2020903@d6.com> I think large binary support is one of the biggest problems preventing adoption of DVCS in industry, at least in my industry (video games), so I'm glad there is some work in the area. I didn't know about Kiln until your mail, and after reading about kbfiles it seems like they've made some progress on the problem, but it's a bummer it appears to be tightly integrated with their commercial product (and it's hg). I have some notes I've been meaning to post about "requirements" for a large binaries feature to be really usable and valuable, but there's been a fair amount of talk about it on various lists and wikis and whatnot so you should check those out. I think the main problem is that as long as the core folks don't think it's an important problem to solve and that it should be relegated to plugins, we're never going to get something that "just works" in a really robust way. This could be a great place for bzr to innovate and differentiate, but most open source projects (and a fair percentage of commercial projects, to be fair) don't have a lot of binary files, so there's not much pressure to solve the problem. The entire game industry would switch overnight if this and the nested subtree thing were solved well, though. It seems like the Right Way to do this is to have the concept of branches which don't have all the revisions in them and that refer to other repositories for parts of the history if it's requested as a fundamental feature, and then you can build large binary support off that relatively easily (a large binary file is marked as only storing the latest revision, or better yet, the latest n revisions, where n is settable by users when they branch, or anytime). The key thing here is that the large binaries are stored in the real repository on the server where disk space is unlimited, just not on every client (unless the client wants a full branch). Storing the large binaries in another system with a plugin is always going to be hack compared to doing it right in the repo. That said, if you do a stop-gap hack as a plugin that works well enough, I'll definitely help you test it! :) Anything is better than running a parallel svn tree for binaries. Thanks, Chris On 2011/07/23 11:16, Anteru wrote: > Hi, > >> or it could even go into a single file eg. >> .bzrmeta/bigfiles >> which contains lines the path and the hash of each big file. > all right, thanks for the keywords link, that definitely looks like a > starting point. So how do you suggest to start? By having some meta > files storing the hash which are tracked "as usual" by bzr, and get hold > of the binary file associated with it using content filters? > > I'm new to Bazaar, and I haven't written a plugin for it yet, so here's > some guesswork: Wouldn't this break when the file is actually changed? > I.e. let's assume I want a work-flow like this ... > > bzr add-big foo.bin > // foo.bin.meta gets added to the repository > bzr ci > // foo.bin.meta is committed > // foo.bin gets transferred using some method to the server > > // other machine > bzr pull > // foo.bin.meta is checked out > // content filter recognizes the file and fetches foo.bin > touch foo.bin > bzr status > // will show foo.bin.meta as untouched, right? > bzr ci > // won't update foo.bin.meta, will it? > > My plan is initially to store the large files locally on disk and just > get the hooking part working (i.e. no server-side communication.) I > think it's enough if every binary file gets hashed and gets stored under > its hash, delta compression is not important here at first and could be > possibly added later on anyway. That should be the easy part. I assume > the hard part is to get the transport layer to transfer the files and > get them stored server-side. > > Cheers, > Anteru > > > From newsgroups at catchall.shelter13.net Sat Jul 23 20:54:14 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sat, 23 Jul 2011 22:54:14 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E2B211B.2020903@d6.com> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> <4E2B0FF7.30807@catchall.shelter13.net> <4E2B211B.2020903@d6.com> Message-ID: <4E2B34F6.7030107@catchall.shelter13.net> Hi Chris, yeah, that's actually the reason why I'm looking into this at all. I have a research engine and it already has a bunch of binaries in the source tree (test textures, other test meshes, binary font files, stuff like this) and I basically see only two solutions to get it working with Bazaar: * Wait for foreign branch support: This would solve it neatly, as I could just have a subdirectory as a lightweight checkout and everything is fine. There's a bunch of problems with that approach when it comes to merging though (how do you merge trees which refer to different versions of the external branch?) (Right now, I have a lightweight checkout branch for the binary stuff, and the workflow sucks.) * Have Kiln-style binary file support right inside Bazaar: Binary files are stored along everything else, just the way they are retrieved changes. Approach two seemed easier to me, and now I just need to figure out how much work it's going to be. > I have some notes I've been meaning to post about "requirements" for a > large binaries feature to be really usable and valuable, but there's > been a fair amount of talk about it on various lists and wikis and > whatnot so you should check those out. Do you have some link? > The entire game > industry would switch overnight if this and the nested subtree thing > were solved well, though. I bet a bunch of researchers would like that as well, having large test data in a repository is not uncommon. > That said, if you do a stop-gap hack as a plugin that works well enough, > I'll definitely help you test it! :) Anything is better than running a > parallel svn tree for binaries. That's cool, thanks! Cheers, Anteru From john at arbash-meinel.com Mon Jul 25 09:41:53 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 25 Jul 2011 11:41:53 +0200 Subject: Should Launchpad pre-fetch tagged revisions in preparation for bzr 2.4 In-Reply-To: References: <4E281B7B.2030107@arbash-meinel.com> Message-ID: <4E2D3A61.6020002@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/21/2011 10:03 PM, Robert Collins wrote: > On Fri, Jul 22, 2011 at 12:28 AM, John Arbash Meinel > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Now that bzr-2.4 is almost out, I was wondering if we want to write a >> script that runs through Launchpad branches, and tries to fill in tagged >> revisions in the development focus. > > That could be very useful. Uhm, we may and|or want a reporting tool > that just gets stats and tells us about problem cases. > > -Rob I did start putting something like this together. I ran it against gcc branches, and none of the missing tags were found. My guess is that the SVN import was done somewhere else. Do we have access to that location? Does anyone? If the tagged revisions aren't available, then maybe it doesn't matter, and we should just help them nuke tags that don't point at available revisions. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4tOmEACgkQJdeBCYSNAANRxACgjNv6M35tYh1NKE5ZP57EZmUi p8QAn3mNr0RUXfUie/yg2bxuys1KZZ8u =vzNg -----END PGP SIGNATURE----- From iwata0303 at gmail.com Mon Jul 25 15:07:20 2011 From: iwata0303 at gmail.com (Iwata) Date: Tue, 26 Jul 2011 00:07:20 +0900 Subject: TortoiseBZR 0.6.4 beta1 has been released Message-ID: Hi. I've tagged release-0.6.4b1 to lp:tortoisebzr. New feature: * Shelve / Unshelve (qbzr 0.21 required) * Direct add mode. It would be helpful if you could update translations of your favorite language. Thanks. -- IWATA Hidetaka From newsgroups at catchall.shelter13.net Mon Jul 25 17:56:28 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Mon, 25 Jul 2011 19:56:28 +0200 Subject: Getting started with a content filter Message-ID: Hi, I'm trying to write a content filter and there's a bunch of things I don't get yet: * How do I specify for which files the content filter should be run? It seems the rules file is the right place for this. I can add a section like this there ... [name *.bin] binstore = on but is there a way to get more complex rules via Bazaar? In my case, I'd like to enable it for file X only (by adding some metadata to a file.) If there is no way to attach it to a file, can files in the repository be uniquely identified? * The file contents are passed to the content filter as chunks, which are strings. That basically forces me to have the whole file in memory. Is there a way to obtain a stream-interface to the file instead of the file contents? * What is the recommended way to get debug output out of my plugin? bzrlib.trace? Is there something else specific for debugging? Cheers, Anteru From checker at d6.com Tue Jul 26 02:16:00 2011 From: checker at d6.com (Chris Hecker) Date: Mon, 25 Jul 2011 19:16:00 -0700 Subject: bzrtools multi-push Message-ID: <4E2E2360.4040009@d6.com> Why is there a multi-pull but no multi-push? Chris From mbp at canonical.com Tue Jul 26 05:46:00 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 26 Jul 2011 15:46:00 +1000 Subject: Getting started with a content filter In-Reply-To: References: Message-ID: On 26 July 2011 03:56, Anteru wrote: > Hi, > > I'm trying to write a content filter and there's a bunch of things I > don't get yet: > > * How do I specify for which files the content filter should be run? It > seems the rules file is the right place for this. I can add a section > like this there ... > > [name *.bin] > binstore = on > > but is there a way to get more complex rules via Bazaar? In my case, I'd > like to enable it for file X only (by adding some metadata to a file.) > If there is no way to attach it to a file, can files in the repository > be uniquely identified? You can look up per-branch configuration options if you want to let users control what is stored or where. But based on the previous discussion it seemed to me that you'd probably want to have a file in .bzrmeta that gives some additional files that ought to be checked out, and the places to put them at? > * The file contents are passed to the content filter as chunks, which > are strings. That basically forces me to have the whole file in memory. > Is there a way to obtain a stream-interface to the file instead of the > file contents? The idea is that the stream can be a generator and then you don't need the whole thing in memory at one time. (This might not be perfectly achieved but that's the idea.) > * What is the recommended way to get debug output out of my plugin? > bzrlib.trace? Is there something else specific for debugging? trace.mutter; if you think this will generate large amounts of output then you should make it conditional if 'binstore' in debug.debug_flags: mutter('unpack %s in %s') ... Martin From john at arbash-meinel.com Tue Jul 26 08:33:27 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 26 Jul 2011 10:33:27 +0200 Subject: bzrtools multi-push In-Reply-To: <4E2E2360.4040009@d6.com> References: <4E2E2360.4040009@d6.com> Message-ID: <4E2E7BD7.1040803@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/26/2011 4:16 AM, Chris Hecker wrote: > > Why is there a multi-pull but no multi-push? > > Chris Generally bzrtools are commands that Aaron wanted to improve his workflow. I'm guessing there isn't any specific reason, other than he may follow many branches, but is only really working on one branch at a time. If you write it, I'm pretty sure he'll merge it. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ue9cACgkQJdeBCYSNAAMbOwCgogl1zJENJ7OYk8mgkn152Zew mXQAn2ZBVOmMXF98YU7Ty9hvAzzek/oM =LkRT -----END PGP SIGNATURE----- From john at arbash-meinel.com Tue Jul 26 09:15:37 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 26 Jul 2011 11:15:37 +0200 Subject: Getting started with a content filter In-Reply-To: References: Message-ID: <4E2E85B9.8000407@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > * The file contents are passed to the content filter as chunks, which > are strings. That basically forces me to have the whole file in memory. > Is there a way to obtain a stream-interface to the file instead of the > file contents? I think technically a "file" object implements the chunked interface. However, we may be assuming you can do ''.join() on it. > > * What is the recommended way to get debug output out of my plugin? > bzrlib.trace? Is there something else specific for debugging? > > Cheers, > Anteru > > trace.mutter is pretty good for debug information. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4uhbkACgkQJdeBCYSNAAMhYACcCiFAejiYnN0T6769PtEB6hVb IlgAoNbFd8wIhAY+dh8rsUdE7GUgEJSP =M1Db -----END PGP SIGNATURE----- From Dennis.Benzinger at gmx.net Tue Jul 26 19:12:01 2011 From: Dennis.Benzinger at gmx.net (Dennis Benzinger) Date: Tue, 26 Jul 2011 21:12:01 +0200 Subject: Fixed bug 735417 Message-ID: <4E2F1181.4070306@gmx.net> Hi! I've just pushed a branch with a fix for https://bugs.launchpad.net/bzr/+bug/735417 to lp:~dennis-benzinger/bzr/735417-BZR_PROGRESS_BAR-help-update. This is my first bug fix for Bazaar so I'm not sure about the process for bug fixes. Should I create a merge proposal now or do you want to do some basic checks before? (Not that there is much to check :-)). While I changed the help text in bzrlib/help_topics/__init__.py I've noticed that the old values are also mentioned in doc/ja/user-reference/index.txt. I don't speak Japanese so I could not correct them. Thanks for your patience, Dennis Benzinger From jelmer at samba.org Tue Jul 26 19:31:03 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Tue, 26 Jul 2011 21:31:03 +0200 Subject: Fixed bug 735417 In-Reply-To: <4E2F1181.4070306@gmx.net> References: <4E2F1181.4070306@gmx.net> Message-ID: <1311708686.18762.4.camel@genhwyvar> Hi Dennis, On Tue, 2011-07-26 at 21:12 +0200, Dennis Benzinger wrote: > I've just pushed a branch with a fix for > https://bugs.launchpad.net/bzr/+bug/735417 to > lp:~dennis-benzinger/bzr/735417-BZR_PROGRESS_BAR-help-update. This is my > first bug fix for Bazaar so I'm not sure about the process for bug > fixes. Should I create a merge proposal now or do you want to do some > basic checks before? (Not that there is much to check :-)). Now is probably the best moment to create the merge proposal - the merge proposal is also very useful for tracking status. It makes it a lot easier for reviewers to see what still needs reviewing (https://code.launchpad.net/bzr/+activereviews) and gives us a forum for discussing your changes. > While I changed the help text in bzrlib/help_topics/__init__.py I've > noticed that the old values are also mentioned in > doc/ja/user-reference/index.txt. I don't speak Japanese so I could not > correct them. I think that's fine - presumably the revision history of the English version is used to find things that have changed since the Japanese translation was first made. Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From checker at d6.com Tue Jul 26 22:40:18 2011 From: checker at d6.com (Chris Hecker) Date: Tue, 26 Jul 2011 15:40:18 -0700 Subject: bzrtools multi-push In-Reply-To: <4E2E7BD7.1040803@arbash-meinel.com> References: <4E2E2360.4040009@d6.com> <4E2E7BD7.1040803@arbash-meinel.com> Message-ID: <4E2F4252.7030506@d6.com> Okay, I'll take a look. I assume I should do it as a separate plugin, not hack it into bzrtools? Chris On 2011/07/26 01:33, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 7/26/2011 4:16 AM, Chris Hecker wrote: >> >> Why is there a multi-pull but no multi-push? >> >> Chris > > Generally bzrtools are commands that Aaron wanted to improve his > workflow. I'm guessing there isn't any specific reason, other than he > may follow many branches, but is only really working on one branch at a > time. > > If you write it, I'm pretty sure he'll merge it. > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk4ue9cACgkQJdeBCYSNAAMbOwCgogl1zJENJ7OYk8mgkn152Zew > mXQAn2ZBVOmMXF98YU7Ty9hvAzzek/oM > =LkRT > -----END PGP SIGNATURE----- > From checker at d6.com Tue Jul 26 22:41:37 2011 From: checker at d6.com (Chris Hecker) Date: Tue, 26 Jul 2011 15:41:37 -0700 Subject: bzrtools multi-push In-Reply-To: <4E2F4252.7030506@d6.com> References: <4E2E2360.4040009@d6.com> <4E2E7BD7.1040803@arbash-meinel.com> <4E2F4252.7030506@d6.com> Message-ID: <4E2F42A1.1000402@d6.com> Or, wait, duh, I just do it as a merge with bzr on lp. Sorry, I've been submitting text diff patches to the Kerberos project for a week, I forgot there's a better way to do this. :) Chris On 2011/07/26 15:40, Chris Hecker wrote: > > Okay, I'll take a look. I assume I should do it as a separate plugin, > not hack it into bzrtools? > > Chris > > > On 2011/07/26 01:33, John Arbash Meinel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 7/26/2011 4:16 AM, Chris Hecker wrote: >>> >>> Why is there a multi-pull but no multi-push? >>> >>> Chris >> >> Generally bzrtools are commands that Aaron wanted to improve his >> workflow. I'm guessing there isn't any specific reason, other than he >> may follow many branches, but is only really working on one branch at a >> time. >> >> If you write it, I'm pretty sure he'll merge it. >> >> John >> =:-> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (Cygwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk4ue9cACgkQJdeBCYSNAAMbOwCgogl1zJENJ7OYk8mgkn152Zew >> mXQAn2ZBVOmMXF98YU7Ty9hvAzzek/oM >> =LkRT >> -----END PGP SIGNATURE----- >> From mbp at canonical.com Wed Jul 27 00:38:44 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 27 Jul 2011 10:38:44 +1000 Subject: bzrtools multi-push In-Reply-To: <4E2F4252.7030506@d6.com> References: <4E2E2360.4040009@d6.com> <4E2E7BD7.1040803@arbash-meinel.com> <4E2F4252.7030506@d6.com> Message-ID: Yes, doing this as a merge into bzr itself would be better; we generally want a batteries-included approach unless there's a downside to including it. Martin From newsgroups at catchall.shelter13.net Wed Jul 27 16:44:37 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Wed, 27 Jul 2011 18:44:37 +0200 Subject: Getting started with a content filter In-Reply-To: References: Message-ID: <4E304075.6000000@catchall.shelter13.net> Hi, > You can look up per-branch configuration options if you want to let > users control what is stored or where. But based on the previous > discussion it seemed to me that you'd probably want to have a file in > .bzrmeta that gives some additional files that ought to be checked > out, and the places to put them at? the main problem is how to distinguish between files with the same path. I.e. the user might to bzr add-large foo.png && bzr ci // mark foo.png as large bzr rm foo.png && bzr ci bzr add foo.png && bzr ci // foo.png is a small file now, and shouldn't be tracked any more Going with the meta-route, I'm going to check in foo.png.meta when using add-large, so I have something in the repository to get hold on. How would this work with .bzrmeta? I definitely need something versioned to attach the meta-data to, and the first plan is to simply store the meta-data instead of the actual data in the repository. Cheers, Anteru From amanic at gmail.com Wed Jul 27 17:04:12 2011 From: amanic at gmail.com (Marius Kruger) Date: Wed, 27 Jul 2011 19:04:12 +0200 Subject: Getting started with a content filter In-Reply-To: <4E304075.6000000@catchall.shelter13.net> References: <4E304075.6000000@catchall.shelter13.net> Message-ID: On 27 July 2011 18:44, Anteru wrote: ... > Going with the meta-route, I'm going to check in foo.png.meta when using > add-large, so I have something in the repository to get hold on. How > would this work with .bzrmeta? The .bzrmeta directory is also versioned and is where plugins can store data like this by convention. The externals plugin for example stores an "externals" file in there that keeps track of external branches which are branched/checked out into specified directories in the working tree. > I definitely need something versioned to > attach the meta-data to, and the first plan is to simply store the > meta-data instead of the actual data in the repository. > -- <>< Marius ><> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Thu Jul 28 01:15:16 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 28 Jul 2011 11:15:16 +1000 Subject: Getting started with a content filter In-Reply-To: <4E304075.6000000@catchall.shelter13.net> References: <4E304075.6000000@catchall.shelter13.net> Message-ID: On 28 July 2011 02:44, Anteru wrote: > Hi, > >> You can look up per-branch configuration options if you want to let >> users control what is stored or where. ?But based on the previous >> discussion it seemed to me that you'd probably want to have a file in >> .bzrmeta that gives some additional files that ought to be checked >> out, and the places to put them at? > the main problem is how to distinguish between files with the same path. > I.e. the user might to > > bzr add-large foo.png && bzr ci > // mark foo.png as large > bzr rm foo.png && bzr ci > bzr add foo.png && bzr ci > // foo.png is a small file now, and shouldn't be tracked any more bzr adds files with a unique id (file_id), so you can distinguish these cases. However, I think it's perhaps jumping ahead a bit to assume this is the way that users want to deal with very large files. I think storing files outside of the repository is essentially a bit of a hack and if we're going to do that, perhaps we should just do the simplest thing that would possibly help. To me, that's something like just having a post-wt-update hook that reads a file with a list of URLs and paths, and downloads the relevant files. There's another possible path, which is to tune the in-repository code to handle very large files efficiently: probably putting them into their own groupcompress packs, not compressing them against anything else, being careful to use streaming interfaces, never doing text diffs on them. It's not impossible and the foundations are there but it will take some work; probably mostly just iterating to see where each problem is. If you want a totally smooth "works just like small files" experience, I think this is the way to go. m From checker at d6.com Thu Jul 28 03:02:07 2011 From: checker at d6.com (Chris Hecker) Date: Wed, 27 Jul 2011 20:02:07 -0700 Subject: Getting started with a content filter In-Reply-To: References: <4E304075.6000000@catchall.shelter13.net> Message-ID: <4E30D12F.10407@d6.com> > each problem is. If you want a totally smooth "works just like small > files" experience, I think this is the way to go. This would be super awesome and the right path for the future, if you think it's a viable way to go. However, how would you solve the "need to support partial history" part that's needed to make this work? In other words, there are (at least) three problems with large binary files: 1. Memory. This is the easiest one to fix, since it's just an optimization thing, iterating to find the problem spots, use streams, different packs, etc. like you say. 2. Can't have entire history in all branches because it gets too big too fast on clients, need to store most of the large binary history on a server. Is there a way to specify a partial history like this now? Are stacked branches something that could help here? It'd have to be per-file, though, not global to the entire branch. In other words, I want all the code revisions local (or most of them), but only the past two large binary revisions, or whatever. The code would need to delete old history locally as new history is checked in (assuming it's been successfully pushed to the server, of course). 3. Need some kind of locking protocol so two artists don't edit an unmergable file at the same time. I know this is heresy for dvcs, but it's going to have to get solved somehow if people are going to use bzr for these media projects that need the large binary files. I think this isn't that big of a deal for this use-case, because #2 is going to require a server be accessible often anyway. Not sure what to do when both artists are offline, but at least warning would be something. Chris On 2011/07/27 18:15, Martin Pool wrote: > On 28 July 2011 02:44, Anteru wrote: >> Hi, >> >>> You can look up per-branch configuration options if you want to let >>> users control what is stored or where. But based on the previous >>> discussion it seemed to me that you'd probably want to have a file in >>> .bzrmeta that gives some additional files that ought to be checked >>> out, and the places to put them at? >> the main problem is how to distinguish between files with the same path. >> I.e. the user might to >> >> bzr add-large foo.png&& bzr ci >> // mark foo.png as large >> bzr rm foo.png&& bzr ci >> bzr add foo.png&& bzr ci >> // foo.png is a small file now, and shouldn't be tracked any more > > bzr adds files with a unique id (file_id), so you can distinguish > these cases. However, I think it's perhaps jumping ahead a bit to > assume this is the way that users want to deal with very large files. > > I think storing files outside of the repository is essentially a bit > of a hack and if we're going to do that, perhaps we should just do the > simplest thing that would possibly help. To me, that's something like > just having a post-wt-update hook that reads a file with a list of > URLs and paths, and downloads the relevant files. > > There's another possible path, which is to tune the in-repository code > to handle very large files efficiently: probably putting them into > their own groupcompress packs, not compressing them against anything > else, being careful to use streaming interfaces, never doing text > diffs on them. It's not impossible and the foundations are there but > it will take some work; probably mostly just iterating to see where > each problem is. If you want a totally smooth "works just like small > files" experience, I think this is the way to go. > > m > > From stephen at xemacs.org Thu Jul 28 04:30:47 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 28 Jul 2011 13:30:47 +0900 Subject: Getting started with a content filter In-Reply-To: <4E30D12F.10407@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> Message-ID: <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> Chris Hecker writes: > 2. Can't have entire history in all branches because it gets too big > too fast on clients, need to store most of the large binary history > on a server. Is there a way to specify a partial history like this > now? Are stacked branches something that could help here? It'd > have to be per-file, though, not global to the entire branch. In > other words, I want all the code revisions local (or most of them), > but only the past two large binary revisions, or whatever. The > code would need to delete old history locally as new history is > checked in (assuming it's been successfully pushed to the server, > of course). Except for the autodelete of old revisions of binaries, the above should all be straightforwardly scriptable in git, assuming keeping BLOBs in BLOB-only subdirectories is acceptable. I know you didn't want to hear that, but there you go. You should keep that in the back of your mind if bzr doesn't get a usable feature soon. (My bet is that Anteru's project will pay off, by the way, so it's likely a moot point.) The closest you can come in current bzr is the two-branch scheme, one a regular branch with a local repo containing the code and the other a lightweight checkout of, or branch stacked on a branch, on the server. (I think you are the one who described the lightweight checkout version of the idea.) Using a stacked branch will not get you the autodelete feature, though, and the lightweight checkout is probably too draconian (only the current version is accessible locally). On the other hand, I'm not sure that autodelete of old revisions is such a good idea. There has to be an easy-to-invoke way to prune them, of course, but I have the feeling that autodelete is going to mess up people who are editing and getting relatively rapid series of revisions. In an autodelete environment, though, they're inevitably going to want to refer to rev. N-1, where rev. N is the most recent available locally. > 3. Need some kind of locking protocol so two artists don't edit an > unmergable file at the same time. I know this is heresy for dvcs, The reason that it's heresy is that it's really not do-able by the VCS, even a centralized one, unless your artists never refer to other people's work while they're editing their own. Once your artists have local checkouts of files they're not editing at the moment but might decide to edit at any time, VCS-based locking is either unreliable or excruciatingly painful for the user. The only time VCS-based locking works well is when you have a strong division of labor, and only occasionally run into clashes. But then you mostly don't need it anyway.... If the editor does it, however, things become very simple. If the artists are offline, they can't communicate anyway. You warn the user, who can then proceed at own risk or not. If they are online, they can see the server, and dotfile locking on the server by the editor is basically what you want, plus some discipline of "commit early". This may require some scripting or the GUI equivalent to make the discipline transparent to the users, of course. From checker at d6.com Thu Jul 28 05:23:25 2011 From: checker at d6.com (Chris Hecker) Date: Wed, 27 Jul 2011 22:23:25 -0700 Subject: Getting started with a content filter In-Reply-To: <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4E30F24D.3040505@d6.com> > On the other hand, I'm not sure that autodelete of old revisions is > such a good idea. I'd be okay with a manual prune of old history if it was fast and worked well. But, once the feature is in, there's no reason you couldn't also have it run automatically for artists as an option. I think I know about all the workarounds with the various dvcses right now, and they're all pretty bad. If I don't get something in bzr by the time my content directories grow (either the separate server hack with stub files, or the Real Thing), I will just put those in svn or p4 since I know they work. That will suck, but I'm mentally prepared for it. Most game developers just say dvcs isn't worth they trouble if they can't have all their files in one system, and I can empathize with that. I'm not sure why you say the locking thing doesn't work with a centralized vcs; it works fine in practice. The file is marked as exclusive-checkout, it's read-only until checkout, you check it out, it's made writable, your name is added to a list on the server, when somebody else tries to check it out, it says "Stephen has it checked out already", you can walk over and ask them what's up, or the admin can force uncheckout the file, and you can always toggle the read-only flag locally if you know what you're doing. That workflow is not fancy, but it works fine, and it prevents two artists from modifying an unmergable file. It has to be supported by the vcs because the reality is it isn't supported by all (any?) editors, so that's a non-starter. I'm not sure what you could do about the online requirement to make it less heresy, but the fact is, the feature is needed if the large binary support is going to be usable by production teams, even if it only works online and warns heavily if you're offline. The good news is it seems artists work on laptops on planes and cafes way less frequently than programmers do, so the online-only constraint won't actually be that painful. Chris On 2011/07/27 21:30, Stephen J. Turnbull wrote: > Chris Hecker writes: > > > 2. Can't have entire history in all branches because it gets too big > > too fast on clients, need to store most of the large binary history > > on a server. Is there a way to specify a partial history like this > > now? Are stacked branches something that could help here? It'd > > have to be per-file, though, not global to the entire branch. In > > other words, I want all the code revisions local (or most of them), > > but only the past two large binary revisions, or whatever. The > > code would need to delete old history locally as new history is > > checked in (assuming it's been successfully pushed to the server, > > of course). > > Except for the autodelete of old revisions of binaries, the above > should all be straightforwardly scriptable in git, assuming keeping > BLOBs in BLOB-only subdirectories is acceptable. I know you didn't > want to hear that, but there you go. You should keep that in the back > of your mind if bzr doesn't get a usable feature soon. (My bet is > that Anteru's project will pay off, by the way, so it's likely a moot > point.) > > The closest you can come in current bzr is the two-branch scheme, one > a regular branch with a local repo containing the code and the other a > lightweight checkout of, or branch stacked on a branch, on the server. > (I think you are the one who described the lightweight checkout > version of the idea.) Using a stacked branch will not get you the > autodelete feature, though, and the lightweight checkout is probably > too draconian (only the current version is accessible locally). > > On the other hand, I'm not sure that autodelete of old revisions is > such a good idea. There has to be an easy-to-invoke way to prune > them, of course, but I have the feeling that autodelete is going to > mess up people who are editing and getting relatively rapid series of > revisions. In an autodelete environment, though, they're inevitably > going to want to refer to rev. N-1, where rev. N is the most recent > available locally. > > > 3. Need some kind of locking protocol so two artists don't edit an > > unmergable file at the same time. I know this is heresy for dvcs, > > The reason that it's heresy is that it's really not do-able by the > VCS, even a centralized one, unless your artists never refer to other > people's work while they're editing their own. Once your artists have > local checkouts of files they're not editing at the moment but might > decide to edit at any time, VCS-based locking is either unreliable or > excruciatingly painful for the user. The only time VCS-based locking > works well is when you have a strong division of labor, and only > occasionally run into clashes. But then you mostly don't need it > anyway.... > > If the editor does it, however, things become very simple. If the > artists are offline, they can't communicate anyway. You warn the > user, who can then proceed at own risk or not. If they are online, > they can see the server, and dotfile locking on the server by the > editor is basically what you want, plus some discipline of "commit > early". This may require some scripting or the GUI equivalent to make > the discipline transparent to the users, of course. > > From mbp at canonical.com Thu Jul 28 06:33:36 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 28 Jul 2011 16:33:36 +1000 Subject: Getting started with a content filter In-Reply-To: <4E30F24D.3040505@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> Message-ID: On 28 July 2011 15:23, Chris Hecker wrote: > >> On the other hand, I'm not sure that autodelete of old revisions is >> such a good idea. > > I'd be okay with a manual prune of old history if it was fast and worked > well. ?But, once the feature is in, there's no reason you couldn't also have > it run automatically for artists as an option. > > I think I know about all the workarounds with the various dvcses right now, > and they're all pretty bad. ?If I don't get something in bzr by the time my > content directories grow (either the separate server hack with stub files, > or the Real Thing), I will just put those in svn or p4 since I know they > work. So, if you put those files into svn, won't svn want to keep them forever? Or will you edit them out of the svn history (I forget the command but I believe there is one), reset the history from time to time, or just live with it because it's only on one server not every machine? m From checker at d6.com Thu Jul 28 07:07:30 2011 From: checker at d6.com (Chris Hecker) Date: Thu, 28 Jul 2011 00:07:30 -0700 Subject: Getting started with a content filter In-Reply-To: References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> Message-ID: <4E310AB2.8040608@d6.com> > time, or just live with it because it's only on one server not every > machine? Yeah, sorry, I wasn't being clear: you DEFINITELY want all the revisions, you just want them on the server that has the 10TB raid array, not the laptop with 1gb free or you have to start deleting pictures of your kids to make space. :) You want the server to have everything, all the history for every file, text, small binary, or large binary. Then, clients branch from that, and you want to get all the code and small binary revisions, and only n of the large binary revisions. If you have a 100mb psd file, you might want 2 or 3 revisions to be kept. If you have a 1gb light map, you might want only 1, or even 0 (meaning lightweight checkout, nothing in the repo, and you know you'll always be on gigabit ethernet when dealing with that file). Clients should be able to choose how much history they get per file, and plugins can set defaults, like maybe brackets per file size. If I check in a new 100mb psd, then I want this magical perfect system to put it in the local branch/shared repository. Then, when I push (or if I have auto-pushing turned on, can't remember what it's called), then I want it to confirm that the psd makes it to the server, and then I want it to kill the n+1th copy of the psd in my repository (or I do this with a manual prune, whichever, it just needs to be easy and quick). If I ask for an old revision, if it's local, no problem, if some of it's remote, then it prompts, and maybe I wait. Not sure what happens to the local repo if I ask for r1 and I'm on r1000 and there are large binaries, but that's not too common, so any reasonable behavior is okay here. Best would probably be something like it takes the history horizon and applies it around that number, or something. The super fancy version might have a sparse local repo, so it could have holes in it, so I can get r50-55 and r998-1000 or something, but that's totally not necessary. The repository should have all the history logs locally, but just not all the file data for these large files. That way I can search the logs quickly, see which files changed, etc. Etc. Chris On 2011/07/27 23:33, Martin Pool wrote: > On 28 July 2011 15:23, Chris Hecker wrote: >> >>> On the other hand, I'm not sure that autodelete of old revisions is >>> such a good idea. >> >> I'd be okay with a manual prune of old history if it was fast and worked >> well. But, once the feature is in, there's no reason you couldn't also have >> it run automatically for artists as an option. >> >> I think I know about all the workarounds with the various dvcses right now, >> and they're all pretty bad. If I don't get something in bzr by the time my >> content directories grow (either the separate server hack with stub files, >> or the Real Thing), I will just put those in svn or p4 since I know they >> work. > > So, if you put those files into svn, won't svn want to keep them > forever? Or will you edit them out of the svn history (I forget the > command but I believe there is one), reset the history from time to > time, or just live with it because it's only on one server not every > machine? > > m > From stephen at xemacs.org Thu Jul 28 09:13:36 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Thu, 28 Jul 2011 18:13:36 +0900 Subject: Getting started with a content filter In-Reply-To: <4E30F24D.3040505@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> Message-ID: <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> Chris Hecker writes: > > > On the other hand, I'm not sure that autodelete of old revisions is > > such a good idea. > > I'd be okay with a manual prune of old history if it was fast and worked > well. But, once the feature is in, there's no reason you couldn't also > have it run automatically for artists as an option. True. My bet is that you'll need to tune frequency for some of them, though. > I'm not sure why you say the locking thing doesn't work with a > centralized vcs; it works fine in practice. Well, as I said it will work if you have a sufficiently low frequency of collisions. I'm surprised you consider lock-management-by-walking- around a reasonable workflow, but obviously I've underestimated the cost of a simultaneous edit or overestimated the cost of "walking around" in your environment (probably both). I'm also surprised that you expect editors to universally refuse to edit read-only files. Some text editors, at least programmers' editors on Unix, are perfectly happy to allow you to edit content loaded from a read-only file. You only find out about that when you try to save, and the editor tells you the original is read-only and asks for an alternative name, or (given POSIX semantics for directories) whether you want to try to force-write the original. > It has to be supported by the vcs because the reality is it isn't > supported by all (any?) editors, so that's a non-starter. Well, you'd have to wrap the editors in scripts or a GUI front-end to make the workflow transparent. > I'm not sure what you could do about the online requirement to make it > less heresy, Requiring that the VCS be online most of the time is not heresy in Bazaar. Bazaar supports lightweight checkouts (and does it well), which require contact with the server for anything related to revisions other than the one checked-out. Edit-locking is a serious design problem, though, because it can only be made to work reliably in a very centralized context. As you've acknowledged (indirectly) it's probably quite possible to come up with a robust design presuming your environment, but it's going to be very tough nut to crack for the general user if there's even a teeny bit of distributedness (eg, stacked branches) involved. From checker at d6.com Thu Jul 28 10:04:53 2011 From: checker at d6.com (Chris Hecker) Date: Thu, 28 Jul 2011 03:04:53 -0700 Subject: Getting started with a content filter In-Reply-To: <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4E313445.3000708@d6.com> > I'm surprised you consider lock-management-by-walking- around a > reasonable workflow, It's way better than the alternative, which is two different artists spending a day working on the same file, and then having to either choose which version to keep, pissing off one of the artists, or forcing them to spend another day "merging" their work, pissing off both of them. And yes, the rate of collisions is low, because everybody is working on different stuff most of the time, and that stuff is (at least roughly) centrally planned by producers or art directors. But, the VCS has to at least put up a fight if two people try to work on the same thing. Walking around, IM, a phone call, these are all reasonably efficient ways of dealing with the problem, even on distributed game teams. If you're in Montreal and you find somebody in Shanghai has locked a texture file you want to edit, you send them an email, and then go work on something else until they reply. It's just a different set of use-cases from programming, where that would block you completely because you can't fix the header or whatever and you can't finish your feature because of that. It works fine for art assets. > I'm also surprised that you expect editors to universally refuse to > edit read-only files. It may not be universal, but they almost all warn if the file is read-only, mostly because they've been made to work well with p4 over the past decade. > Well, you'd have to wrap the editors in scripts or a GUI front-end > to make the workflow transparent. Artists can be trained to use p4win and similar things just fine. They just need help for things they can't magically know, like somebody else on the team is in the middle of editing the same psd. That's the problem we're trying to solve here, and it's totally solvable with a couple reasonable assumptions. > Edit-locking is a serious design problem, though, because it can > only be made to work reliably in a very centralized context. Sure, which is why I was musing about the general dvcs case in my previous mail, but the centralized case is still an incredibly important use-case (at least for my industry, and I would assume any industry that has humans editing large unmergable binary files). It's important not to get hung up on not being able to solve the hard theoretical problem perfectly, and not use that as an excuse to not solve the important and relatively easy practical problem that people actually need solved. Again, all this may be totally specific to my industry (video games), but I'd guess it isn't. And, as I was remarking to Martin and John offlist, if bzr solved these problems right, like making large binary files 1st class citizens rather than handled with hacky plugins, then it would be a big leap forward for dvcs. I know a lot of people in the game industry who would love to switch to dvcs from p4/svn, but they have to have the large unmergable binary file problems solved first. My guess is open source projects will start to get more and more assets like these in them as things become more graphically oriented, too. Chris On 2011/07/28 02:13, Stephen J. Turnbull wrote: > Chris Hecker writes: > > > > > On the other hand, I'm not sure that autodelete of old revisions is > > > such a good idea. > > > > I'd be okay with a manual prune of old history if it was fast and worked > > well. But, once the feature is in, there's no reason you couldn't also > > have it run automatically for artists as an option. > > True. My bet is that you'll need to tune frequency for some of them, > though. > > > I'm not sure why you say the locking thing doesn't work with a > > centralized vcs; it works fine in practice. > > Well, as I said it will work if you have a sufficiently low frequency > of collisions. I'm surprised you consider lock-management-by-walking- > around a reasonable workflow, but obviously I've underestimated the > cost of a simultaneous edit or overestimated the cost of "walking > around" in your environment (probably both). > > I'm also surprised that you expect editors to universally refuse to > edit read-only files. Some text editors, at least programmers' > editors on Unix, are perfectly happy to allow you to edit content > loaded from a read-only file. You only find out about that when you > try to save, and the editor tells you the original is read-only and > asks for an alternative name, or (given POSIX semantics for > directories) whether you want to try to force-write the original. > > > It has to be supported by the vcs because the reality is it isn't > > supported by all (any?) editors, so that's a non-starter. > > Well, you'd have to wrap the editors in scripts or a GUI front-end to > make the workflow transparent. > > > I'm not sure what you could do about the online requirement to make it > > less heresy, > > Requiring that the VCS be online most of the time is not heresy in > Bazaar. Bazaar supports lightweight checkouts (and does it well), > which require contact with the server for anything related to > revisions other than the one checked-out. > > Edit-locking is a serious design problem, though, because it can only > be made to work reliably in a very centralized context. As you've > acknowledged (indirectly) it's probably quite possible to come up with > a robust design presuming your environment, but it's going to be very > tough nut to crack for the general user if there's even a teeny bit of > distributedness (eg, stacked branches) involved. > From simon.kersey at ipl.com Thu Jul 28 12:52:13 2011 From: simon.kersey at ipl.com (Simon Kersey) Date: Thu, 28 Jul 2011 12:52:13 +0000 (UTC) Subject: Getting started with a content filter References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> Message-ID: Chris Hecker d6.com> writes: > > > > 3. Need some kind of locking protocol so two artists don't edit an > unmergable file at the same time. I know this is heresy ... But I had a go at it anyway see https://launchpad.net/bzr-reserved-edit It would probably need to be tweaked for your needs - it assumes that the centralized repository is on a shared file system but that shouldn't be too difficult. Cheers, Simon From Dennis.Benzinger at gmx.net Thu Jul 28 19:33:29 2011 From: Dennis.Benzinger at gmx.net (Dennis Benzinger) Date: Thu, 28 Jul 2011 21:33:29 +0200 Subject: How to fix bug 498952? Message-ID: <4E31B989.4000209@gmx.net> Hi! I'm trying to fix bug , but I'm not sure it should be done. Would it be acceptable to use the reStructuredText parser from docutils? Or should additional dependencies be avoided and some regex based parsing of the table be used? Best regards, Dennis Benzinger From newsgroups at catchall.shelter13.net Thu Jul 28 20:12:13 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Thu, 28 Jul 2011 22:12:13 +0200 Subject: Getting started with a content filter In-Reply-To: <4E313445.3000708@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> Message-ID: <4E31C29D.3050306@catchall.shelter13.net> Hi, so just before this discussion gets completely out-of-scope :) Is there some wiki/discussion page/blueprint where we can take down notes so the use cases can be gathered somewhere? It seems to me that use-cases and solutions get mixed up a bit, which is not a good thing. I totally agree with Martin that large files should just work as small files. Ideally, you just set some per-branch value of how much space I'm willing to allocate to old revisions of binary files. That doesn't sound too hard in theory, once the actual work-flow is written down. As I don't have the expertise to improve bzr to the point where all data is passed around as streams, I'll focus on the proof-of-concept plugin which just adds some support for storing large files. I'm away for the next three weeks though, so progress might be a bit slow. Re locks: Locking files can be done already with a plugin, can't it? You just have to perform a commit to add some metadata on check-out and another one on check-in, and your editor must pick up the metadata. I can't see how file locking can be built in into a DVCS unless you run a lightweight checkout, and honestly, isn't that enough for artists anyway? Do artists really need old revisions from the repository? My feeling is that artists are fine with tons of local copies that they somehow manage on their own, so having a lightweight checkout for them shouldn't be much of a problem. For developers, you want real branches of course, but that's fine as developers shouldn't collide on binary content anyway. Cheers, Anteru From mbp at canonical.com Thu Jul 28 22:46:48 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 29 Jul 2011 08:46:48 +1000 Subject: Getting started with a content filter In-Reply-To: <4E31C29D.3050306@catchall.shelter13.net> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> <4E31C29D.3050306@catchall.shelter13.net> Message-ID: On 29 July 2011 06:12, Anteru wrote: > Hi, > > so just before this discussion gets completely out-of-scope :) > > Is there some wiki/discussion page/blueprint where we can take down > notes so the use cases can be gathered somewhere? It seems to me that > use-cases and solutions get mixed up a bit, which is not a good thing. Yes, you can put it into . I would suggest (but it's up to you) basing it on the template from , because that has had a lot of success in avoiding scope creep, bikeshedding or premature implementation details. Martin From checker at d6.com Thu Jul 28 22:51:15 2011 From: checker at d6.com (Chris Hecker) Date: Thu, 28 Jul 2011 15:51:15 -0700 Subject: Getting started with a content filter In-Reply-To: <4E31C29D.3050306@catchall.shelter13.net> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> <4E31C29D.3050306@catchall.shelter13.net> Message-ID: <4E31E7E3.7070602@d6.com> > Re locks: Locking files can be done already with a plugin, can't it? Yeah, let's worry about locking later, since it's the _way_ easier problem to solve. Doing the large file handling is much harder and more important to get right for moving forward. I'll check out Simon's plugin at some point, it sounds like a good starting point, and yeah, I think I plugin can handle the locking just fine. Chris On 2011/07/28 13:12, Anteru wrote: > Hi, > > so just before this discussion gets completely out-of-scope :) > > Is there some wiki/discussion page/blueprint where we can take down > notes so the use cases can be gathered somewhere? It seems to me that > use-cases and solutions get mixed up a bit, which is not a good thing. > > I totally agree with Martin that large files should just work as small > files. Ideally, you just set some per-branch value of how much space I'm > willing to allocate to old revisions of binary files. That doesn't sound > too hard in theory, once the actual work-flow is written down. > > As I don't have the expertise to improve bzr to the point where all data > is passed around as streams, I'll focus on the proof-of-concept plugin > which just adds some support for storing large files. I'm away for the > next three weeks though, so progress might be a bit slow. > > Re locks: Locking files can be done already with a plugin, can't it? You > just have to perform a commit to add some metadata on check-out and > another one on check-in, and your editor must pick up the metadata. I > can't see how file locking can be built in into a DVCS unless you run a > lightweight checkout, and honestly, isn't that enough for artists > anyway? Do artists really need old revisions from the repository? My > feeling is that artists are fine with tons of local copies that they > somehow manage on their own, so having a lightweight checkout for them > shouldn't be much of a problem. For developers, you want real branches > of course, but that's fine as developers shouldn't collide on binary > content anyway. > > Cheers, > Anteru > From andrew.bennetts at canonical.com Fri Jul 29 03:17:20 2011 From: andrew.bennetts at canonical.com (Andrew Bennetts) Date: Fri, 29 Jul 2011 13:17:20 +1000 Subject: Farewell! (sort of) Message-ID: <20110729031720.GF6894@aihal.home.puzzling.org> Hi all, After many years I'm leaving Canonical, and so leaving the Bazaar team. I've greatly enjoyed working with the Bazaar community outside of Canonical. You folks are a huge part of what makes Bazaar so good! It's safe to say that after such a long time I won't be able to let go completely, so I expect I'll still be around a bit :) But I of course will have much less time to spend helping out. If you're interested in filling the hole I'm leaving, or know someone who might be interested, here's the job description: I hope I haven't left too many bugs behind ;) It's been a pleasure, and thank you to everyone in the community for helping make it so. -Andrew. From stephen at xemacs.org Fri Jul 29 04:27:07 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 29 Jul 2011 13:27:07 +0900 Subject: Getting started with a content filter In-Reply-To: <4E313445.3000708@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> Message-ID: <87r559pv8k.fsf@uwakimon.sk.tsukuba.ac.jp> Chris Hecker writes: > It's way better than the alternative, which is two different artists > spending a day working on the same file, and then having to either > choose which version to keep, pissing off one of the artists, or forcing > them to spend another day "merging" their work, pissing off both of > them. The long-run solution needs to be fixing the merge process. But that's not going to happen soon. > > Well, you'd have to wrap the editors in scripts or a GUI front-end > > to make the workflow transparent. > > Artists can be trained to use p4win and similar things just fine. They > just need help for things they can't magically know, like somebody else > on the team is in the middle of editing the same psd. That's the > problem we're trying to solve here, and it's totally solvable with a > couple reasonable assumptions. Right, and what I'm suggesting is that you wrap the editor in a more functional equivalent of #! /bin/sh if ssh lockmgr at server mkdir $1.lock; then edit-blob $1 if ! ssh lockmgr at server rmdir $1.lock; then echo "Call admin, something went wrong with lock removal." fi else echo "$1 is locked, please try again later. Lock information:" ssh lockmgr at server ls -l $1.lock echo "If it's taking too long, call locker or admin to find out what's up." fi If a user invokes edit-blob directly and forces a merge, then guess who gets to spend Saturday doing it? :-) Of course, this only addresses the locking issue; the storage problem has to be solved in the VCS somehow. > > Edit-locking is a serious design problem, though, because it can > > only be made to work reliably in a very centralized context. > > Sure, which is why I was musing about the general dvcs case in my > previous mail, but the centralized case is still an incredibly important > use-case (at least for my industry, and I would assume any industry that > has humans editing large unmergable binary files). It's important not > to get hung up on not being able to solve the hard theoretical problem > perfectly, and not use that as an excuse to not solve the important and > relatively easy practical problem that people actually need solved. The problem is that code to deal with important (to you) practical problems can easily impact the more important (to a large fraction of the user community) already solved use cases and cause a regression. It's not obvious to me that it's easy to determine when the use case is "very centralized" and when it's not. I have no objection to doing this in a plugin, because that requires that you, the user who needs it, enable it and you (only) can deal with any fallout. But you're not terribly happy with the plugin idea, at least in the long run. > Again, all this may be totally specific to my industry (video games), > but I'd guess it isn't. In theory, it's not. In practice, my uninformed suspicion is that not only is it fairly unique to video games and maybe movies, but there are likely to be breakthroughs in merge technology that remove them from the list. But you'd be better off asking Perforce and Subversion developers about other use cases, since they've probably had bug reports and feature requests from the relevant users. From fullermd at over-yonder.net Fri Jul 29 04:43:07 2011 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Thu, 28 Jul 2011 23:43:07 -0500 Subject: Getting started with a content filter In-Reply-To: <4E313445.3000708@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> Message-ID: <20110729044307.GU2369@over-yonder.net> On Thu, Jul 28, 2011 at 03:04:53AM -0700 I heard the voice of Chris Hecker, and lo! it spake thus: > > I know a lot of people in the game industry who would love to switch > to dvcs from p4/svn, Actually, I thought games/film/etc were more Alienbrain territory. -- Matthew Fuller (MF4839) | fullermd at over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From checker at d6.com Fri Jul 29 06:14:34 2011 From: checker at d6.com (Chris Hecker) Date: Thu, 28 Jul 2011 23:14:34 -0700 Subject: Getting started with a content filter In-Reply-To: <87r559pv8k.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> <87r559pv8k.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <4E324FCA.4030309@d6.com> On 2011/07/28 21:27, Stephen J. Turnbull wrote: > But you're not terribly happy with the plugin idea, at least in the > long run. No, for the locking feature, a plugin is fine as long as it works seamlessly and robustly if it's installed. I think it's probably best as a plugin, actually, since it is specific to a setup. For the large binaries, I'm pretty sure it needs to be in core to be truly robust and have the right features to make it useful. At least, that's my opinion from my understanding of things right now; just making it clear. I think the "advances in merge technology with solve the locking problem" is a technological-solution-to-an-aesthetic-problem fantasy. There is no tool for the next 50+ years that will merge two textures to an artist's satisfaction (which, of course, won't stop a lot of useless siggraph papers being published on the topic that never get used in production, but that's a different problem altogether). On 2011/07/28 21:43, Matthew D. Fuller wrote: > Actually, I thought games/film/etc were more Alienbrain territory. Most people I know looked at it and decided not to use it years ago. I assume they have customers since there's a big list on their site, but at least at EA/Maxis, I didn't know of a single project that used it. All the content was in p4 (usually split up using p4's partial checkouts feature so everybody didn't have to sync everything). You want all the content and code in the same system so you can recreate a build exactly. Maybe Alienbrain will use p4 as a backend or something nowadays. I'll ask around. Chris On 2011/07/28 21:27, Stephen J. Turnbull wrote: > Chris Hecker writes: > > > It's way better than the alternative, which is two different artists > > spending a day working on the same file, and then having to either > > choose which version to keep, pissing off one of the artists, or forcing > > them to spend another day "merging" their work, pissing off both of > > them. > > The long-run solution needs to be fixing the merge process. But > that's not going to happen soon. > > > > Well, you'd have to wrap the editors in scripts or a GUI front-end > > > to make the workflow transparent. > > > > Artists can be trained to use p4win and similar things just fine. They > > just need help for things they can't magically know, like somebody else > > on the team is in the middle of editing the same psd. That's the > > problem we're trying to solve here, and it's totally solvable with a > > couple reasonable assumptions. > > Right, and what I'm suggesting is that you wrap the editor in a more > functional equivalent of > > #! /bin/sh > if ssh lockmgr at server mkdir $1.lock; then > edit-blob $1 > if ! ssh lockmgr at server rmdir $1.lock; then > echo "Call admin, something went wrong with lock removal." > fi > else > echo "$1 is locked, please try again later. Lock information:" > ssh lockmgr at server ls -l $1.lock > echo "If it's taking too long, call locker or admin to find out what's up." > fi > > If a user invokes edit-blob directly and forces a merge, then guess > who gets to spend Saturday doing it? :-) > > Of course, this only addresses the locking issue; the storage problem > has to be solved in the VCS somehow. > > > > Edit-locking is a serious design problem, though, because it can > > > only be made to work reliably in a very centralized context. > > > > Sure, which is why I was musing about the general dvcs case in my > > previous mail, but the centralized case is still an incredibly important > > use-case (at least for my industry, and I would assume any industry that > > has humans editing large unmergable binary files). It's important not > > to get hung up on not being able to solve the hard theoretical problem > > perfectly, and not use that as an excuse to not solve the important and > > relatively easy practical problem that people actually need solved. > > The problem is that code to deal with important (to you) practical > problems can easily impact the more important (to a large fraction of > the user community) already solved use cases and cause a regression. > It's not obvious to me that it's easy to determine when the use case > is "very centralized" and when it's not. > > I have no objection to doing this in a plugin, because that requires > that you, the user who needs it, enable it and you (only) can deal > with any fallout. But you're not terribly happy with the plugin idea, > at least in the long run. > > > Again, all this may be totally specific to my industry (video games), > > but I'd guess it isn't. > > In theory, it's not. In practice, my uninformed suspicion is that not > only is it fairly unique to video games and maybe movies, but there > are likely to be breakthroughs in merge technology that remove them > from the list. But you'd be better off asking Perforce and Subversion > developers about other use cases, since they've probably had bug > reports and feature requests from the relevant users. > > From stephen at xemacs.org Fri Jul 29 07:26:44 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 29 Jul 2011 16:26:44 +0900 Subject: Getting started with a content filter In-Reply-To: <4E324FCA.4030309@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> <87r559pv8k.fsf@uwakimon.sk.tsukuba.ac.jp> <4E324FCA.4030309@d6.com> Message-ID: <87k4b1pmx7.fsf@uwakimon.sk.tsukuba.ac.jp> Chris Hecker writes: > No, for the locking feature, a plugin is fine as long as it works > seamlessly and robustly if it's installed. OK, sorry for the confusion. > I think the "advances in merge technology with solve the locking > problem" is a technological-solution-to-an-aesthetic-problem fantasy. > There is no tool for the next 50+ years that will merge two textures to > an artist's satisfaction No, of course not. But I don't think any kind of locking is going to solve that kind of problem either (except maybe if the locks are on the *outside* of separate carrels, and only the manager has the key!) Also, it's rare that any reasonably large automatic merge comes off to a programmer's satisfaction, you know. The point is to get close enough that the tweaking takes an hour rather than a day. I know that "artists" tend to classify things into "my work", "acceptable", and "my eyes were about to dissolve out of their sockets", but perhaps automatic merges can come close enough to "acceptable" to save time. From checker at d6.com Fri Jul 29 18:39:32 2011 From: checker at d6.com (Chris Hecker) Date: Fri, 29 Jul 2011 11:39:32 -0700 Subject: Getting started with a content filter In-Reply-To: <4E324FCA.4030309@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> <87r559pv8k.fsf@uwakimon.sk.tsukuba.ac.jp> <4E324FCA.4030309@d6.com> Message-ID: <4E32FE64.2050203@d6.com> > alienbrain Yeah, I asked around, and nobody uses/likes it (some tweets below). Like I said at the beginning of this thead, this is a great opportunity for bzr to provide a more modern (not to mention OSS) alternative to p4 for games and other mixed code+data projects if large binary support is really done right. Chris @kenpex Angelo Pesce @ChristinaCoffin @checker Ye I've used AB, 5 yrs ago. It was ok-ish for data and terrible for code. Perforce is better for both. 14 minutes ago @CornyKorn21 Nick Korn @checker We use Alienbrain at our studio... I'm personally not a fan of it one bit. At least not for code. 1 hour ago @justin_liew Justin Liew @checker we used it once and it was a disaster. 2 hours ago @ChristinaCoffin Christina Ann Coffin @checker used that ages ago on a ps2 era project and hated it, most places lately just use perforce now for code+data 2 hours ago @LukeHalliwell Luke Halliwell @checker used it briefly early on at rtw. It was awful in so many ways. Switched to perforce. 2 hours ago @polygonhell Rob Povey @checker I don't kn ow of anyone who uses it anymore. I know of lots of companies who bought it. 3 hours ago @TomHammersley Tom Hammersley @tenpn @checker wasn't it all the coders' fault? Sigh... 10 hours ago @ancient_james James Brown @checker We used to use it at Lionhead 11 hours ago @tenpn tenpn @checker ...and they weren't happy about moving, let me tell you. 11 hours ago @tenpn tenpn @checker Codies used to use it for art. utterly useless but has max integration so the artists dig it. Recently moved them on to perforce. 11 hours ago @cowbs John Bellomy @checker I shipped a game with it, once, seven years ago. 11 hours ago @plushapo Borut Pfeifer @checker I worked on a team (@ SOE) where the artists insisted they use it, so we had 2, P4 for code, it was as horrible as you'd imagine. 11 hours ago On 2011/07/28 23:14, Chris Hecker wrote: > > > On 2011/07/28 21:27, Stephen J. Turnbull wrote: >> But you're not terribly happy with the plugin idea, at least in the >> long run. > > No, for the locking feature, a plugin is fine as long as it works > seamlessly and robustly if it's installed. I think it's probably best as > a plugin, actually, since it is specific to a setup. For the large > binaries, I'm pretty sure it needs to be in core to be truly robust and > have the right features to make it useful. At least, that's my opinion > from my understanding of things right now; just making it clear. > > I think the "advances in merge technology with solve the locking > problem" is a technological-solution-to-an-aesthetic-problem fantasy. > There is no tool for the next 50+ years that will merge two textures to > an artist's satisfaction (which, of course, won't stop a lot of useless > siggraph papers being published on the topic that never get used in > production, but that's a different problem altogether). > > On 2011/07/28 21:43, Matthew D. Fuller wrote: >> Actually, I thought games/film/etc were more Alienbrain territory. > > Most people I know looked at it and decided not to use it years ago. I > assume they have customers since there's a big list on their site, but > at least at EA/Maxis, I didn't know of a single project that used it. > All the content was in p4 (usually split up using p4's partial checkouts > feature so everybody didn't have to sync everything). You want all the > content and code in the same system so you can recreate a build exactly. > Maybe Alienbrain will use p4 as a backend or something nowadays. I'll > ask around. > > Chris > > > On 2011/07/28 21:27, Stephen J. Turnbull wrote: >> Chris Hecker writes: >> >> > It's way better than the alternative, which is two different artists >> > spending a day working on the same file, and then having to either >> > choose which version to keep, pissing off one of the artists, or >> forcing >> > them to spend another day "merging" their work, pissing off both of >> > them. >> >> The long-run solution needs to be fixing the merge process. But >> that's not going to happen soon. >> >> > > Well, you'd have to wrap the editors in scripts or a GUI front-end >> > > to make the workflow transparent. >> > >> > Artists can be trained to use p4win and similar things just fine. They >> > just need help for things they can't magically know, like somebody else >> > on the team is in the middle of editing the same psd. That's the >> > problem we're trying to solve here, and it's totally solvable with a >> > couple reasonable assumptions. >> >> Right, and what I'm suggesting is that you wrap the editor in a more >> functional equivalent of >> >> #! /bin/sh >> if ssh lockmgr at server mkdir $1.lock; then >> edit-blob $1 >> if ! ssh lockmgr at server rmdir $1.lock; then >> echo "Call admin, something went wrong with lock removal." >> fi >> else >> echo "$1 is locked, please try again later. Lock information:" >> ssh lockmgr at server ls -l $1.lock >> echo "If it's taking too long, call locker or admin to find out what's >> up." >> fi >> >> If a user invokes edit-blob directly and forces a merge, then guess >> who gets to spend Saturday doing it? :-) >> >> Of course, this only addresses the locking issue; the storage problem >> has to be solved in the VCS somehow. >> >> > > Edit-locking is a serious design problem, though, because it can >> > > only be made to work reliably in a very centralized context. >> > >> > Sure, which is why I was musing about the general dvcs case in my >> > previous mail, but the centralized case is still an incredibly >> important >> > use-case (at least for my industry, and I would assume any industry >> that >> > has humans editing large unmergable binary files). It's important not >> > to get hung up on not being able to solve the hard theoretical problem >> > perfectly, and not use that as an excuse to not solve the important and >> > relatively easy practical problem that people actually need solved. >> >> The problem is that code to deal with important (to you) practical >> problems can easily impact the more important (to a large fraction of >> the user community) already solved use cases and cause a regression. >> It's not obvious to me that it's easy to determine when the use case >> is "very centralized" and when it's not. >> >> I have no objection to doing this in a plugin, because that requires >> that you, the user who needs it, enable it and you (only) can deal >> with any fallout. But you're not terribly happy with the plugin idea, >> at least in the long run. >> >> > Again, all this may be totally specific to my industry (video games), >> > but I'd guess it isn't. >> >> In theory, it's not. In practice, my uninformed suspicion is that not >> only is it fairly unique to video games and maybe movies, but there >> are likely to be breakthroughs in merge technology that remove them >> from the list. But you'd be better off asking Perforce and Subversion >> developers about other use cases, since they've probably had bug >> reports and feature requests from the relevant users. >> >> From john at arbash-meinel.com Fri Jul 29 20:20:58 2011 From: john at arbash-meinel.com (John Meinel) Date: Fri, 29 Jul 2011 22:20:58 +0200 Subject: Farewell! (sort of) In-Reply-To: <20110729031720.GF6894@aihal.home.puzzling.org> References: <20110729031720.GF6894@aihal.home.puzzling.org> Message-ID: It has been great working with you, and I certainly hope to keep seeing you around. The nice thing about open source is you'll always have access to work on it. :) John =:-> On Jul 28, 2011 10:18 PM, "Andrew Bennetts" wrote: > Hi all, > > After many years I'm leaving Canonical, and so leaving the Bazaar team. > I've greatly enjoyed working with the Bazaar community outside of > Canonical. You folks are a huge part of what makes Bazaar so good! > > It's safe to say that after such a long time I won't be able to let go > completely, so I expect I'll still be around a bit :) But I of course > will have much less time to spend helping out. > > If you're interested in filling the hole I'm leaving, or know someone > who might be interested, here's the job description: > < https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=308 > > > I hope I haven't left too many bugs behind ;) > > It's been a pleasure, and thank you to everyone in the community for > helping make it so. > > -Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crystalrecursion at gmail.com Sat Jul 30 03:53:09 2011 From: crystalrecursion at gmail.com (Eugene Wee) Date: Sat, 30 Jul 2011 11:53:09 +0800 Subject: Farewell! (sort of) In-Reply-To: <20110729031720.GF6894@aihal.home.puzzling.org> References: <20110729031720.GF6894@aihal.home.puzzling.org> Message-ID: Hi Andrew, On Fri, Jul 29, 2011 at 11:17 AM, Andrew Bennetts wrote: > After many years I'm leaving Canonical, and so leaving the Bazaar team. > I've greatly enjoyed working with the Bazaar community outside of > Canonical. ?You folks are a huge part of what makes Bazaar so good! I'm only one of the many "anonymous" users of Bazaar, but thanks for your contribution over the years :) Oh yes, and this certainly is not really your farewell to Bazaar community, heheh. Regards, Eugene From luoyonggang at gmail.com Sun Jul 31 15:15:41 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Sun, 31 Jul 2011 23:15:41 +0800 Subject: [bzr-svn] When using auto layout, error appeared, so what's the cause? Message-ID: I was using my own source code *lp:~luoyonggang/bzr-svn/b3 * D:\CI\bld\b>run.bat D:\CI\bld\b>rm -rf l* D:\CI\bld\b>bzr svn-import --layout auto svn://localhost/br/llvm l1 ('AutoDetectCopyLayout with log', , '/llvm/') WARNING:Path /llvm has copy from None and not in an branch in revision:1 WARNING:Path /llvm/branches has copy from None and not in an branch in revision:1 WARNING:Path /llvm/tags has copy from None and not in an branch in revision:1 Try add branch /llvm/trunk by using path trunk on revision 1 copy from None! Add branch /llvm/trunk with ['/trunk', 0, 1, True]! Try add branch /llvm/branches/chaos by using path chaos on revision 2 copy from None! Add branch /llvm/branches/chaos with ['/trunk', 0, 2, True]! Add branch /llvm/branches/fine with ['/llvm/trunk', 1, 4, True]! Add branch /llvm/branches/chaos/b with ['/llvm/trunk', 4, 6, True]! Add branch /llvm/branches/chaos/d with ['/llvm/trunk', 4, 8, True]! Try add branch /llvm/branches/apple by using path apple on revision 9 copy from None! Add branch /llvm/branches/apple with ['/trunk', 0, 9, True]! Add branch /llvm/branches/apple/a with ['/llvm/trunk', 8, 10, True]! Add branch /llvm/branches/apple/b with ['/llvm/trunk', 8, 11, True]! Try add branch /llvm/branches/history by using path history on revision 13 copy from None! Add branch /llvm/branches/history with ['/trunk', 0, 13, True]! Add branch /llvm/branches/history/a with ['/llvm/trunk', 8, 14, True]! Add branch /llvm/branches/history/b with ['/llvm/trunk', 8, 15, True]! Add branch /llvm/tags/good with ['/llvm/branches/apple/a', 10, 16, True]! Add branch /llvm/tags/goodb with ['/llvm/branches/apple/b', 11, 17, True]! Add branch /llvm/tags/chaosa with ['/llvm/branches/chaos/d', 8, 18, True]! WARNING:Path /unicode has copy from None and not in an branch in revision:25 WARNING:Path /unicode/1 has copy from None and not in an branch in revision:25 WARNING:Path /unicode/2 has copy from None and not in an branch in revision:25 AutoDetectCopyLayout finished Using repository layout: auto parse llvm/branches/history/a/Are you sure.txt:24 parse llvm/branches/history/a:24nches 2/26 parse llvm/branches/apple/b/GOOD.txt:23 parse llvm/branches/chaos/d/sametime.txt:23 parse llvm/branches/fine/TODO.txt:23 parse llvm/trunk/funny.txt:23 parse llvm/branches/fine:23 parse llvm/branches/apple/b:23 parse llvm/trunk:23 parse llvm/branches/chaos/d:23 parse llvm/trunk/modifydefault.txt:22 parse llvm/branches/history/wow:21 parse llvm/branches/history/wow/goodoptions.txt:21 parse llvm/branches/history:21 parse llvm/branches/history/readme.txt:20 parse llvm/branches/history/a/HA.txt:19 parse llvm/tags/chaosa:18 parse llvm/tags/goodb:17 parse llvm/tags/good:16 parse llvm/tags/good/WHyApple.txt:16 parse llvm/branches/history/b:15 parse llvm/branches/history/b:15 parse llvm/branches/history/a:14 parse llvm/branches/history:13 parse llvm/branches/apple/a/WHyApple.txt:12 parse llvm/branches/apple/a:12 parse llvm/branches/apple/b:11 parse llvm/branches/apple/a:10 parse llvm/branches/apple:9 parse llvm/branches/apple:9 parse llvm/branches/chaos/d:8 parse llvm/branches/chaos/a:7 ('is_parent', 'llvm/branches/chaos/a', 'branch', False) ('is_parent', 'llvm/branches/chaos/a', 'tag', False) parse llvm/branches/chaos:7 parse llvm/branches/chaos/b:6 parse llvm/branches/chaos/b:6 parse llvm/branches/chaos/a:5 parse llvm/branches/chaos/a/TODO.txt:5 parse llvm/branches/chaos/a/a:5 parse llvm/branches/chaos/a/a/a.txt:5 parse llvm/branches/chaos/a/b:5 parse llvm/branches/chaos/a/b/b.txt:5 parse llvm/branches/fine:4 parse llvm/branches/fine/a:4 parse llvm/branches/fine/b:4 parse llvm/trunk/a:3 parse llvm/trunk/a/a.txt:3 parse llvm/trunk/b:3 parse llvm/trunk/b/b.txt:3 parse llvm/branches/chaos:2 parse llvm/branches/chaos/README.TXT:2 parse llvm:1 parse llvm/branches:1 parse llvm/tags:1 parse llvm/trunk:1 parse llvm/trunk/TODO.txt:1 bzr: ERROR: bzrlib.errors.NoSuchRevision: CHKInventoryRepository('file:///D:/CI/bld/b/l1/.bzr/repository/') has no revision ('svn-v4:c19a81e 0-789f-1047-ad32-a6eb670b4137:llvm/branches/chaos:6',) Traceback (most recent call last): File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 926, in exception_to_return_code return the_callable(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 1126, in run_bzr ret = run(*run_argv) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 691, in run_argv_aliases return self.run(**all_cmd_args) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 713, in run return self._operation.run_simple(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\cleanup.py", line 135, in run_simple self.cleanups, self.func, *args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\cleanup.py", line 165, in _do_with_cleanups result = func(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\commands.py", line 169, in run incremental=not restore, to_revnum=to_revnum, prefix=prefix) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 357, in convert_repository RepositoryConverter(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 244, in __init__ revfinder, mapping, heads) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 283, in _fetch_to_shared_repo inter.fetch(needed=missing) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1568, in fetch pack_hint = self._fetch_revisions(needed, pb) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1493, in _fetch_revisions use_replay=self._use_replay) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1455, in _fetch_revisions_nochunks editor = self._get_editor(revmeta, mapping) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1361, in _get_editor bzr_parent_trees = self._get_parent_trees(revmeta, mapping) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1346, in _get_parent_trees parent_trees = [self.target.revision_tree(parent_revids[0])] File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\decorators.py", line 140, in read_locked result = unbound(self, *args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\repository.py", line 2596, in revision_tree inv = self.get_inventory(revision_id) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\decorators.py", line 140, in read_locked result = unbound(self, *args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\repository.py", line 2423, in get_inventory return self.iter_inventories([revision_id]).next() File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\repofmt\groupcompress_repo.py", line 1018, in _iter_inventories raise errors.NoSuchRevision(self, record.key) NoSuchRevision: CHKInventoryRepository('file:///D:/CI/bld/b/l1/.bzr/repository/') has no revision ('svn-v4:c19a81e0-789f-1047-ad32-a6eb670b4 137:llvm/branches/chaos:6',) bzr 2.3.3 on python 2.7.1 (Windows-7-6.1.7601-SP1) arguments: ['D:\\CI\\Tools\\Building\\Python\\Scripts\\bzr', 'svn-import', '-- layout', 'auto', 'svn://localhost/br/llvm', 'l1'] plugins: bash_completion[2.3.3], launchpad[2.3.3], netrc_credential_store[2.3.3], news_merge[2.3.3], svn[1.1.0dev] encoding: 'cp936', fsenc: 'mbcs', lang: None *** Bazaar has encountered an internal error. This probably indicates a bug in Bazaar. You can help us fix it by filing a bug report at https://bugs.launchpad.net/bzr/+filebug including this traceback and a description of the problem. D:\CI\bld\b> -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: From luoyonggang at gmail.com Sun Jul 31 15:51:47 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Sun, 31 Jul 2011 23:51:47 +0800 Subject: [bzr-svn] When using auto layout, error appeared, so what's the cause? In-Reply-To: References: Message-ID: This is the svn repo that I was converted. -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: br.svndump Type: application/octet-stream Size: 12785 bytes Desc: not available URL: From luoyonggang at gmail.com Mon Aug 1 05:26:48 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Mon, 1 Aug 2011 13:26:48 +0800 Subject: What's the meaning of this error? Message-ID: bzr: ERROR: An inconsistent delta was supplied: [(None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb', 'a'), '20 at c19a81e0-789f-1047-ad32-a6eb6 70b4137:llvm%2Fbranches%2Fhistory%2Fb%2Fa'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa', 'TODO.txt'), '20 at c19a81e0-789f-1047-ad32-a6 eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2FTODO.txt'), (None, StaticTuple('13 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2F', 'a'), '20 at c19a81e0-789f-1047-ad32- a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fa', 'a.txt'), '20 at c19a81e0-789f-1047-ad32- a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fa%2Fa.txt'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa', 'HA.txt'), '20 at c19a81e0-789f-1 047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2FHA.txt'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa', 'b'), '20 at c19a81e0-789f- 1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fb'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fb', 'b.txt'), '20 at c19a81e0-7 89f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fb%2Fb.txt'), (None, StaticTuple('13 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2F', 'readme.txt'), '2 0 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Freadme.txt'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb%2Fb', 'b. txt'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb%2Fb%2Fb.txt'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2Fhistory%2 Fb', 'TODO.txt'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb%2FTODO.txt'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2 Fhistory%2Fa', 'a'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fa%2Fa'), (None, StaticTuple('13 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2Fhis tory%2F', 'b'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2Fhistory%2Fb' , 'b'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2Fb%2Fb'), (None, StaticTuple('20 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2Fhistory%2Fb%2Fa' , 'a.txt'), '20 at c19a81e0-789f-1047-ad32-a6eb670b4137 :llvm%2Fbranches%2Fhistory%2Fb%2Fa%2Fa.txt')] reason: New items are already in the map [(StaticTuple('13 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2F', 'a'), '14 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2 Fbranches%2Fhistory%2Fa'), (StaticTuple('13 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhistory%2F', 'b'), '15 at c19a81e0-789f-1047-ad32-a6eb670b4137:llvm%2Fbranches%2Fhis tory%2Fb')]. -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Mon Aug 1 07:17:51 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 1 Aug 2011 17:17:51 +1000 Subject: What's the meaning of this error? In-Reply-To: References: Message-ID: On 1 August 2011 15:26, ???(Yonggang Luo) wrote: > bzr: ERROR: An inconsistent delta was supplied: [(None, It's an internal error; without more information about what you're trying to do it's hard to tell what would be causing it. It looks like you're using bzr-svn and so the first thing I'd recommend is checking you have the tip of bzr and bzr-svn. m From luoyonggang at gmail.com Mon Aug 1 07:45:58 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Mon, 1 Aug 2011 15:45:58 +0800 Subject: What's the meaning of this error? In-Reply-To: References: Message-ID: Thanks, I've found the cause. https://code.launchpad.net/~luoyonggang/bzr-svn/b3 The problem is at the current time, bzr-svn din't support for multiple branches at the same path. Such as an path /branches/branchA/branchB It's contained branch */branches/branchA* and */branches/branchA/branchB*, the exist codebase didn't deal with it well. So, in auto layout, I disable such feature, so that just enable those branches din't contains other branches. So, I set */branches/branchA* is not an branch, the internal error is gone. now https://code.launchpad.net/~luoyonggang/bzr-svn/b3 can convert simple enough svn repos, So maybe it's an change to propose an merge? -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernooij at gmail.com Mon Aug 1 11:07:45 2011 From: jvernooij at gmail.com (Jelmer Vernooij) Date: Mon, 01 Aug 2011 13:07:45 +0200 Subject: What's the meaning of this error? In-Reply-To: References: Message-ID: <1312196868.9816.9.camel@localhost> On Mon, 2011-08-01 at 15:45 +0800, ???(Yonggang Luo) wrote: > Thanks, I've found the cause. > https://code.launchpad.net/~luoyonggang/bzr-svn/b3 > > > The problem is at the current time, bzr-svn din't support for multiple > branches at the same path. > Such as an path /branches/branchA/branchB > It's contained branch /branches/branchA > and /branches/branchA/branchB, > the exist codebase didn't deal with it well. > So, in auto layout, I disable such feature, so that just enable those > branches din't contains other branches. > So, I set /branches/branchA is not an branch, the internal error is > gone. This never occurs in the current code base either, so this error would never occur without your patch. If you need this to work for your custom layout, you'll have to change bzr-svn to allow multiple path elements to be a branch in the same layout. Cheers, Jelmer From iwata0303 at gmail.com Mon Aug 1 22:40:16 2011 From: iwata0303 at gmail.com (Iwata) Date: Tue, 2 Aug 2011 07:40:16 +0900 Subject: TortoiseBzr 0.6.4 has been released Message-ID: Hi, all. Now, TortoiseBzr 0.6.4 is available. Please include this to windows installer of upcoming bzr-2.4 release. (and bzr-2.3.5 if it will come). NEW FEATURE: * Shelve/Unshelve (qbzr 0.21 is needed) * Direct add mode BUG FIXES: * Language setting in bazaar.conf is ignored. Regards. From davidkmuir at gmail.com Tue Aug 2 11:43:21 2011 From: davidkmuir at gmail.com (David Muir) Date: Tue, 02 Aug 2011 21:43:21 +1000 Subject: [ANN] QBzr 0.21 final released In-Reply-To: <4E27E1EA.5@ukr.net> References: <4E27E1EA.5@ukr.net> Message-ID: <4E37E2D9.30106@gmail.com> Just wanting to say thank you. I've been having to use Mercurial for the past month and I *really* miss using qbzr. Thanks for making it, and by extension Bazaar, awesome. Cheers, David On 21/07/11 18:23, Alexander Belchenko wrote: > On behalf of QBzr development team I'm happy to announce new release of > QBzr 0.21 codenamed "Tilia". > > This release intended to be used as companion release for bzr 2.4, and > might support bzr 2.3. > > I'd like to thank the people who have helped make this release > awesome. Thank you. > > What's new in this release > -------------------------- > QBzr 0.21 is companion release for bzr 2.4, and compatible with bzr 2.3. > New features in this release: > > Now you can select changes to shelve and unshelve your saved changes > with new shiny qshelve and qunshelve dialogs. > > qdiff window has been reworked and all controls moved to a toolbar, > similar to one in qannotate window. Also qdiff toolbar provides you > new functions: text search within active pane and also knob to ignore > whitespace changes (it's also available as command-line option). > > User can configure the tab width and this setting affects qdiff, > qannotate and qcat windows. By default tab width equals to 8 > characters, user can set new default value in bazaar.conf as > ``tab_width = N`` (either via qconfig or editing [DEFAULT] section of > bazaar.conf). Also user can set individual tab width for branches in > their branch.conf. User can configure tab width via "View Options" > menu in toolbars of qdiff, qannotate. > > QBzr provides support for new builtin feature of bzr: mergetools. Now > you can easier configure your favorite diff/merge tool to be used from > qconflicts or context menu in qbrowse (Working Tree browser in Bazaar > Explorer). > > If you have python-gpgme installed and you have enabled gpg-signatures > for your commits then you can see new messages regarding valid > gpg-signatures available in qlog. Also you can run check of your > signatures with new qverify-signatures command. > > Other changes include major rework of qinfo dialog (show the same > information as CLI ``bzr info`` does), qcommit dialog now remembers > state of "Show non-versioned" knob between runs, now it's possible to > save old state of the file from qlog dialog (using context menu in > file list), error dialogs has been improved (now also support apport > if available) and several other improvements and bugfixes (see full > changelog for details at the end of this mail). > > Downloads > --------- > Sources tarball and windows installer available to download from > https://launchpad.net/qbzr/0.21/0.21 > > Release branch: lp:qbzr/0.21 > > About QBzr > ---------- > QBzr is a cross-platform GUI front end for Bazaar, based on Qt toolkit. > QBzr provided GUI frontend for many core bzr commands and several > universal dialogs and helper commands. Equivalents for core bzr commands > has the same names as CLI commands but with prefix "q". > > QBzr is used as library of GUI dialogs in other products: > * Bazaar Explorer > * TortoiseBzr > * QBzr-Eclipse > > QBzr at Launchpad: > https://launchpad.net/qbzr > > Changelog > --------- > Changes after 0.21 beta 1: > > * qcat: > * Fixed problem with viewing file from qbrowse. > (Alexander Belchenko, Bug #776196) > * qinfo: > * Turned off word-wrap in location label: prevents strange > path display if there are spaces in the path. > (A. S. Budden, Bug #781040) > * Fixed UnicodeError for non-ascii paths. > (Alexander Belchenko, Bug #790138) > * qdiff, qannotate: > * Tab-width can be customised from the view menu. > (Bug #490377, A. S. Budden) > * qgetnew: > * The target location no longer gets overwritten > when the source location changes. (Andr?? Bachmann) > * qlog: > * File list context menu: added support to save content of a file > of specific revision as a new file. (Andr?? Bachmann) > * Show digital signature information for commits if python-gpgme is > installed > * Improved error dialogs on internal/other error, > support for apport (if it's available). > (Jonathan Riddell) > * Branch/Checkout dialogs: > * Fixed UnicodeDecodeError with non-ascii paths in target directory > picker. (Alexander Belchenko, Bug #789083) > * Use bzrlib.mergetools for managing and using external merge tools > in qconfig > and qconflicts. (Bug #489915, Gordon Tyler) > * New qshelve / qunshelve dialogs. (IWATA Hidetaka) > * New command qverify-signatures to show digital signature statuses > for branch commits > > Changes in 0.21 beta 1: > > * qbranch: > * Fixed problem with very small width of input fields in the dialog > on Mac OSX. (Timothy Reaves, Bug #667090) > * qbrowse: > * Use `qcat --native` equivalent to allow opening copies of files from > branches without working trees. (A. S. Budden, Bug #752422) > * qcommit: > * Remember "Show non-versioned" checkbox state. > (Nick Sonneveld, Bug #258926) > * qconflicts: > * Fixed internal error when there is conflict in non-versioned file. > (Alexander Belchenko, Bug #655451) > * qdiff: > * New toolbar with controls and options (similar to qannotate's > toolbar). > (Dorin Scutara??u) > * Support for ignore whitespace differences in changes. > This mode can be turned on from command-line (`qdiff -w` > or `qdiff --ignore-whitespace`) and from GUI itself (in View > Options). > (Dorin Scutara??u, Glen Mailer, Bug #642000) > * Added Find action to do text search within either pane. > (Dorin Scutara??u, Bug #497832) > * qinfo: > * Significantly simpler implementation that shows the information > provided by Bazaar. This fills in the gaps in the data shown > by qinfo (such as details of checkouts) and means that changes > to 'bzr info' will automatically be reflected in qinfo. > (A. S. Budden, Bug #439624) > * qsubprocess: > * Reliable exception encoding to pass exception attributes > from subprocess to the GUI process. (Martin [gz], Bug #686735) > * qannotate, qdiff: > * Find text box turns red if no matches are found. > (A. S. Budden, Bug #772244) > * qcat, qannotate, qdiff, qconfig: > * Added ability to customise the tab-stop width (setting in qconfig, > affects qcat, qannotate and qdiff). > The setting is stored in [DEFAULT] section of bazaar.conf, > and is named tab_width (it can also be configured with qconfig). > Units > are characters (so 4 means a tab should be displayed with the > width of 4 > spaces). The default value is 8. The setting can also be > adjusted in > branch.conf for specific branches. (Bug #490377, A. S. Budden) > > Alexander > From luoyonggang at gmail.com Tue Aug 2 12:44:31 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Tue, 2 Aug 2011 20:44:31 +0800 Subject: [bzr-svn] There is should be some lock problems around sqllite. Message-ID: Delete br llvm/branches/release_21:41946 Delete br llvm/branches/release_21:41945 Delete br llvm/branches/release_21:41943 Delete br llvm/branches/release_21:41920 bzr: ERROR: sqlite3.OperationalError: database is locked Traceback (most recent call last): File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 930, in exception_to_return_code return the_callable(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 1130, in run_bzr ret = run(*run_argv) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 691, in run_argv_aliases return self.run(**all_cmd_args) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\commands.py", line 713, in run return self._operation.run_simple(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\cleanup.py", line 135, in run_simple self.cleanups, self.func, *args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\cleanup.py", line 165, in _do_with_cleanups result = func(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\commands.py", line 177, in run incremental=not restore, to_revnum=to_revnum, prefix=prefix) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 357, in convert_repository RepositoryConverter(*args, **kwargs) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 244, in __init__ revfinder, mapping, heads) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\convert.py", line 279, in _fetch_to_shared_repo needs_manual_check, pb=pb, heads=heads) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\fetch.py", line 1191, in find_iter_revisions (m, lhsm) = revmeta.get_appropriate_mappings(m) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\revmeta.py", line 263, in get_appropriate_mappings original = self.get_original_mapping() File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\revmeta.py", line 762, in get_original_mapping self._original_mapping) File "D:\CI\Tools\Building\Python\lib\site-packages\bzrlib\plugins\svn\cache\sqlitecache.py", line 243, in set_original_mapping self.cachedb.execute("insert into original_mapping (path, revnum, original_mapping) values (?, ?, ?)", (foreign_revid[1].decode("utf-8"), foreign_revid[2], orig_mapping_name)) OperationalError: database is locked bzr 2.4b3 on python 2.7.1 (Windows-7-6.1.7601-SP1) arguments: ['D:\\CI\\Tools\\Building\\Python\\Scripts\\bzr', 'svn-import', '-- all', '--layout', 'auto', 'svn://localhost/llvm/llvm/', 'llvm'] plugins: bash_completion[2.4b3], changelog_merge[2.4b3], launchpad[2.4b3], netrc_credential_store[2.4b3], news_merge[2.4b3], svn[1.1.0dev], weave_fmt[2.4b3] encoding: 'cp936', fsenc: 'mbcs', lang: None *** Bazaar has encountered an internal error. This probably indicates a bug in Bazaar. You can help us fix it by filing a bug report at https://bugs.launchpad.net/bzr/+filebug including this traceback and a description of the problem. D:\CI\bld\b> -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernooij at gmail.com Tue Aug 2 12:53:50 2011 From: jvernooij at gmail.com (Jelmer Vernooij) Date: Tue, 02 Aug 2011 14:53:50 +0200 Subject: [bzr-svn] There is should be some lock problems around sqllite. In-Reply-To: References: Message-ID: <1312289632.3087.24.camel@localhost> On Tue, 2011-08-02 at 20:44 +0800, ???(Yonggang Luo) wrote: > Delete br llvm/branches/release_21:41946 > Delete br llvm/branches/release_21:41945 > Delete br llvm/branches/release_21:41943 > Delete br llvm/branches/release_21:41920 > bzr: ERROR: sqlite3.OperationalError: database is locked Please see the bug tracker: This is http://pad.lv/685251 Patches welcome. Cheers, Jelmer From luoyonggang at gmail.com Tue Aug 2 16:43:51 2011 From: luoyonggang at gmail.com (=?UTF-8?B?572X5YuH5YiaKFlvbmdnYW5nIEx1bykg?=) Date: Wed, 3 Aug 2011 00:43:51 +0800 Subject: [bzr-svn] There is should be some lock problems around sqllite. In-Reply-To: <1312289632.3087.24.camel@localhost> References: <1312289632.3087.24.camel@localhost> Message-ID: Maybe this is the solution. http://stackoverflow.com/questions/5529820/sqlite3-operationalerror-database-is-locked We need specify separate sql database for each repo, not for each url. 2011/8/2 Jelmer Vernooij > On Tue, 2011-08-02 at 20:44 +0800, ???(Yonggang Luo) wrote: > > Delete br llvm/branches/release_21:41946 > > Delete br llvm/branches/release_21:41945 > > Delete br llvm/branches/release_21:41943 > > Delete br llvm/branches/release_21:41920 > > bzr: ERROR: sqlite3.OperationalError: database is locked > Please see the bug tracker: > > This is http://pad.lv/685251 > > Patches welcome. > > Cheers, > > Jelmer > > > -- ?? ? ??? Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernooij at gmail.com Tue Aug 2 17:41:52 2011 From: jvernooij at gmail.com (Jelmer Vernooij) Date: Tue, 02 Aug 2011 19:41:52 +0200 Subject: [bzr-svn] There is should be some lock problems around sqllite. In-Reply-To: References: <1312289632.3087.24.camel@localhost> Message-ID: <1312306914.3032.6.camel@genhwyvar> (CC'ing the bug. Usually, the bug tracker is the right place for comments specific to a particular bug. ) On Wed, 2011-08-03 at 00:43 +0800, ???(Yonggang Luo) wrote: > Maybe this is the solution. > http://stackoverflow.com/questions/5529820/sqlite3-operationalerror-database-is-locked > We need specify separate sql database for each repo, not for each url. That would negate a lot of the benefit of actually having a cache. It's possible to have multiple processes working against the same bzr repository - which would mean we could still hit locking issues. We don't need a database that can support multiple writers with high concurrency. It's fine if we have to wait for another process to release the database lock - the only thing that it could be working on is updating the cache, and that's what the process that's waiting would do too. The main thing that's missing is actually asking sqlite to wait for the lock to be released rather than raising an exception immediately if it finds a lock. IIUC this is possible, but I haven't had the time to look up the right functions in the API, write some tests and patch bzr-svn to use it. Cheers, Jelmer > > 2011/8/2 Jelmer Vernooij > On Tue, 2011-08-02 at 20:44 +0800, ???(Yonggang Luo) wrote: > > Delete br llvm/branches/release_21:41946 > > Delete br llvm/branches/release_21:41945 > > Delete br llvm/branches/release_21:41943 > > Delete br llvm/branches/release_21:41920 > > bzr: ERROR: sqlite3.OperationalError: database is locked > > Please see the bug tracker: > > This is http://pad.lv/685251 > > Patches welcome. > > Cheers, > > Jelmer > > > > > > -- > ?? > ? > ??? > Yours > sincerely, > Yonggang Luo > > From jelmer at canonical.com Wed Aug 3 00:14:45 2011 From: jelmer at canonical.com (Jelmer Vernooij) Date: Wed, 03 Aug 2011 02:14:45 +0200 Subject: Colocated branch support progress - preserving characters in URLs Message-ID: <1312330486.3032.21.camel@genhwyvar> The ability to address colocated branches using URLs has long been in progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a bit with John and Martin at the recent Launchpad sprint, I'm finally back on track hacking on it. There are basically four things left to do now: 1) Avoid URLescaping comma's when converting local paths to URLs. (lp:~jelmer/bzr/escape-comments) 2) Preserve the distinction between literal and delimiting comma's in URLs when they are parsed in e.g. ConnectedTransport (2) 3) Parse the subsegment parameters for Transports and make them accessible (done, lp:~jelmer/bzr/transport-segments) 4) Look at the transport segment parameters in ControlDir and use them to determine the default branch (this should be fairly easy) I'm wondering how exactly to do (2). At the moment when we receive a URL we parse it and then urlunescape all characters. Among other things, this means that urlencoded characters won't be distinguisable from literal characters. So far, this distinction hasn't really mattered as we didn't have a different interpretation for them. To make sure we don't lose this information, I would like to stop urlunescaping things like ConnectedTransport._path, ConnectedTransport._username, etc and instead urlunescape it later. Does that seem reasonable, or is there perhaps a better way to work around the current limitations I haven't considered? Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From mbp at canonical.com Wed Aug 3 04:00:57 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 3 Aug 2011 14:00:57 +1000 Subject: babune broken Message-ID: A recent change (probably one of mine) has broken babune on all Ubuntu distroreleases, I guess with an environment-specific Unicode problem: http://babune.ladeuil.net:24842/job/selftest-chroot-natty/lastCompletedBuild/testReport/ Martin From bialix at ukr.net Wed Aug 3 08:26:51 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Wed, 03 Aug 2011 11:26:51 +0300 Subject: [ANN] QBzr 0.21 final released In-Reply-To: <4E37E2D9.30106@gmail.com> References: <4E27E1EA.5@ukr.net> <4E37E2D9.30106@gmail.com> Message-ID: <4E39064B.2020601@ukr.net> :-) David Muir ?????: > Just wanting to say thank you. I've been having to use Mercurial for the > past month and I *really* miss using qbzr. Thanks for making it, and by > extension Bazaar, awesome. > > Cheers, > David > > On 21/07/11 18:23, Alexander Belchenko wrote: >> On behalf of QBzr development team I'm happy to announce new release of >> QBzr 0.21 codenamed "Tilia". >> >> This release intended to be used as companion release for bzr 2.4, and >> might support bzr 2.3. >> >> I'd like to thank the people who have helped make this release >> awesome. Thank you. From gordon at doxxx.net Wed Aug 3 13:57:59 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Wed, 03 Aug 2011 09:57:59 -0400 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <1312330486.3032.21.camel@genhwyvar> References: <1312330486.3032.21.camel@genhwyvar> Message-ID: <4E3953E7.2030603@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not trying to bikeshed here but this seems to have relevance to actual technical issues encountered during implementation... Why use commas? Why not use a URL fragment to separate location from branch name? bzr+ssh://host/path/to/repo#branch Looks a lot better to me than bzr+ssh://host/path/to/repo,branch And it allows you to avoid this issue of encoding/decoding commas. On 8/2/2011 8:14 PM, Jelmer Vernooij wrote: > The ability to address colocated branches using URLs has long been in > progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a > bit with John and Martin at the recent Launchpad sprint, I'm finally > back on track hacking on it. > > There are basically four things left to do now: > > 1) Avoid URLescaping comma's when converting local paths to URLs. > (lp:~jelmer/bzr/escape-comments) > 2) Preserve the distinction between literal and delimiting comma's in > URLs when they are parsed in e.g. ConnectedTransport (2) > 3) Parse the subsegment parameters for Transports and make them > accessible (done, lp:~jelmer/bzr/transport-segments) > 4) Look at the transport segment parameters in ControlDir and use them > to determine the default branch (this should be fairly easy) > > I'm wondering how exactly to do (2). At the moment when we receive a URL > we parse it and then urlunescape all characters. Among other things, > this means that urlencoded characters won't be distinguisable from > literal characters. > > So far, this distinction hasn't really mattered as we didn't have a > different interpretation for them. > > To make sure we don't lose this information, I would like to stop > urlunescaping things like ConnectedTransport._path, > ConnectedTransport._username, etc and instead urlunescape it later. Does > that seem reasonable, or is there perhaps a better way to work around > the current limitations I haven't considered? > > Cheers, > > Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOOVPnAAoJEIrPJfWinA2uSUIH/juyW6LuLVcg/qEe5E0SBW80 HhFY6GkL1OMTTBLm1jQ2xfcJK01E/OmqKqqS7Jlsen8gZhBA7zqDGBoA0en+etrQ 6YIk91zpAE9XgFv0bInUGgvYPybCRIfrcghfpivg0DkjckAZydkki5qra8CjiThG ErmEDd0r9K1Tkg73c2RHgJm/977OMkr2RtFbm9H9SU8yhW+GYcDmZnxaUyfCTb1K YNrVSC7VN40AMAZW+eLm8A54NOqvg8/961rAin4Kk4iIQhUf+QwUWk04Y/SuRGt3 YWWHiWuOmgc9q/RLbwmPUHnDmqXvVApyYdLVrd/nb7VPs9ssdd83/GMYpAuokOw= =xxOO -----END PGP SIGNATURE----- From jelmer at samba.org Wed Aug 3 14:27:37 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Wed, 03 Aug 2011 16:27:37 +0200 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <4E3953E7.2030603@doxxx.net> References: <1312330486.3032.21.camel@genhwyvar> <4E3953E7.2030603@doxxx.net> Message-ID: <1312381657.753.14.camel@genhwyvar> On Wed, 2011-08-03 at 09:57 -0400, Gordon Tyler wrote: > > I'm not trying to bikeshed here but this seems to have relevance to > actual technical issues encountered during implementation... > > Why use commas? Why not use a URL fragment to separate location from > branch name? > > bzr+ssh://host/path/to/repo#branch > > Looks a lot better to me than > > bzr+ssh://host/path/to/repo,branch The bit after the # isn't actually sent to the server, which makes it impossible to e.g. address branches over HTTP that way when opening them in a browser. A hash also requires escaping in a lot of shells, which makes it inconvenient to use for local paths. > And it allows you to avoid this issue of encoding/decoding commas. Instead it adds the issue of encoding/decoding hashes. I'm not sure if that really makes much difference. Cheers, Jelmer > > On 8/2/2011 8:14 PM, Jelmer Vernooij wrote: > > The ability to address colocated branches using URLs has long been > in > > progress (https://bugs.launchpad.net/bugs/380871). After > brainstorming a > > bit with John and Martin at the recent Launchpad sprint, I'm finally > > back on track hacking on it. > > > > There are basically four things left to do now: > > > > 1) Avoid URLescaping comma's when converting local paths to URLs. > > (lp:~jelmer/bzr/escape-comments) > > 2) Preserve the distinction between literal and delimiting comma's > in > > URLs when they are parsed in e.g. ConnectedTransport (2) > > 3) Parse the subsegment parameters for Transports and make them > > accessible (done, lp:~jelmer/bzr/transport-segments) > > 4) Look at the transport segment parameters in ControlDir and use > them > > to determine the default branch (this should be fairly easy) > > > > I'm wondering how exactly to do (2). At the moment when we receive a > URL > > we parse it and then urlunescape all characters. Among other things, > > this means that urlencoded characters won't be distinguisable from > > literal characters. > > > > So far, this distinction hasn't really mattered as we didn't have a > > different interpretation for them. > > > > To make sure we don't lose this information, I would like to stop > > urlunescaping things like ConnectedTransport._path, > > ConnectedTransport._username, etc and instead urlunescape it later. > Does > > that seem reasonable, or is there perhaps a better way to work > around > > the current limitations I haven't considered? > > > > Cheers, > > > > Jelmer > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOOVPnAAoJEIrPJfWinA2uSUIH/juyW6LuLVcg/qEe5E0SBW80 > HhFY6GkL1OMTTBLm1jQ2xfcJK01E/OmqKqqS7Jlsen8gZhBA7zqDGBoA0en+etrQ > 6YIk91zpAE9XgFv0bInUGgvYPybCRIfrcghfpivg0DkjckAZydkki5qra8CjiThG > ErmEDd0r9K1Tkg73c2RHgJm/977OMkr2RtFbm9H9SU8yhW+GYcDmZnxaUyfCTb1K > YNrVSC7VN40AMAZW+eLm8A54NOqvg8/961rAin4Kk4iIQhUf+QwUWk04Y/SuRGt3 > YWWHiWuOmgc9q/RLbwmPUHnDmqXvVApyYdLVrd/nb7VPs9ssdd83/GMYpAuokOw= > =xxOO > -----END PGP SIGNATURE----- > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From gordon at doxxx.net Wed Aug 3 20:34:18 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Wed, 03 Aug 2011 16:34:18 -0400 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <1312381657.753.14.camel@genhwyvar> References: <1312330486.3032.21.camel@genhwyvar> <4E3953E7.2030603@doxxx.net> <1312381657.753.14.camel@genhwyvar> Message-ID: <4E39B0CA.3040608@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/3/2011 10:27 AM, Jelmer Vernooij wrote: > The bit after the # isn't actually sent to the server, which makes it impossible to e.g. address branches over HTTP that way when opening them in a browser. A hash also requires escaping in a lot of shells, which makes it inconvenient to use for local paths. Ah, I wasn't aware of this. Good reason to use something else then. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOObDKAAoJEIrPJfWinA2u+NcH/RGCSCa5ah86yCrUb5wS46jW pxtJUVk/H4dLMCNFEQWZaTKSNkkMWOrvUHrTM2loTYLuGbuLzK7CpdJoL7CXd4Kq EfiIWyo14r1SR1gy2168MGhyvdGNeLUQzYPBu2xgdnPqxWtV12dP24+Uyui7nghb bQQZgffj46noXPyLmqe8yjnkmehnMXngGMpcL/oLT/F3q+pBIYZSGMzmE8SH6IUO 5Ss1mrrEVnTur8/hcoJgx9/t3eaGFRvR+9gB3WcwoxfFxmsT5M/M94tnxi4suRJr PQeSt3fc5l+4RGH6ZJVtQ/qW9ppGuerYeCEjyWdjHpAggb22z2JgkvQA3QRveJM= =3fd2 -----END PGP SIGNATURE----- From gordon at doxxx.net Wed Aug 3 20:38:44 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Wed, 03 Aug 2011 16:38:44 -0400 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <1312330486.3032.21.camel@genhwyvar> References: <1312330486.3032.21.camel@genhwyvar> Message-ID: <4E39B1D4.7090406@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/2/2011 8:14 PM, Jelmer Vernooij wrote: > To make sure we don't lose this information, I would like to stop > urlunescaping things like ConnectedTransport._path, > ConnectedTransport._username, etc and instead urlunescape it later. Does > that seem reasonable, or is there perhaps a better way to work around > the current limitations I haven't considered? Is it possible to guarantee that when they need to be unescaped, they will be? It would be a nasty bug to track down if a particular use of those fields was not getting them in unescaped form. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOObHTAAoJEIrPJfWinA2uH80H/3u+nLl7HSx0RfeS7QyEhX/B Xt12X+gtl0srRKX0E9nGKQ7I2Pe5d8CfH8VfYtQlWtL+ql03UVVRCo4ffc2s2b3Y Xw4kBhUzZ1NGKiRqA8pbyTQ9NMHNy3EIpA1khN+eBo3QnyoTz+EToAxIE++pOVJR NgqjidIODJpxLMybPp7QDWuG1UkN9o09Hn9BMpCU8yXS7UtN9QSWVWygdgE63xoQ RTw82Bw1gaYOjN5g2TGH2EZebcIoCMXqr+O5uBkTEoXsCk6U8c5VUWTYdkYUv38o ftMuFs5D1nJGKcPAir4sYUVORiJxrFTU39bQLuZxD2rCUhDZjY6s4Ws0A8sXSdw= =1ZRX -----END PGP SIGNATURE----- From mbp at canonical.com Thu Aug 4 01:05:21 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 4 Aug 2011 11:05:21 +1000 Subject: babune broken In-Reply-To: References: Message-ID: On 3 August 2011 14:00, Martin Pool wrote: > A recent change (probably one of mine) has broken babune on all Ubuntu > distroreleases, I guess with an environment-specific Unicode problem: > http://babune.ladeuil.net:24842/job/selftest-chroot-natty/lastCompletedBuild/testReport/ Also, maxb points out that some of the daily ppa builds are failing in . m From bialix at ukr.net Thu Aug 4 05:04:53 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Thu, 04 Aug 2011 08:04:53 +0300 Subject: [Bzr-packagers] TortoiseBzr 0.6.4 has been released In-Reply-To: References: Message-ID: <4E3A2875.1010701@ukr.net> 02.08.2011 1:40, Iwata ?????: > Now, TortoiseBzr 0.6.4 is available. > Please include this to windows installer of upcoming bzr-2.4 release. > (and bzr-2.3.5 if it will come). I've created merge proposal with updated version of TBZR for bzr 2.4: https://code.launchpad.net/~bialix/bzr-windows-installers/2.4final/+merge/70400 I suggest you to provide similar patches for bzr-windows-installers in the future. If you have any questions about that project -- please ask. -- All the dude wanted was his rug back From mbp at canonical.com Thu Aug 4 07:04:45 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 4 Aug 2011 17:04:45 +1000 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <1312330486.3032.21.camel@genhwyvar> References: <1312330486.3032.21.camel@genhwyvar> Message-ID: <20110804070445.GA6773@sourcefrog.net> On 3 Aug 2011, Jelmer Vernooij wrote: > The ability to address colocated branches using URLs has long been in > progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a > bit with John and Martin at the recent Launchpad sprint, I'm finally > back on track hacking on it. > > There are basically four things left to do now: > > 1) Avoid URLescaping comma's when converting local paths to URLs. > (lp:~jelmer/bzr/escape-comments) > 2) Preserve the distinction between literal and delimiting comma's in > URLs when they are parsed in e.g. ConnectedTransport (2) > 3) Parse the subsegment parameters for Transports and make them > accessible (done, lp:~jelmer/bzr/transport-segments) > 4) Look at the transport segment parameters in ControlDir and use them > to determine the default branch (this should be fairly easy) > > I'm wondering how exactly to do (2). At the moment when we receive a URL > we parse it and then urlunescape all characters. Among other things, > this means that urlencoded characters won't be distinguisable from > literal characters. > > So far, this distinction hasn't really mattered as we didn't have a > different interpretation for them. > > To make sure we don't lose this information, I would like to stop > urlunescaping things like ConnectedTransport._path, > ConnectedTransport._username, etc and instead urlunescape it later. Does > that seem reasonable, or is there perhaps a better way to work around > the current limitations I haven't considered? Maybe another way is to say that _unsplit_url (or something similar) should return a more-structured path object that contains information about path parameters - it can handle splitting them out at the same time it does the other unescaping? Also, since it now has about 6 return values, perhaps it should be superseded by a function that returns a ParsedURL with named fields (or something.) -- Martin From colin at gibibit.com Thu Aug 4 21:03:15 2011 From: colin at gibibit.com (Colin D Bennett) Date: Thu, 4 Aug 2011 14:03:15 -0700 Subject: We trying to launch the GitHub for Bzr In-Reply-To: <87vcwi1osk.fsf@benfinney.id.au> References: <20110606081918.4fc4d9a6@atmarama.net> <87vcwi1osk.fsf@benfinney.id.au> Message-ID: <20110804140315.52b7ddff@svelte> On Tue, 07 Jun 2011 10:13:47 +1000 Ben Finney wrote: > John Szakmeister writes: > > > I've found Launchpad's workflow a bit burdensome. On top of that, > > it tends to be sluggish. The permissions structure is also > > confusing. One of the nicest things about GitHub is the ability to > > host actual pages. So you can create a website for your project. > > If it has a clear place for a project's documentation, that in itself > will be a big advantage over Launchpad. +1 Whenever I hit the Launchpad page for a project, I am frustrated because I can't find a ?documentation? page. Usually I have to go find the main branch and browse around to see if I can find a README.txt or some HTML documentation in the source tree. Regards, Colin From newsgroups at catchall.shelter13.net Sat Jul 23 20:54:14 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sat, 23 Jul 2011 22:54:14 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: <4E2B211B.2020903@d6.com> References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> <4E2B0FF7.30807@catchall.shelter13.net> <4E2B211B.2020903@d6.com> Message-ID: <4E2B34F6.7030107@catchall.shelter13.net> Hi Chris, yeah, that's actually the reason why I'm looking into this at all. I have a research engine and it already has a bunch of binaries in the source tree (test textures, other test meshes, binary font files, stuff like this) and I basically see only two solutions to get it working with Bazaar: * Wait for foreign branch support: This would solve it neatly, as I could just have a subdirectory as a lightweight checkout and everything is fine. There's a bunch of problems with that approach when it comes to merging though (how do you merge trees which refer to different versions of the external branch?) (Right now, I have a lightweight checkout branch for the binary stuff, and the workflow sucks.) * Have Kiln-style binary file support right inside Bazaar: Binary files are stored along everything else, just the way they are retrieved changes. Approach two seemed easier to me, and now I just need to figure out how much work it's going to be. > I have some notes I've been meaning to post about "requirements" for a > large binaries feature to be really usable and valuable, but there's > been a fair amount of talk about it on various lists and wikis and > whatnot so you should check those out. Do you have some link? > The entire game > industry would switch overnight if this and the nested subtree thing > were solved well, though. I bet a bunch of researchers would like that as well, having large test data in a repository is not uncommon. > That said, if you do a stop-gap hack as a plugin that works well enough, > I'll definitely help you test it! :) Anything is better than running a > parallel svn tree for binaries. That's cool, thanks! Cheers, Anteru From newsgroups at catchall.shelter13.net Wed Jul 27 16:44:37 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Wed, 27 Jul 2011 18:44:37 +0200 Subject: Getting started with a content filter In-Reply-To: References: Message-ID: <4E304075.6000000@catchall.shelter13.net> Hi, > You can look up per-branch configuration options if you want to let > users control what is stored or where. But based on the previous > discussion it seemed to me that you'd probably want to have a file in > .bzrmeta that gives some additional files that ought to be checked > out, and the places to put them at? the main problem is how to distinguish between files with the same path. I.e. the user might to bzr add-large foo.png && bzr ci // mark foo.png as large bzr rm foo.png && bzr ci bzr add foo.png && bzr ci // foo.png is a small file now, and shouldn't be tracked any more Going with the meta-route, I'm going to check in foo.png.meta when using add-large, so I have something in the repository to get hold on. How would this work with .bzrmeta? I definitely need something versioned to attach the meta-data to, and the first plan is to simply store the meta-data instead of the actual data in the repository. Cheers, Anteru From newsgroups at catchall.shelter13.net Thu Jul 28 20:12:13 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Thu, 28 Jul 2011 22:12:13 +0200 Subject: Getting started with a content filter In-Reply-To: <4E313445.3000708@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <87aabzqb60.fsf@uwakimon.sk.tsukuba.ac.jp> <4E30F24D.3040505@d6.com> <871uxarcn3.fsf@uwakimon.sk.tsukuba.ac.jp> <4E313445.3000708@d6.com> Message-ID: <4E31C29D.3050306@catchall.shelter13.net> Hi, so just before this discussion gets completely out-of-scope :) Is there some wiki/discussion page/blueprint where we can take down notes so the use cases can be gathered somewhere? It seems to me that use-cases and solutions get mixed up a bit, which is not a good thing. I totally agree with Martin that large files should just work as small files. Ideally, you just set some per-branch value of how much space I'm willing to allocate to old revisions of binary files. That doesn't sound too hard in theory, once the actual work-flow is written down. As I don't have the expertise to improve bzr to the point where all data is passed around as streams, I'll focus on the proof-of-concept plugin which just adds some support for storing large files. I'm away for the next three weeks though, so progress might be a bit slow. Re locks: Locking files can be done already with a plugin, can't it? You just have to perform a commit to add some metadata on check-out and another one on check-in, and your editor must pick up the metadata. I can't see how file locking can be built in into a DVCS unless you run a lightweight checkout, and honestly, isn't that enough for artists anyway? Do artists really need old revisions from the repository? My feeling is that artists are fine with tons of local copies that they somehow manage on their own, so having a lightweight checkout for them shouldn't be much of a problem. For developers, you want real branches of course, but that's fine as developers shouldn't collide on binary content anyway. Cheers, Anteru From newsgroups at catchall.shelter13.net Sat Jul 23 18:16:23 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sat, 23 Jul 2011 20:16:23 +0200 Subject: Binary file storage similar to Kiln In-Reply-To: References: <4E29C058.9060303@arbash-meinel.com> <4E29E1CB.5080005@catchall.shelter13.net> Message-ID: <4E2B0FF7.30807@catchall.shelter13.net> Hi, > or it could even go into a single file eg. > .bzrmeta/bigfiles > which contains lines the path and the hash of each big file. all right, thanks for the keywords link, that definitely looks like a starting point. So how do you suggest to start? By having some meta files storing the hash which are tracked "as usual" by bzr, and get hold of the binary file associated with it using content filters? I'm new to Bazaar, and I haven't written a plugin for it yet, so here's some guesswork: Wouldn't this break when the file is actually changed? I.e. let's assume I want a work-flow like this ... bzr add-big foo.bin // foo.bin.meta gets added to the repository bzr ci // foo.bin.meta is committed // foo.bin gets transferred using some method to the server // other machine bzr pull // foo.bin.meta is checked out // content filter recognizes the file and fetches foo.bin touch foo.bin bzr status // will show foo.bin.meta as untouched, right? bzr ci // won't update foo.bin.meta, will it? My plan is initially to store the large files locally on disk and just get the hooking part working (i.e. no server-side communication.) I think it's enough if every binary file gets hashed and gets stored under its hash, delta compression is not important here at first and could be possibly added later on anyway. That should be the easy part. I assume the hard part is to get the transport layer to transfer the files and get them stored server-side. Cheers, Anteru From jelmer at samba.org Thu Aug 4 11:22:51 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Thu, 04 Aug 2011 13:22:51 +0200 Subject: Colocated branch support progress - preserving characters in URLs In-Reply-To: <20110804070445.GA6773@sourcefrog.net> References: <1312330486.3032.21.camel@genhwyvar> <20110804070445.GA6773@sourcefrog.net> Message-ID: <4E3A810B.8090804@samba.org> On 04/08/11 09:04, Martin Pool wrote: > On 3 Aug 2011, Jelmer Vernooij wrote: >> The ability to address colocated branches using URLs has long been in >> progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a >> bit with John and Martin at the recent Launchpad sprint, I'm finally >> back on track hacking on it. >> >> There are basically four things left to do now: >> >> 1) Avoid URLescaping comma's when converting local paths to URLs. >> (lp:~jelmer/bzr/escape-comments) >> 2) Preserve the distinction between literal and delimiting comma's in >> URLs when they are parsed in e.g. ConnectedTransport (2) >> 3) Parse the subsegment parameters for Transports and make them >> accessible (done, lp:~jelmer/bzr/transport-segments) >> 4) Look at the transport segment parameters in ControlDir and use them >> to determine the default branch (this should be fairly easy) >> >> I'm wondering how exactly to do (2). At the moment when we receive a URL >> we parse it and then urlunescape all characters. Among other things, >> this means that urlencoded characters won't be distinguisable from >> literal characters. >> >> So far, this distinction hasn't really mattered as we didn't have a >> different interpretation for them. >> >> To make sure we don't lose this information, I would like to stop >> urlunescaping things like ConnectedTransport._path, >> ConnectedTransport._username, etc and instead urlunescape it later. Does >> that seem reasonable, or is there perhaps a better way to work around >> the current limitations I haven't considered? > Maybe another way is to say that _unsplit_url (or something similar) > should return a more-structured path object that contains information > about path parameters - it can handle splitting them out at the same > time it does the other unescaping? > > Also, since it now has about 6 return values, perhaps it should be > superseded by a function that returns a ParsedURL with named fields (or > something.) I like that idea, it seems a lot easier than trying to manually keep track of what is and what is not urlescaped everywhere. I'll give it a go - thanks. Cheers, Jelmer From mbp at canonical.com Fri Aug 5 07:21:32 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 5 Aug 2011 17:21:32 +1000 Subject: pilot report Message-ID: I was patch pilot this week, and last week, because spiv was ill. We had quite a few submissions from new contributors which I've tried to finish off, but I haven't had a huge amount of time and there are still about 25 needing review in bzr itself[2] plus some more in other bzr-related projects[3]. We should soon be moving pqm onto some faster hardware which will make integration a little faster and dealing with mutually dependent branches a bit easier. Jelmer will be up next week[1], but he could probably do with help from other reviewers to finish off all this work. Martin [1] http://wiki.bazaar.canonical.com/PatchPilot#preview [2] https://code.launchpad.net/bzr/+activereviews [3] https://code.launchpad.net/bazaar/+activereviews From john at arbash-meinel.com Fri Aug 5 09:50:00 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 05 Aug 2011 11:50:00 +0200 Subject: Getting started with a content filter In-Reply-To: <4E30D12F.10407@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> Message-ID: <4E3BBCC8.5020402@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > 2. Can't have entire history in all branches because it gets too > big too fast on clients, need to store most of the large binary > history on a server. Is there a way to specify a partial history > like this now? Are stacked branches something that could help here? > It'd have to be per-file, though, not global to the entire branch. > In other words, I want all the code revisions local (or most of > them), but only the past two large binary revisions, or whatever. > The code would need to delete old history locally as new history is > checked in (assuming it's been successfully pushed to the server, of > course). This one is tricky. And because of this requirement, I feel it should be a specialized plugin/storage mechanism. There are lots of things like lightweight checkouts/stacked branches etc that one could do. It just feels like storing them out-of-band works best here. > > 3. Need some kind of locking protocol so two artists don't edit an > unmergable file at the same time. I know this is heresy for dvcs, > but it's going to have to get solved somehow if people are going to > use bzr for these media projects that need the large binary files. I > think this isn't that big of a deal for this use-case, because #2 is > going to require a server be accessible often anyway. Not sure what > to do when both artists are offline, but at least warning would be > something. > > Chris There are 2 plugins I know of that provide some sort of cooperative locking support for bzr. I had been working on one (about 50% complete, IIRC), and someone else put one together. Though I can't find it now. lp:~jameinel/+junk/file_locking I was happy with how mine was fleshing itself out. It basically writes a file to a shared location that tracks what files are/aren't locked. It tracked what *needed* to be locked by glob, IIRC. In a distributed system, locking is going to be cooperative, but if the tool support is reasonable, then I think it is fine to add. I still don't quite understand *why* two people would be trying to edit the same large-binary in incompatible ways. Although, maybe it is say editing the beginning and ending of a video. Which is perfectly compatible, just bad tool support for merging the changes together. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk47vMgACgkQJdeBCYSNAANkUwCglXpEBiLzfsjVncINHb2KnDpf D1MAoM/fgq8NxgLRZStNwRIXNihumCFz =yhtU -----END PGP SIGNATURE----- From vila+bzr at canonical.com Fri Aug 5 15:35:27 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Fri, 05 Aug 2011 17:35:27 +0200 Subject: stack-based configuration files road-map Message-ID: <87k4arzxa8.fsf@free.fr> Hi, >From some IRC discussions I'd like to clarify the road-map for the deployment of the stack-based config files. So far, the building blocks have landed and a couple of config options use the stack-based implementation while the rest of the options still use the actual implementation. Since there is a significant number of bugs to be address and many missing features roughly defined at http://doc.bazaar.canonical.com/devnotes/configuration.html , some things needs to be landed before other can be implemented. Here is one way to organize all the steps (some of them can be done concurrently): #. Use the stacked-based implementation for all bzr options. This will probably reveal bugs or missing features I didn't catch earlier. It will also probably clarify how remote branch config options behave (and whether the behavior is different when accessed via the smart server or via dumb protocols). #. Make 'bzr config' use the stack-based implementation #. Implement option expansion across sections and files. Convert all templates to use the option expansion instead of their specific implementation. Get rid of appendpath and friends, make sure variations are easy to add (appendir). #. Make sure that any config file is read/written once at most for a given bzr command. (Running the test suite as of today reports ~1e6 opened config files). #. Support declaring a list of environment variables acting as default values for a given option #. Add a command-line switch to override an option Once the above are addressed, it will become easier/clearer to think about adding new features (sections in all config files, distinction between defaults and overrides, system-wide config file). Adding new features could probably be driven by implementing the system-wide config file: #. Add a SystemStore handling a single no-name section (like branch.conf) #. Implement PathMatcher #. Add path-named sections by using the PathMatcher Vincent From checker at d6.com Fri Aug 5 17:59:26 2011 From: checker at d6.com (Chris Hecker) Date: Fri, 05 Aug 2011 10:59:26 -0700 Subject: Getting started with a content filter In-Reply-To: <4E3BBCC8.5020402@arbash-meinel.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> Message-ID: <4E3C2F7E.8060400@d6.com> > This one is tricky. And because of this requirement, I feel it should > be a specialized plugin/storage mechanism. There are lots of things > like lightweight checkouts/stacked branches etc that one could do. It > just feels like storing them out-of-band works best here. My guess is this means the feature is pretty much doomed to not work robustly in all cases, sadly. It's exactly like the submodules/externals problem, but it's maybe worse, because the files are part of the core project, not some recognized modular external library or whatever. I really wish I could convince one of the big three dvcs core teams that this set of features could form a foundation for a "next generation" dvcs, and that this is a big hole in the supported use-cases of existing dvcs. Frustrated, Chris On 2011/08/05 02:50, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ... > >> 2. Can't have entire history in all branches because it gets too >> big too fast on clients, need to store most of the large binary >> history on a server. Is there a way to specify a partial history >> like this now? Are stacked branches something that could help here? >> It'd have to be per-file, though, not global to the entire branch. >> In other words, I want all the code revisions local (or most of >> them), but only the past two large binary revisions, or whatever. >> The code would need to delete old history locally as new history is >> checked in (assuming it's been successfully pushed to the server, of >> course). > > This one is tricky. And because of this requirement, I feel it should be > a specialized plugin/storage mechanism. There are lots of things like > lightweight checkouts/stacked branches etc that one could do. It just > feels like storing them out-of-band works best here. > >> >> 3. Need some kind of locking protocol so two artists don't edit an >> unmergable file at the same time. I know this is heresy for dvcs, >> but it's going to have to get solved somehow if people are going to >> use bzr for these media projects that need the large binary files. I >> think this isn't that big of a deal for this use-case, because #2 is >> going to require a server be accessible often anyway. Not sure what >> to do when both artists are offline, but at least warning would be >> something. >> >> Chris > > There are 2 plugins I know of that provide some sort of cooperative > locking support for bzr. I had been working on one (about 50% complete, > IIRC), and someone else put one together. Though I can't find it now. > > lp:~jameinel/+junk/file_locking > > I was happy with how mine was fleshing itself out. It basically writes a > file to a shared location that tracks what files are/aren't locked. It > tracked what *needed* to be locked by glob, IIRC. > > In a distributed system, locking is going to be cooperative, but if the > tool support is reasonable, then I think it is fine to add. I still > don't quite understand *why* two people would be trying to edit the same > large-binary in incompatible ways. Although, maybe it is say editing the > beginning and ending of a video. Which is perfectly compatible, just bad > tool support for merging the changes together. > > John > =:-> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk47vMgACgkQJdeBCYSNAANkUwCglXpEBiLzfsjVncINHb2KnDpf > D1MAoM/fgq8NxgLRZStNwRIXNihumCFz > =yhtU > -----END PGP SIGNATURE----- > From andreas.ostermann.11 at googlemail.com Wed Aug 10 06:27:30 2011 From: andreas.ostermann.11 at googlemail.com (Andreas Ostermann) Date: Wed, 10 Aug 2011 08:27:30 +0200 Subject: bzr push one branch below another In-Reply-To: References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> Message-ID: Hi, But what bazaar should avoid is to push into a shared repository location. I created a shared repository: xxx/projectA Then wen had some branches there: xxx/projectA/userA xxx/projectA/userB xxx/projectA/userC My colleague accidentaly pushed into xxx/projectA, which directly created a branch there. I think this should be avoided. brgds, AO 2011/7/11 Marco Pantaleoni : > On Fri, Jul 8, 2011 at 9:20 PM, Denys Duchier > wrote: >> >> currently, it is possible to "bzr push" a branch into a subdirectory of >> another branch. ?should bzr complain? ?is it worth it? > > It's a feature that I use constantly, so I don't think bzr should complain > :-) > > Ciao, > Marco > > -- > Marco Pantaleoni > > From Michael.Gliwinski at henderson-group.com Wed Aug 10 07:53:23 2011 From: Michael.Gliwinski at henderson-group.com (Michael Gliwinski) Date: Wed, 10 Aug 2011 08:53:23 +0100 Subject: bzr push one branch below another In-Reply-To: References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> Message-ID: <201108100853.24246.Michael.Gliwinski@henderson-group.com> On Wednesday 10 Aug 2011 07:27:30 Andreas Ostermann wrote: > But what bazaar should avoid is to push into a shared repository location. > > I created a shared repository: > > xxx/projectA > > Then wen had some branches there: > > xxx/projectA/userA > xxx/projectA/userB > xxx/projectA/userC > > My colleague accidentaly pushed into xxx/projectA, which directly > created a branch there. I think this should be avoided. Well, this is actually useful as well. IIRC it's even mentioned in the user guide. E.g. for some of our projects we have: .../projectA # trunk .../projectA/feature1 # common feature branch .../projectA/user1/feature1 # user1's feature branch -- Michael Gliwinski Henderson Group Information Services 9-11 Hightown Avenue, Newtownabby, BT36 4RT Phone: 028 9034 3319 ********************************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract. If you have received this email in error please notify support at henderson-group.com John Henderson (Holdings) Ltd Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. Registered in Northern Ireland Registration Number NI010588 Vat No.: 814 6399 12 ********************************************************************************* From michaelcrain at hotmail.com Wed Aug 10 11:02:17 2011 From: michaelcrain at hotmail.com (spinner) Date: Wed, 10 Aug 2011 04:02:17 -0700 (PDT) Subject: Latex project with parent-child files Message-ID: <32223099.post@talk.nabble.com> I'm a newby to Bazaar and looking at Bazaar Explorer to manage my dissertation writing. I'm writing my diss in multiple LaTex files and bringing them together into a parent (wrap) file with \include{chap1.tex}, \include{chap2.tex}, etc. I'm having a problem in identifying the proper parent-child folder structure to write the necessary .aux files (Tex) so the folders? work with Bazaar. I can't figure out a directory structure that blends Tex's requirements to write aux files for the child files and Bazaar. I'm hoping someone else has already figured out how to make these two requirements work together. First, here's my understanding of Bazaar's general folder requirements. I believe it essentially works with this folder structure for simple projects: ~/diss/wrap/trunk/wrapfile.tex. It adds a folder named 'trunk' and my working tex file is in this trunk folder. Bazaar's 'project' name is the name of the preceding folder 'wrap' and the working tex file is not in this folder. To keep a tidy version system, I want to keep my chapters as separate versioning 'projects' in different folders. Thus: /chap1/trunk/chap1.tex, /chap2/trunk/chap2.tex, etc. I don't want to put all these chapter tex files in one huge Bazaar project folder because the folder gets untidy. Second, to compile a document in LaTeX with parent-child files when these files are in separate directories, I understand Tex requires that the child tex files be in subfolders below the parent to get the \include command in the parent (wrap) file to work properly, which depends on Tex writing aux files for each child in their respective child folders. Thus, we have this folder structure according to Tex's requirements: /wrap/wrapfile.tex /wrap/chap1/chap1.tex /wrap/chap2/chap2.tex Here's my problem. How do I reconcile Tex's and Bazaar's requirements? Bazaar needs this folder structure to keep chapters as separate versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex How do the child files and their folders fit into this version system? Logically, I don't believe this will work well in Bazaar: /wrap/trunk/wrapfile.tex /wrap/trunk/chap1/trunk/chap1.tex If you are still reading this message, thank you. As I said, I hope someone has already found a solution to get parent-child files working with Bazaar and keeping chapters as separate projects. Many thanks. -- View this message in context: http://old.nabble.com/Latex-project-with-parent-child-files-tp32223099p32223099.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From russel at russel.org.uk Wed Aug 10 15:27:49 2011 From: russel at russel.org.uk (Russel Winder) Date: Wed, 10 Aug 2011 16:27:49 +0100 Subject: Latex project with parent-child files In-Reply-To: <32223099.post@talk.nabble.com> References: <32223099.post@talk.nabble.com> Message-ID: <1312990069.5923.24.camel@launcelot.russel.org.uk> Michael, On Wed, 2011-08-10 at 04:02 -0700, spinner wrote: > I'm a newby to Bazaar and looking at Bazaar Explorer to manage my > dissertation > writing. I'm writing my diss in multiple LaTex files and bringing them > together into a parent (wrap) file with \include{chap1.tex}, > \include{chap2.tex}, etc. Sounds standard and sensible to me :-) > I'm having a problem in identifying the proper parent-child folder > structure to write the necessary .aux files (Tex) so the folders? work > with Bazaar. I can't figure out a directory structure that blends > Tex's requirements to write aux files for the child files and > Bazaar. I'm hoping someone else has already figured out how to make > these two requirements work together. I am not sure what has given you the ideas that Bazaar has a required folder structure because it does not. Bazaar manages a directory tree without regard for any structure other than that the .bzr directory at the top of the project hierarchy is special. Thus the only requirements are those of TeX. (I assume you are using pdfLaTex or XeLaTeX rather than TeX.) > First, here's my understanding of Bazaar's general folder > requirements. I believe it essentially works with this folder > structure for simple projects: ~/diss/wrap/trunk/wrapfile.tex. It adds > a folder named 'trunk' and my working tex file is in this trunk > folder. Bazaar's 'project' name is the name of the preceding folder > 'wrap' and the working tex file is not in this folder. To keep a tidy > version system, I want to keep my chapters as separate versioning > 'projects' in different folders. Thus: /chap1/trunk/chap1.tex, > /chap2/trunk/chap2.tex, etc. I don't want to put all these chapter tex > files in one huge Bazaar project folder because the folder gets > untidy. Uuuurrrr.... no. I am not sure what documentation has given you this view of Bazaar, but it is wrong. (Ignoring the complexity of shared repositories) The project directory (branch) is the one with .bzr in it. There are no other constraints. I generally have a branch looking something like: + doc.ltx + Chapters | + chapter1.ltx | + chapter2.ltx etc. I don't see any need for anything more complex than this since to appear to separately version each chapter you just have the workflow of only ever committing one file at a time. > Second, to compile a document in LaTeX with parent-child files when > these files are in separate directories, I understand Tex requires > that the child tex files be in subfolders below the parent to get the > \include command in the parent (wrap) file to work properly, which > depends on Tex writing aux files for each child in their respective > child folders. Thus, we have this folder structure according to Tex's > requirements: /wrap/wrapfile.tex /wrap/chap1/chap1.tex > /wrap/chap2/chap2.tex TeX has no such requirement, you can input or include files from anywhere in the filestore. It is normal though for the input/include files to be in subdirectories. The aux files will be written in the directory in which the source file offered to the executable of (pdf|xe)(La)TeX is. > Here's my problem. How do I reconcile Tex's and Bazaar's requirements? > > Bazaar needs this folder structure to keep chapters as separate > versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex I don't understand the need to separately version chapters. > How do the child files and their folders fit into this version system? > Logically, I don't believe this will work well in Bazaar: > /wrap/trunk/wrapfile.tex /wrap/trunk/chap1/trunk/chap1.tex If you really have to have separate Bazaar branches per chapter then create the branches all in the same directory and them just use the ../chapterN/chapterN.ltx type path in the input/include. > If you are still reading this message, thank you. As I said, I hope > someone has already found a solution to get parent-child files working > with Bazaar and keeping chapters as separate projects. Many thanks. To quote: If I want to get there, I wouldn't start here. I would just use a single Bazaar branch with the control LaTeX file in the root (with the .bzr directory) and then subdirectories for Chapters, Images, SourceCode etc. with the Images and SourceCode directories having per chapter subdirectories. Then use Waf or SCons to manage everything. Do not even think about keeping aux files in the branch under version control, generate them every session. Having written a number of books using LaTeX (and now XeLaTeX), I can attest to the fact that letting Waf/SCons control the dependencies is about 100000000% easier than trying to do what it says in the TeXBook -- which is about 20 years behind the times in terms of tooling. But that criticism doesn't mean I don't love and use XeLaTeX -- I think it is the only sane document preparation system (*). (*) Except for slides for presentation where I admit I don't use beamer because it is too restrictive, I'm afraid I just use LibreOffice Impress for that. But XeLaTex for everything else document wise. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From colin at gibibit.com Wed Aug 10 23:36:09 2011 From: colin at gibibit.com (Colin D Bennett) Date: Wed, 10 Aug 2011 16:36:09 -0700 Subject: bzr push one branch below another In-Reply-To: <201108100853.24246.Michael.Gliwinski@henderson-group.com> References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> <201108100853.24246.Michael.Gliwinski@henderson-group.com> Message-ID: <20110810163609.5ef90698@svelte> On Wed, 10 Aug 2011 08:53:23 +0100 Michael Gliwinski wrote: > On Wednesday 10 Aug 2011 07:27:30 Andreas Ostermann wrote: > > But what bazaar should avoid is to push into a shared repository > > location. > > > > I created a shared repository: > > > > xxx/projectA > > > > Then wen had some branches there: > > > > xxx/projectA/userA > > xxx/projectA/userB > > xxx/projectA/userC > > > > My colleague accidentaly pushed into xxx/projectA, which directly > > created a branch there. I think this should be avoided. > > Well, this is actually useful as well. IIRC it's even mentioned in > the user guide. E.g. for some of our projects we have: > > .../projectA # trunk > .../projectA/feature1 # common feature branch > .../projectA/user1/feature1 # user1's feature branch Agreed. Please don't remove the ability to have a branch in the root of a shared repository. However, I think there is still a good solution to Andreas's colleague's problem of accidentally pushing to xxx/projectA instead of xxx/projectA/userB: Add some way to specifically tell Bazaar not to allow a branch to be created in a specific location. Perhaps create a .bzr/no-branches-allowed file? Or an option in the repository config file? Regards, Colin From colin at gibibit.com Wed Aug 10 23:41:55 2011 From: colin at gibibit.com (Colin D Bennett) Date: Wed, 10 Aug 2011 16:41:55 -0700 Subject: Latex project with parent-child files In-Reply-To: <1312990069.5923.24.camel@launcelot.russel.org.uk> References: <32223099.post@talk.nabble.com> <1312990069.5923.24.camel@launcelot.russel.org.uk> Message-ID: <20110810164155.79ce36ea@svelte> On Wed, 10 Aug 2011 16:27:49 +0100 Russel Winder wrote: > Michael, > > On Wed, 2011-08-10 at 04:02 -0700, spinner wrote: > > Bazaar needs this folder structure to keep chapters as separate > > versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex > > I don't understand the need to separately version chapters. Perhaps the desire is to be able to follow the evolution of a specific chapter more easily, without getting entangled by other chapters' changes? That's the only thing that comes to mind for me. Even in that case, you could put all chapters in one Bazaar branch (versioning the entire dissertation as a single entity), and then do 'bzr log chap1' or 'bzr qlog chap1' etc. to see the log of a specific chapter. For one thing, keeping the entire document in one Bazaar branch means you can uniquely identify a version of the document with the Bazaar revno or revid. This makes backups and release management easier. Regards, Colin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From nils-gmane at ackermath.info Thu Aug 11 00:14:15 2011 From: nils-gmane at ackermath.info (Nils Ackermann) Date: Wed, 10 Aug 2011 19:14:15 -0500 Subject: Latex project with parent-child files References: <32223099.post@talk.nabble.com> Message-ID: <87vcu4st2g.fsf@thysbe.localdomain> spinner writes: > I'm a newby to Bazaar and looking at Bazaar Explorer to manage my > dissertation writing. I'm writing my diss in multiple LaTex files and > bringing them together into a parent (wrap) file with > \include{chap1.tex}, \include{chap2.tex}, etc. Nowadays I don't see the necessity anymore to split up my Latex projects into parts. I use one large latex file for the text and keep it under bzr in just one directory, together with helper files such as .bzrignore, Makefile and scripts from the vc latex bundle http://www.ctan.org/pkg/vc There are editors out there that deal well with large Latex files if they are properly structured. HTH, Nils From russel at russel.org.uk Thu Aug 11 02:07:19 2011 From: russel at russel.org.uk (Russel Winder) Date: Thu, 11 Aug 2011 03:07:19 +0100 Subject: Latex project with parent-child files In-Reply-To: <20110810164155.79ce36ea@svelte> References: <32223099.post@talk.nabble.com> <1312990069.5923.24.camel@launcelot.russel.org.uk> <20110810164155.79ce36ea@svelte> Message-ID: <1313028439.4643.2.camel@launcelot.russel.org.uk> On Wed, 2011-08-10 at 16:41 -0700, Colin D Bennett wrote: [ . . . ] > Perhaps the desire is to be able to follow the evolution of a > specific chapter more easily, without getting entangled by other > chapters' changes? That's the only thing that comes to mind for me. It just seems like beginning to implement CVS using Bazaar as infrastructure? > Even in that case, you could put all chapters in one Bazaar branch > (versioning the entire dissertation as a single entity), and then do > 'bzr log chap1' or 'bzr qlog chap1' etc. to see the log of a specific > chapter. > > For one thing, keeping the entire document in one Bazaar branch means > you can uniquely identify a version of the document with the Bazaar > revno or revid. This makes backups and release management easier. Which was the whole reason for Subversion replacing CVS I suspect :-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mbp at canonical.com Thu Aug 11 05:26:12 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 11 Aug 2011 15:26:12 +1000 Subject: stack-based configuration files road-map In-Reply-To: <87k4arzxa8.fsf@free.fr> References: <87k4arzxa8.fsf@free.fr> Message-ID: That sounds great. The 'load it just once' probably means tying the configuration objects to the library state object. One other thing has been on my mind, which is handling configuration and isolation during testing: * in (nearly?) every case, we want tests to run totally isolated from the configuration of the user running the tests; having all configuration go through a single patch will let us clean up some code that does that, but it also may mean the stack itself needs to be isolated * since the tests don't care about the user's configuration, they don't really need to go to a file on disk * it would be useful to have a clean way for tests to see what happens when a particular value is configured * some tests for configuration itself will be exceptions Martin From john at arbash-meinel.com Thu Aug 11 08:07:15 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Thu, 11 Aug 2011 10:07:15 +0200 Subject: How to fix bug 498952? In-Reply-To: <4E31B989.4000209@gmx.net> References: <4E31B989.4000209@gmx.net> Message-ID: <4E438DB3.7070602@arbash-meinel.com> On 7/28/2011 9:33 PM, Dennis Benzinger wrote: > Hi! > > I'm trying to fix bug , > but I'm not sure it should be done. > > Would it be acceptable to use the reStructuredText parser from > docutils? Or should additional dependencies be avoided and some regex > based parsing of the table be used? > > > Best regards, Dennis Benzinger > Sorry about the delay in response to this. I think having autodoc use the reStructuredText parser would be reasonable. I'm not really sure what the intermediate form is, though. It might be easier to do with a simple regex based parser. If I were working on it, I would probably start at looking at the reST parser, but I wouldn't stick with it if it didn't look promising. John =:-> From vila+bzr at canonical.com Thu Aug 11 13:37:41 2011 From: vila+bzr at canonical.com (vila+bzr at canonical.com) Date: Thu, 11 Aug 2011 15:37:41 +0200 Subject: stack-based configuration files road-map In-Reply-To: (Martin Pool's message of "Thu, 11 Aug 2011 15:26:12 +1000") References: <87k4arzxa8.fsf@free.fr> Message-ID: >>>>> Martin Pool writes: > That sounds great. > The 'load it just once' probably means tying the configuration objects > to the library state object. Yes. > One other thing has been on my mind, which is handling configuration > and isolation during testing: Since they depend on BZR_HOME, that shouldn't be an issue. > * in (nearly?) every case, we want tests to run totally isolated from > the configuration of the user running the tests; having all > configuration go through a single patch will let us clean up some code > that does that, but it also may mean the stack itself needs to be > isolated Right, we miss a registry to acquire the stacks for a given context, I'm working on that. > * since the tests don't care about the user's configuration, they > don't really need to go to a file on disk I'm not sure I follow here, tests have a isolated home directory so they'll find their own config files (or not) there. Are you thinking about a way to force a given option value for a test (or a class/suite/run) ? Like using a command-line option (http://pad.lv/491196) ? > * it would be useful to have a clean way for tests to see what > happens when a particular value is configured Yup. I'm still unclear on how we will use that but that's definitely something I want to investigate. > * some tests for configuration itself will be exceptions What do you mean by configuration here ? From michaelcrain at hotmail.com Fri Aug 12 03:29:29 2011 From: michaelcrain at hotmail.com (spinner) Date: Thu, 11 Aug 2011 20:29:29 -0700 (PDT) Subject: Latex project with parent-child files In-Reply-To: <1313028439.4643.2.camel@launcelot.russel.org.uk> References: <32223099.post@talk.nabble.com> <1312990069.5923.24.camel@launcelot.russel.org.uk> <20110810164155.79ce36ea@svelte> <1313028439.4643.2.camel@launcelot.russel.org.uk> Message-ID: <32246973.post@talk.nabble.com> Many thanks for all your excellent comments. I discovered that the source of my biggest confusion is selecting the model when initializing a new project. It seems that I should be using the plain branch model. The documentation said that 99% of the time the model will be something else. Now, the structure looks like I want. No 'trunk' folder, which was the source of my initial confusion. I'll be testing this out over the next several days. Question: I am using Bazaar solo, and not using it to collaborate with others. Also, I carry my files on an external HD between my office and home computers. I've got things installed and working on one computer. Do I need to do anything on the second computer, working with the same external drive, other than install Bazaar on it? Russel, I'm not familiar with Waf nor SCons. Do these work in conjunction with a LaTeX package (I have the MikTex installation)? What does it do better than LaTeX? I understand it doesn't create all those annoying Tex process files. What else? Thanks again. -- View this message in context: http://old.nabble.com/Latex-project-with-parent-child-files-tp32223099p32246973.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From stephen at xemacs.org Fri Aug 12 04:46:37 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Fri, 12 Aug 2011 13:46:37 +0900 Subject: Latex project with parent-child files In-Reply-To: <32246973.post@talk.nabble.com> References: <32223099.post@talk.nabble.com> <1312990069.5923.24.camel@launcelot.russel.org.uk> <20110810164155.79ce36ea@svelte> <1313028439.4643.2.camel@launcelot.russel.org.uk> <32246973.post@talk.nabble.com> Message-ID: <87obzvme36.fsf@uwakimon.sk.tsukuba.ac.jp> spinner writes: > I discovered that the source of my biggest confusion is selecting the > model when initializing a new project. I'm pretty sure you're referring to "shared repositories." It may have seemed otherwise, but in fact shared repositories are a pure space optimization for multi-branch projects.[1] They have *no* implications at all for the structure of the project itself. > Question: I am using Bazaar solo, and not using it to collaborate with > others. Also, I carry my files on an external HD between my office and > home computers. I've got things installed and working on one > computer. Do I need to do anything on the second computer, working > with the same external drive, other than install Bazaar on it? No. > Russel, I'm not familiar with Waf nor SCons. These are build dependency management software. The traditional tool on Unix is called "make". The basic problem is that you may have generated files for your document (such as graphs). Doing the work of generating them every time is time-consuming, ie, slows down the edit-generate-review cycle. Make-like tools help minimize the work done in generating your document, thus speeding up the process. Probably MikTeX handles the basics for you already, though. Does MikTex ever produce output that does *not* reflect some change or addition you've made to the document? If the answer is "no", you don't *need* Waf or SCons. (Though you may find them useful in projects where you want more automation than MikTeX provides -- if you've got a little time, you might want to investigate them.) > I understand it doesn't create all those annoying Tex process > files. What else? That's probably not a benefit. TeX creates the TeX process files. (It's possible that MikTeX allows you to generate one chapter at a time, in which case you would get fewer files because make-like tools are more or less designed for processing the whole document every time, but skipping steps that were already done the last time.) However, if you are working in a MikTeX interface for TeX and Bazaar Explorer for version control, I don't see why you should care about the auxiliary files. MikTeX should suppress listing of .aux, .dvi, and .log files unless you ask for them, and Bazaar Explorer will do the same if you add a .bzrignore file with three lines *.aux *.dvi *.log in it to the top folder of your project. Of course if you get a file listing from the command shell or the GUI desktop file manager, you get all the gory details. Then for the command shell, "bzr ls" will DTRT, and as for using the file manager, "the doctor says, 'if it hurts, just stop doing that!'" :-) Just get used to using Bazaar Explorer instead. Footnotes: [1] A project where for some reason multiple versions of the same content are in development at the same time. For example, in the case of a dissertation, you may have a chapter which you are simultaneously submitting for publication. Your examiners will likely demand a "fat" discussion proving you know everything about the subject, while the journal editor will insist on a "lean" discussion, assuming that the reader knows almost everything and you just tell her the news. It's not clear to me that existing VCSes can help you much with this particular case, but that's the kind of thing branches help manage. From russel at russel.org.uk Fri Aug 12 08:07:41 2011 From: russel at russel.org.uk (Russel Winder) Date: Fri, 12 Aug 2011 09:07:41 +0100 Subject: Latex project with parent-child files In-Reply-To: <87obzvme36.fsf@uwakimon.sk.tsukuba.ac.jp> References: <32223099.post@talk.nabble.com> <1312990069.5923.24.camel@launcelot.russel.org.uk> <20110810164155.79ce36ea@svelte> <1313028439.4643.2.camel@launcelot.russel.org.uk> <32246973.post@talk.nabble.com> <87obzvme36.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1313136461.746.63.camel@anglides.russel.org.uk> On Fri, 2011-08-12 at 13:46 +0900, Stephen J. Turnbull wrote: [ . . . ] > > Russel, I'm not familiar with Waf nor SCons. > > These are build dependency management software. The traditional tool > on Unix is called "make". The basic problem is that you may have > generated files for your document (such as graphs). Doing the work of > generating them every time is time-consuming, ie, slows down the > edit-generate-review cycle. Make-like tools help minimize the work > done in generating your document, thus speeding up the process. Make though is very platform dependent because the dependency language is separate from the action language (external DSL). Hence CMake. Waf and SCons are Python based systems such that the action language and the dependency language are the same (internal DSL). This makes Waf and SCons far more portable. Plus they have far superior built-in handling of LaTeX build. (Rake, etc. provide the dependency management as an internal DSL and then leave you to deal with all your own action rules -- unless you are managing Ruby applications.) > Probably MikTeX handles the basics for you already, though. Does > MikTex ever produce output that does *not* reflect some change or > addition you've made to the document? If the answer is "no", you > don't *need* Waf or SCons. (Though you may find them useful in > projects where you want more automation than MikTeX provides -- if > you've got a little time, you might want to investigate them.) As far as I know (I don't use Windows) MikTeX is just a packaging of (La)TeX for Windows, it doesn't provide tooling other than a previewer. Think an "easy to install on Windows" version of TeXLive. Except that MikTeX has an auto installing package manager which sounds very cool. I am not sure if TeXWorks comes bundled in MikTeX as it does in MacTex and is packaged for Debian. > > I understand it doesn't create all those annoying Tex process > > files. What else? > > That's probably not a benefit. TeX creates the TeX process files. > (It's possible that MikTeX allows you to generate one chapter at a > time, in which case you would get fewer files because make-like tools > are more or less designed for processing the whole document every > time, but skipping steps that were already done the last time.) > > However, if you are working in a MikTeX interface for TeX and Bazaar > Explorer for version control, I don't see why you should care about > the auxiliary files. MikTeX should suppress listing of .aux, .dvi, > and .log files unless you ask for them, and Bazaar Explorer will do > the same if you add a .bzrignore file with three lines > > *.aux > *.dvi > *.log If you are using makeindex or bibtex there are a whole load more extra generated files you want to ignore as far as Bazaar is concerned. I do not ignore them though as it shows when I haven't cleaned a project. I find it far easier to recreate all the generated files when I sit down for a session, and then remove them all at the end of that session. Even for a complex 700 page book creation time is very short and leaving files lying round just isn't worth it. I can see in the days before sensible build support a different work process was valid, but these days, it is much easier to use the tools rather than leave stuff lying around. > in it to the top folder of your project. Of course if you get a file > listing from the command shell or the GUI desktop file manager, you > get all the gory details. Then for the command shell, "bzr ls" will > DTRT, and as for using the file manager, "the doctor says, 'if it > hurts, just stop doing that!'" :-) Just get used to using Bazaar > Explorer instead. Unless you are a command line addict as I am in which case "bzr glog" is about the only GUI tool I use for Bazaar. > > Footnotes: > [1] A project where for some reason multiple versions of the same > content are in development at the same time. For example, in the case > of a dissertation, you may have a chapter which you are simultaneously > submitting for publication. Your examiners will likely demand a "fat" > discussion proving you know everything about the subject, while the > journal editor will insist on a "lean" discussion, assuming that the > reader knows almost everything and you just tell her the news. It's > not clear to me that existing VCSes can help you much with this > particular case, but that's the kind of thing branches help manage. That sounds like two different documents that originally shared some material to me rather than variants of the same project. I would advise two branches, one for the dissertation and one for the paper and use a merge tool to deal with keeping common material in sync. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From mbp at canonical.com Fri Aug 12 08:17:18 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 12 Aug 2011 18:17:18 +1000 Subject: stack-based configuration files road-map In-Reply-To: References: <87k4arzxa8.fsf@free.fr> Message-ID: On 11 August 2011 23:37, wrote: >>>>>> Martin Pool writes: > > ? ?> That sounds great. > ? ?> The 'load it just once' probably means tying the configuration objects > ? ?> to the library state object. > > Yes. > > ? ?> One other thing has been on my mind, which is handling configuration > ? ?> and isolation during testing: > > Since they depend on BZR_HOME, that shouldn't be an issue. It will be for the system-global file that Grid is adding. > > ? ?> ?* in (nearly?) every case, we want tests to run totally isolated from > ? ?> the configuration of the user running the tests; having all > ? ?> configuration go through a single patch will let us clean up some code > ? ?> that does that, but it also may mean the stack itself needs to be > ? ?> isolated > > Right, we miss a registry to acquire the stacks for a given context, I'm > working on that. > > ? ?> ?* since the tests don't care about the user's configuration, they > ? ?> don't really need to go to a file on disk > > I'm not sure I follow here, tests have a isolated home directory so > they'll find their own config files (or not) there. > > Are you thinking about a way to force a given option value for a test > (or a class/suite/run) ? > > Like using a command-line option (http://pad.lv/491196) ? I was thinking that it's just inefficient to do disk IO when we know there's nothing interesting there; but obviously this is not urgent. > > ? ?> ?* it would be useful to have a clean way for tests to see what > ? ?> happens when a particular value is configured > > Yup. I'm still unclear on how we will use that but that's definitely > something I want to investigate. > > ? ?> ?* some tests for configuration itself will be exceptions > > What do you mean by configuration here ? Tests that the configuration stack really does go to disk, to the user's directory, etc. Martin From vila+bzr at canonical.com Fri Aug 12 09:43:38 2011 From: vila+bzr at canonical.com (vila) Date: Fri, 12 Aug 2011 11:43:38 +0200 Subject: stack-based configuration files road-map In-Reply-To: (Martin Pool's message of "Fri, 12 Aug 2011 18:17:18 +1000") References: <87k4arzxa8.fsf@free.fr> Message-ID: >>>>> Martin Pool writes: >> Since they depend on BZR_HOME, that shouldn't be an issue. > It will be for the system-global file that Grid is adding. Ha, right, yeah, forgot that one (even if I mentioned it in the review ;) > I was thinking that it's just inefficient to do disk IO when we know > there's nothing interesting there; but obviously this is not urgent. And probably a premature optimization compared to the fact that we read a config file for every option *today*, reaching the point where a config file is read only once (even if it doesn't exist) will already be the most significant progress. >> >> ? ?> ?* it would be useful to have a clean way for tests to see what >> ? ?> happens when a particular value is configured >> >> Yup. I'm still unclear on how we will use that but that's definitely >> something I want to investigate. >> >> ? ?> ?* some tests for configuration itself will be exceptions >> >> What do you mean by configuration here ? > Tests that the configuration stack really does go to disk, to the > user's directory, etc. Right, basic unit tests then, I think we have adequate coverage so far but feel free to contradict me ;) Vincent From iwata0303 at gmail.com Fri Aug 12 16:44:13 2011 From: iwata0303 at gmail.com (Iwata) Date: Sat, 13 Aug 2011 01:44:13 +0900 Subject: TortoiseBzr 0.6.5 has been released Message-ID: Hi, all. Now, TortoiseBzr 0.6.5 is available. This is maintenance release only one fix is included. BUG FIXES: * No tbzr menus are shown in the folders under Windows 7 "Libraries". (#819426) From vila+bzr at canonical.com Sat Aug 13 19:45:21 2011 From: vila+bzr at canonical.com (vila) Date: Sat, 13 Aug 2011 21:45:21 +0200 Subject: [ANN] bzr 2.4.0 has gone gold Message-ID: Hi, Here comes 2.4.0 ! Let's build installers and packages to make 2.4.0 an even better bzr than ever. All plugin authors should now have official releases for inclusion. If they haven't yet and you encounter issues while packaging, please report here so we can more easily track the issues (or even better file bugs *and* report here ;). It will also be nice if you can reply to this mail to list which versions of which plugins you packaged. See the Changelog at https://launchpad.net/bzr/2.4/2.4.0 for more details about what is included and for the tarball. I'll make the official announcement next Tuesday morning UTC (2011-08-16) with whatever packages/installers are available at this point. Have fun ! Vincent From newsgroups at catchall.shelter13.net Sun Aug 14 09:26:53 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sun, 14 Aug 2011 11:26:53 +0200 Subject: Getting started with a content filter In-Reply-To: <4E3C2F7E.8060400@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> <4E3C2F7E.8060400@d6.com> Message-ID: <4E4794DD.7060706@catchall.shelter13.net> Hi, > I really wish I could convince one of the big three dvcs core teams > that this set of features could form a foundation for a "next > generation" dvcs, and that this is a big hole in the supported > use-cases of existing dvcs. Do you have a bug open for this? I've created a Wiki page here: http://wiki.bazaar.canonical.com/Specs/LFStore That would provide at least a single point where the use-cases are documented, so anyone can pick it up. (Side note: The wiki seems partly broken. In particular, http://wiki.bazaar.canonical.com/CategorySpecification does not show anything, and the "search bazaar" text in the top right is partly obscured by the search box itself.) Cheers, Anteru From newsgroups at catchall.shelter13.net Sun Aug 14 09:26:53 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Sun, 14 Aug 2011 11:26:53 +0200 Subject: Getting started with a content filter In-Reply-To: <4E3C2F7E.8060400@d6.com> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> <4E3C2F7E.8060400@d6.com> Message-ID: <4E4794DD.7060706@catchall.shelter13.net> Hi, > I really wish I could convince one of the big three dvcs core teams > that this set of features could form a foundation for a "next > generation" dvcs, and that this is a big hole in the supported > use-cases of existing dvcs. Do you have a bug open for this? I've created a Wiki page here: http://wiki.bazaar.canonical.com/Specs/LFStore That would provide at least a single point where the use-cases are documented, so anyone can pick it up. (Side note: The wiki seems partly broken. In particular, http://wiki.bazaar.canonical.com/CategorySpecification does not show anything, and the "search bazaar" text in the top right is partly obscured by the search box itself.) Cheers, Anteru From andreas.ostermann.11 at googlemail.com Sun Aug 14 14:04:39 2011 From: andreas.ostermann.11 at googlemail.com (Andreas Ostermann) Date: Sun, 14 Aug 2011 16:04:39 +0200 Subject: bzr push one branch below another In-Reply-To: <201108100853.24246.Michael.Gliwinski@henderson-group.com> References: <871uy0bmv3.fsf@tiny.univ-orleans.fr> <201108100853.24246.Michael.Gliwinski@henderson-group.com> Message-ID: Hi! Then there should be a possibility to disable it by a setting or so. Much more usefull than pushing into the shared repository location is - imho - the bzr qlog feature to show the tree and current positions of _all_ branches below the shared repository when calling qlog on this location. When the shared repo directory also contains a branch qlog only shows the tree/log of this branch without the branches below... brgds, AO 2011/8/10 Michael Gliwinski : > On Wednesday 10 Aug 2011 07:27:30 Andreas Ostermann wrote: >> But what bazaar should avoid is to push into a shared repository location. >> >> I created a shared repository: >> >> xxx/projectA >> >> Then wen had some branches there: >> >> xxx/projectA/userA >> xxx/projectA/userB >> xxx/projectA/userC >> >> My colleague accidentaly pushed into xxx/projectA, which directly >> created a branch there. I think this should be avoided. > > Well, this is actually useful as well. ?IIRC it's even mentioned in the user > guide. ?E.g. for some of our projects we have: > > ?.../projectA ? ? ? ? ? ? ? ? ? # trunk > ?.../projectA/feature1 ? ? ? ? ?# common feature branch > ?.../projectA/user1/feature1 ? ?# user1's feature branch > > > -- > Michael Gliwinski > Henderson Group Information Services > 9-11 Hightown Avenue, Newtownabby, BT36 4RT > Phone: 028 9034 3319 > > ********************************************************************************************** > The information in this email is confidential and may be legally privileged. ?It is intended solely for the addressee and access to the email by anyone else is unauthorised. > If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. > When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed ?in the governing client engagement leter or contract. > If you have received this email in error please notify support at henderson-group.com > > John Henderson (Holdings) Ltd > Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT. > Registered in Northern Ireland > Registration Number NI010588 > Vat No.: 814 6399 12 > ********************************************************************************* > > > From mbp at canonical.com Mon Aug 15 00:57:36 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 15 Aug 2011 10:57:36 +1000 Subject: Getting started with a content filter In-Reply-To: <4E4794DD.7060706@catchall.shelter13.net> References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> <4E3C2F7E.8060400@d6.com> <4E4794DD.7060706@catchall.shelter13.net> Message-ID: On 14 August 2011 19:26, Anteru wrote: > Hi, > >> I really wish I could convince one of the big three dvcs core teams >> that this set of features could form a foundation for a "next >> generation" dvcs, and that this is a big hole in the supported >> use-cases of existing dvcs. > Do you have a bug open for this? I've created a Wiki page here: > http://wiki.bazaar.canonical.com/Specs/LFStore > > That would provide at least a single point where the use-cases are > documented, so anyone can pick it up. > (Side note: The wiki seems partly broken. In particular, > http://wiki.bazaar.canonical.com/CategorySpecification does not show > anything, fixed. > and the "search bazaar" text in the top right is partly > obscured by the search box itself.) It looks ok to me in Chrome and Firefox. What were you using? At some point we will update the theme and improve the css, so it's probably not worth filing a bug for this specific thing. Martin From gordon at doxxx.net Tue Aug 16 00:48:46 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 15 Aug 2011 20:48:46 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: <4E49BE6E.2090604@doxxx.net> -----BEGIN PGP MESSAGE----- Charset: UTF-8 Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ hQEMA+x9icZhVRYrAQgAhHFe0P21SHg/sDMGue4Vl+s1eweONB6gVTBSWFlfPjd3 qmJPDM6Pp9RrWiaJPKNuXEsdOZSjOr4wnPaDX79nBXTTHpfz74J3wPTeAvPWxItI kJA+W/LGWZ5tJvw3LyG62LAueKkaNgBHH+pPUpVQz5pL2MaBVJyMqdo16ncENCLh 5XobTTVBZ0mZD7nKss8vrUBdDjtvyeFr/xTLYc3SNRywIBjHIs5TdzRoxtShf/Hz aCcjzN6hHOOtv8yJIrB/4FwsTxJRKmR+cEpj++DpdsRIWC0RueGoRuQPcHbpjxZ+ uQ+E5NaDjqfDSwlfbWShFDnlwmzJO/Pc16YrFvSj/dLqAWEv3iZ30jXkT3FDt3HB RV8fH3SgmPo+dWpnAlUpNXKZWgijowsadj+ibVID1c+YT6pJuy3W5/4xKMdKwhbd Ow4gqt+w5y7dysvpx+Df9PiHCuyjscB9oAmo0sKhkAGBKlbg6WJQVImRhLBW8rMT R1iJb7HiyCu0XGSzZeeAK/LIFjjYZ4sYrOu1+2w8qp2ECR3uy7h3L/RNjUo9E2lP xDaAJrK29uPfhug/SawIET7NtXhs1RecaCXSWcrR/lFuuVlA1As0ZOY6aYnUQ+qA uw4GAmOICyFX3bgpKNKfuQnQsokFx64Kb5FHeBL14FlIoWlrupzuBlVGDgVblc9H WllK8SPxh+B+TAUqMlce8pvWWmmkA3VTiGl28o/pSZzrUWwEgltWf2RxJpHQhFI/ dkf93QwBLHUwwnL2eW/iBri3frXsVdFU181kFS4SlnIqv4XIeOgBAvO/lOmHj96F Q++QFOHSXcgSgeLCUGcb962P+KpgJCzfOle21nuwKFczULhi/eJaM+P2pkyAtrPM j9t8I8Us5xxe74Ef/1D0onge8EUKC5+rzJ3xzmxGIQ9TtwOtFdbzLZXIISWh/SxV g5Jc1mwUppnSSusvlDmmzBH0LNU6q+z72wy5/UpU78ORoxuR/w/aBH4mQ8c8zUYQ 11MBCRM603pSfFskb65kDBzfyj6kGhlt5yUNBM0gzR/vp5mSONgXfSd5Ns8Q5v02 CnDvcgY+Ag21J5F5tcIxm/Zp+TiCKoWriFHPFDeMqEHJL60HNvUBAwioSCxN1LvJ PlsDceJKR+9wcLfP+PlIsFmgDEBJ5HQJkCte75DrDt7q1xAdz9GaYF8ReJh6otfp 9cpL/EvbHAn0Bk2MJkJHBXdNJeui9swzA7pa/81A6Th5TiSmMV0MFy3lwfLcjER0 6qkmfCKOJ0k6DMMPtM3G8DYiEOdEvWT6LhBFs/5VGqsq9z6hnKrTfs1Sf51vEFDS vtA6wZe4sZLstC3QTG/d1pyCamJRFlTpVl6sP5BQb8H6SGSzCzYNbnBe5Z+QZHZ1 Xu77OW1XwHNNVTKtNluI+7rr3c06yd7gIHTf1cIF/evlzcKc54DMUZxp2mhK4ZRr 89BN2LEkMLXQE1FoazzVFHtkGfo2YWtJZ/J1wCgxoHCr4uUmE9XurXJ6F4kFC63e QD7nHr4jIkE62Sl9Ps4y+uyg15Mh/ZsMhvDTuzfoS6cHZ9RG1Hbhz7/ZGQHGF8Gx 4PXE+0sQXqoutl1QnU8yLznh9Ur3rv5xSZQQB512xH9b+XQmXZqRu0Hn5Q166uPT h6NLjs4KbWmCkyYHLcbzoHN01hTdryFiXkg5YMMxXPX07OcCI3ALC2Q4SN49qm24 3sBfQ60A8PsX+bcsWfoGawvHnfPsuyOSbQEOSoyoRgWNpzQAww3rNIwSXnbNsUqD 1j5YBXlyexVO6EvXqTXlCiBtdGvhGduujvki2092OSVJ9WaKVeFDlzb33UxXCCFV i6WUJbq4DB/LIXRcWL3zFTowgjav1CfI0dYk1ckkuEUUF0MccmNScs5TSegFjL2v nvjZXDP2ScdezQgzJ35nIh8+0WsgVQTiM49tqxylgBruh/YadLEirOxLvCFd5dX4 5A7NMzeJRsRHajtWwPUmzfFKWb5Mp01XtdLQbXDRuY8HpSdUKupXfGqIIKxL9C+S S8UqHzJrlOf76ewVqqJEq6trcfamsHIsU+o7xfyyLzztQT4bmCWCaIYwLff/JFnC y0U= =BeyM -----END PGP MESSAGE----- From gordon at doxxx.net Tue Aug 16 00:55:32 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 15 Aug 2011 20:55:32 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <4E49BE6E.2090604@doxxx.net> References: <4E49BE6E.2090604@doxxx.net> Message-ID: <4E49C004.3000202@doxxx.net> -----BEGIN PGP MESSAGE----- Charset: UTF-8 Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ hQEMA+x9icZhVRYrAQf/Z6/BgIJSOf9RlWWOH3VB2lCIkCP81uH9ANUesmtmokfk sW9drdVFzOy7XgLIDhyyjBh68ZWd4G7svPdgTDz6g6IU0o+HH7ck9jvyR3hEbpSp pXgFzyPXWplJgUiSQOSV5KAjKt02FAQTwgwnxErqaBXbmvwFvmd9JhMo8pc4C5j+ doKn38eIy0TzBVTs5t+x0NwtD1QzyGv/JGXAS2xUcUpo/mQlgqzkV4Jl1J6QOFox g2Dp/CvMce/TiLKRreykmaAxcdCIgYYQSY//YXevufGbAwYYiZTLUQ3EGIGH9ECR xXhSYa1nF0M1/OrsINaz0zCARhq1OTi/R2/sbXd9K9LqAaOtdbC1Jm+pYg3ZVDR7 ZPX1pxpipJhXyjWCrS55Iy7iaVWRdGii7S1TCCMArGBRQ25QFqId6NkadGoGM2OW muI/wX9kARTaIkPw7+mLn6bIc//bsV70HaEY7qgageiy6h723UcKZVOMUd8TChMh WokdWMYFsuySO127l23/dZKro1GteQvo3GZD4j8c8OvOXlxsGsxwQNLhDd/pKMxb yicZSGe6e7eL2kit+6aYHefyXYR3SVYoA5LNHnDR3MLFGkVsYE2pi3vKRJOt6BXS 6t0Y5yuMTAuJfZ/DOMP85tP8M1KqtmmiFVw3JhfprcrI+odVpXg/uvFS9Jc+DepR +Iz0IvPXck0AMdNoCurzHIasQPmoiT6k/hXjdB6XEYCKj7fy2qSnAD0VNidSCT8K gfY1iHAOvMNm5n4kPtIeqx2zVwNpI1eWoa7M3UVFyRpOmp7C327N9FvDuMIZqGYg 4itzifqO05F77WDL/zRi5N/8xE1xv3YEYOeMnVA1/c8N0fKOk3U9xLovKt970thE yDRLLVIdiGz7lu8CPhNIAq2Rc7hxUe3N16DvBDv+giFvejKvPVoELpir8zlZNQGh hScB2l3HEyNrWrYM2g4wDrSHE3sCHAPnWTMRrIDI55vaRmDNmBadOodl/wDC0W6u 9/B9HRmuk/U5RlMObmwXLd6CkHRQ3N4vccur0AhDAVGReH5aStCs+MKST36NX+BG GmNWFoql+fWWn0XBdya8XE+8DDbkedKQ808tozeVKEDcmwqX9k0kMfagfOaj6Cn3 IPRSWcydUrKiVqgzKi7PBq4I2hWF3AUPLnpt0/68/JMjjxt4L8F9Lfa9ITJVlNvu C7tdZB5F2Jqj8PxjBeMSbqpmOCcvwnekOsEpRtdxe+5ilDUG/i+D3j7NzQi60Iqc bGdyAYVTVFBDBA81giXKZP+YKeyeAAz8UCFgKDxi1AcrXfVcUUoCviHhkLeY2B1f 3piWo6SujwJWKsWWAHrQ3bfVHWrVtaE+GIE5cLfZEhG78MrE3160ovxNe8JcywHQ Qw/07i5PoO0WOwLr7tR44zcw2DeML9jvMNgLArCTIMDc3OKrF8GUyt5ObprbOE83 U59jVtxujdtCD/s1T4bH4yEN6V8FWxJxm7Uusr0potSzPKqqzEyxpPGE/YAitAT5 6nWZhke1OupbiHZrV/K6kH5BaTx63c1T5TlchWTswjy3P3d6J1PH7hSvsx3XA+04 wSdz00PrrU7mA+JOaw/YBsAZjafHFmwd5LU0X1jrD2Se/GBQw9erFS+zQKwcFeaG tUjdN3+txN1XOjXs9dxNy9WGB8nRyMC0v0Ho60hZ8XHaUwyDnrjuJ6HPP7CtAZRc B8C4bMqfORBfVckI8pHyW5YQIXXHzsuXL+qZ6b9fJZSiJMQ79SR/Li6cvHkpHr90 L6t0XC7RrVm6w8E7lC0C29ySdlHRCR/VBZ2dgkde0tYxE5XMnY7ssi1mdKI37RbY k1WG1wxceBWbJuPATRi9bYcO4jXloI+wkYbXI6UwUNC3zHF2vPoasCogiZfUUu/M pPbwKOTVlfmNczUjfIXPM0BYGC0RKRKNrvJg7fkhcRNmOb9NgPjH5zmCL3m0cD9+ MHoHLNaP0VoX5demwy62eMrsf/YcJRFtIiRY2Bw8zYeCdmsfhgtehxOeYu1fx9AI DWWf4mrnJta4Lo0McltL9nOmfpJFHcU/jNm+4NXfO4HEr2hU1T46rULdM6oLHtTn EUGF68n4HOQEzFetr1d7gT552tfEPVGk9CBBSJm6lKngcEzlqe28b9IrQnCHdpsO J2U2QPwBh3BOiTcFpViOHSiKe0IzIVExARsjfNOb1YGmxx5MWMjNivfyTw== =6gIB -----END PGP MESSAGE----- From gordon at doxxx.net Tue Aug 16 00:56:58 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 15 Aug 2011 20:56:58 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: <4E49C05A.2070107@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Let's try this again without turning on encryption, shall we? Sorry :P On 8/13/2011 3:45 PM, vila wrote: > Let's build installers and packages to make 2.4.0 an even better bzr > than ever. > > All plugin authors should now have official releases for inclusion. Nope. Jelmer tells me bzr-svn won't have an official release for a few days. qbzr recently released 0.21.1 for 2.4 but the upcoming 0.21.2 would be preferred since it has a bugfix for the Merge tab in qconfig. bzr-loom and bzr-pipeline have not made official releases since before the 2.4 series started even though they have relatively recent commits. And that's ignoring the various other plugins that have never had an official release (either tagged in their repo or a downloadable tarball), for which I usually just package whatever happens to be the tip at the time. I'm going to put off packaging the Mac OS X installer until at least bzr-svn and qbzr are released since I consider those major plugins. > It will also be nice if you can reply to this mail to list which > versions of which plugins you packaged. Currently, although this may be subject to change over the next few days: bzrtools v2.4.0 bzr-colo v0.3.0 bzr-email r49 bzr-explorer v1.2.1 bzr-extmerge r16 bzr-fastimport r327 (v0.10.0 looked a little old) bzr-keychain r15 bzr-loom r140 bzr-pipeline r203 qbzr r1421 (until v0.21.2 is released) bzr-rewrite v0.6.2 subvertpy v0.8.3 bzr-svn r3801 (until stable version is released) bzr-upload r86 bzr-xmloutput r157 I'm considering dropping bzr-extmerge since we now have decently configurable external merge support in bzr 2.4 and qbzr 0.21. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOScBaAAoJEIrPJfWinA2ug7wH/0+VeG+GY1UwkFsUJFoH3zRq RKHwEZroKwb6eD/PrN3i/TV+jFDtZlRezB2M2P5Fogg+ZZzhPVO/0pQfKZCkDHh/ XjxWausop/2P1QutL/sHyP4mlo82jGSaNk3cpGTM/7PqhJRh0LsLuJl4Nnbq0bKL VQfsCICjI+1mROrCaeUeY5Sg+uoWLQFBgkvwAu4hCw+0p0N+6p3pehBFCmwtWUKC +2RPSzpdUlcJstA1Gci6d995mbmQ/xBENYgW6keOVqgeqgBhUC1dvjq0JVyAFrcg pDHEHyPg1ixL48nrJf/LFMhoAq4QlDDUckT6lUvfGNO5t59LV1rTYtiF54W1wC0= =r7C2 -----END PGP SIGNATURE----- From bialix at ukr.net Tue Aug 16 05:54:58 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 16 Aug 2011 08:54:58 +0300 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <4E49C05A.2070107@doxxx.net> References: <4E49C05A.2070107@doxxx.net> Message-ID: <4E4A0632.9020108@ukr.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 16.08.2011 3:56, Gordon Tyler ?????: > Let's try this again without turning on encryption, shall we? > > Sorry :P > > On 8/13/2011 3:45 PM, vila wrote: >> Let's build installers and packages to make 2.4.0 an even better >> bzr than ever. > >> All plugin authors should now have official releases for >> inclusion. > > Nope. Jelmer tells me bzr-svn won't have an official release for a > few days. qbzr recently released 0.21.1 for 2.4 but the upcoming > 0.21.2 would be preferred since it has a bugfix for the Merge tab > in qconfig. Gordon, I haven't thought about Merge tab fix as urgent, and the bug marked as Medium, so I haven't released it yet. But if you think we should release 0.21.2 then we should do it in the next few days. Thanks for pointing it out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFOSgYyzYr338mxwCURAiz1AJ9ZYNKSzqpXRGFDNrfEW2MeYuyGOQCfWI5j ZL58/P79Cg8KAAhSvjF9QCg= =ltxx -----END PGP SIGNATURE----- From michaelcrain at hotmail.com Tue Aug 9 02:30:51 2011 From: michaelcrain at hotmail.com (spinner) Date: Mon, 8 Aug 2011 19:30:51 -0700 (PDT) Subject: Latex doc with parent-child files Message-ID: <32223099.post@talk.nabble.com> I'm a newby and looking at Bazaar Explorer to manage my dissertation writing. I'm writing my diss in multiple LaTex files and bringing them together into a parent (wrap) file with \include{chap1.tex}, \include{chap2.tex}, etc. I'm having a problem in identifying the proper parent-child folder structure to write the necessary .aux files (Tex) so the folders? work with Bazaar. I can't figure out a directory structure that blends Tex's requirements to write aux files for the child files and Bazaar. I'm hoping someone else has already figured out how to make these two requirements work together. First, here's my understanding of Bazaar's general folder requirements. I believe it essentially works with this folder structure for simple projects: ~/diss/wrap/trunk/wrapfile.tex. It adds a folder named 'trunk' and my working tex file is in this trunk folder. Bazaar's 'project' name is the name of the preceding folder 'wrap' and the working tex file is not in this folder. To keep a tidy version system, I want to keep my chapters as separate versioning 'projects' in different folders. Thus: /chap1/trunk/chap1.tex, /chap2/trunk/chap2.tex, etc. I don't want to put all these chapter tex files in one huge Bazaar project folder because the folder gets untidy. Second, to compile a document in LaTeX with parent-child files when these files are in separate directories, I understand Tex requires that the child tex files be in subfolders below the parent to get the \include command in the parent (wrap) file to work properly, which depends on Tex writing aux files for each child in their respective child folders. Thus, we have this folder structure according to Tex's requirements: /wrap/wrapfile.tex /wrap/chap1/chap1.tex /wrap/chap2/chap2.tex Here's my problem. How do I reconcile Tex's and Bazaar's requirements? Bazaar needs this folder structure to keep chapters as separate versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex How do the child files and their folders fit into this version system? Logically, I don't believe this will work well in Bazaar: /wrap/trunk/wrapfile.tex /wrap/trunk/chap1/trunk/chap1.tex If you are still reading this message, thank you. As I said, I hope someone has already found a solution to get parent-child files working with Bazaar and keeping chapters as separate projects. Many thanks. -- View this message in context: http://old.nabble.com/Latex-doc-with-parent-child-files-tp32223099p32223099.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From michaelcrain at hotmail.com Tue Aug 9 02:37:40 2011 From: michaelcrain at hotmail.com (spinner) Date: Mon, 8 Aug 2011 19:37:40 -0700 (PDT) Subject: Latex project with parent-child files Message-ID: <32223099.post@talk.nabble.com> I'm a newby and looking at Bazaar Explorer to manage my dissertation writing. I'm writing my diss in multiple LaTex files and bringing them together into a parent (wrap) file with \include{chap1.tex}, \include{chap2.tex}, etc. I'm having a problem in identifying the proper parent-child folder structure to write the necessary .aux files (Tex) so the folders? work with Bazaar. I can't figure out a directory structure that blends Tex's requirements to write aux files for the child files and Bazaar. I'm hoping someone else has already figured out how to make these two requirements work together. First, here's my understanding of Bazaar's general folder requirements. I believe it essentially works with this folder structure for simple projects: ~/diss/wrap/trunk/wrapfile.tex. It adds a folder named 'trunk' and my working tex file is in this trunk folder. Bazaar's 'project' name is the name of the preceding folder 'wrap' and the working tex file is not in this folder. To keep a tidy version system, I want to keep my chapters as separate versioning 'projects' in different folders. Thus: /chap1/trunk/chap1.tex, /chap2/trunk/chap2.tex, etc. I don't want to put all these chapter tex files in one huge Bazaar project folder because the folder gets untidy. Second, to compile a document in LaTeX with parent-child files when these files are in separate directories, I understand Tex requires that the child tex files be in subfolders below the parent to get the \include command in the parent (wrap) file to work properly, which depends on Tex writing aux files for each child in their respective child folders. Thus, we have this folder structure according to Tex's requirements: /wrap/wrapfile.tex /wrap/chap1/chap1.tex /wrap/chap2/chap2.tex Here's my problem. How do I reconcile Tex's and Bazaar's requirements? Bazaar needs this folder structure to keep chapters as separate versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex How do the child files and their folders fit into this version system? Logically, I don't believe this will work well in Bazaar: /wrap/trunk/wrapfile.tex /wrap/trunk/chap1/trunk/chap1.tex If you are still reading this message, thank you. As I said, I hope someone has already found a solution to get parent-child files working with Bazaar and keeping chapters as separate projects. Many thanks. -- View this message in context: http://old.nabble.com/Latex-project-with-parent-child-files-tp32223099p32223099.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From rluckey at blackducksoftware.com Wed Aug 10 17:19:20 2011 From: rluckey at blackducksoftware.com (Robin Luckey) Date: Wed, 10 Aug 2011 13:19:20 -0400 Subject: revids that include periods are interpreted as ranges Message-ID: I have found several Bzr repositories with revids that include the substring '..' within them. Although these are single revids, bzr interprets them as revid *ranges*, and thus they cannot be passed as parameters to the bzr command line tools. For example, lp:nvda contains such a revid in its first revision: http://bazaar.launchpad.net/~nvda-core-dev/nvda/main/revision/1 The revid for this revision is: svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46 The '..' substring causes bzr to believe this is a range spec, and thus any command line operations that attempt to use this revid as a parameter will fail: $ bzr log --show-id -v --limit 1 -c 'svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46' bzr: ERROR: Option --change does not accept revision ranges There are dozens of such revids in this repository, and I have found several other repositories affected by this problem. All of the offending revids appear to have been generated during conversion from Subversion. Is there any workaround for this problem? Is there any way to escape these revids or to coerce bzr so that they will not be interpreted as ranges? Cheers, Robin Luckey From madzientist at gmail.com Fri Aug 5 18:49:51 2011 From: madzientist at gmail.com (madzientist) Date: Fri, 5 Aug 2011 11:49:51 -0700 (PDT) Subject: bzr branch leads to empty folder Message-ID: <32204637.post@talk.nabble.com> hi i used to successfully push and branch to an ftp server. a few days ago i had to use break-lock to break a lock after i accidentally used ctrl-c to stop the push process. since then all new branches or merge operations on that server appear to finish successfully, but at the server end, the directories are empty. is this something that could have happened from within bzr ? it is true even for new branches of directories newly brought under version control. or is it something at the server end ? thanks, suresh -- View this message in context: http://old.nabble.com/bzr-branch-leads-to-empty-folder-tp32204637p32204637.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From michaelcrain at hotmail.com Tue Aug 9 02:14:39 2011 From: michaelcrain at hotmail.com (spinner) Date: Mon, 8 Aug 2011 19:14:39 -0700 (PDT) Subject: Latex doc with parent-child files Message-ID: <32223099.post@talk.nabble.com> I'm a newby and looking at Bazaar to manage my dissertation writing. I'm writing my diss in multiple LaTex files and bringing them together into a parent (wrap) file with \include{chap1.tex}, \include{chap2.tex}, etc. I'm having a problem in identifying the proper parent-child folder structure to write the necessary .aux files (Tex) so the folders? work with Bazaar. I can't figure out a directory structure that blends Tex's requirements to write aux files for the child files and Bazaar. I'm hoping someone else has already figured out how to make these two requirements work together. First, here's my understanding of Bazaar's general folder requirements. I believe it essentially works with this folder structure for simple projects: ~/diss/wrap/trunk/wrapfile.tex. It adds a folder named 'trunk' and my working tex file is in this trunk folder. Bazaar's 'project' name is the name of the preceding folder 'wrap' and the working tex file is not in this folder. To keep a tidy version system, I want to keep my chapters as separate versioning 'projects' in different folders. Thus: /chap1/trunk/chap1.tex, /chap2/trunk/chap2.tex, etc. I don't want to put all these chapter tex files in one huge Bazaar project folder because the folder gets untidy. Second, to compile a document in LaTeX with parent-child files when these files are in separate directories, I understand Tex requires that the child tex files be in subfolders below the parent to get the \include command in the parent (wrap) file to work properly, which depends on Tex writing aux files for each child in their respective child folders. Thus, we have this folder structure according to Tex's requirements: /wrap/wrapfile.tex /wrap/chap1/chap1.tex /wrap/chap2/chap2.tex Here's my problem. How do I reconcile Tex's and Bazaar's requirements? Bazaar needs this folder structure to keep chapters as separate versioning projects: /wrap/trunk/wrapfile.tex /chap1/trunk/chap1.tex How do the child files and their folders fit into this version system? Logically, I don't believe this will work well in Bazaar: /wrap/trunk/wrapfile.tex /wrap/trunk/chap1/trunk/chap1.tex If you are still reading this message, thank you. As I said, I hope someone has already found a solution to get parent-child files working with Bazaar and keeping chapters as separate projects. Many thanks. -- View this message in context: http://old.nabble.com/Latex-doc-with-parent-child-files-tp32223099p32223099.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From vila at canonical.com Thu Aug 11 13:00:07 2011 From: vila at canonical.com (vila at canonical.com) Date: Thu, 11 Aug 2011 15:00:07 +0200 Subject: [ANN] bzr 2.4.0 has gone gold Message-ID: Hi, Here comes 2.4.0 ! Let's build installers and packages to make 2.4.0 an even better bzr than ever. All plugin authors should now have official releases for inclusion. If they haven't yet and you encounter issues while packaging, please report here so we can more easily track the issues (or even better file bugs *and* report here ;). It will also be nice if you can reply to this mail to list which versions of which plugins you packaged. See the Changelog at https://launchpad.net/bzr/2.4/2.4.0 for more details about what is included and for the tarball. I'll make the official announcement next Tuesday morning UTC (2011-08-16) with whatever packages/installers are available at this point. Have fun ! Vincent From john at arbash-meinel.com Tue Aug 16 09:12:07 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 16 Aug 2011 11:12:07 +0200 Subject: Standup 2011-08-16 Message-ID: <4E4A3467.4050109@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Martin - Lots of good ideas from Statik, may start joining the standup if we move it to sometime other than 4am US. - Working on package import HTTPError failures. Which seems to be growing. http://pad.lv/819910 - Interviewed several people for the replace-spiv position, have some candidates that look pretty good. - Launchpad should be getting a good candidate soon for the Project Manager position. - Couple patches/reviews udd,gpg - Played with ssh reconnection for Launchpad - Might be good to incorporate the python-oops code into the UDD importer - Will be switching work schedule this week to overlap a bit more with European devs. * Jelmer - Was Patch Pilot, did lots of reviews. Landed 2 contributor patches - Fixed some Launchpad related bugs, introduced a regression bug #826082 and bug #826136 - Uploaded bzr 2.4.0 into Debian - Working on getting bzr-svn released - Colocated branch support updates, all the pieces seem to be implemented, just need final reviews and landing. - Should allow non-master imports, but will need the new bzr and new bzr-git to be rolled out on Launchpad first. - We should get ppa support for 'lucid-cat'/'hardy-cat' which is the IS distributions used for Canonical servers. This allows making it easier to create a .deb that can be rolled out by LOSAs. * Should we be pushing to update the bzr that is on Launchpad, or should Launchpad be integrating our releases? While they have "more people" to work on the integration, we have more specific motivation of wanting the new code to be available. Often have a fair number of little breaks when jumping minor versions (2.2=>2.3=>2.4, etc.) Stable releases should be more straightforward. - For now, we expect to push the bzr releases into Launchpad, getting some assistance from them as necessary. * There is now HAProxy in front of 2 Codehosting services. - Still struggling with how to handle long-lived connections. Because bzr can reasonably stay connected for 30 minutes while transferring lots of data, it is hard to find a window of what a reasonable wait time is before disconnecting clients. - If bzr starts doing reasonable reconnects, then it becomes easier to just disconnect the client, and it can reconnect to the other service. * Now that there is an internal Canonistack cloud, we might try deploying tarmac or Babune (Jenkins) to it. * John - get_parent_map updates - Code Reviews - Backported "freshness" check to bzr-2.1 - Working on Quilt merging on Thurs * Vincent - Worked on config - 2.4.0 has gone Gold, will probably delay the "is available" release Some delays because of new email configurations. - Looking to do more formal emails to packagers to make sure the right versions are getting packaged for a given release, but to also not block the release waiting indefinitely for plugins. - ModuleAvailableFeature __import__ logic bug. Probably just target trunk * Jonathan Riddell - Was away for the Desktop Summit. Very good to meet up with desktop friends - Pointed out apt-get still recommends 'bzr get' rather than 'bzr branch'. Has been fixed. - KDE search wasn't ignoring .bzr/, fixed. - Started working on a KDE Dolphin plugin for bzr support - Request for 'bzr commit -i' (interactive mode) - Request for 'bzr qlog' to include diff 'inline' - Patch Pilot this week John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5KNGcACgkQJdeBCYSNAAMYqgCfTGw3BTrYbmHtnpihPRRS+V45 S78An0oJhDt9+EeRO4+sh8Tm9atTBbXz =WzHv -----END PGP SIGNATURE----- From mbp at canonical.com Tue Aug 16 09:36:32 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 16 Aug 2011 19:36:32 +1000 Subject: bzr branch leads to empty folder In-Reply-To: <32204637.post@talk.nabble.com> References: <32204637.post@talk.nabble.com> Message-ID: On 6 August 2011 04:49, madzientist wrote: > > hi > > i used to successfully push and branch to an ftp server. a few days ago i > had to use break-lock to break a lock after i accidentally used ctrl-c to > stop the push process. since then all new branches or merge operations on > that server appear to finish successfully, but at the server end, the > directories are empty. > > is this something that could have happened from within bzr ? it is true even > for new branches of directories newly brought under version control. or is > it something at the server end ? bzr never builds working trees over ftp: branch directories will always contain just a '.bzr' directory, which may be hidden by default. I don't think this is correlated with you needing to break the lock. On the other hand if even .bzr is missing then something else is going wrong and we need more details about what command you're running and what error if any it prints. m From bialix at ukr.net Tue Aug 16 09:49:29 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 16 Aug 2011 12:49:29 +0300 Subject: revids that include periods are interpreted as ranges In-Reply-To: References: Message-ID: <4E4A3D29.4070808@ukr.net> Robin Luckey ?????: > I have found several Bzr repositories with revids that include the substring '..' within them. Although these are single revids, bzr interprets them as revid *ranges*, and thus they cannot be passed as parameters to the bzr command line tools. > > For example, lp:nvda contains such a revid in its first revision: > > http://bazaar.launchpad.net/~nvda-core-dev/nvda/main/revision/1 > > The revid for this revision is: > > svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46 > > The '..' substring causes bzr to believe this is a range spec, and thus any command line operations that attempt to use this revid as a parameter will fail: > > $ bzr log --show-id -v --limit 1 -c 'svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46' > bzr: ERROR: Option --change does not accept revision ranges > > There are dozens of such revids in this repository, and I have found several other repositories affected by this problem. All of the offending revids appear to have been generated during conversion from Subversion. > > Is there any workaround for this problem? Is there any way to escape these revids or to coerce bzr so that they will not be interpreted as ranges? Is there any reason why you can't use revision numbers instead? From madzientist at gmail.com Tue Aug 16 10:46:51 2011 From: madzientist at gmail.com (Suresh Krishna) Date: Tue, 16 Aug 2011 11:46:51 +0100 Subject: bzr branch leads to empty folder In-Reply-To: References: <32204637.post@talk.nabble.com> Message-ID: > bzr never builds working trees over ftp: branch directories will > always contain just a '.bzr' directory, which may be hidden by > default. yes, that is it. thank you !! suresh From john at arbash-meinel.com Tue Aug 16 10:04:13 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 16 Aug 2011 12:04:13 +0200 Subject: revids that include periods are interpreted as ranges In-Reply-To: References: Message-ID: <4E4A409D.9010600@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/10/2011 7:19 PM, Robin Luckey wrote: > > I have found several Bzr repositories with revids that include the > substring '..' within them. Although these are single revids, bzr > interprets them as revid *ranges*, and thus they cannot be passed as > parameters to the bzr command line tools. > > For example, lp:nvda contains such a revid in its first revision: > > http://bazaar.launchpad.net/~nvda-core-dev/nvda/main/revision/1 > > The revid for this revision is: > > svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46 > > The '..' substring causes bzr to believe this is a range spec, and > thus any command line operations that attempt to use this revid as a > parameter will fail: > > $ bzr log --show-id -v --limit 1 -c > 'svn-v3-list-QlpoOTFBWSZTWbrL2vUAAB1VgAAQABCAQDrrnqAgAFCgaaGRkxBoTIJ6mmaNRwhndFAoNhZjh_YY4a01fOg1ulgNNC2UrzPdXXEnDpX8XckU4UJC6y9r1A..:dbe06fc7-9119-0410-a01d-9dbf589ecbba:trunk:46' > > bzr: ERROR: Option --change does not accept revision ranges > > There are dozens of such revids in this repository, and I have found > several other repositories affected by this problem. All of the > offending revids appear to have been generated during conversion from > Subversion. > > Is there any workaround for this problem? Is there any way to escape > these revids or to coerce bzr so that they will not be interpreted as > ranges? > > Cheers, Robin Luckey > You could try using "revid:" syntax, but I'm pretty sure the code that does "-r" and "-c" parsing splits on '..' before it gets to the RevisionSpec objects themselves. Certainly there is a limitation here. As without using ".." as a special meaning, how would one enter a range between two revision-ids. This is the first I've seen it come up as an issue, so we haven't incorporated an escape mechanism, etc. I know Robert has mentioned long ago, that we would *like* a recursive descent parser. (Which I think means, try the whole string as an identifier, grab as much of it as fits a spec, then split of the rest and start parsing the remainder, etc.) As Alexander mentioned, one workaround is to address these revisions by their revision number, instead of by their revision id. bzr itself is unlikely to generate '..' in revision-ids, just because of how the revision-ids are generated. But there isn't an explicit trap for them. (Specifically, I just tested: BZR_EMAIL="Test " and the .. ends up in the revision-id.) So certainly, file a bug on this, though I don't have any quick-and-cheap answers for how to fix it. I know at one point we discussed using multiple '-r' flags to define a range, rather than '..' syntax. Though that would be a pretty large change at this point. Maybe we could change the parser so that if you do "revid:" it won't accept '..' unless it was followed by an obvious revspec. For example: bzr log -r "revid:abcd..xyz" Would be treated as "abcd..xyz" but bzr log -r "revid:abcd..revid:xyz" would be treated as a range between 2 revisions "abcd" and "xyz". I would probably want it to support "revid:" and simple numbers (for revnos). Mostly because I like to do things like: bzr log -r "revid:abcd..-1" But honestly, I don't use raw revids particularly often. But they certainly are meant to be available, and uniquely identify a revision. Especially for automated processing, etc. So I would like to have a way to work with your use case. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5KQJ0ACgkQJdeBCYSNAANfVwCfTG+qTPUU7OfpjvYmv20xNE2L x2QAn3E0hvbFBDqLU/X8okvXfSjVgJ0w =/rRL -----END PGP SIGNATURE----- From vila+bzr at canonical.com Tue Aug 16 13:55:11 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 16 Aug 2011 15:55:11 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <4E49C05A.2070107@doxxx.net> (Gordon Tyler's message of "Mon, 15 Aug 2011 20:56:58 -0400") References: <4E49C05A.2070107@doxxx.net> Message-ID: >>>>> Gordon Tyler writes: > On 8/13/2011 3:45 PM, vila wrote: >> Let's build installers and packages to make 2.4.0 an even better bzr >> than ever. >> >> All plugin authors should now have official releases for inclusion. > Nope. Jelmer tells me bzr-svn won't have an official release for a few > days. qbzr recently released 0.21.1 for 2.4 but the upcoming 0.21.2 > would be preferred since it has a bugfix for the Merge tab in qconfig. > bzr-loom and bzr-pipeline have not made official releases since before > the 2.4 series started even though they have relatively recent commits. > And that's ignoring the various other plugins that have never had an > official release (either tagged in their repo or a downloadable > tarball), for which I usually just package whatever happens to be the > tip at the time. > I'm going to put off packaging the Mac OS X installer until at least > bzr-svn and qbzr are released since I consider those major plugins. I'd rather have packages and installers based on specific revids than delay them. Our users care less than us about having stable branches for plugins and as long as we document which revisions are used (which we do already for all the package/installers I'm aware of) that's fine. Using dedicated branches is aimed at facilitating plugin author lifes but if they prefer a different workflow, that's fine too. Now, we could try to reach each plugin author and tell him which revision has been used so that it's at least tagged there if only for our own needs. >> It will also be nice if you can reply to this mail to list which >> versions of which plugins you packaged. > Currently, although this may be subject to change over the next > few days: Thanks, Vincent From gordon at doxxx.net Tue Aug 16 14:23:25 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 16 Aug 2011 10:23:25 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <4E4A0632.9020108@ukr.net> References: <4E49C05A.2070107@doxxx.net> <4E4A0632.9020108@ukr.net> Message-ID: <3c4be18c207957c79e4bd377b8bae088@localhost> On Tue, 16 Aug 2011 08:54:58 +0300, Alexander Belchenko wrote: > Gordon, I haven't thought about Merge tab fix as urgent, and the bug > marked as Medium, so I haven't released it yet. But if you think we > should release 0.21.2 then we should do it in the next few days. > Thanks for pointing it out. I guess I feel it's hugely important since it's my bug. ;) I don't want to rush you so if you're okay with it, I'll just package the revision (r1421) that has the bugfix since I think it's the only revision after the 0.21.1 release. Which reminds me, I must use the lp:qbzr/0.21 branch and not trunk... Ciao, Gordon From gordon at doxxx.net Tue Aug 16 14:34:15 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 16 Aug 2011 10:34:15 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: <4E49C05A.2070107@doxxx.net> Message-ID: On Tue, 16 Aug 2011 15:55:11 +0200, vila wrote: >>>>>> Gordon Tyler writes: > > I'm going to put off packaging the Mac OS X installer until at least > > bzr-svn and qbzr are released since I consider those major plugins. > > I'd rather have packages and installers based on specific revids than > delay them. I see no point in releasing an installer if I know that a particular plugin requires some work to be compatible with the new version of bzr. That's on-par with Oracle's JDK7 release. :P I also don't want to release an "official" installer which bundles some arbitrarily selected revision of a major plugin and have the plugin author mad at me because I couldn't wait. > Our users care less than us about having stable branches for plugins and > as long as we document which revisions are used (which we do already for > all the package/installers I'm aware of) that's fine. > > Using dedicated branches is aimed at facilitating plugin author lifes > but if they prefer a different workflow, that's fine too. Whether they have a dedicated branch or not doesn't really matter much to me, so long as there is either a relatively recent tarball release or some indication that a particular revision should be used. Otherwise I have to assume that the tip of trunk is "stable". So far that hasn't been a problem (that I know of), but I fear it will come back to bite me in the ass one day. > Now, we could try to reach each plugin author and tell him which > revision has been used so that it's at least tagged there if only for > our own needs. One would hope that bzr plugin authors are subscribed to the bzr mailing list. Ciao, Gordon From bialix at ukr.net Tue Aug 16 14:40:56 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 16 Aug 2011 17:40:56 +0300 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <3c4be18c207957c79e4bd377b8bae088@localhost> References: <4E49C05A.2070107@doxxx.net> <4E4A0632.9020108@ukr.net> <3c4be18c207957c79e4bd377b8bae088@localhost> Message-ID: <4E4A8178.1060501@ukr.net> Gordon Tyler ?????: > On Tue, 16 Aug 2011 08:54:58 +0300, Alexander Belchenko > wrote: >> Gordon, I haven't thought about Merge tab fix as urgent, and the bug >> marked as Medium, so I haven't released it yet. But if you think we >> should release 0.21.2 then we should do it in the next few days. >> Thanks for pointing it out. > > I guess I feel it's hugely important since it's my bug. ;) > > I don't want to rush you so if you're okay with it, I'll just package the > revision (r1421) that has the bugfix since I think it's the only revision > after the 0.21.1 release. Which reminds me, I must use the lp:qbzr/0.21 > branch and not trunk... I'm okay with it. From vila+bzr at canonical.com Tue Aug 16 15:06:20 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 16 Aug 2011 17:06:20 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: (Gordon Tyler's message of "Tue, 16 Aug 2011 10:34:15 -0400") References: <4E49C05A.2070107@doxxx.net> Message-ID: >>>>> Gordon Tyler writes: > I see no point in releasing an installer if I know that a > particular plugin requires some work to be compatible with the new > version of bzr. That's on-par with Oracle's JDK7 release. :P If you *know* the plugin is not compatible, yes of course. Any name you want to share with us ? :) > I also don't want to release an "official" installer which bundles > some arbitrarily selected revision of a major plugin and have the > plugin author mad at me because I couldn't wait. Then just take the same revision that was used for 2.4b5, what's the issue ? > Whether they have a dedicated branch or not doesn't really matter > much to me, so long as there is either a relatively recent tarball > release or some indication that a particular revision should be > used. Otherwise I have to assume that the tip of trunk is > "stable". So far that hasn't been a problem (that I know of), but > I fear it will come back to bite me in the ass one day. We did freeze the API after 2.4b5 specifically so that plugin authors *may* create dedicated releases, if they didn't, they won't be in a position to do anything with your ass :-p We do time-based releases so that we don't get blocked by last-minute landed features and because we consider there is more value in having our software in the hands of our users early. Keep in mind that 2.4.1 will be frozen on 2011-09-01 so there is no point in delaying 2.4.0. Vincent From gordon at doxxx.net Tue Aug 16 15:59:37 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 16 Aug 2011 11:59:37 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: <4E49C05A.2070107@doxxx.net> Message-ID: <8116cd3ad0e0cb62bd2688518c40dd75@localhost> On Tue, 16 Aug 2011 17:06:20 +0200, vila wrote: >>>>>> Gordon Tyler writes: > > > > > I see no point in releasing an installer if I know that a > > particular plugin requires some work to be compatible with the new > > version of bzr. That's on-par with Oracle's JDK7 release. :P > > If you *know* the plugin is not compatible, yes of course. > > Any name you want to share with us ? :) I'll admit that I'm making an assumption here, which is that bzr-svn requires more work to be bzr 2.4.0 compatible. If it is usable in its current state, then I'll package that. > > I also don't want to release an "official" installer which bundles > > some arbitrarily selected revision of a major plugin and have the > > plugin author mad at me because I couldn't wait. > > Then just take the same revision that was used for 2.4b5, what's the > issue ? Due to the build methodology I use for betas, I don't have a record of the revision used. > We do time-based releases so that we don't get blocked by last-minute > landed features and because we consider there is more value in having > our software in the hands of our users early. > > Keep in mind that 2.4.1 will be frozen on 2011-09-01 so there is no > point in delaying 2.4.0. Very well. I'll build it tonight (EST). Ciao, Gordon From gordon at doxxx.net Wed Aug 17 02:19:59 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 16 Aug 2011 22:19:59 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <8116cd3ad0e0cb62bd2688518c40dd75@localhost> References: <4E49C05A.2070107@doxxx.net> <8116cd3ad0e0cb62bd2688518c40dd75@localhost> Message-ID: <4E4B254F.8090702@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mac OS X 10.6 installer for bzr 2.4.0 has been uploaded. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOSyVPAAoJEIrPJfWinA2us4AIAId1/eCyyfwQNS+o7t6lKlxQ tT3LRcZ9iFc/LhTjfJ0xvMLfnmNx3EI7VPvTBfU1rvWc/A7YTkfc0oH8GZIw4x9f 4h2JygHM2u/sZM/b76SHS/MPxCXs0pezxQdgnfgToQLptsZaxFpSC9UGc4Dluz0d 5l8DXAhpXMyrslkSzb+kzCs74XwdOxosypNs3RMrDvClPDFy858/FHGo08p5ORFd If4vY4JV0maujgZ/RcEt3ZoA/vHUJ1EwnVQpZvpX+Pwv85X5inroCj4cdbZDgtYt OGXu/mLZsNB96Vh7y9tFCKYV4VtNJe6t4Co/Nn/3eEKxx/Pv6FMrVKnKDwP8reQ= =Xnho -----END PGP SIGNATURE----- From mbp at canonical.com Wed Aug 17 02:23:32 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 17 Aug 2011 12:23:32 +1000 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <8116cd3ad0e0cb62bd2688518c40dd75@localhost> References: <4E49C05A.2070107@doxxx.net> <8116cd3ad0e0cb62bd2688518c40dd75@localhost> Message-ID: On 17 August 2011 01:59, Gordon Tyler wrote: > On Tue, 16 Aug 2011 17:06:20 +0200, vila wrote: >>>>>>> Gordon Tyler writes: >> >> >> >> ? ? > I see no point in releasing an installer if I know that a >> ? ? > particular plugin requires some work to be compatible with the new >> ? ? > version of bzr. ?That's on-par with Oracle's JDK7 release. :P >> >> If you *know* the plugin is not compatible, yes of course. >> >> Any name you want to share with us ? :) > > I'll admit that I'm making an assumption here, which is that bzr-svn > requires more work to be bzr 2.4.0 compatible. If it is usable in its > current state, then I'll package that. I think the trunks do work, but also that Jelmer was planning to make official releases of the foreign format plugins fairly soon. Maybe he can confirm or denay? Waiting a few days to get an official release would be fine. m From vila+bzr at canonical.com Wed Aug 17 06:54:36 2011 From: vila+bzr at canonical.com (vila) Date: Wed, 17 Aug 2011 08:54:36 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <8116cd3ad0e0cb62bd2688518c40dd75@localhost> (Gordon Tyler's message of "Tue, 16 Aug 2011 11:59:37 -0400") References: <4E49C05A.2070107@doxxx.net> <8116cd3ad0e0cb62bd2688518c40dd75@localhost> Message-ID: >>>>> Gordon Tyler writes: > On Tue, 16 Aug 2011 17:06:20 +0200, vila wrote: >>>>>>> Gordon Tyler writes: >> >> >> >> > I see no point in releasing an installer if I know that a >> > particular plugin requires some work to be compatible with the new >> > version of bzr. That's on-par with Oracle's JDK7 release. :P >> >> If you *know* the plugin is not compatible, yes of course. >> >> Any name you want to share with us ? :) > I'll admit that I'm making an assumption here, which is that > bzr-svn requires more work to be bzr 2.4.0 compatible. If it is > usable in its current state, then I'll package that. I think it is, AIUI Jelmer *will* make an official release but it shouldn't be different (and if it is, well, 2.4.1 will include it anyway). >> > I also don't want to release an "official" installer which bundles >> > some arbitrarily selected revision of a major plugin and have the >> > plugin author mad at me because I couldn't wait. >> >> Then just take the same revision that was used for 2.4b5, what's the >> issue ? > Due to the build methodology I use for betas, I don't have a > record of the revision used. Ha right, I should know. Well, may be that can be addressed by keeping track of which (revno, revid) is used when building from a branch ? >> We do time-based releases so that we don't get blocked by last-minute >> landed features and because we consider there is more value in having >> our software in the hands of our users early. >> >> Keep in mind that 2.4.1 will be frozen on 2011-09-01 so there is no >> point in delaying 2.4.0. > Very well. I'll build it tonight (EST). Thanks a lot ! Vincent From jelmer at canonical.com Wed Aug 17 07:10:33 2011 From: jelmer at canonical.com (Jelmer Vernooij) Date: Wed, 17 Aug 2011 09:10:33 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: <4E49C05A.2070107@doxxx.net> <8116cd3ad0e0cb62bd2688518c40dd75@localhost> Message-ID: <1313565034.9903.6.camel@localhost> On Wed, 2011-08-17 at 12:23 +1000, Martin Pool wrote: > On 17 August 2011 01:59, Gordon Tyler wrote: > > On Tue, 16 Aug 2011 17:06:20 +0200, vila wrote: > >>>>>>> Gordon Tyler writes: > >> > >> > >> > >> > I see no point in releasing an installer if I know that a > >> > particular plugin requires some work to be compatible with the new > >> > version of bzr. That's on-par with Oracle's JDK7 release. :P > >> > >> If you *know* the plugin is not compatible, yes of course. > >> > >> Any name you want to share with us ? :) > > > > I'll admit that I'm making an assumption here, which is that bzr-svn > > requires more work to be bzr 2.4.0 compatible. If it is usable in its > > current state, then I'll package that. > > I think the trunks do work, but also that Jelmer was planning to make > official releases of the foreign format plugins fairly soon. Maybe he > can confirm or denay? Waiting a few days to get an official release > would be fine. I'm indeed planning to do a release fairly soon; there is also a potential critical issue in bzr-svn trunk, which I'd like to resolve (fix or downgrade) before doing a release. Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From vila+bzr at canonical.com Wed Aug 17 07:16:01 2011 From: vila+bzr at canonical.com (vila) Date: Wed, 17 Aug 2011 09:16:01 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: (Martin Pool's message of "Wed, 17 Aug 2011 12:23:32 +1000") References: <4E49C05A.2070107@doxxx.net> <8116cd3ad0e0cb62bd2688518c40dd75@localhost> Message-ID: >>>>> Martin Pool writes: > Waiting a few days to get an official release would be fine. Well, it's of course fine to wait. On the other hand, there is always a reason to wait but most of them just contradict the time-based release philosophy ;) So just a reminder of the rationales (for all of us, I fall in the same trap on a regular basis): 1 - users cannot use software that is not released, 2 - the longer you wait, the more new bugs you add, 3 - we have a strong record of delivering stable releases, 4 - we fix critical bugs quickly. All of these rely on us being able to release quickly and regularly. Past experiences have shown that long delayed releases cause more problems than regular ones. My personal golden rule when faced with a choice about releasing/delaying is: is it time to release ? And the golden answer is: if it worked and no *new* bugs have been reported, then just release the new bzr and the already released plugins. The main exception to this rule is when we release the first beta of a new series as it may break plugin compatibility, but even there, points (1), (2) and (4) above apply: the sooner it's out, the better. 2.4.0 comes after 5 beta releases, I don't expect a lot of breakage here. Far more exposition, sure, may be some new bugs but not that much and 2.4.1 is planned for 2011-09-01 anyway. Time-based-release-manager'ly yours, Vincent P.S.: And yes, I *will* wait for a bit more installers/packages to be available before doing the official announcement, but don't expect me to wait *that* long ;) And thanks again to Gordon for the first 2.4.0 installer !!! That required some guts ;) From jelmer at samba.org Wed Aug 17 09:58:19 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Wed, 17 Aug 2011 11:58:19 +0200 Subject: Colocated branch progress In-Reply-To: <1312330486.3032.21.camel@genhwyvar> References: <1312330486.3032.21.camel@genhwyvar> Message-ID: <4E4B90BB.1050609@samba.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/11 02:14, Jelmer Vernooij wrote: > The ability to address colocated branches using URLs has long been in > progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a > bit with John and Martin at the recent Launchpad sprint, I'm finally > back on track hacking on it. > > There are basically four things left to do now: > > 1) Avoid URLescaping comma's when converting local paths to URLs. > (lp:~jelmer/bzr/escape-comments) > 2) Preserve the distinction between literal and delimiting comma's in > URLs when they are parsed in e.g. ConnectedTransport (2) > 3) Parse the subsegment parameters for Transports and make them > accessible (done, lp:~jelmer/bzr/transport-segments) > 4) Look at the transport segment parameters in ControlDir and use them > to determine the default branch (this should be fairly easy) All this has now finally happened, and is currently pending for landing on bzr.dev. This means that with control directory formats that support it, you can now do things like: $ bzr log "file:///path/to/repo,branch=foo We might add shorter forms of this available in the future, but will have to be careful to not break other use cases. For example, supporting "/tmp/repo,branch=foo" will break things for people who actually have branches with a comma in their name. There are also two pending branches that make it possible to list colocated branches ("bzr branches") and switch between them using "bzr switch". Cheers, Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOS5C7AAoJEACAbyvXKaRXR/QP/2TCYi4t80EDIrzAjUd3Tgs5 Gqx8V8W3h6Bf1AQ5PsQlCSmrJk5lRGqddmBX6T/GtX6OseN+p4Zk1Ha0v/kLpEYI 3KllRV0G4lGI/PS1xOfcNPuVxzIIN3LpiPUtc0qOE3jiSkwDGpGYkqy1GkmrUN7x sQOCdgcQZoIdgkGvI/x1I/rGsnQWizSUDvahXEkb3gAGfC0ZXriczt27wbqAMiO4 RwSzL9rgxktFBMCHCCH5pOSr336bcHCwPbNshcFVCilFA/2RQVFX7f97NG9BuEP6 ZlaHAOfQfhgqUg9Dmct1CTy3aDGHnT7oWIC7JocAyHTh/Fh86vadwfnCKPQVE6Fj uXptamT27WR8TmygK/OLHk9tMkcExT6tWKWxM+9s95Z4KmKPKMSi1cgnMZcGeO8E pa2SOGozKXJWj1yYSjCGcnQXzWx8VZFqxoC8wuy4LQHMmojJ8JKZQEX/SaFvCSRz 1wo6WWCD6VPjaCua/X2V+BUJ4JFzWzoI/t4/b2IJgGzTJHtbVeiRyYPdvSBnUuGD njtGPLLh2moZYw1lOe09JTe05gg7serarmGcLWgc321URaEcR8v/E4J7N9h3OhgF M/2blGXZbinY4Cx52HKSvi5YpfRDR/qRTqvPddmDTsDhCd6Yy708wIz9cpR6tW5b tfCsjPjaMwRnV69YZ5NN =MBj7 -----END PGP SIGNATURE----- From amanic at gmail.com Wed Aug 17 14:10:42 2011 From: amanic at gmail.com (Marius Kruger) Date: Wed, 17 Aug 2011 16:10:42 +0200 Subject: bzr branch leads to empty folder In-Reply-To: References: <32204637.post@talk.nabble.com> Message-ID: On 16 August 2011 11:36, Martin Pool wrote: > bzr never builds working trees over ftp: branch directories will > always contain just a '.bzr' directory, which may be hidden by > default. As you know, this is a common gotcha. I wonder if we can make it more discoverable like writing a special non-hidded file when we create a treeless branch eg. bazaar-treeless-branch.txt which contains some info about what is going on. When you do actually do a checkout, this file should be deleted. -- just another sleep-depraved/delusional idea <>< Marius ><> From amanic at gmail.com Wed Aug 17 14:37:25 2011 From: amanic at gmail.com (Marius Kruger) Date: Wed, 17 Aug 2011 16:37:25 +0200 Subject: Standup 2011-08-16 In-Reply-To: <4E4A3467.4050109@arbash-meinel.com> References: <4E4A3467.4050109@arbash-meinel.com> Message-ID: > * Jonathan Riddell > ? ?- Started working on a KDE Dolphin plugin for bzr support I saw and used the following a little some time ago (it seemed to work fine): http://blog.saturnlaboratories.co.za/archive/2010/08/02/tortoisebzr-style-right-click-menus-kde found related while searching for above: http://kde-apps.org/content/show.php/QBazaar+service+menu?content=142321 -- I used to use KDE +-2000..2011.04 but just had to have a unity.. <>< Marius ><> From mbp at canonical.com Thu Aug 18 07:34:34 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 18 Aug 2011 17:34:34 +1000 Subject: bzr branch leads to empty folder In-Reply-To: References: <32204637.post@talk.nabble.com> Message-ID: On 18 August 2011 00:10, Marius Kruger wrote: > On 16 August 2011 11:36, Martin Pool wrote: >> bzr never builds working trees over ftp: branch directories will >> always contain just a '.bzr' directory, which may be hidden by >> default. > > As you know, this is a common gotcha. > I wonder if we can make it more discoverable like writing a special > non-hidded file > when we create a treeless branch eg. bazaar-treeless-branch.txt > which contains some info about what is going on. > When you do actually do a checkout, this file should be deleted. It's a good idea, and quite technically possible. There's a bug asking for it. Would you like to have a go at it? The other thing I'd like is to at least optionally actually build the tree over ftp. Martin From david.planella at ubuntu.com Wed Aug 17 18:41:53 2011 From: david.planella at ubuntu.com (David Planella) Date: Wed, 17 Aug 2011 20:41:53 +0200 Subject: Ubuntu AppDeveloper Week - Call for Sessions Message-ID: <1313606513.6574.232.camel@avenc> Hi Bzr Developers, The next Ubuntu AppDeveloper Week its going to be in a few weeks time, from the *5th to 9th September*, and with your help it's going to be awesome as usual. For those of you not familiar with UADW: "Ubuntu App Developer Week is a week of sessions aimed at enabling and inspiring developers to write applications that scratch their itches. Our goal is to give all attendees a taste of the wide variety of tools on the Ubuntu platform that can be used to create awesome applications, and to showcase some applications that have been created and explain how they were put together." At this point I'm doing a preliminary call for IRC sessions before the announcement, and I'd like to ask you to contribute with your sessions or suggestions. This is a great opportunity to showcase and to teach about the unique technologies that enable application developers to create beautiful apps using our platform. And to recruit new contributors for your project ;) Here are just some ideas on interesting topics to we should definitely have content on: * Unity Scopes/Lenses * Unity 2D * AppIndicators * Ubuntu One * Multitouch * The Application Review Process * Quickly * Python, PyGtk * Qt, QML, PyQt * Bzr * Launchpad, the Launchpad API * ... Call for sessions ----------------- So here's what I'd like to ask you to do: Do you have an idea for a cool topic you'd like to hear more about? * Add it here: https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Prep Or the improved alternative: Do you want to deliver a session on _your_ cool topic? * Add it here: https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable Thanks a lot for your help in making the next UADW rock! Cheers, David. -- David Planella Ubuntu Translations Coordinator www.ubuntu.com / www.davidplanella.wordpress.com www.identi.ca/dplanella / www.twitter.com/dplanella -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From amanic at gmail.com Thu Aug 18 13:45:32 2011 From: amanic at gmail.com (Marius Kruger) Date: Thu, 18 Aug 2011 15:45:32 +0200 Subject: bzr branch leads to empty folder In-Reply-To: References: <32204637.post@talk.nabble.com> Message-ID: On 18 August 2011 09:34, Martin Pool wrote: ... > It's a good idea, and quite technically possible. ?There's a bug > asking for it. ?Would you like to have a go at it? sure, but I not right now - too many urgent things on my plate ATM :( I added it to my list :) -- <>< Marius ><> From andrew at bemusement.org Thu Aug 18 23:23:57 2011 From: andrew at bemusement.org (Andrew Bennetts) Date: Fri, 19 Aug 2011 09:23:57 +1000 Subject: revids that include periods are interpreted as ranges In-Reply-To: <4E4A409D.9010600@arbash-meinel.com> References: <4E4A409D.9010600@arbash-meinel.com> Message-ID: <20110818232357.GA30960@flay.puzzling.org> On Tue, Aug 16, 2011 at 12:04:13PM +0200, John Arbash Meinel wrote: [...] > But honestly, I don't use raw revids particularly often. But they > certainly are meant to be available, and uniquely identify a revision. > Especially for automated processing, etc. So I would like to have a way > to work with your use case. Two thoughts: 1) if we had a way to refer to a revision by a (unique) substring of the revid (as some other tools do) that might kill two birds with one stone: provide a workaround for this issue, and also make using raw revids slightly more convenient. Obviously arranging for those lookups to be cheap is non-trivial, but e.g. a plugin could maintain an index. 2) scripts that rely on ?-r revid:$REV? to unambiguously refer to a single revision and not a range might be trickable into doing slightly wrong things if you can inject a sufficiently tricky revision ID. Imagine e.g. committing a specially crafted revision ID that caused a merge robot to merge some malicious revisions rather than the one that was reviewed. So this is potentially a security issue, although I think not a serious or urgent one. -Andrew. From eugene.tarasenko at gmail.com Fri Aug 19 10:29:39 2011 From: eugene.tarasenko at gmail.com (Eugene Tarasenko) Date: Fri, 19 Aug 2011 03:29:39 -0700 (PDT) Subject: Create PPA for bzr-externals plugin Message-ID: <32294160.post@talk.nabble.com> Hi, one user asks me about creating PPA package for bzr-externals plugin https://answers.launchpad.net/bzr-externals/+question/168306 could anybody help with it and create a package? -- View this message in context: http://old.nabble.com/Create-PPA-for-bzr-externals-plugin-tp32294160p32294160.html Sent from the Bazaar - General Discussion mailing list archive at Nabble.com. From a.starr.b at gmail.com Fri Aug 19 15:46:29 2011 From: a.starr.b at gmail.com (Andrew Starr-Bochicchio) Date: Fri, 19 Aug 2011 11:46:29 -0400 Subject: Create PPA for bzr-externals plugin In-Reply-To: <32294160.post@talk.nabble.com> References: <32294160.post@talk.nabble.com> Message-ID: On Fri, Aug 19, 2011 at 6:29 AM, Eugene Tarasenko wrote: > > Hi, one user asks me about creating PPA package for bzr-externals plugin > https://answers.launchpad.net/bzr-externals/+question/168306 could anybody > help with it and create a package? I just pushed initial work on debian packaging to: lp:~andrewsomething/bzr-externals/packaging Though as I don't use it in any of my workflows, I don't know if I'm up for maintaining this package in the long run. Running "bzr builddeb" in that branch will give you a working package. -- Andrew Starr-Bochicchio Ubuntu Developer Debian Contributor PGP/GPG Key ID: D53FDCB1 From _ at maxb.eu Sat Aug 20 17:50:39 2011 From: _ at maxb.eu (Max Bowsher) Date: Sat, 20 Aug 2011 18:50:39 +0100 Subject: Obsoleting Karmic from the last of the PPAs Message-ID: <4E4FF3EF.6080004@maxb.eu> We already stopped building for Karmic in the daily PPA some time ago. I proposed cessation of karmic support in the beta PPA back in May, to no objections: https://lists.ubuntu.com/archives/bazaar/2011q2/072668.html (though I didn't actually follow through on removing karmic from the beta PPA at that time - I'm going to do it now) Karmic is now nearly 4 months past EOL, so I think it's time to make the call to obsolete it from the main "ppa" PPA too at this point. Trusting that this is a pretty obvious decision at this point, and as it is easily revertible (by copying back from the obsolete PPA), I'm just going to do it. Please let me know if you feel this was in any way precipitous :-) Max. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From markgrandi at gmail.com Sun Aug 21 11:12:35 2011 From: markgrandi at gmail.com (Mark Grandi) Date: Sun, 21 Aug 2011 04:12:35 -0700 Subject: Checking out repo with symlinks on windows Message-ID: So, i have this repository that has a symlink in it, and it turns out that i cannot check out / branch that repository on windows because bazaar doesn't support it. I looked around and saw there was already a bug report for this here: https://bugs.launchpad.net/bzr/+bug/81689 alllll the way from 2006 and its still not fixed. Part of the problem is that python itself didn't have support for os.path.symlink and os.path.islink for a long time, but even though the bug is already closed (http://bugs.python.org/issue1578269), it only seems to work in python 3.x, and not in python 2.7, and waiting for bazaar to go to python 3 is not really an option. I researched how other version control systems deal with this, and it seems that git (msysgit at least) converts the symlink to a text file with the path as the text, while command line git tries to restore them, and has a setting to make it convert the sym link into a text file. No idea what it does if that variable is not set and you try to clone into a windows machine (links: http://stackoverflow.com/questions/954560/what-does-git-do-to-files-that-are-a-symbolic-linkand http://stackoverflow.com/questions/5917249/git-symlinks-in-windows, and http://code.google.com/p/msysgit/issues/detail?id=224) In SVN, it seems to just convert symlinks into a normal file on windows (from http://subversion.apache.org/faq.html#symlinks) in mercurial , it also seems to do the conversion of a symlink into a file (from http://stackoverflow.com/questions/1967973/mercurial-symlinks-on-windows) so, we see a pattern here. While it would be awesome to convert a unix symlink into a windows link or junction or whatever, since there seems to be problems with requiring administration privileges to actually create the link (or at least the default windows settings are set up that way, its possible to make other accounts have that privilege however you need to do it manually), why doesn't bazaar do this as well? I talked about this on the #bzr irc and someone suggested: >But I think it'd be possible to arrange for the code to do something like "if platform == 'win32' and dirstate_kind == 'symlink' and disk_kind == 'file': pretend disk kind is symlink" > Why? Because 'bzr status' etc looks at what's on disk (with os.stat, basically) and reports 'file', 'directory', 'symlink'. While i know python, I don't know much about the bazaar codebase. If bazaar actually saves the kind of the file as a symlink, then it would be easy to convert the file into a text file with just the path on windows, however i have no idea what would happen if the user edited that file, and how it would save the information in the repo. I just feel this bug should at least be fixed enough where windows users can actually download the repository instead of not being able to at all. ~mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Mon Aug 22 00:05:53 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 22 Aug 2011 10:05:53 +1000 Subject: Checking out repo with symlinks on windows In-Reply-To: References: Message-ID: Hi Mark, I think converting it to a file would be fine. It needs a little bit of care to make sure that a commit in that tree does not commit a replacement of the symlink with a file but that's feasible. If you want to have a go at fixing it we'll help. Martin From aaron at aaronbentley.com Mon Aug 22 02:57:20 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Sun, 21 Aug 2011 22:57:20 -0400 Subject: bzr branch leads to empty folder In-Reply-To: References: <32204637.post@talk.nabble.com> Message-ID: <4E51C590.1040106@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-08-18 03:34 AM, Martin Pool wrote: > The other thing I'd like is to at least optionally actually build the > tree over ftp. I've got some work in progress to modularize the TreeTransform code so that it doesn't have to hit the filesystem. My goal was to have memory-only PreviewTrees, but the work could be extended to building trees over FTP or other transports. Do you mean actual working trees? Because our current working trees require OS locks, so that doesn't seem feasible except over the smart transport. But if they're not actual working trees, then updating them properly on subsequent pushes could be very tricky. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5RxY0ACgkQ0F+nu1YWqI1M2QCcD5o1W7zOelprlEa7DTJc8oNr E+sAn1weUeNMZf3PKN0Mz4mnIyEqHj2w =A1Fh -----END PGP SIGNATURE----- From mbp at canonical.com Mon Aug 22 03:08:48 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 22 Aug 2011 13:08:48 +1000 Subject: bzr branch leads to empty folder In-Reply-To: <4E51C590.1040106@aaronbentley.com> References: <32204637.post@talk.nabble.com> <4E51C590.1040106@aaronbentley.com> Message-ID: On 22 August 2011 12:57, Aaron Bentley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11-08-18 03:34 AM, Martin Pool wrote: >> The other thing I'd like is to at least optionally actually build the >> tree over ftp. > > I've got some work in progress to modularize the TreeTransform code so > that it doesn't have to hit the filesystem. ?My goal was to have > memory-only PreviewTrees, but the work could be extended to building > trees over FTP or other transports. That'd be great. > Do you mean actual working trees? ?Because our current working trees > require OS locks, so that doesn't seem feasible except over the smart > transport. ?But if they're not actual working trees, then updating them > properly on subsequent pushes could be very tricky. I was thinking that we could change to using lockdirs guarding the dirstate (which would be very worthwhile for a bunch of other reasons) and then have real trees. I think having a thing that looks like a working tree but can't actually be edited would be likely to lead to confusion. Martin From andreas.roehler at online.de Mon Aug 22 08:06:04 2011 From: andreas.roehler at online.de (=?ISO-8859-15?Q?Andreas_R=F6hler?=) Date: Mon, 22 Aug 2011 10:06:04 +0200 Subject: partial revert Message-ID: <4E520DEC.1010400@online.de> Hi, with several changes in a file, want to revert one of them but keep others. Learned so far shelving the good and reverting the remain would be the path. The setback AFAIU: with shelve I must deal with all the changes. OTOH as diff knows already every line, a command revert-partial from-line to-line seems within the range of possibilities. Maybe it exists already? Thanks, Andreas From jriddell at ubuntu.com Mon Aug 22 10:07:01 2011 From: jriddell at ubuntu.com (Jonathan Riddell) Date: Mon, 22 Aug 2011 11:07:01 +0100 Subject: patch pilot report Message-ID: <20110822100701.GA1326@starsky.19inch.net> Shannon Weyrick's patch to merge on large files. We got this finished off and merged in. https://code.launchpad.net/~weyrick/bzr/54624-warn-on-large-files/+merge/70691 "bzr push -q now does not print name of pushed location" tidied up and merged https://code.launchpad.net/~asc/bzr/bzrpushmessagesuppress/+merge/66909 "Add missing config store and stacks for control.conf and remote branches." approved with docstrings added https://code.launchpad.net/~vila/bzr/missing-stacks/+merge/71918 "config.LocationMatcher properly excludes unrelated sections" approved https://code.launchpad.net/~vila/bzr/829237-location-matcher-misses/+merge/72151 'Add a "bzr branches" command.' approved https://code.launchpad.net/~jelmer/bzr/cmd-branches/+merge/71577 and my own ones.. "Document gpgme usage in comments." and 'Report commits signed with expired keys in "verify-signatures".' finally merged after some battling with PQM https://code.launchpad.net/~jr/bzr/804253-comment-gpgme-verify-usage/+merge/70337 https://code.launchpad.net/~jr/bzr/804254-expired-keys/+merge/70419 'qverify-signatures: Report commits signed with expired keys in "verify-signatures"' https://code.launchpad.net/~jr/qbzr/verify-signatures-expired/+merge/70422 With patch piloting I struggle that I'm not qualified to review many patches, the last thing I want to do is approve a patch only to find it contains some obvious problem I overlooked. Also many merge proposals have ongoing conversations and it seems those who have already commented are best qualified to take it to approval. On patch pilot duty this week is John. Jonathan From mbp at canonical.com Mon Aug 22 10:18:10 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 22 Aug 2011 20:18:10 +1000 Subject: patch pilot report In-Reply-To: <20110822100701.GA1326@starsky.19inch.net> References: <20110822100701.GA1326@starsky.19inch.net> Message-ID: Thanks for getting all those patches finished and for sending a report. > With patch piloting I struggle that I'm not qualified to review many > patches, the last thing I want to do is approve a patch only to find > it contains some obvious problem I overlooked. ?Also many merge > proposals have ongoing conversations and it seems those who have already > commented are best qualified to take it to approval. That can be hard. It's nice if the pilot can get everything cleared, but for less experienced people it's not realistic, and we need to remember that even helping one patch is worthwhile. If you're not confident to review a patch there are some still some options available: * ask questions about things that do look wrong, or just not clearly right * say "I don't know this well but what I can understand looks ok" * ask/remind some other specific developer to review it * download the branch and test it interactively If there's a live conversation and it seems on track probably not action is necessary. If nothing has happened for a few days you can * try to summarize the conversation and what needs to be done * prod someone to follow up Review tries to deal with all (most) developers writing imperfect code; piloting is partly to address most developers being imperfectly organized about integrating work. Martin From nick.allen at onlinehome.de Mon Aug 22 10:23:36 2011 From: nick.allen at onlinehome.de (Nicholas Allen) Date: Mon, 22 Aug 2011 12:23:36 +0200 Subject: Bazaar 2.4 crashes when doing lightweight checkout (2.3.4 has no problems) Message-ID: <4E522E28.4020003@onlinehome.de> Hi, Just thought I would let you know on the list in case anyone has a workaround for this bug I reported: https://bugs.launchpad.net/bzr/+bug/830947 Basically, lightweight checkouts are now impossible so I've had to uninstall bazaar from the package manager and reinstall 2.3.4 from source. If anyone has a workaround so I can use 2.4 then would be grateful... Cheers, Nick From vila+bzr at canonical.com Tue Aug 23 09:04:37 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 23 Aug 2011 11:04:37 +0200 Subject: Standup 2011-08-23 Message-ID: * Martin * Pretty good week, talk to a bunch of people about fixing bugs in udd importer. Fix some bugs there (restful clients) * Moved our blog to https://blog.bazaar.canonical.com/ * Went to pycon Australia and fixed some easy bugs in upstream python. * Hope to address bugs assigned to me (disconnect/reconnect ssh) * A new way to handle standups: focus on summary and have separate specific meetings on specific problems. * John * First of the get_parent_map stuff. Needs to work on the second part (better cache use). * PP this week. * Looking at patch importer stuff (stacked branches) * Vincent * Waiting for a green light for 2.4.0 official announcement * More config stuff, issues with env variables not easy to decode since paths need special handling hence an indication that a env variable *is* a path (as opposed to a simple string). Rough roadmap therefore is: * find a good solution for env variables, * option expansion (waiting on env vars but almost ready to submit), * probably a path/url option type (not sure about that yet) * migrating the remaining options * Jelmer * Good handle on bug #824513 (bzr-svn) * work on colocated branches * Jonathan * PP last week, bunch of landings, a bit of hesitation, answered by poolie's mail. * Working on kde dolphin integration, should be done this week * Fixing issues in bzr-explorer docs * Looking at i18n, will work on it this week * Look deeper at signature checks. From mbp at canonical.com Tue Aug 23 09:24:59 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 23 Aug 2011 19:24:59 +1000 Subject: Checking out repo with symlinks on windows In-Reply-To: References: Message-ID: On 23 August 2011 02:42, Mark Grandi wrote: > Sure, I'd like to see if i could fix it. I've already been looking around > the bazaar code base a bit. Any idea on where I should start? > > ~mark The changes that seem to be needed are: * this ought to be governed by a policy knob that should default probably to being switched by the OS, but that can also be controlled by the user, in case they are for example on linux but using an ntfs filesystem (this could be done later) * when building a tree (in tree_transform), conditionally create a placeholder file rather than a symlink * when looking at the contents of a working tree, conditionally report files as being symlinks if they're links in the basis tree rather than in the actual on-disk tree - the dirstate based working trees should have attributes you can use to find the cached reference tree. hth, you can ask for more details. Martin From vila+bzr at canonical.com Tue Aug 23 09:40:37 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 23 Aug 2011 11:40:37 +0200 Subject: About config and useless IOs Message-ID: One of the goals of the new config stuff I'm working on is to avoid needlessly reading config files. This matters more when accessing remote branches than when dealing with local configs but it's hard to realize what is going on without some numbers. In revno 5981, I landed some utility stuff to measure such IOs (among other config operations) across the whole test suite which gave the following numbers (when running the test suite with -Econfig_stats and then invoking subunit-sum on the resulting stream, see https://code.launchpad.net/~vila/bzr/selftest-config-stats/+merge/64549 for details): config.load : 296 config.save : 106 config.get : 82 config.set : 52 config.remove : 8 old_config.load : 1002308 old_config.save : 5018 old_config.get : 383768 old_config.set : 4873 old_config.remove: 14 Each line represents the number of times a hook is called and a hook is set for every config operation (loading/saving a file, getting/setting/removing a config option). This gives some rough idea of the starting point. What happened since then ? revno 5999: (spiv) Make Branch.open more than 3x faster. config.load : 297 config.save : 106 config.get : 83 config.set : 52 config.remove : 8 old_config.load : 896574 old_config.save : 5022 old_config.get : 384308 old_config.set : 4877 old_config.remove: 14 Boom, 200.000 useless IOs down the drain. revno 6047: (mbp) merge 2.3 and 2.4 to trunk config.load : 603 config.save : 106 config.get : 190444 config.set : 52 config.remove : 8 old_config.load : 806023 old_config.save : 5053 old_config.get : 334777 old_config.set : 4904 old_config.remove: 14 What is really relevant in this merge is the introduction of the fdatasync options which use the new design: ~189.000 useless IOs down the drain again (notice that that config.load is now less than config.get because Martin did cache the config in the workingtree/branch object and avoided re-loading the config file for each option). revno 6082 (the tip when I ran all these stat collection jobs): config.load : 62055 config.save : 114 config.get : 258910 config.set : 58 config.remove : 8 old_config.load : 631616 old_config.save : 5070 old_config.get : 271380 old_config.set : 4923 old_config.remove: 14 Here we see that 60.000 IOs went from the old design to the new one (due to migrating the options from one design to the other) which is a pre-requisite to avoid most of them when reaching the read once/write once I'm aiming with the new design. Vincent From bialix at ukr.net Tue Aug 23 10:18:48 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 23 Aug 2011 13:18:48 +0300 Subject: Standup 2011-08-23 In-Reply-To: References: Message-ID: <4E537E88.9080801@ukr.net> vila ?????: > > * Moved our blog to https://blog.bazaar.canonical.com/ Chrome said SSL certificate is invalid(?) and after proceeding I see Not Found page. From bialix at ukr.net Tue Aug 23 10:20:02 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 23 Aug 2011 13:20:02 +0300 Subject: Standup 2011-08-23 In-Reply-To: References: Message-ID: <4E537ED2.5040906@ukr.net> vila ?????: > * Vincent > > * Waiting for a green light for 2.4.0 official announcement Windows installer? From jelmer at samba.org Tue Aug 23 10:21:01 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Tue, 23 Aug 2011 12:21:01 +0200 Subject: Standup 2011-08-23 In-Reply-To: <4E537ED2.5040906@ukr.net> References: <4E537ED2.5040906@ukr.net> Message-ID: <4E537F0D.9030103@samba.org> On 08/23/2011 12:20 PM, Alexander Belchenko wrote: > vila ?????: >> * Vincent >> >> * Waiting for a green light for 2.4.0 official announcement > > Windows installer? > bzr-svn 1.1.0. Cheers, Jelmer From mbp at canonical.com Tue Aug 23 10:32:39 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 23 Aug 2011 20:32:39 +1000 Subject: Standup 2011-08-23 In-Reply-To: <4E537E88.9080801@ukr.net> References: <4E537E88.9080801@ukr.net> Message-ID: On 23 August 2011 20:18, Alexander Belchenko wrote: > vila ?????: >> >> ?* Moved our blog to https://blog.bazaar.canonical.com/ > > Chrome said SSL certificate is invalid(?) Yep, that's a known problem, I think they are purchasing a new one. > and after proceeding I see Not > Found page. That's news to me, but I can reproduce it too. I'll look into it. Thanks, Martin From mbp at canonical.com Tue Aug 23 10:45:20 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 23 Aug 2011 20:45:20 +1000 Subject: Bazaar 2.4 crashes when doing lightweight checkout (2.3.4 has no problems) In-Reply-To: <4E522E28.4020003@onlinehome.de> References: <4E522E28.4020003@onlinehome.de> Message-ID: On 22 August 2011 20:23, Nicholas Allen wrote: > Hi, > > Just thought I would let you know on the list in case anyone has a > workaround for this bug I reported: > > https://bugs.launchpad.net/bzr/+bug/830947 > > Basically, lightweight checkouts are now impossible so I've had to uninstall > bazaar from the package manager and reinstall 2.3.4 from source. If anyone > has a workaround so I can use 2.4 then would be grateful.. I had a look at it; I can't immediately see how to reproduce it or what is causing it. One possible workaround would be to use a non-lightweight checkout. Martin From mbp at canonical.com Tue Aug 23 10:51:40 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 23 Aug 2011 20:51:40 +1000 Subject: partial revert In-Reply-To: <4E520DEC.1010400@online.de> References: <4E520DEC.1010400@online.de> Message-ID: On 22 August 2011 18:06, Andreas R?hler wrote: > Hi, > > with several changes in a file, want to revert one of them but keep others. > > Learned so far shelving the good and reverting the remain would be the path. > The setback AFAIU: with shelve I must deal with all the changes. > > OTOH as diff knows already every line, a command > > revert-partial from-line to-line > > seems within the range of possibilities. > > Maybe it exists already? Hi Andreas, The way I tend to deal with that is to run 'bzr diff --using meld', or open the previous and edited versions of the files in vimdiff, and then copy back the lines I want. emacs vc integration also has some tool to do this. Putting something into the shelve ui to say "skip to line N" could be useful, though generally users won't want to type line numbers... Martin From john at arbash-meinel.com Tue Aug 23 11:20:19 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 23 Aug 2011 13:20:19 +0200 Subject: partial revert In-Reply-To: References: <4E520DEC.1010400@online.de> Message-ID: <4E538CF3.9000802@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/2011 12:51 PM, Martin Pool wrote: > On 22 August 2011 18:06, Andreas R?hler > wrote: >> Hi, >> >> with several changes in a file, want to revert one of them but >> keep others. >> >> Learned so far shelving the good and reverting the remain would >> be the path. The setback AFAIU: with shelve I must deal with all >> the changes. >> >> OTOH as diff knows already every line, a command >> >> revert-partial from-line to-line >> >> seems within the range of possibilities. >> >> Maybe it exists already? > > Hi Andreas, > > The way I tend to deal with that is to run 'bzr diff --using meld', > or open the previous and edited versions of the files in vimdiff, > and then copy back the lines I want. emacs vc integration also has > some tool to do this. > > Putting something into the shelve ui to say "skip to line N" could > be useful, though generally users won't want to type line > numbers... > > Martin > I believe there is already "e" for edit mode if you have a diff editor set. I think we changed it in recent versions to always show the option, giving you the chance to realize you need to set an editor. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5TjPMACgkQJdeBCYSNAAMXaQCeJw5LSDg4n4Wq1nbUzWmhvzKV n14AoId7d9ymNgyzlDcWmRZKB2G8XF1Z =+lZK -----END PGP SIGNATURE----- From vila+bzr at canonical.com Tue Aug 23 11:39:20 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 23 Aug 2011 13:39:20 +0200 Subject: Standup 2011-08-23 In-Reply-To: <4E537F0D.9030103@samba.org> (Jelmer Vernooij's message of "Tue, 23 Aug 2011 12:21:01 +0200") References: <4E537ED2.5040906@ukr.net> <4E537F0D.9030103@samba.org> Message-ID: >>>>> Jelmer Vernooij writes: > On 08/23/2011 12:20 PM, Alexander Belchenko wrote: >> vila ?????: >>> * Vincent >>> >>> * Waiting for a green light for 2.4.0 official announcement >> >> Windows installer? >> > bzr-svn 1.1.0. Both :-D Vincent From andreas.roehler at online.de Tue Aug 23 15:55:50 2011 From: andreas.roehler at online.de (=?UTF-8?B?QW5kcmVhcyBSw7ZobGVy?=) Date: Tue, 23 Aug 2011 17:55:50 +0200 Subject: partial revert In-Reply-To: <4E538CF3.9000802@arbash-meinel.com> References: <4E520DEC.1010400@online.de> <4E538CF3.9000802@arbash-meinel.com> Message-ID: <4E53CD86.4030607@online.de> Am 23.08.2011 13:20, schrieb John Arbash Meinel: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/23/2011 12:51 PM, Martin Pool wrote: >> On 22 August 2011 18:06, Andreas R?hler >> wrote: >>> Hi, >>> >>> with several changes in a file, want to revert one of them but >>> keep others. >>> >>> Learned so far shelving the good and reverting the remain would >>> be the path. The setback AFAIU: with shelve I must deal with all >>> the changes. >>> >>> OTOH as diff knows already every line, a command >>> >>> revert-partial from-line to-line >>> >>> seems within the range of possibilities. >>> >>> Maybe it exists already? >> >> Hi Andreas, >> >> The way I tend to deal with that is to run 'bzr diff --using meld', >> or open the previous and edited versions of the files in vimdiff, >> and then copy back the lines I want. emacs vc integration also has >> some tool to do this. >> >> Putting something into the shelve ui to say "skip to line N" could >> be useful, though generally users won't want to type line >> numbers... >> >> Martin >> > > I believe there is already "e" for edit mode if you have a diff editor > set. I think we changed it in recent versions to always show the > option, giving you the chance to realize you need to set an editor. > > John > =:-> Hi, thanks all. I'll have a closer look at the Emacs VC. Andreas From vila+bzr at canonical.com Tue Aug 23 16:29:02 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 23 Aug 2011 18:29:02 +0200 Subject: partial revert In-Reply-To: <4E53CD86.4030607@online.de> ("Andreas =?iso-8859-1?Q?R=F6hle?= =?iso-8859-1?Q?r=22's?= message of "Tue, 23 Aug 2011 17:55:50 +0200") References: <4E520DEC.1010400@online.de> <4E538CF3.9000802@arbash-meinel.com> <4E53CD86.4030607@online.de> Message-ID: >>>>> Andreas R?hler writes: > Hi, > thanks all. I'll have a closer look at the Emacs VC. Then search for diff-mode (mainly diff-goto-source, diff-apply-hunk and diff-split-hunk). Getting various bzr outputs (bzr diff, bzr diff -rsubmit:) in a buffer set to diff-mode address most of my needs (especially coming back to one the file I'm currently modifying and reverting one or several hunks). I also occasionally edit/save these buffers instead of shelving or use 'M-x cd ' to paste changes (uncommitted or cherry-picked) from one branch to the other (diff-apply-hunk works both ways: to revert an existing change OR apply a change to a pristine file). I'm also using http://download.gna.org/dvc/ as it provides easy access to such buffers ;) Vincent From jelmer at samba.org Tue Aug 23 12:13:27 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Tue, 23 Aug 2011 14:13:27 +0200 Subject: Colocated branch progress In-Reply-To: <4E4B90BB.1050609@samba.org> References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> Message-ID: <4E539967.6060002@samba.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/08/11 11:58, Jelmer Vernooij wrote: > On 03/08/11 02:14, Jelmer Vernooij wrote: > > The ability to address colocated branches using URLs has long been in > > progress (https://bugs.launchpad.net/bugs/380871). After brainstorming a > > bit with John and Martin at the recent Launchpad sprint, I'm finally > > back on track hacking on it. > > > There are basically four things left to do now: > > > 1) Avoid URLescaping comma's when converting local paths to URLs. > > (lp:~jelmer/bzr/escape-comments) > > 2) Preserve the distinction between literal and delimiting comma's in > > URLs when they are parsed in e.g. ConnectedTransport (2) > > 3) Parse the subsegment parameters for Transports and make them > > accessible (done, lp:~jelmer/bzr/transport-segments) > > 4) Look at the transport segment parameters in ControlDir and use them > > to determine the default branch (this should be fairly easy) > All this has now finally happened, and is currently pending for landing > on bzr.dev. > > This means that with control directory formats that support it, you can > now do things like: > > $ bzr log "file:///path/to/repo,branch=foo > > We might add shorter forms of this available in the future, but will > have to be careful to not break other use cases. For example, supporting > "/tmp/repo,branch=foo" will break things for people who actually have > branches with a comma in their name. > > There are also two pending branches that make it possible to list > colocated branches ("bzr branches") and switch between them using "bzr > switch". There is now also a branch up that adds support for colocated branches to the standard bzrdir format, in a backwards compatible manner: https://code.launchpad.net/~jelmer/bzr/metadir-goes-colo/+merge/72451 Once that lands it should be possible to use colocated branches in bzr core, without the use of any plugins. The UI still needs some work though, and there is a bug about having bzr-colo's commands support the in-core colocated branches: https://bugs.launchpad.net/bzr-colo/+bug/830799 We should also improve various bits in the core UI to deal better with colocated branches: * Have some way to clone a control directory including *all* colocated branches (bug 831939) * Ability to remove colocated branches easily (bug 831464) * Ability to easily switch to new or existing colocated branches in "bzr switch" (bug 826814) * Anything else? For all colocated-related bugs, see also the "colocated" tag in Launchpad: https://bugs.launchpad.net/bzr/+bugs?field.tag=colocated Cheers, Jelmer -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOU5lnAAoJEACAbyvXKaRXh/8QAJDpLw0EYrfwL3xgfNlV/KS9 iazar5rj1jUeEXCJ178/QEcko7BGq64dzRq7vlb/qKywh2aQoEoHtl10dYUq1CVd J1mr771WRmsQC+q2l0uzVBeFgf5kF/Q7JiL6whP7tyJL/3wXfoYOwq1+hdc2pXEj T78zJ/gntoLHkPO4N9GV9PgUjAN3Dal7vZDqHq4zWDjGu9+iSjfYbSJ9fLzBs4cs j9WDxjMec1UmtdQ0gSSRNyqr/8vd0uLIPVi8bzqgD9pRPP903shpm4Ir9Y0vck4b rOxJHd4fFxwHfONIbz+ShFfieYuYjB6mwdfey9n3QCSaucJQINHUsG6ZS42vajCq jjEPbkgG5vyTmRnBwUNywMwX/X3tbnTISo8qGV4e6nnXnoFoDPCqMeiJ8tiMjj/G xUFA4Ufo5im5O6GDD0SI/LwfhAynXedIkVhhFPo1QE0+8fZsIy9jNweWsHDf6Eot oYBOFBfuEinaPSprkH+Z2Ny43FiuWHsh/AdRDCa4uf4Wxjxl7IjIPWfjqWkV+FmA JURu1/XsUjMqlaI1lfA9E5Lev/UVg9mUHzkwM1PLBsM97WhM0olVBqQpVq9wq0D/ fFjsLL7oc7hNjIjOQIEqECRZr0gPiGQVJvHMu0PVJT6plTu1aqsiSBGG3J8h8xQf CYCIzQmrFXFphPi6953b =6wMA -----END PGP SIGNATURE----- From gordon at doxxx.net Tue Aug 23 20:23:37 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 23 Aug 2011 16:23:37 -0400 Subject: Colocated branch progress In-Reply-To: <4E539967.6060002@samba.org> References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> <4E539967.6060002@samba.org> Message-ID: On Tue, 23 Aug 2011 14:13:27 +0200, Jelmer Vernooij wrote: > * Ability to easily switch to new or existing colocated branches in > "bzr switch" (bug 826814) Other commands, such as merge, log, diff, qlog, qdiff, etc. should also be able to use branches easily, as easily as the colo plugin. I don't want to have to type out some long-ass URL. :) Ciao, Gordon From robertc at robertcollins.net Wed Aug 24 04:05:00 2011 From: robertc at robertcollins.net (Robert Collins) Date: Wed, 24 Aug 2011 16:05:00 +1200 Subject: Colocated branch progress In-Reply-To: <4E539967.6060002@samba.org> References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> <4E539967.6060002@samba.org> Message-ID: What will this do on push to LP ? LP doesn't model N branches in one branch-url [yet]... From vila+bzr at canonical.com Wed Aug 24 08:13:14 2011 From: vila+bzr at canonical.com (vila) Date: Wed, 24 Aug 2011 10:13:14 +0200 Subject: Colocated branch progress In-Reply-To: <4E539967.6060002@samba.org> (Jelmer Vernooij's message of "Tue, 23 Aug 2011 14:13:27 +0200") References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> <4E539967.6060002@samba.org> Message-ID: >>>>> Jelmer Vernooij writes: > * Have some way to clone a control directory including *all* colocated > branches (bug 831939) > * Ability to remove colocated branches easily (bug 831464) > * Ability to easily switch to new or existing colocated branches in > "bzr switch" (bug 826814) > * Anything else? * bzr upgrade (if only to upgrade all branches) (http://pad.lv/832581) * bzr check to ensure the branches hierarchy stays in sync with the 'branch-list' file (http://pad.lv/832584) Vincent From newsgroups at catchall.shelter13.net Wed Aug 24 08:15:00 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Wed, 24 Aug 2011 10:15:00 +0200 Subject: Getting started with a content filter In-Reply-To: References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> <4E3C2F7E.8060400@d6.com> <4E4794DD.7060706@catchall.shelter13.net> Message-ID: <4E54B304.1030605@catchall.shelter13.net> Hi, >> and the "search bazaar" text in the top right is partly >> obscured by the search box itself.) > > It looks ok to me in Chrome and Firefox. What were you using? At Firefox 6 -- found the issue, I'm using a custom font and the "search bazaar" text takes my font settings, making the text slightly larger and thus overlapping. Cheers, Anteru From newsgroups at catchall.shelter13.net Wed Aug 24 08:15:00 2011 From: newsgroups at catchall.shelter13.net (Anteru) Date: Wed, 24 Aug 2011 10:15:00 +0200 Subject: Getting started with a content filter In-Reply-To: References: <4E304075.6000000@catchall.shelter13.net> <4E30D12F.10407@d6.com> <4E3BBCC8.5020402@arbash-meinel.com> <4E3C2F7E.8060400@d6.com> <4E4794DD.7060706@catchall.shelter13.net> Message-ID: <4E54B304.1030605@catchall.shelter13.net> Hi, >> and the "search bazaar" text in the top right is partly >> obscured by the search box itself.) > > It looks ok to me in Chrome and Firefox. What were you using? At Firefox 6 -- found the issue, I'm using a custom font and the "search bazaar" text takes my font settings, making the text slightly larger and thus overlapping. Cheers, Anteru From jelmer at samba.org Thu Aug 25 10:58:35 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Thu, 25 Aug 2011 12:58:35 +0200 Subject: Colocated branch progress In-Reply-To: References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> <4E539967.6060002@samba.org> Message-ID: <4E562ADB.6010908@samba.org> On 08/23/2011 10:23 PM, Gordon Tyler wrote: > On Tue, 23 Aug 2011 14:13:27 +0200, Jelmer Vernooij > wrote: >> * Ability to easily switch to new or existing colocated branches in >> "bzr switch" (bug 826814) > Other commands, such as merge, log, diff, qlog, qdiff, etc. should also be > able to use branches easily, as easily as the colo plugin. I don't want to > have to type out some long-ass URL. :) That makes sense in general when you specify a location - bug filed as https://bugs.launchpad.net/bzr/+bug/833665 The other commands are usually used in an existing control directory, where they will just use the default colocated branch. switch allows changing the currently active branch so is a bit special in this regard. Cheers, Jelmer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jelmer at samba.org Thu Aug 25 11:00:32 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Thu, 25 Aug 2011 13:00:32 +0200 Subject: Colocated branch progress In-Reply-To: References: <1312330486.3032.21.camel@genhwyvar> <4E4B90BB.1050609@samba.org> <4E539967.6060002@samba.org> Message-ID: <4E562B50.6050706@samba.org> On 08/24/2011 06:05 AM, Robert Collins wrote: > What will this do on push to LP ? LP doesn't model N branches in one > branch-url [yet]... Yeah, we'll have to look at that. This is also a good opportunity to support things like looms better. Cheers, Jelmer From john at arbash-meinel.com Fri Aug 26 14:06:48 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 26 Aug 2011 16:06:48 +0200 Subject: Notes on fdatasync for the test suite Message-ID: <4E57A878.3010206@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been feeling the pain of how slow our test suite has been lately, and I figured I'd poke around a bit if I could. Basically, our test suite is now running about 3.5hrs per run, where back in May it was running 45min per run. I don't have concrete evidence of the cause. It seems to be something in 2.4, but it may/may not be the fdatasync change. I see some runs before fdatasync landed that were 2hrs, though that could be human-submission delay. I'm planning on looking into this a bit more, since it is actually a 4.5x slowdown. And it has started showing up significantly in our process. First off, we got a nice backlog of tests the last couple of days, so it can be clear how long the test suite takes by looking at the date-stamps in my email. 08-24 16:16 6039 08-24 19:13 6094 3h 08-24 22:33 6095 3h20m 08-25 01:55 6096 3h20m 08-25 05:21 6097 3h25m 08-25 07:42 6098 2h20m 08-25 09:51 6099 2h09m 08-25 12:33 6100 2h40m 08-25 16:04 6101 3h30m 08-25 23:10 6102 7h06m probably 2 test runs (first failed) 08-26 02:51 6103 3h40m 08-26 11:54 6104 9h probably not backlogged The first thing that strikes me is the large variation. We go from 3+hrs per test run at night, down to 2+hrs/test run in the morning. The revnos indicate that they were all done on 'trunk', so it isn't a 2.3vs2.4 thing. Some more times from other days 08-19 14:36 4770 # 2.0 test suite, IIRC runs 2 times for LANG=C 08-19 17:46 6083 3h10m 08-19 22:27 4882 4h45m # 2.1 test, confirmed not to have LANG=C tests 08-20 01:44 6084 3h15m 08-20 05:12 6085 3h30m 08-20 07:22 6086 2h10m 08-20 11:02 5135 3h40m # 2.2 test suite 08-20 13:49 6087 2h30m 08-20 14:31 5660 0h42m # 2.3 test suite ??????, confirmed by the # Revision.timestamps 08-20 16:41 6088 2h10m 08-20 22:36 6036 3h50m # 2.4 08-21 00:42 6089 2h06m 08-21 13:35 6090 08-21 15:40 6037 2h05m # 2.4 08-21 19:21 6091 3h40m The almost scary one is that the 2.3 test suite completed in 42min. I really don't know what was going on there. My mailbox only goes back to May 2011, as I've otherwise been deleting these messages. But back then we have 05-04 02:49 5817 05-04 04:29 5818 2h40m 05-04 11:41 5819 7h12m # 7h/2 = 3h36m 05-04 14:10 5820 2h30m 05-04 18:17 5821 4h07m 05-04 19:38 5822 1h21m ? 05-04 21:07 5823 1h29m 05-04 21:55 5824 0h48m 05-04 22:44 5825 0h49m 05-05 00:17 5826 1h33m 05-05 01:04 5827 0h47m 05-05 01:53 5828 0h49m 05-05 02:41 5829 0h48m 05-05 05:14 5830 2h33m # jelmer was staying up way too late # or there were 2 previous failures The huge thing I see here is a test suite that is running in 50 minutes instead of more than 3 hours. You can potentially discount the 3-hour runs earlier in the day as not being a backlog, and just being the delay between submissions. Which would also be consistent with the time of day. 14UTC is about 4pm in Europe. I thought that maybe Martin's fdatasync patch could have contributed. I did a controlled test of just a subset "bt.per_repository.test_commit". The numbers were: 319.8s comment out config lookup and force flags to False 322.9s change osutils.fdatasync to just return 338.5s unchanged bzr.dev 377.0s add config.GlobalStack.set('repository.fdatasync', False) config.GlobalStack.set('dirstate.fdatasync', False) In overrideEnvironmentForTesting My guess is that the overhead of locking 2 times, and having all tests that read files actually have to read and parse the config is what slowed this down. Note that in bulk, the fdatasync seems to account for 339-320/339 = ~5%. That is certainly nothing like 2-3x that we are seeing. Martin's change landed around July 27th. However, notice that the original times I'm reporting are also for bzr-2.1/2/3, which *don't* have Martin's patch. Though we did have a 40min run of a 2.3 branch. Here are some runs from July: 07-14 15:11 5655 # 2.3 07-14 15:52 6025 0h41m # 2.4 07-14 19:14 5656 07-14 20:16 5657 1h02m # 2.3.5 07-15 11:16 6018 # 2.4 07-15 12:35 6027 1h19m 07-15 13:42 6019 1h07m # 2.4 07-15 16:13 6028 2h30m # failed? 07-15 17:08 6029 0h53m 07-25 05:36 6043 07-25 08:53 6022 3h17m # 2.4 07-25 13:08 6044 07-25 16:01 6045 2h53m 07-27 05:03 6046 1h02m 07-27 07:05 6023 2h02m # 2.4, this is the fdatasync patch ### 08-01 07:47 5659 # 2.3 08-01 10:36 6025 2h45m # 2.4, merging up 5659, probably human delay 08-05 18:51 6052 08-05 21:18 6053 2h27m 08-06 03:29 6026 08-06 05:52 6054 2h23m 08-09 11:04 6058 08-09 14:34 6059 3h34m 08-09 19:04 6060 4h30m 08-09 22:17 6027 3h21m # 2.4 08-11 14:20 6030 08-11 17:22 6031 3h02m 08-11 20:50 6061 3h28m I haven't been able to go through all the logs, and commit/email timestamps are have a fuzzy relationship with test suite times. (It can never be faster than the test suite, but it can lag because of human actions, etc.) However, I haven't been able to find a confirmed 2.4/trunk run since Martin's patch landed that is faster than 2hr. And often 3hr+. Which is a very far cry from the 45min it used to be. However, also note that 2 days before Martin's patch landed, we already had a couple 2-3hr runs. Maybe it was something else, like ConfigStack causing us to read files 2-3x, or the Inventory.filter using set() that caused the regression. I'm running an SSD now, so it could be fdatasync but it only has a big effect when you have a spinning disk. Anyway, I plan to try to do some test-suite time bisection on Monday if I can. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5XqHgACgkQJdeBCYSNAAO5ywCfS1iB6ZLQmG9jUlhyLtO+y3nT QO0AmQEPpTc0g6+OskIks494ADbVmU7N =Qfa1 -----END PGP SIGNATURE----- From lolando at debian.org Fri Aug 26 14:51:16 2011 From: lolando at debian.org (Roland Mas) Date: Fri, 26 Aug 2011 16:51:16 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: <4E57A878.3010206@arbash-meinel.com> (John Arbash Meinel's message of "Fri, 26 Aug 2011 16:06:48 +0200") References: <4E57A878.3010206@arbash-meinel.com> Message-ID: <87ippk4463.fsf@mirexpress.internal.placard.fr.eu.org> John Arbash Meinel, 2011-08-26 16:06:48 +0200 : > I've been feeling the pain of how slow our test suite has been lately, > and I figured I'd poke around a bit if I could. > > Basically, our test suite is now running about 3.5hrs per run, where > back in May it was running 45min per run. I don't have concrete > evidence of the cause. It seems to be something in 2.4, but it may/may > not be the fdatasync change. I see some runs before fdatasync landed > that were 2hrs, though that could be human-submission delay. > > I'm planning on looking into this a bit more, since it is actually a > 4.5x slowdown. And it has started showing up significantly in our > process. You may like to investigate running the testsuite under the eatmydata wrapper; it's an LD_PRELOAD hack that makes stuff faster by disabling all kinds of sync-like behaviour. Roland. -- Roland Mas That's one of the good fings about not existin'; they leave you alone most of the time. -- in My Hero (Tom Holt) From jelmer at samba.org Fri Aug 26 17:46:11 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Fri, 26 Aug 2011 19:46:11 +0200 Subject: [ANNOUNCE] bzr-svn 1.1.0 Message-ID: <1314380771.10269.3.camel@localhost> I'm very happy to announce the release of the next version of bzr-svn, 1.1.0 (https://launchpad.net/bzr-svn/1.1/1.1.0). This release was long overdue, and adds support for bzr 2.3 and 2.4 as well as fixing a large number of bugs. Here is the full list of changes: BUG FIXES * Support `old_tip` argument to WorkingTree.update(). (Jelmer Vernooij, #695460) * Cope with layouts returning project paths that don't exist. (Max Bowsher, Jelmer Vernooij, #638492) * Support symlinks being changed into files, when their contents are no longer in the cache. (Max Bowsher, #638697) * Fix regression in 'bzr missing -v'. (#645360, Jelmer Vernooij) * Support non-ascii paths in SqliteCache when retrieving mappings. (#643737, Jelmer Vernooij) * Mark as compatible with bzr 2.3. (Jelmer Vernooij, #717475) * Mark as compatible with bzr 2.4. (Jelmer Vernooij, #828381) * Remove reference to edge.launchpad.net, which is going away. (Jelmer Vernooij, #666021) * Support binary files when sending svn-style diffs. (Jelmer Vernooij, #665662) * Fix compatibility with Python 2.4. (Kristian Berge Ness) * Support revision argument to update(). (Jelmer Vernooij, #537387) * Fix corner case bugs with branch moves. (Jelmer Vernooij, #701752) * Store short testament rather than long testament in bzr:testament revision property. (Jelmer Vernooij, #701380) * Provide ``BranchConfig.has_explicit_nickname()``. (Jelmer Vernooij, #704840) * Implement ReverseTagDict.__iter__. (Jelmer Vernooij) * SvnRepositoryFormat.initialize() is now implemented. (Jelmer Vernooij) * Use filters when generating sha1 sum for working tree files. (Jelmer Vernooij, #597887) * Support commit wiht svn:keywords use in working tree. (Jelmer Vernooij, #654329) * Preserve username when looking up credentials. (Jelmer Vernooij, #710931) * Fix following of parent path copies from the root. (Jelmer Vernooij, #665027) * Abort when branches diverge during push. (Jelmer Vernooij, #515850) * Support non-ascii characters in branch paths in foreign revision displayer (used by e.g. "bzr log"). (Jelmer Vernooij, #728380) * dpushing multiple commits no longer repeatedly downloads the entire tree. (Jelmer Vernooij, #582898) * Fix `push_merged_revisions = True` for committing to bound branches. (Jelmer Vernooij, #486811) * Transport.is_readonly() is now respected. (Jelmer Vernooij, #731268) * Fix ControlDir.sprout() implementation for newer versions of bzr. (Jelmer Vernooij, #717937) * bzr-svn no longer uses file properties to store metadata anymore, unless `allow_metadata_in_file_properties`. (Jelmer Vernooij, #704716) * Implement more efficient ``InterFromSvnBranch.fetch``. (Jelmer Vernooij, #741760) * Tags are now copied during clone if enabled ("branch.fetch_tags = True"). (Jelmer Vernooij, #309682) * "bzr commit --lossy" can now be used in bound branches. (Jelmer Vernooij, #587721) * Directories that are not considered branches by the standard apache layout can now be fetched. (Jelmer Vernooij, #794984) * More efficient discovery of tags. (Jelmer Vernooij, #797915) * Support tag setting for simple wildcard layouts. (Jelmer Vernooij, #816338) * Fix handling of NULL_REVISION in per-file revision graphs. (Jelmer Vernooij, #795700) * Prevent "holes" in the tdb cache when the process is aborted while updating the cache. (Jelmer Vernooij, #664085) * Fix handling of non-ascii directories when pushed to svn. (IWATA Hidetaka, #795994) * Fix importing of non-ascii characters in bzr:revprop: values. (Jelmer Vernooij, #821168) * Allow concurrent access of SQLite cache, rather than aborting. (Jelmer Vernooij, #685251) * Remove pointless _metadata_changed attribute which could not always be accessed. (Jelmer Vernooij, #771536) * Store correct file graph information in bzr-svn metadata. (Jelmer Vernooij, #485601) FEATURES * When roundtripping revisions a revision property with the Bazaar testament is now set as a revision property. (Jelmer Vernooij) * bzr-svn now requires Bazaar 2.3 or higher. (Jelmer Vernooij) * `bzr rmbranch` was implemented. (Jelmer Vernooij, #731305) * New hidden ``bzr svn-branches`` command which can display the branches found by bzr-svn in a svn repository. (Jelmer Vernooij) * Basic support for multiple branches in a single control directory. (Jelmer Vernooij, #740261) INTERNALS * Switch to using record_iter_changes style committing everywhere. (Jelmer Vernooij) * Implement InterOtherSvnBranch.copy_content_into. (Jelmer Vernooij, #731289) * Push is now record_iter_changes() based. (Jelmer Vernooij, #387623) CHANGES * bzr-svn now requires Python 2.5. (Jelmer Vernooij) The source code can be downloaded here: * http://samba.org/~jelmer/bzr/bzr-svn-1.1.0.tar.gz A detached GPG signature made with my keys (1EEF5276, D729A457) can be found here: * http://samba.org/~jelmer/bzr/bzr-svn-1.1.0.tar.gz.asc As always, please report any bugs you find in Launchpad: * https://launchpad.net/bzr-svn/+filebug Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part URL: From vila+bzr at canonical.com Sat Aug 27 12:48:56 2011 From: vila+bzr at canonical.com (vila) Date: Sat, 27 Aug 2011 14:48:56 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: (vila's message of "Sat, 13 Aug 2011 21:45:21 +0200") References: Message-ID: Hi, We discovered a critical bug (http://pad.lv/826946) while the installers and packages were being built and decided to delay the official announcement. Part of these discussions happened on IRC, the summary is that the bug is now fixed and bzr-svn 1.1.0 has been released. Please build packages and installers so we can officially announce 2.4.0. Thanks in advance, Vincent P.S.: Gordon, sorry for pushing you that hard for the mac installers ;) Feel free to either do a -2 installer or wait for 2.4.1 to catch up with bzr-svn. From jelmer at samba.org Sat Aug 27 14:44:06 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sat, 27 Aug 2011 16:44:06 +0200 Subject: make_branch_and_tree support for workingtree-less control directories Message-ID: <4E5902B6.2060705@samba.org> TestCaseWithTransport.make_branch_and_tree() creates, unsurprisingly, both a branch and a tree - in the same location. This breaks for some control dir formats that don't support working trees. Good examples of this are remote bzr directories, svn repository directories and git bare repositories. At the moment there are some workarounds in make_branch_and_tree to support treeless control directories, which are specific to RemoteBzrDir. I would like to make make_branch_and_tree() construct a branch in a different location and then create a checkout of it in the specified path. This should also remove the need for special casing of RemoteBzrDir in make_branch_and_tree. See the attached diff for what I have in mind. With this patch, a lot more bzr.dev tests pass against bzr-svn (~200) and bzr-git (~150), leaving just a couple of handful failing in total for bzr-svn. The patch also introduces ~80 failing tests in bzr.dev itself, but all of those look like they're fixable. The problem with this approach is that there are now (in some situations) two relevant formats - the format used by the branch, and the format used by the checkout. What would be the best way to deal with this? I would like to fix this by: * Renaming the 'format' argument to 'branch_format' * Adding a 'tree_format' argument that is mutually exclusive with 'branch_format' * Adding WorkingTreeFormat.get_branch_bzrdir_format_for_testing(), which returns the ControlDirFormat to use when testing WorkingTree-only control directories (like a svn checkout) The main risk seems to be that callers can more easily test with the wrong format. Does this seem like a reasonable approach? Cheers, Jelmer -------------- next part -------------- A non-text attachment was scrubbed... Name: generic-make-branch-and-tree.diff Type: text/x-patch Size: 4543 bytes Desc: not available URL: From jelmer at samba.org Sat Aug 27 14:46:05 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sat, 27 Aug 2011 16:46:05 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: <4E59032D.7090201@samba.org> On 08/27/2011 02:48 PM, vila wrote: > Hi, > > We discovered a critical bug (http://pad.lv/826946) while the installers > and packages were being built and decided to delay the official > announcement. > > Part of these discussions happened on IRC, the summary is that the bug > is now fixed and bzr-svn 1.1.0 has been released. > > Please build packages and installers so we can officially announce > 2.4.0. FWIW The 2.4 packages have landed in Debian sid and Ubuntu oneiric. Cheers, Jelmer From gordon at doxxx.net Sat Aug 27 21:04:40 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Sat, 27 Aug 2011 17:04:40 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: I'll probably get to it in the next day or two. Currently in a house cleaning frenzy for parental visit next week. :) On 2011-08-27, at 8:48 AM, vila wrote: > Hi, > > We discovered a critical bug (http://pad.lv/826946) while the installers > and packages were being built and decided to delay the official > announcement. > > Part of these discussions happened on IRC, the summary is that the bug > is now fixed and bzr-svn 1.1.0 has been released. > > Please build packages and installers so we can officially announce > 2.4.0. > > Thanks in advance, > > Vincent > > P.S.: Gordon, sorry for pushing you that hard for the mac installers ;) > Feel free to either do a -2 installer or wait for 2.4.1 to catch up with > bzr-svn. > From mbp at canonical.com Mon Aug 29 06:28:22 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 29 Aug 2011 16:28:22 +1000 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: I've just updated http://doc.bazaar.canonical.com/ to say 2.5 is current, and am just going to fix to point to "what's new in 2.5". M From jelmer at samba.org Sun Aug 28 23:45:24 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Mon, 29 Aug 2011 01:45:24 +0200 Subject: Spurious test failures in open_write_stream Message-ID: <4E5AD314.3000404@samba.org> Hi, While trying to build bzr 2.4.0 on hardy, I am running into spurious test failures in open_write_stream when being called from _write_index. I've seen this particular exception being raised from various different tests. For some reason I can only reproduce the problem on the buildds an not on my local machine. Especially the fact that the failures are spurious and not locally reproducible make it hard to fix this. Has anybody seen these errors before? This is the traceback from one of the errors: ERROR: bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all ---------------------------------------------------------------------- _StringException: Text attachment: log ------------ 210.429 creating repository in file:///tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch/.bzr/. 210.433 creating branch in file:///tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch/ 210.451 trying to create missing lock '/tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch/.bzr/checkout/dirstate' 210.472 opening working tree '/tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch' 210.499 preparing to commit INFO Committing to: /tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch/ 210.504 Selecting files for commit with filter None INFO added a INFO Committed revision 1. 210.539 Committed revid r1 as revno 1. 210.575 preparing to commit INFO Committing to: /tmp/testbzr-00q0sT.tmp/bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all/work/branch/ 210.579 Selecting files for commit with filter None INFO added b 210.604 aborting commit write group because of exception: 210.605 Traceback (most recent call last): File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/commit.py", line 440, in _commit self.rev_id = self.builder.commit(self.message) File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/vf_repository.py", line 200, in commit self.repository.commit_write_group() File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/repository.py", line 641, in commit_write_group result = self._commit_write_group() File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/repofmt/pack_repo.py", line 1711, in _commit_write_group hint = self._pack_collection._commit_write_group() File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/repofmt/pack_repo.py", line 1596, in _commit_write_group self._new_pack.finish() File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/repofmt/pack_repo.py", line 486, in finish self._write_index('text', self.text_index, 'file texts', suspend) File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/repofmt/pack_repo.py", line 546, in _write_index mode=self._file_mode) File "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/transport/local.py", line 331, in open_write_stream handle = osutils.open_file(abspath, 'wb') IOError: [Errno 21] Is a directory Cheers, Jelmer From john at arbash-meinel.com Mon Aug 29 15:03:44 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 29 Aug 2011 17:03:44 +0200 Subject: Spurious test failures in open_write_stream In-Reply-To: <4E5AD314.3000404@samba.org> References: <4E5AD314.3000404@samba.org> Message-ID: <4E5BAA50.6080701@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/29/2011 1:45 AM, Jelmer Vernooij wrote: > Hi, > > While trying to build bzr 2.4.0 on hardy, I am running into > spurious test failures in open_write_stream when being called from > _write_index. > > I've seen this particular exception being raised from various > different tests. For some reason I can only reproduce the problem > on the buildds an not on my local machine. > > Especially the fact that the failures are spurious and not locally > reproducible make it hard to fix this. > > Has anybody seen these errors before? This is the traceback from > one of the errors: > > ERROR: > bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all ... > > File > "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/transport/local.py", > > line 331, in open_write_stream > handle = osutils.open_file(abspath, 'wb') IOError: [Errno 21] Is a > directory > > Cheers, > > Jelmer > > I haven't seen this before myself. Getting EISDIR is pretty strange here. This is when it is writing the index files out, so the files should always have a '.iix', '.tix' etc, even if 'name' somehow became an empty string. Now, if this was ENOTDIR, that could be something else entirely, but EISDIR is just really strange. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5bqk8ACgkQJdeBCYSNAANJ1QCbB2YPPWOeMt1jRir/hWzjA2gR T+oAoNTKadZXyvW6hRHb0FpAaoHg2XVq =A3CJ -----END PGP SIGNATURE----- From colin at gibibit.com Mon Aug 29 17:39:25 2011 From: colin at gibibit.com (Colin D Bennett) Date: Mon, 29 Aug 2011 10:39:25 -0700 Subject: revids that include periods are interpreted as ranges In-Reply-To: References: Message-ID: <20110829103925.7496e19e@svelte> On Wed, 10 Aug 2011 13:19:20 -0400 Robin Luckey wrote: > > I have found several Bzr repositories with revids that include the > substring '..' within them. Although these are single revids, bzr > interprets them as revid *ranges*, and thus they cannot be passed as > parameters to the bzr command line tools. Also consider the possibility of a tag containing the string ?..?. Although I agree that in practice, tags generally would not contain this string. It would be nice if there were some way to be extra explicit, such as adding new --first-rev=PURE_REV and --last-rev=PURE_REV options in addition to the parsed --revision=REVISIONSPEC_OR_POSSIBLY_A_RANGE option. The PURE_REV values would be handled verbatim and not parsed as possible ranges. This would be a simple and complete solution that could be used especially for scripts, where a user is not able to observe and handle to rare chance that the ?..? occurs in a revision range. Regards, Colin From briandealwis at gmail.com Mon Aug 29 18:24:26 2011 From: briandealwis at gmail.com (Brian de Alwis) Date: Mon, 29 Aug 2011 14:24:26 -0400 Subject: revids that include periods are interpreted as ranges In-Reply-To: <20110829103925.7496e19e@svelte> References: <20110829103925.7496e19e@svelte> Message-ID: <38600B83-A813-4025-AC78-52021A20E928@gmail.com> How about supporting quoting? bzr log -r \"revid:xxx..xxx\"..\"revid:?\" Brian. On 29-Aug-2011, at 1:39 PM, Colin D Bennett wrote: > On Wed, 10 Aug 2011 13:19:20 -0400 > Robin Luckey wrote: > >> >> I have found several Bzr repositories with revids that include the >> substring '..' within them. Although these are single revids, bzr >> interprets them as revid *ranges*, and thus they cannot be passed as >> parameters to the bzr command line tools. > > Also consider the possibility of a tag containing the string ?..?. > Although I agree that in practice, tags generally would not contain > this string. It would be nice if there were some way to be extra > explicit, such as adding new > --first-rev=PURE_REV and --last-rev=PURE_REV options in addition to the > parsed --revision=REVISIONSPEC_OR_POSSIBLY_A_RANGE option. The > PURE_REV values would be handled verbatim and not parsed as possible > ranges. This would be a simple and complete solution that could be > used especially for scripts, where a user is not able to observe and > handle to rare chance that the ?..? occurs in a revision range. > > Regards, > Colin > From jelmer at samba.org Mon Aug 29 23:44:33 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Tue, 30 Aug 2011 01:44:33 +0200 Subject: Spurious test failures in open_write_stream In-Reply-To: <4E5BAA50.6080701@arbash-meinel.com> References: <4E5AD314.3000404@samba.org> <4E5BAA50.6080701@arbash-meinel.com> Message-ID: <4E5C2461.7040204@samba.org> On 08/29/2011 05:03 PM, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/29/2011 1:45 AM, Jelmer Vernooij wrote: >> Hi, >> >> While trying to build bzr 2.4.0 on hardy, I am running into >> spurious test failures in open_write_stream when being called from >> _write_index. >> >> I've seen this particular exception being raised from various >> different tests. For some reason I can only reproduce the problem >> on the buildds an not on my local machine. >> >> Especially the fact that the failures are spurious and not locally >> reproducible make it hard to fix this. >> >> Has anybody seen these errors before? This is the traceback from >> one of the errors: >> >> ERROR: >> bzrlib.tests.blackbox.test_version_info.TestVersionInfo.test_custom_implies_all > ... > >> > File >> "/build/buildd/bzr-2.4.0/build/lib.linux-i686-2.5/bzrlib/transport/local.py", >> >> > line 331, in open_write_stream >> handle = osutils.open_file(abspath, 'wb') IOError: [Errno 21] Is a >> directory >> >> Cheers, >> >> Jelmer >> >> > I haven't seen this before myself. Getting EISDIR is pretty strange > here. This is when it is writing the index files out, so the files > should always have a '.iix', '.tix' etc, even if 'name' somehow became > an empty string. > > Now, if this was ENOTDIR, that could be something else entirely, but > EISDIR is just really strange. Yeah, my thoughts exactly. At least that means I'm not missing something obvious here. It seems that not running with --parallel stops the spurious test failures, so that means this issue is no longer blocking me. It's still a mystery to me why this would break when running the tests in parallel though, since we're running all tests in separate directories (IIUC). Cheers, Jelmer From gordon at doxxx.net Mon Aug 29 23:57:41 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 29 Aug 2011 19:57:41 -0400 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: References: Message-ID: <4E5C2775.7090500@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mac OS X 10.6 installer #2 is uploaded, with bzr-svn 1.1.0. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOXCd1AAoJEIrPJfWinA2uIMQH/j++Ln/66Zf6EmIKf8FS6XFG zEmxEGz6QYDYBUrT35jEZBc3Hg5yNI+0oaJ1ZyFtvUhKrKIKFHtYLb7Ft5FW61/H jrLsMjdCYkMrbNnRl75D2+K0Tz/3jRl5qzQg3BIst8ugxUTgcOVrQ1iHL03nTK50 71YCxFljVe/EEXUnFrotOrNlofxglUT0KAeUdrVC/yBjDJp3/l7+IC3MyL93Kdza J1iU9stgHp3Dm1S41CQlLbQ4rzmgUljOX1IQsbrMZhWBT3ttz+FN9bE8V1nAoXW9 vVeRder9z7nKxK0B03nqnK/Go8I5+JjM6b4I4aTWwOFZ7X102adP9U0rTSwUKX4= =Uo20 -----END PGP SIGNATURE----- From davidkmuir at gmail.com Tue Aug 30 05:21:40 2011 From: davidkmuir at gmail.com (David Muir) Date: Tue, 30 Aug 2011 15:21:40 +1000 Subject: bzr heads help Message-ID: <4E5C7364.5000607@gmail.com> Two issues: 1. I noticed that running bzr heads --all on a relatively small repository (~1800 revs) takes quite a long time: $ bzr heads --all --debug-time get heads: 0.134533882141 make head marks: 79.3243851662 Fetching just the live heads takes just as long. Is it supposed to be that slow? 2. What is the difference between live and dead heads? My guess is that a live head is one that exists in a branch, but has not been merged into any other branch? eg : branch1 - live head A-B-C-D-E trunk - dead head? A-B-C after branch1 has been merged into trunk: branch1 - dead head A-B-C-D-E trunk - live head A-B-C-----F \D-E/ Is this correct? Cheers, David From mbp at canonical.com Tue Aug 30 05:35:16 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 30 Aug 2011 15:35:16 +1000 Subject: bzr heads help In-Reply-To: <4E5C7364.5000607@gmail.com> References: <4E5C7364.5000607@gmail.com> Message-ID: On 30 August 2011 15:21, David Muir wrote: > Two issues: > > 1. I noticed that running bzr heads --all on a relatively small > repository (~1800 revs) takes quite a long time: > > $ bzr heads --all --debug-time > get heads: 0.134533882141 > make head marks: 79.3243851662 > > Fetching just the live heads takes just as long. > Is it supposed to be that slow? No, it's not supposed to be slow. Running it on bzr which has much more history takes 19s: faster would be better, but this is proportionally much faster. A good way to debug this, if you want to work on it, is to add '--lsprof-file heads.callgrind' and then load that up in kcachegrind. It looks to me like it spends a lot of time recursing to find the possible branches under the repository and that might fairly easily be improved by for example telling it not to look recursively inside checkouts, or perhaps not to distinguish live and dead heads. > 2. What is the difference between live and dead heads? My guess is that > a live head is one that exists in a branch, but has not been merged into > any other branch? I think that's right. m From bialix at ukr.net Tue Aug 30 06:56:27 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 30 Aug 2011 09:56:27 +0300 Subject: bzr heads help In-Reply-To: <4E5C7364.5000607@gmail.com> References: <4E5C7364.5000607@gmail.com> Message-ID: <4E5C899B.2000209@ukr.net> 30.08.2011 8:21, David Muir ?????: > Two issues: > > 1. I noticed that running bzr heads --all on a relatively small > repository (~1800 revs) takes quite a long time: > > $ bzr heads --all --debug-time > get heads: 0.134533882141 > make head marks: 79.3243851662 > > Fetching just the live heads takes just as long. > Is it supposed to be that slow? Most likely you'd get similar time if you run `bzr branches` in your location. > 2. What is the difference between live and dead heads? My guess is that > a live head is one that exists in a branch, but has not been merged into > any other branch? live head -- exists in the branch as branch tip. dead head -- tip revision not in the branch. Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or `bzr pull --overwrite` (losing your local history). The purpose of `heads` command is to be able to find revision ids for lost revisions. From eliz at gnu.org Tue Aug 30 07:25:39 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 30 Aug 2011 03:25:39 -0400 Subject: bzr heads help In-Reply-To: <4E5C899B.2000209@ukr.net> (message from Alexander Belchenko on Tue, 30 Aug 2011 09:56:27 +0300) References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> Message-ID: > Date: Tue, 30 Aug 2011 09:56:27 +0300 > From: Alexander Belchenko > Cc: bazaar at lists.canonical.com > > > 2. What is the difference between live and dead heads? My guess is that > > a live head is one that exists in a branch, but has not been merged into > > any other branch? > > live head -- exists in the branch as branch tip. > > dead head -- tip revision not in the branch. > > Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or `bzr > pull --overwrite` (losing your local history). The purpose of `heads` > command is to be able to find revision ids for lost revisions. It would be _really_ nice to have all this information as part of "bzr help heads". TIA From john at arbash-meinel.com Tue Aug 30 07:38:31 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 30 Aug 2011 09:38:31 +0200 Subject: bzr heads help In-Reply-To: References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> Message-ID: <4E5C9377.5090200@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/30/2011 9:25 AM, Eli Zaretskii wrote: >> Date: Tue, 30 Aug 2011 09:56:27 +0300 From: Alexander Belchenko >> Cc: bazaar at lists.canonical.com >> >>> 2. What is the difference between live and dead heads? My guess >>> is that a live head is one that exists in a branch, but has not >>> been merged into any other branch? >> >> live head -- exists in the branch as branch tip. >> >> dead head -- tip revision not in the branch. >> >> Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or >> `bzr pull --overwrite` (losing your local history). The purpose >> of `heads` command is to be able to find revision ids for lost >> revisions. > > It would be _really_ nice to have all this information as part of > "bzr help heads". > > TIA > 'bzr merge && bzr revert' doesn't create a dead head, because 'merge' doesn't create a node. You can only create nodes with 'commit'. And pull them into your graph with pull, etc. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ck3cACgkQJdeBCYSNAAMQ5gCgl/PcHlBGfAwH15IdSnKYWTkk gTgAn0KktONJizZyntCXuNkasHAa9R6+ =KoZu -----END PGP SIGNATURE----- From fullermd at over-yonder.net Tue Aug 30 07:43:08 2011 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Tue, 30 Aug 2011 02:43:08 -0500 Subject: bzr heads help In-Reply-To: <4E5C9377.5090200@arbash-meinel.com> References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> <4E5C9377.5090200@arbash-meinel.com> Message-ID: <20110830074308.GL2493@over-yonder.net> On Tue, Aug 30, 2011 at 09:38:31AM +0200 I heard the voice of John Arbash Meinel, and lo! it spake thus: > >> Date: Tue, 30 Aug 2011 09:56:27 +0300 From: Alexander Belchenko > >> > >> Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or > > 'bzr merge && bzr revert' doesn't create a dead head, because > 'merge' doesn't create a node. I'd guess he meant an update;revert in a bound branch. And he left out the simplest case; "rm -rf unmerged_branch" 8-} -- Matthew Fuller (MF4839) | fullermd at over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From mbp at canonical.com Tue Aug 30 07:44:26 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 30 Aug 2011 17:44:26 +1000 Subject: bzr heads help In-Reply-To: <4E5C9377.5090200@arbash-meinel.com> References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> <4E5C9377.5090200@arbash-meinel.com> Message-ID: On 30 August 2011 17:38, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 8/30/2011 9:25 AM, Eli Zaretskii wrote: >>> Date: Tue, 30 Aug 2011 09:56:27 +0300 From: Alexander Belchenko >>> Cc: bazaar at lists.canonical.com >>> >>>> 2. What is the difference between live and dead heads? My guess >>>> is that a live head is one that exists in a branch, but has not >>>> been merged into any other branch? >>> >>> live head -- exists in the branch as branch tip. >>> >>> dead head -- tip revision not in the branch. >>> >>> Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or >>> `bzr pull --overwrite` (losing your local history). The purpose >>> of `heads` command is to be able to find revision ids for lost >>> revisions. >> >> It would be _really_ nice to have all this information as part of >> "bzr help heads". >> >> TIA >> > > 'bzr merge && bzr revert' doesn't create a dead head, because 'merge' > doesn't create a node. You can only create nodes with 'commit'. And > pull them into your graph with pull, etc. Well, merge won't create a revision, but in the common case of merging from a separate repository it will implicitly fetch them, which I guess is what Alexander was thinking of. Could someone put up a patch to put this into the help? M From bialix at ukr.net Tue Aug 30 08:00:01 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 30 Aug 2011 11:00:01 +0300 Subject: bzr heads help In-Reply-To: References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> <4E5C9377.5090200@arbash-meinel.com> Message-ID: <4E5C9881.5070905@ukr.net> Martin Pool ?????: > On 30 August 2011 17:38, John Arbash Meinel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 8/30/2011 9:25 AM, Eli Zaretskii wrote: >>>> Date: Tue, 30 Aug 2011 09:56:27 +0300 From: Alexander Belchenko >>>> Cc: bazaar at lists.canonical.com >>>> >>>>> 2. What is the difference between live and dead heads? My guess >>>>> is that a live head is one that exists in a branch, but has not >>>>> been merged into any other branch? >>>> live head -- exists in the branch as branch tip. >>>> >>>> dead head -- tip revision not in the branch. >>>> >>>> Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or >>>> `bzr pull --overwrite` (losing your local history). The purpose >>>> of `heads` command is to be able to find revision ids for lost >>>> revisions. >>> It would be _really_ nice to have all this information as part of >>> "bzr help heads". >>> >>> TIA >>> >> 'bzr merge && bzr revert' doesn't create a dead head, because 'merge' >> doesn't create a node. You can only create nodes with 'commit'. And >> pull them into your graph with pull, etc. > > Well, merge won't create a revision, but in the common case of merging > from a separate repository it will implicitly fetch them, which I > guess is what Alexander was thinking of. Sorry I was unclear, I've meant that merge will fetch new revisions and they will be present in the repository so can be found by `bzr heads`, as Martin said. From bialix at ukr.net Tue Aug 30 08:00:01 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 30 Aug 2011 11:00:01 +0300 Subject: bzr heads help In-Reply-To: References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> <4E5C9377.5090200@arbash-meinel.com> Message-ID: <4E5C9881.5070905@ukr.net> Martin Pool ?????: > On 30 August 2011 17:38, John Arbash Meinel wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 8/30/2011 9:25 AM, Eli Zaretskii wrote: >>>> Date: Tue, 30 Aug 2011 09:56:27 +0300 From: Alexander Belchenko >>>> Cc: bazaar at lists.canonical.com >>>> >>>>> 2. What is the difference between live and dead heads? My guess >>>>> is that a live head is one that exists in a branch, but has not >>>>> been merged into any other branch? >>>> live head -- exists in the branch as branch tip. >>>> >>>> dead head -- tip revision not in the branch. >>>> >>>> Dead head created by `bzr uncommit`, `bzr merge && bzr revert` or >>>> `bzr pull --overwrite` (losing your local history). The purpose >>>> of `heads` command is to be able to find revision ids for lost >>>> revisions. >>> It would be _really_ nice to have all this information as part of >>> "bzr help heads". >>> >>> TIA >>> >> 'bzr merge && bzr revert' doesn't create a dead head, because 'merge' >> doesn't create a node. You can only create nodes with 'commit'. And >> pull them into your graph with pull, etc. > > Well, merge won't create a revision, but in the common case of merging > from a separate repository it will implicitly fetch them, which I > guess is what Alexander was thinking of. Sorry I was unclear, I've meant that merge will fetch new revisions and they will be present in the repository so can be found by `bzr heads`, as Martin said. From john at arbash-meinel.com Tue Aug 30 08:38:17 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 30 Aug 2011 10:38:17 +0200 Subject: [ANN] bzr 2.4.0 has gone gold In-Reply-To: <4E5C2775.7090500@doxxx.net> References: <4E5C2775.7090500@doxxx.net> Message-ID: <4E5CA179.9080000@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/30/2011 1:57 AM, Gordon Tyler wrote: > > Mac OS X 10.6 installer #2 is uploaded, with bzr-svn 1.1.0. bzr-2.4.0-1-setup.exe et al have been uploaded. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5coXkACgkQJdeBCYSNAAPL+gCgwgMFUM9QlFJ3V1lg+NP5emyi lAoAn1+bCceG7eyLwxE0fEAoNgjp+7rB =RJwN -----END PGP SIGNATURE----- From john at arbash-meinel.com Tue Aug 30 08:39:01 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 30 Aug 2011 10:39:01 +0200 Subject: Desolation (win32 build image) updates Message-ID: <4E5CA1A5.2090209@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to give a heads up about things done to desolation: 1) Applied all pending Windows patches (rebooted) 2) Updated Cython to 0.15 3) Installed 'meliae' so that memory debugging can be available 4) Applied IWATA's patch to bzr-windows-installers to update TortoiseBzr to 0.6.5. 5) Updated to bzr-svn 1.1.0 6) Downgraded Cython to 0.14.1. 0.15 introduces "no implicit initialization". Which means "cdef foo" no longer auto-initializes 'foo' to None, or 0 or NULL, etc. I'd like us to switch, but it gives a lot of warnings during compile time, and I don't want it to cause real problems before we do some patches to the code. I'm sure some of them are spurious, like this one in _bencode.pyx: cdef char *next_tail ... n = strtol(self.tail, &next_tail, 10) '&next_tail' is referenced before it is initialized, but strtol uses it as an 'out' and not an 'in'. I'll try to put some patches up that remove the warnings when compiling with Cython 0.15 so we can use it for newer releases. https://bugs.launchpad.net/bzr/+bug/837221 John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5coaUACgkQJdeBCYSNAAM/SACfTHiRtGP7tJzW6yEnAVbqxY9w 1bUAnR6Bw6WqzHZUzFuUCC+n203qbaMP =nt1w -----END PGP SIGNATURE----- From vila+bzr at canonical.com Tue Aug 30 11:23:00 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 30 Aug 2011 13:23:00 +0200 Subject: [ANN] bzr 2.4.0 released Message-ID: On behalf of the Bazaar team and community, I'm happy to announce availability of a new release of the bzr adaptive version control system. Bazaar is part of the GNU system to produce a free operating system. Thanks to everyone who contributed patches, suggestions, and feedback. Bazaar is now available for download from https://launchpad.net/bzr/2.4/2.4.0 as a source tarball. Installers are available for windows and OSX from the url above too. This release marks the start of another long-term-stable series. From here, we will only make bugfix releases on the 2.4 series (2.4.1, etc, and support it until February 2013), while 2.5 will become our new development series. This is a bugfix and polish release over the 2.3 series, with a large number of bugs fixed (>150 for the 2.4 series alone), and some performance improvements. Support for python 2.4 and 2.5 has been dropped, many large working tree operations have been optimized as well as some stacked branches operations. Users are encouraged to upgrade from the other stable series. See http://doc.bazaar.canonical.com/bzr.dev/en/whats-new/whats-new-in-2.4.html for more details, Vincent From aaron at aaronbentley.com Tue Aug 30 13:20:47 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 30 Aug 2011 09:20:47 -0400 Subject: bzr heads help In-Reply-To: <4E5C9377.5090200@arbash-meinel.com> References: <4E5C7364.5000607@gmail.com> <4E5C899B.2000209@ukr.net> <4E5C9377.5090200@arbash-meinel.com> Message-ID: <4E5CE3AF.3090504@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-08-30 03:38 AM, John Arbash Meinel wrote: > 'bzr merge && bzr revert' doesn't create a dead head, because 'merge' > doesn't create a node. It will add a node to your repository if you're merging a revision not present in your repository. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5c468ACgkQ0F+nu1YWqI2ciACfSKQDm0bEKd5rNm3J2/wV5pLI SjAAn31BbWb8XhUIwYyIo5C6GgaTiZpw =QLd3 -----END PGP SIGNATURE----- From davidkmuir at gmail.com Tue Aug 30 14:18:10 2011 From: davidkmuir at gmail.com (David Muir) Date: Wed, 31 Aug 2011 00:18:10 +1000 Subject: bzr heads help In-Reply-To: References: <4E5C7364.5000607@gmail.com> Message-ID: <4E5CF122.8040003@gmail.com> On 30/08/11 15:35, Martin Pool wrote: > On 30 August 2011 15:21, David Muir wrote: >> Two issues: >> >> 1. I noticed that running bzr heads --all on a relatively small >> repository (~1800 revs) takes quite a long time: >> >> $ bzr heads --all --debug-time >> get heads: 0.134533882141 >> make head marks: 79.3243851662 >> >> Fetching just the live heads takes just as long. >> Is it supposed to be that slow? > No, it's not supposed to be slow. Running it on bzr which has much > more history takes 19s: faster would be better, but this is > proportionally much faster. > > A good way to debug this, if you want to work on it, is to add > '--lsprof-file heads.callgrind' and then load that up in kcachegrind. > It looks to me like it spends a lot of time recursing to find the > possible branches under the repository and that might fairly easily be > improved by for example telling it not to look recursively inside > checkouts, or perhaps not to distinguish live and dead heads. That would explain it. I have about 50 or so branches that I think it's recursing through. Thanks, David From aaron at aaronbentley.com Tue Aug 30 14:25:14 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 30 Aug 2011 10:25:14 -0400 Subject: bzr heads help In-Reply-To: References: <4E5C7364.5000607@gmail.com> Message-ID: <4E5CF2CA.3040404@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-08-30 01:35 AM, Martin Pool wrote: > It looks to me like it spends a lot of time recursing to find the > possible branches under the repository and that might fairly easily be > improved by for example telling it not to look recursively inside > checkouts Telling it not to look recursively inside .bzr directories would miss branches created by bzr-colo and bzr-pipeline, and possibly others. I think we need to make it massively faster to fail to open a branch. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5c8soACgkQ0F+nu1YWqI19DACbBFlalVEuPelftoyl9rko35Nj KygAnRrLILFEfe623QihD1D9Xi1uWgPE =ta1F -----END PGP SIGNATURE----- From denys.duchier at univ-orleans.fr Tue Aug 30 14:55:34 2011 From: denys.duchier at univ-orleans.fr (Denys Duchier) Date: Tue, 30 Aug 2011 16:55:34 +0200 Subject: 2 patches for bzr.dev/cython.dev Message-ID: <87vctf7xuh.fsf@univ-orleans.fr> I am running bzr.dev and cython.dev. cython dev has version "0.15+" (notice the plus) which makes bzr's setup.py choke. here is a possible fix: ----8<-------------------------------------------------------------- === modified file 'setup.py' --- setup.py 2011-08-25 11:02:37 +0000 +++ setup.py 2011-08-30 14:44:42 +0000 @@ -202,7 +202,9 @@ from distutils.command.build_ext import build_ext else: have_pyrex = True - pyrex_version_info = tuple(map(int, pyrex_version.split('.'))) + import re + _version = re.match("^[0-9.]+", pyrex_version).group(0) + pyrex_version_info = tuple(map(int, _version.split('.'))) class build_ext_if_possible(build_ext): ----8<-------------------------------------------------------------- after that, "bzr status" bombs in the bzr.dev directory because of an uninitialized variable "changed". here is a possible fix: ----8<-------------------------------------------------------------- === modified file 'bzrlib/_dirstate_helpers_pyx.pyx' --- bzrlib/_dirstate_helpers_pyx.pyx 2011-04-22 14:12:22 +0000 +++ bzrlib/_dirstate_helpers_pyx.pyx 2011-08-30 14:43:05 +0000 @@ -1793,6 +1793,7 @@ advance_entry = -1 advance_path = -1 result = None + changed = None path_handled = 0 if current_entry is None: # unversioned - the check for path_handled when the path ----8<-------------------------------------------------------------- Cheers, --Denys From john at arbash-meinel.com Tue Aug 30 16:17:30 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 30 Aug 2011 18:17:30 +0200 Subject: 2 patches for bzr.dev/cython.dev In-Reply-To: <87vctf7xuh.fsf@univ-orleans.fr> References: <87vctf7xuh.fsf@univ-orleans.fr> Message-ID: <4E5D0D1A.20407@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/30/2011 4:55 PM, Denys Duchier wrote: > I am running bzr.dev and cython.dev. cython dev has version "0.15+" > (notice the plus) which makes bzr's setup.py choke. here is a > possible fix: I did just run into some warnings for cython 0.15, which I'm tracking in bug #837221.[1] I'm planning to switch to 0.15 when I can. I'm guessing there will be more fallout than just this. Specifically 0.15 changed stance from implicitly initializing variables to requiring it to be explicit. I'm hoping there won't be a lot of fallout vs maintaining Pyrex compatibility as well. If you can at least put your patches on the bugs, it will give us a better way of tracking it. Even better if you want to go as far as creating a branch and pushing it up as well. Thanks for the heads up, John =:-> [1] http://pad.lv/837221 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5dDRoACgkQJdeBCYSNAAOJyQCgp/k7LLAbDD6EV6Nq0yaF8Wu4 0doAn2Nj8FfNQy7fhhoxAhTPvYfYnqcV =3h6I -----END PGP SIGNATURE----- From denys.duchier at univ-orleans.fr Tue Aug 30 18:28:40 2011 From: denys.duchier at univ-orleans.fr (Denys Duchier) Date: Tue, 30 Aug 2011 20:28:40 +0200 Subject: 2 patches for bzr.dev/cython.dev In-Reply-To: <4E5D0D1A.20407@arbash-meinel.com> (John Arbash Meinel's message of "Tue, 30 Aug 2011 18:17:30 +0200") References: <87vctf7xuh.fsf@univ-orleans.fr> <4E5D0D1A.20407@arbash-meinel.com> Message-ID: <87hb4y92jr.fsf@univ-orleans.fr> John Arbash Meinel writes: > If you can at least put your patches on the bugs, it will give us a > better way of tracking it. Even better if you want to go as far as > creating a branch and pushing it up as well. done and linked to bug #837221. --Denys From davidkmuir at gmail.com Wed Aug 31 03:22:39 2011 From: davidkmuir at gmail.com (David Muir) Date: Wed, 31 Aug 2011 13:22:39 +1000 Subject: bzr heads help In-Reply-To: <4E5CF2CA.3040404@aaronbentley.com> References: <4E5C7364.5000607@gmail.com> <4E5CF2CA.3040404@aaronbentley.com> Message-ID: <4E5DA8FF.1090501@gmail.com> On 08/31/2011 12:25 AM, Aaron Bentley wrote: > On 11-08-30 01:35 AM, Martin Pool wrote: > > It looks to me like it spends a lot of time recursing to find the > > possible branches under the repository and that might fairly easily be > > improved by for example telling it not to look recursively inside > > checkouts > > Telling it not to look recursively inside .bzr directories would miss > branches created by bzr-colo and bzr-pipeline, and possibly others. I > think we need to make it massively faster to fail to open a branch. > > Aaron I got a cachegrind dump, but didn't have much time to look at it. I'll have another look later tonight. From what I remember, there was a big chunk taken up by posix something-or-other. David From john at arbash-meinel.com Wed Aug 31 16:25:37 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Wed, 31 Aug 2011 18:25:37 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: <4E57A878.3010206@arbash-meinel.com> References: <4E57A878.3010206@arbash-meinel.com> Message-ID: <4E5E6081.8050001@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/26/2011 04:06 PM, John Arbash Meinel wrote: > I've been feeling the pain of how slow our test suite has been lately, > and I figured I'd poke around a bit if I could. > I have a test suite run with timings for both a 2.3 branch and a 2.4 branch with fdatasync disabled (and one with it enabled). However, the 2.3 run took surprisingly longer than 2.4. I wrote a script to make it easier to compare the individual test runs by lining them up and comparing the run time. And every so often I see just a huge spike in the 2.3 time. For example: ...TestLogEncodings.test_stdout_encoding 237 > 155 ...TestLogErrors.test_log_bad_message_re 143 > 74 ...TestLogErrors.test_log_change_incompatible_with_revision 32 > 7 ...TestLogErrors.test_log_change_nonexistent_dotted_revno 147 > 71 ...TestLogErrors.test_log_change_nonexistent_revno 143 > 71 ...TestLogErrors.test_log_change_single_revno_only 118 > 65 ...TestLogErrors.test_log_exclude_ancestry_no_range 249 > 142 ...TestLogErrors.test_log_exclude_ancestry_single_revision 1363 > 344 ...TestLogErrors.test_log_nonexistent_dotted_revno 191 > 74 ...TestLogErrors.test_log_nonexistent_file 208 > 76 ...TestLogErrors.test_log_nonexistent_revno 193 > 69 ...TestLogErrors.test_log_reversed_dotted_revspecs 1159 > 351 ...TestLogErrors.test_log_reversed_revspecs 389 > 171 ...TestLogErrors.test_log_unsupported_timezone 283 > 206 ...TestLogErrors.test_log_zero_begin_revspec 297 > 217 ...TestLogErrors.test_log_zero_end_revspec 274 > 203 ...TestLogErrors.test_log_zero_revspec 162 > 70 ...TestLogExcludeCommonAncestry.test_exclude_common_ancestry_ 301 > 145 ...TestLogFile.test_log_file1 752 > 348 ...TestLogFile.test_log_file2 1142 > 434 ...TestLogFile.test_log_file3 722 > 337 ...TestLogFile.test_log_file_historical_end 865 > 459 ...TestLogFile.test_log_file_historical_missing 830 > 473 ...TestLogFile.test_log_file_historical_start 856 < 939 ...TestLogFile.test_log_file_renamed 1282 > 1026 Just a test that suddenly runs in >1s where everything else is sub second. I have another test run with fdatasync on, and things look quite a bit worse. But the fact that every-so-often we get a big spike in the run time seems odd. But it might be because there are other processes running? (I think Martin mentioned the machine is shared with U1). John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5eYIEACgkQJdeBCYSNAANb2ACgglTjl/5EoFQPqKqHfTp3Jied /BYAn2uDZQ3SUGtXAdMA3TjbHeNCZGwr =Iv3E -----END PGP SIGNATURE----- From gzlist at googlemail.com Thu Sep 1 14:03:30 2011 From: gzlist at googlemail.com (Martin (gzlist)) Date: Thu, 1 Sep 2011 15:03:30 +0100 Subject: Notes on fdatasync for the test suite In-Reply-To: <4E5E6081.8050001@arbash-meinel.com> References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: I'm wondering if memory pressure might also be a factor to the increasing run time? Do we have any numbers on the max resource usage of the run vs what the box has available? On 31/08/2011, John Arbash Meinel wrote: > > But the fact that every-so-often we get a big spike in the run time > seems odd. But it might be because there are other processes running? (I > think Martin mentioned the machine is shared with U1). Seemingly random big spikes sounds normal for fsync to me, as the work required depends on all pending i/o not just file in question. Martin From john at arbash-meinel.com Thu Sep 1 18:39:06 2011 From: john at arbash-meinel.com (John Meinel) Date: Thu, 1 Sep 2011 20:39:06 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: Those spikes were on 2.3 which doesn't have fsync. John =:-> On Sep 1, 2011 4:03 PM, "Martin (gzlist)" wrote: > I'm wondering if memory pressure might also be a factor to the > increasing run time? Do we have any numbers on the max resource usage > of the run vs what the box has available? > > On 31/08/2011, John Arbash Meinel wrote: >> >> But the fact that every-so-often we get a big spike in the run time >> seems odd. But it might be because there are other processes running? (I >> think Martin mentioned the machine is shared with U1). > > Seemingly random big spikes sounds normal for fsync to me, as the work > required depends on all pending i/o not just file in question. > > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vila+bzr at canonical.com Fri Sep 2 08:24:16 2011 From: vila+bzr at canonical.com (vila) Date: Fri, 02 Sep 2011 10:24:16 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: <4E5E6081.8050001@arbash-meinel.com> (John Arbash Meinel's message of "Wed, 31 Aug 2011 18:25:37 +0200") References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: >>>>> John Arbash Meinel writes: > On 08/26/2011 04:06 PM, John Arbash Meinel wrote: >> I've been feeling the pain of how slow our test suite has been lately, >> and I figured I'd poke around a bit if I could. >> > I have a test suite run with timings for both a 2.3 branch and a 2.4 > branch with fdatasync disabled (and one with it enabled). Some more data points from that 'make check timings' patch landed on bzr.dev *only* at revno 6120. This patch output time UTC stamps before and after running selftest and nothing else. pqm creates a patch..log file for every submission. These files are mirrored at chinstrap:/srv/bzr-pqm-logs/. The stamp itself is probably created when the submission is *received* rather than started and in an unknown time zone (I'm guessing here but from the lines below it's obvious that it's not UTC and it's not when the job start). Each line mentions: - the file stamp (unknown TZ), - no duration for submissions that either failed or didn't output time stamps (could be submissions against branches other than trunk), - the duration of selftest (i.e. excluding extension compilation and doc generation), - the start time of selftest (UTC) - the end time of selftest (UTC) $ for p in patch.1314[89]*.log ; do pqm-time.py $p ; done 2011-09-01 02:25:12: duration: 2011-09-01 02:25:17: duration: 2011-09-01 02:25:23: duration: 2011-09-01 07:07:47: duration: 2:06:56 start: 2011-09-01 10:57:30, end: 2011-09-01 13:04:26 2011-09-01 11:03:19: duration: 2:09:02 start: 2011-09-01 13:07:19, end: 2011-09-01 15:16:21 2011-09-01 13:03:31: duration: 2:53:02 start: 2011-09-01 15:18:26, end: 2011-09-01 18:11:28 2011-09-01 13:03:34: duration: 2:07:47 start: 2011-09-01 18:13:16, end: 2011-09-01 20:21:03 2011-09-01 18:26:41: duration: 2011-09-01 20:04:31: duration: 2011-09-01 22:36:40: duration: 2:04:57 start: 2011-09-01 21:10:23, end: 2011-09-01 23:15:20 The last line is weird as the time stamp appears to be *after* the selftest start (22h36 >> 21:10) and I have no good guess here. I'd be inclined to guess for UTC+2 (so 22h36 UTC+2 == 20h36 UTC) but that would mean that even for that last submission, it took ~45 minutes to do whatever is needed before starting the 'make check', compile extensions and generate the doc ? A bit too much... Anyone knows how/when the file time stamp is created and in which TZ ? Vincent From mbp at canonical.com Fri Sep 2 08:57:08 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 2 Sep 2011 18:57:08 +1000 Subject: Notes on fdatasync for the test suite In-Reply-To: References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: > The last line is weird as the time stamp appears to be *after* the > selftest start (22h36 >> 21:10) and I have no good guess here. I'd be > inclined to guess for UTC+2 (so 22h36 UTC+2 == 20h36 UTC) but that would > mean that even for that last submission, it took ~45 minutes to do > whatever is needed before starting the 'make check', compile extensions > and generate the doc ? A bit too much... > > Anyone knows how/when the file time stamp is created and in which TZ ? file times will normally be updated every time data is written to them (so, the last time anything was written) and they're stored in utc and displayed as whatever tz you ask for. It's possible but probably unlikely a machine's clock is set wrong. m From vila+bzr at canonical.com Fri Sep 2 09:28:11 2011 From: vila+bzr at canonical.com (vila) Date: Fri, 02 Sep 2011 11:28:11 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: (Martin Pool's message of "Fri, 2 Sep 2011 18:57:08 +1000") References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: >>>>> Martin Pool writes: >> The last line is weird as the time stamp appears to be *after* the >> selftest start (22h36 >> 21:10) and I have no good guess here. I'd be >> inclined to guess for UTC+2 (so 22h36 UTC+2 == 20h36 UTC) but that would >> mean that even for that last submission, it took ~45 minutes to do >> whatever is needed before starting the 'make check', compile extensions >> and generate the doc ? A bit too much... >> >> Anyone knows how/when the file time stamp is created and in which TZ ? > file times will normally be updated every time data is written to them > (so, the last time anything was written) and they're stored in utc and > displayed as whatever tz you ask for. It's possible but probably > unlikely a machine's clock is set wrong. I'm not talking about the file modification or creation times but about the stamp that is embedded in the file *name*. As such I suspect it's the current time when the file is created or even when the submission is received (but with a resolution of 1 second, I except it's taken at a place where the processing will take more than one second). I.e.: -rw-r--r-- 1 vila vila 2932 2011-09-02 01:15 patch.1314909400.log patch.1314909400.log ==> 2011-09-01 22:36:40 2011-09-01 22:36:40: duration: 2:04:57 start: 2011-09-01 21:10:23, end: 2011-09-01 23:15:20 so the modification time roughly matches the end time but the origin of the stamp in the name is unclear. No big deal, just surprising and not worth investigating for now (I asked in case people already knows). Vincent From vila+bzr at canonical.com Fri Sep 2 10:33:57 2011 From: vila+bzr at canonical.com (vila) Date: Fri, 02 Sep 2011 12:33:57 +0200 Subject: [ANN] 2.2.5 has gone gold Message-ID: Time for a new SRU in the 2.2 series ! One regression introduced in 2.2b1 has been fixed for some rare conflict resolutions. Also a warning is now emitted when branching an out-of-date ubuntu packaging branch. Upgrading is recommended for all users on earlier 2.2 releases. Since we released 2.4.0 as our new stable release, only the packagers still maintaining a stable 2.2 series are concerned (for Ubuntu that means maverick for which the SRU process should start soon http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates). The tarball has been uploaded at: https://launchpad.net/bzr/+milestone/2.2.5 and the release will be announced next Tuesday. Note that the landing on lp:bzr/2.2 is still queued and would occur later today (so that bzr-2.2.5 tag won't exist until then) but I've ran the test suite locally before submission. Vincent From lists08-bzr at davor.org Fri Sep 2 13:12:39 2011 From: lists08-bzr at davor.org (Eric Siegerman) Date: Fri, 02 Sep 2011 09:12:39 -0400 Subject: Notes on fdatasync for the test suite In-Reply-To: References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> Message-ID: <1314969159.25871.6.camel@claves> On Fri, 2011-09-02 at 11:28 +0200, vila wrote: > patch.1314909400.log ==> 2011-09-01 22:36:40 That looks like a UNIX time_t; if so, it's in UTC, which would give a time of: Thu Sep 1 20:36:40 2011 which is plausible, given: start: 2011-09-01 21:10:23 That makes the other lines somewhat less plausible -- it means the delay from timestamp creation till "start:" is two hours longer than you've shown. But could it be that PQM was just really backed up at the time? - Eric (whose current contract is in a Mercurial shop, which is why I've pretty much vanished from this list...) From john at arbash-meinel.com Fri Sep 2 13:45:44 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 02 Sep 2011 15:45:44 +0200 Subject: Setting up Tarmac Message-ID: <4E60DE08.30902@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So I played around with a dummy Tarmac installation on Canonistack. I set it up to merge proposals for a dummy branch of Meliae. It didn't seem particularly hard to set up. There are a couple of rough edges, but overall I think it works pretty well. It is nice that it puts the failure results back on the Launchpad page. Though with our "failures generate the entire success + failure log to stdout/stderr" that may be a bit much to put on a Launchpad post. You can sort of see what I mean here: https://code.launchpad.net/~jameinel/meliae/bad_test/+merge/73807 So I don't think it is ready to be a replacement for PQM just yet. We'll have to change how bzr generates its failure logs first. (By default tarmac just reads all of stderr and prints it out.) Also, Tarmac doesn't have the visibility of the current run that PQM has. At least as near as I can tell, there isn't a web UI that would let you see how many patches are in the queue and when your patch is going to get merged, etc. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5g3ggACgkQJdeBCYSNAAOHbQCcC6Q8rJUW2MaaI9OoqFkSl+pi 7d0AoJfMI+IKOv7BCRaExv1b/PgGxh4P =79lD -----END PGP SIGNATURE----- From vila+bzr at canonical.com Fri Sep 2 14:26:44 2011 From: vila+bzr at canonical.com (vila) Date: Fri, 02 Sep 2011 16:26:44 +0200 Subject: Notes on fdatasync for the test suite In-Reply-To: <1314969159.25871.6.camel@claves> (Eric Siegerman's message of "Fri, 02 Sep 2011 09:12:39 -0400") References: <4E57A878.3010206@arbash-meinel.com> <4E5E6081.8050001@arbash-meinel.com> <1314969159.25871.6.camel@claves> Message-ID: Thanks ! >>>>> Eric Siegerman writes: > On Fri, 2011-09-02 at 11:28 +0200, vila wrote: >> patch.1314909400.log ==> 2011-09-01 22:36:40 > That looks like a UNIX time_t; if so, it's in UTC, That was my understanding. > which would give a time of: Thu Sep 1 20:36:40 2011 And this was enough to made me realize the bug in my script (I used datetime.fromtimestamp instead of datetime.utcfromtimestamp), doh ! > which is plausible, given: start: 2011-09-01 21:10:23 So, with all dates/times now in UTC: $ for p in patch.1314[89]*.log ; do pqm-time.py $p ; done 2011-09-01 00:25:12: duration: 2011-09-01 00:25:17: duration: 2011-09-01 00:25:23: duration: 2011-09-01 05:07:47: duration: 2:06:56 start: 2011-09-01 10:57:30, end: 2011-09-01 13:04:26 2011-09-01 09:03:19: duration: 2:09:02 start: 2011-09-01 13:07:19, end: 2011-09-01 15:16:21 2011-09-01 11:03:31: duration: 2:53:02 start: 2011-09-01 15:18:26, end: 2011-09-01 18:11:28 2011-09-01 11:03:34: duration: 2:07:47 start: 2011-09-01 18:13:16, end: 2011-09-01 20:21:03 2011-09-01 16:26:41: duration: 2011-09-01 18:04:31: duration: 2011-09-01 20:36:40: duration: 2:04:57 start: 2011-09-01 21:10:23, end: 2011-09-01 23:15:20 2011-09-02 06:23:20: duration: 2:07:42 start: 2011-09-02 06:27:01, end: 2011-09-02 08:34:43 2011-09-02 07:39:42: duration: 2:03:18 start: 2011-09-02 08:37:33, end: 2011-09-02 10:40:51 2011-09-02 07:39:54: duration: 2:03:05 start: 2011-09-02 10:42:26, end: 2011-09-02 12:45:31 And all lines now make sense ! And with the collected data so far, we're at 2h/patch with one spike at ~3h for selftest only. > - Eric (whose current contract is in a Mercurial shop, which is > why I've pretty much vanished from this list...) Too bad, come back quickly ;) Vincent From eliz at gnu.org Sun Sep 4 05:52:50 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 04 Sep 2011 01:52:50 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr Message-ID: See https://bugs.launchpad.net/bzr-git/+bug/839483 for the background. It turns out that there's no documented way of installing Dulwich with C extensions on MS-Windows where bzr was installed with the stand-alone installer. I understand that without these extensions bzr-git performance "sucks". Is it possible to have instructions for doing that manually? I'm guessing that doing so would involve compiling the *.c files that come with Dulwich into some kind of a DLL, is that right? Can that be done with MinGW GCC (as opposed to MSVC)? Can someone please show the command line for invoking the compiler, and instructions for where to put the DLL? If manual compilation is impossible, or if only MSVC is supported for that, would it be possible to have this DLL available somewhere, if not bundled with the stand-alone installer? TIA From eliz at gnu.org Sun Sep 4 05:59:44 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 04 Sep 2011 01:59:44 -0400 Subject: Address resolution problem with bzr-git Message-ID: This strange problem happens only on one machine out of 3 I tried. The other work with this repository with no connectivity problems. D:\usr\eli\bzr>bzr branch http://git.gnus.org/gnus.git bzr: ERROR: Connection error: Couldn't resolve host 'git.gnus.org' [Errno 11001] getaddrinfo failed I thought that some firewall somewhere blocks something, but another machine on the same network doesn't have this problem. Restarting didn't help, either. Strangely, .bzr.log seems to indicate that bzr invoked the svn plugin, see below. A Web browser has no problems getting to this address on the same machine which shows this error. What can I do to debug and solve this problem? TIA 7.156 Traceback (most recent call last): File "bzrlib\commands.pyo", line 946, in exception_to_return_code File "bzrlib\commands.pyo", line 1150, in run_bzr File "bzrlib\commands.pyo", line 699, in run_argv_aliases File "bzrlib\commands.pyo", line 721, in run File "bzrlib\cleanup.pyo", line 135, in run_simple File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups File "bzrlib\builtins.pyo", line 1263, in run File "bzrlib\bzrdir.pyo", line 918, in open_tree_or_branch File "bzrlib\bzrdir.pyo", line 828, in open File "bzrlib\bzrdir.pyo", line 858, in open_from_transport File "bzrlib\lazy_import.pyo", line 129, in __call__ File "bzrlib\transport\__init__.pyo", line 1690, in do_catching_redirections File "bzrlib\bzrdir.pyo", line 845, in find_format File "bzrlib\controldir.pyo", line 749, in find_format File "C:/Program Files/Bazaar/plugins\svn\__init__.py", line 259, in probe_transport File "C:/Program Files/Bazaar/plugins\svn\__init__.py", line 182, in dav_options File "bzrlib\transport\http\_urllib.pyo", line 79, in _perform File "urllib2.pyo", line 391, in open File "urllib2.pyo", line 409, in _open File "urllib2.pyo", line 369, in _call_chain File "bzrlib\transport\http\_urllib2_wrappers.pyo", line 722, in http_open File "bzrlib\transport\http\_urllib2_wrappers.pyo", line 666, in do_open File "bzrlib\transport\http\_urllib2_wrappers.pyo", line 561, in retry_or_raise ConnectionError: Connection error: Couldn't resolve host 'git.gnus.org' [Errno 11001] getaddrinfo failed From john at arbash-meinel.com Sun Sep 4 08:33:03 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Sun, 04 Sep 2011 10:33:03 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: Message-ID: <4E6337BF.7090309@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/4/2011 7:52 AM, Eli Zaretskii wrote: > See https://bugs.launchpad.net/bzr-git/+bug/839483 for the > background. > > It turns out that there's no documented way of installing Dulwich > with C extensions on MS-Windows where bzr was installed with the > stand-alone installer. I understand that without these extensions > bzr-git performance "sucks". > > Is it possible to have instructions for doing that manually? I'm > guessing that doing so would involve compiling the *.c files that > come with Dulwich into some kind of a DLL, is that right? Can that > be done with MinGW GCC (as opposed to MSVC)? Can someone please > show the command line for invoking the compiler, and instructions > for where to put the DLL? > > If manual compilation is impossible, or if only MSVC is supported > for that, would it be possible to have this DLL available > somewhere, if not bundled with the stand-alone installer? > > TIA > In newer versions of bzr (I think in 2.4+), IIRC we support putting files in a 'site-packages' directory. Which will be part of the python search path. I don't know if it will need to be "site-packages/*.pyd" or "site-packages/dulwich/*.pyd" (I'm guessing the latter). But you should be able to install any plugins/modules/dependency code into there and have Bazaar find it. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5jN78ACgkQJdeBCYSNAAOrhgCgld6MNxcz1jBm6Y3S8oavQY8M /cMAniRLy4Td6AnFJSK4hLYj0oAbJsG7 =ijg4 -----END PGP SIGNATURE----- From eliz at gnu.org Sun Sep 4 08:54:57 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 04 Sep 2011 04:54:57 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6337BF.7090309@arbash-meinel.com> (message from John Arbash Meinel on Sun, 04 Sep 2011 10:33:03 +0200) References: <4E6337BF.7090309@arbash-meinel.com> Message-ID: > Date: Sun, 04 Sep 2011 10:33:03 +0200 > From: John Arbash Meinel > CC: bazaar at lists.canonical.com > > In newer versions of bzr (I think in 2.4+), IIRC we support putting > files in a 'site-packages' directory. Which will be part of the python > search path. Yes, I'm using 2.4.0, and this feature is supported there. > I don't know if it will need to be "site-packages/*.pyd" or > "site-packages/dulwich/*.pyd" (I'm guessing the latter). But you > should be able to install any plugins/modules/dependency code into > there and have Bazaar find it. Thanks. But how do I produce the *.pyd files? There are none in the dulwich tarball. TIA From jelmer at samba.org Sun Sep 4 15:25:43 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sun, 04 Sep 2011 17:25:43 +0200 Subject: Address resolution problem with bzr-git In-Reply-To: References: Message-ID: <4E639877.30808@samba.org> On 09/04/2011 07:59 AM, Eli Zaretskii wrote: > This strange problem happens only on one machine out of 3 I tried. > The other work with this repository with no connectivity problems. > > D:\usr\eli\bzr>bzr branch http://git.gnus.org/gnus.git > bzr: ERROR: Connection error: Couldn't resolve host 'git.gnus.org' [Errno 11001] getaddrinfo failed > > I thought that some firewall somewhere blocks something, but another > machine on the same network doesn't have this problem. Restarting > didn't help, either. > > Strangely, .bzr.log seems to indicate that bzr invoked the svn plugin, > see below. > The various plugins all check to see whether a location that was specified on the command-line contains a format they support. They all do this using the regular bzr infrastructure for http though - "bzr --no-plugins http://git.gnus.org/gnus.git" should give you the same error. Cheers, Jelmer From gzlist at googlemail.com Sun Sep 4 15:41:17 2011 From: gzlist at googlemail.com (Martin (gzlist)) Date: Sun, 4 Sep 2011 16:41:17 +0100 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <4E6337BF.7090309@arbash-meinel.com> Message-ID: On 04/09/2011, Eli Zaretskii wrote: > > Thanks. But how do I produce the *.pyd files? There are none in the > dulwich tarball. This works* for me: bzr branch lp:dulwich cd dulwich setup.py install_lib -d \path\to\site-packages You'll need the right version of msvc for your python version as per usual when dealing with python extensions that need a C compiler. Martin *Actually, it doesn't quite, but does when I use a Python built using vc9 which supplies strnlen unlike the older C runtime. From jelmer at samba.org Sun Sep 4 15:59:35 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sun, 04 Sep 2011 17:59:35 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <4E6337BF.7090309@arbash-meinel.com> Message-ID: <4E63A067.90308@samba.org> On 09/04/2011 05:41 PM, Martin (gzlist) wrote: > On 04/09/2011, Eli Zaretskii wrote: >> Thanks. But how do I produce the *.pyd files? There are none in the >> dulwich tarball. > This works* for me: > > bzr branch lp:dulwich > cd dulwich > setup.py install_lib -d \path\to\site-packages > > You'll need the right version of msvc for your python version as per > usual when dealing with python extensions that need a C compiler. > > Martin > > > *Actually, it doesn't quite, but does when I use a Python built using > vc9 which supplies strnlen unlike the older C runtime. This requires a python interpreter which Eli doesn't have available - as far as I understand it's not included with the standalone windows installer. Cheers, Jelmer From jelmer at samba.org Sun Sep 4 15:59:56 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sun, 04 Sep 2011 17:59:56 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <4E6337BF.7090309@arbash-meinel.com> Message-ID: <4E63A07C.4050405@samba.org> On 09/04/2011 05:41 PM, Martin (gzlist) wrote: > On 04/09/2011, Eli Zaretskii wrote: >> Thanks. But how do I produce the *.pyd files? There are none in the >> dulwich tarball. > This works* for me: > > bzr branch lp:dulwich > cd dulwich > setup.py install_lib -d \path\to\site-packages > > You'll need the right version of msvc for your python version as per > usual when dealing with python extensions that need a C compiler. > > Martin > > > *Actually, it doesn't quite, but does when I use a Python built using > vc9 which supplies strnlen unlike the older C runtime. This requires a python interpreter which Eli doesn't have available - as far as I understand it's not included with the standalone windows installer. Cheers, Jelmer From gzlist at googlemail.com Sun Sep 4 16:19:46 2011 From: gzlist at googlemail.com (Martin (gzlist)) Date: Sun, 4 Sep 2011 17:19:46 +0100 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E63A067.90308@samba.org> References: <4E6337BF.7090309@arbash-meinel.com> <4E63A067.90308@samba.org> Message-ID: On 04/09/2011, Jelmer Vernooij wrote: > This requires a python interpreter which Eli doesn't have available - as > far as I understand it's not included with the standalone windows installer. Another machine with the same major version (and 32bit) Python interpreter should do. It would certainly be more convenient to ship binaries, but I'm not sure what kind of packaging would make sense. Generally, people who want to customise their Bazaar installation are better off installing Python first then adding Bazaar and whatever plugins they want, rather than using the all-in-one installer. Martin From eliz at gnu.org Sun Sep 4 16:20:44 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 04 Sep 2011 19:20:44 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E63A067.90308@samba.org> References: <4E6337BF.7090309@arbash-meinel.com> <4E63A067.90308@samba.org> Message-ID: <83liu4z3c3.fsf@gnu.org> > Date: Sun, 04 Sep 2011 17:59:35 +0200 > From: Jelmer Vernooij > > On 09/04/2011 05:41 PM, Martin (gzlist) wrote: > > On 04/09/2011, Eli Zaretskii wrote: > >> Thanks. But how do I produce the *.pyd files? There are none in the > >> dulwich tarball. > > This works* for me: > > > > bzr branch lp:dulwich > > cd dulwich > > setup.py install_lib -d \path\to\site-packages > > > > You'll need the right version of msvc for your python version as per > > usual when dealing with python extensions that need a C compiler. > > > > Martin > > > > > > *Actually, it doesn't quite, but does when I use a Python built using > > vc9 which supplies strnlen unlike the older C runtime. > This requires a python interpreter which Eli doesn't have available Not only that, the fact that I need MSVC is in itself a problem: it's a proprietary tool. I use MinGW GCC. (I'm surprised MSVC is used to build binaries of a GNU project.) It would be swell if someone could make these *.pyd available somewhere. In the long run, I think they need either to come with dulwich or be included in the stand-alone installer. From jelmer at samba.org Sun Sep 4 16:39:22 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Sun, 04 Sep 2011 18:39:22 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83liu4z3c3.fsf@gnu.org> References: <4E6337BF.7090309@arbash-meinel.com> <4E63A067.90308@samba.org> <83liu4z3c3.fsf@gnu.org> Message-ID: <4E63A9BA.4020004@samba.org> On 09/04/2011 06:20 PM, Eli Zaretskii wrote: >> Date: Sun, 04 Sep 2011 17:59:35 +0200 >> From: Jelmer Vernooij >> >> On 09/04/2011 05:41 PM, Martin (gzlist) wrote: >>> On 04/09/2011, Eli Zaretskii wrote: >>>> Thanks. But how do I produce the *.pyd files? There are none in the >>>> dulwich tarball. >>> This works* for me: >>> >>> bzr branch lp:dulwich >>> cd dulwich >>> setup.py install_lib -d \path\to\site-packages >>> >>> You'll need the right version of msvc for your python version as per >>> usual when dealing with python extensions that need a C compiler. >>> >>> Martin >>> >>> >>> *Actually, it doesn't quite, but does when I use a Python built using >>> vc9 which supplies strnlen unlike the older C runtime. >> This requires a python interpreter which Eli doesn't have available > Not only that, the fact that I need MSVC is in itself a problem: it's > a proprietary tool. I use MinGW GCC. (I'm surprised MSVC is used to > build binaries of a GNU project.) > > It would be swell if someone could make these *.pyd available > somewhere. > > In the long run, I think they need either to come with dulwich or be > included in the stand-alone installer. I don't think bundling them with Dulwich is a good idea, that way people who want to bzr-git still have to muck about trying to install individual libraries and plugins. It would be ideal if dulwich/bzr-git could be included in the windows installer, but I'm not sure how much extra maintainance burden that adds to whoever does the installers. Cheers, Jelmer From gzlist at googlemail.com Sun Sep 4 16:41:04 2011 From: gzlist at googlemail.com (Martin (gzlist)) Date: Sun, 4 Sep 2011 17:41:04 +0100 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83liu4z3c3.fsf@gnu.org> References: <4E6337BF.7090309@arbash-meinel.com> <4E63A067.90308@samba.org> <83liu4z3c3.fsf@gnu.org> Message-ID: On 04/09/2011, Eli Zaretskii wrote: > > Not only that, the fact that I need MSVC is in itself a problem: it's > a proprietary tool. I use MinGW GCC. (I'm surprised MSVC is used to > build binaries of a GNU project.) Python isn't a GNU project, and dulwich just uses the distutils like everything else does. It's possible to build Python extensions with other compilers, I was just trying to give you the shortest instructions to solve your problem. Feel free read the documentation on using mingw instead. Martin From eliz at gnu.org Sun Sep 4 17:00:35 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 04 Sep 2011 20:00:35 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <4E6337BF.7090309@arbash-meinel.com> <4E63A067.90308@samba.org> <83liu4z3c3.fsf@gnu.org> Message-ID: <83ehzwz1ho.fsf@gnu.org> > Date: Sun, 4 Sep 2011 17:41:04 +0100 > From: "Martin (gzlist)" > Cc: Jelmer Vernooij , bazaar at lists.canonical.com > > Feel free read the documentation on using mingw instead. Thanks, but someone said in this thread it must be the same compiler that is used to produce the stand-alone installer. That's why I said "GNU project": I meant Bazaar, not Python. If I don't have to use the same compiler that was used to prepare the installer, then it's another story, and I will investigate. But I'd hate to waste my time just to learn that it really must be MSVC. Thanks. From mbp at canonical.com Mon Sep 5 02:34:43 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 5 Sep 2011 12:34:43 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: Message-ID: On 4 September 2011 15:52, Eli Zaretskii wrote: > See https://bugs.launchpad.net/bzr-git/+bug/839483 for the background. Tangentially to this, I learned recently about , which is builtin in python3.3 but also available separately for 2.x. We could possibly ship it in the Windows pre-built installers to get better tracebacks in this sort of case. (I'm not totally sure it would have handled this particular error but I think so.) > It turns out that there's no documented way of installing Dulwich with > C extensions on MS-Windows where bzr was installed with the > stand-alone installer. In general it seems like the standalone installer just tends to be very self-contained - there are other bugs about the difficulties of getting it to run other modules. Perhaps we could just bundle bzr-git and dulwich in the installers? > Not only that, the fact that I need MSVC is in itself a problem: it's > a proprietary tool. I use MinGW GCC. (I'm surprised MSVC is used to > build binaries of a GNU project.) I think the short story is that Python on Windows strongly prefers msvc so we build with that too. It is certainly not desirable either theoretically or practically but it seems the best tradeoff given we're supporting a proprietary platform in the first place. m From eliz at gnu.org Mon Sep 5 02:53:47 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 05 Sep 2011 05:53:47 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: Message-ID: <838vq3zolg.fsf@gnu.org> > From: Martin Pool > Date: Mon, 5 Sep 2011 12:34:43 +1000 > Cc: bazaar at lists.canonical.com > > On 4 September 2011 15:52, Eli Zaretskii wrote: > > See https://bugs.launchpad.net/bzr-git/+bug/839483 for the background. > > Tangentially to this, I learned recently about > , which is builtin in > python3.3 but also available separately for 2.x. We could possibly > ship it in the Windows pre-built installers to get better tracebacks > in this sort of case. (I'm not totally sure it would have handled > this particular error but I think so.) Sounds like a good idea. > Perhaps we could just bundle bzr-git and dulwich in the installers? I'd certainly welcome that. > I think the short story is that Python on Windows strongly prefers > msvc so we build with that too. It is certainly not desirable either > theoretically or practically but it seems the best tradeoff given > we're supporting a proprietary platform in the first place. If there's a chance building the dulwich *.pyd files with MinGW could succeed nonetheless, I'd like to explore that possibility. From stephen at xemacs.org Mon Sep 5 04:05:05 2011 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Mon, 05 Sep 2011 13:05:05 +0900 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <838vq3zolg.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> Message-ID: <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> Eli Zaretskii writes: > If there's a chance building the dulwich *.pyd files with MinGW could > succeed nonetheless, I'd like to explore that possibility. This is a question which would best be explored on python-list aka comp.lang.python. I don't recall any traffic on python-devel regarding building Python with non-MS toolchains, except for the occasional statement that it's possible (maybe even supported in some sense). The PSF and Active State Python installers are built with MS tools, and I would guess that the great majority of Windows installs are one of those two. It would be asking for trouble for Python-based projects to distribute extension binaries built with third-party toolchains. I suppose there are very few Python-based projects that do so, in or out of GNU. So your best bet is FS advocates who also use Python a lot, and c.l.py is most likely where you'll find them. HTH From eliz at gnu.org Mon Sep 5 05:40:35 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 05 Sep 2011 01:40:35 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: > From: "Stephen J. Turnbull" > Cc: Martin Pool , > bazaar at lists.canonical.com > Date: Mon, 05 Sep 2011 13:05:05 +0900 > > I don't recall any traffic on python-devel regarding building Python > with non-MS toolchains, except for the occasional statement that it's > possible (maybe even supported in some sense). The PSF and Active > State Python installers are built with MS tools, and I would guess > that the great majority of Windows installs are one of those two. It > would be asking for trouble for Python-based projects to distribute > extension binaries built with third-party toolchains. I suppose there > are very few Python-based projects that do so, in or out of GNU. > > So your best bet is FS advocates who also use Python a lot, and c.l.py > is most likely where you'll find them. HTH Thanks. There are a few pages floating around that explain how to use MinGW, but they all describe how to tweak distutils to invoke MinGW rather than MSVC. That requires to have Python installed, so this is not what I'm looking for. This comes the closest to what I need: http://docs.python.org/extending/windows.html#using-dlls-in-practice although it uses MSVC. But "translation" to MinGW is simple. The example indicates that the Python include directory and import library are needed, even for such manual techniques... So it looks like having such extension as part of the standalone installer is the only practical way that doesn't require a Python installation. From septagramm at gmail.com Mon Sep 5 06:03:18 2011 From: septagramm at gmail.com (Igor Novikov) Date: Mon, 05 Sep 2011 14:03:18 +0800 Subject: authentication.conf not working Message-ID: <4E646626.1020105@gmail.com> I have set up a little bzr+ssh repository on my home server. But I can't get bazaar to remember my login and password. Here's my ~/.bazaar/authentication.conf: [StreetCleaner] scheme=bzr+ssh host=192.168.0.2 user=bzr_septi password='well_its_here_but_its_irrelevant' But when I do: $ bzr checkout bzr+ssh://bzr_septi at 192.168.0.2//StreetCleaner I'm being still asked for a password. What am I doing wrong? From philip.peitsch at gmail.com Mon Sep 5 06:06:41 2011 From: philip.peitsch at gmail.com (Philip Peitsch) Date: Mon, 5 Sep 2011 16:06:41 +1000 Subject: authentication.conf not working In-Reply-To: <4E646626.1020105@gmail.com> References: <4E646626.1020105@gmail.com> Message-ID: Have you tried the scheme as just ssh rather than bzr+ssh? On Mon, Sep 5, 2011 at 4:03 PM, Igor Novikov wrote: > I have set up a little bzr+ssh repository on my home server. But I can't > get bazaar to remember my login and password. Here's my > ~/.bazaar/authentication.conf: > > [StreetCleaner] > scheme=bzr+ssh > host=192.168.0.2 > user=bzr_septi > password='well_its_here_but_**its_irrelevant' > > But when I do: > > $ bzr checkout bzr+ssh://bzr_septi at 192.168.0.**2//StreetCleaner > > I'm being still asked for a password. What am I doing wrong? > > -- Philip Peitsch Mob: 0439 810 260 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Sep 5 07:25:49 2011 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 05 Sep 2011 09:25:49 +0200 Subject: authentication.conf not working In-Reply-To: <4E646626.1020105@gmail.com> References: <4E646626.1020105@gmail.com> Message-ID: <4E64797D.1050309@canonical.com> W dniu 05.09.2011 08:03, Igor Novikov pisze: > I have set up a little bzr+ssh repository on my home server. But I can't > get bazaar to remember my login and password. Here's my > ~/.bazaar/authentication.conf: > > [StreetCleaner] > scheme=bzr+ssh > host=192.168.0.2 > user=bzr_septi > password='well_its_here_but_its_irrelevant' > > But when I do: > > $ bzr checkout bzr+ssh://bzr_septi at 192.168.0.2//StreetCleaner > > I'm being still asked for a password. What am I doing wrong? > This is not a direct answer but is there any reason why you cannot authenticate with ssh keys? This is always better and more secure than password authentication as far as I know. Best regards Zygmunt From vila+bzr at canonical.com Mon Sep 5 07:29:19 2011 From: vila+bzr at canonical.com (vila) Date: Mon, 05 Sep 2011 09:29:19 +0200 Subject: [pilot] Summary September 2nd Message-ID: Hi, My name is vila and I've been your Patch Pilot this week. The week was intense: http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 Our landings were slowed down significantly and the consensus was that our pqm bot was suffering from fdatasync fallouts (from 1h and 1/2 to >3h, also 2h seem to be the average and spikes have been observed on the 2.3 branch), all in all: weird stuff)... which jam addressed (https://code.launchpad.net/~jameinel/bzr/2.4-disable-selftest-fdatasync-837293/+merge/73757) for the 2.4 branch (hopefully he'll merge that to trunk soon). This means we had quite an heavy load on pqm: http://webnumbr.com/bzr-pqm-queue-length.from%282011-08-28%29 but managed to land ~25 patches, not that bad considering the circumstances and the fact that we released 2.4.0 and froze 2.2.5. Jonathan made significant progress on the i18n and still have 4 patches ready to land. Jelmer continued his crusade for collocated branches and various other improvements to close the gap between bzr core and the foreign plugins. John fixed some bugs that should seriously enhance the network performance for stacked branches. Benji York started fixing some thread unsafe behavior in a creative way (especially on the test side) and that in turn triggered Martin Von Gagern to dig further (still under review). So while bzrlib is still not *guaranteed* to be thread-safe, this is some nice progress. Your own pilot landed some more config related work reducing the gap between the old and new design, more to come on this front. Disclaimer: The selection above is totally biased and partial, more have been done, thanks to all ! ;) I wish poolie an happy piloting week, Vincent From bialix at ukr.net Mon Sep 5 08:59:42 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Mon, 05 Sep 2011 11:59:42 +0300 Subject: authentication.conf not working In-Reply-To: <4E646626.1020105@gmail.com> References: <4E646626.1020105@gmail.com> Message-ID: <4E648F7E.3050208@ukr.net> Igor Novikov ?????: > I have set up a little bzr+ssh repository on my home server. But I can't > get bazaar to remember my login and password. Here's my > ~/.bazaar/authentication.conf: > > [StreetCleaner] > scheme=bzr+ssh > host=192.168.0.2 > user=bzr_septi > password='well_its_here_but_its_irrelevant' > > But when I do: > > $ bzr checkout bzr+ssh://bzr_septi at 192.168.0.2//StreetCleaner > > I'm being still asked for a password. What am I doing wrong? scheme = ssh and also set up env variable BZR_SSH=paramiko. From vila+bzr at canonical.com Tue Sep 6 08:40:42 2011 From: vila+bzr at canonical.com (vila) Date: Tue, 06 Sep 2011 10:40:42 +0200 Subject: Standup 2011-09-06 Message-ID: Bazaar Standup 2011-09-06 * Vincent * Patch Pilot, summary mail sent, lots of good stuff, * Help mthaddon setting up the new pqm, * more config stuff landed, more in the pipe, jelmer raised the subversion.conf, needs to file corresponding bugs that need to be fixed to allow the migration of the branch config options, * 2.4.0 released, 2.2.5 frozen, * more than 120 import failures fixed http://webnumbr.com/ubuntu-package-import-failures.from%282011-08-29%29, including the append_revisions_only and the HTTPError ones, plus some other that just needed to be requeued, some new ones appeared (PristineTarError for kde packages) * Jonathan * i18n branches to add more stuff to be translated, did some timing tests, * did talk on Bazaar Explorer at Ubuntu App Developer Week * may look at openSUSE packaging that currently carries 2.0.5, * Jelmer * add support for git co-located branches deployed on launchpad, * unification between code imports (git, hg, svn) and code mirrors (bzr) in Launchpad * some fallout from co-located branches addressing support on Windows, mgz is looking into it * look into build from branch into archive (from an existing dev branch that needs some polishing) * unsure about co-located branch support in the 2a format, discussing with John whether to land now or the develop format + UI in a separate branch first (? la brisbane-core) From john at arbash-meinel.com Tue Sep 6 12:21:12 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 06 Sep 2011 14:21:12 +0200 Subject: [pilot] Summary September 2nd In-Reply-To: References: Message-ID: <4E661038.7090804@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/05/2011 09:29 AM, vila wrote: > Hi, > > My name is vila and I've been your Patch Pilot this week. > > The week was intense: > > http://webnumbr.com/.join%28bzr-active-reviews,bzr-pqm-queue-length,bzr-merged-reviews.derivative%29 > > Our landings were slowed down significantly and the consensus was that > our pqm bot was suffering from fdatasync fallouts (from 1h and 1/2 to >> 3h, also 2h seem to be the average and spikes have been observed on the > 2.3 branch), all in all: weird stuff)... which jam addressed > (https://code.launchpad.net/~jameinel/bzr/2.4-disable-selftest-fdatasync-837293/+merge/73757) > for the 2.4 branch (hopefully he'll merge that to trunk soon). Landed on trunk. I'm sprinting with the U1 guys this week (who shared the PQM box). It seems our fdatasync stuff was impacting there test suite to the point that it was failing 8 times out of 10 or so. Apparently twisted defaults to having an explicit timeout on each test, and the load/sync/whatever was causing tests to timeout enough that they couldn't land their branches. So they currently set up Tarmac on Canonistack, and originally just had it running on someone's local machine. I mentioned elsewhere some limitations for *us* with Tarmac for bzr. Bits like "the full stderr + stdout is posted to Launchpad for a failing test", and "there is minimal visibility into the test suite run". I believe they handled the visibility issue by copying stderr/out to a temp file, and then exporting that via an HTTP service. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5mEDgACgkQJdeBCYSNAAMdNACfaNt45xRuqzzh6Kij+iH1RIlh BrMAoMKcNS/30DoTu/QuOcpbVMIWFopq =MSy2 -----END PGP SIGNATURE----- From Martin at lichtvoll.de Tue Sep 6 12:50:28 2011 From: Martin at lichtvoll.de (Martin Steigerwald) Date: Tue, 6 Sep 2011 14:50:28 +0200 Subject: how to ignore a file thats checked in Message-ID: <201109061450.29110.Martin@lichtvoll.de> Hi! I wish to have a file in my bazaar branch that is changes my network manager, cause I like to record my home default configuration of it. But I like to ignore any automatic changes. Thus I thought I bzr ignore it, but bzr ignore doesn't seem to let me ignore file that are still in the branch. Why? Can bzr be told to ignore is *nonetheless* instead of insisting that it knows better whats good for me? merkaba:/etc> bzr ignore resolv.conf Warning: the following files are version controlled and match your ignore pattern: resolv.conf These files will continue to be version controlled unless you 'bzr remove' them. merkaba:/etc> bzr diff === added file '.bzrignore' --- .bzrignore 1970-01-01 00:00:00 +0000 +++ .bzrignore 2011-09-06 12:42:49 +0000 @@ -0,0 +1,1 @@ +resolv.conf === modified file 'resolv.conf' --- resolv.conf 2011-07-15 22:58:31 +0000 +++ resolv.conf 2011-09-06 11:15:22 +0000 @@ -1,4 +1,5 @@ # Generated by NetworkManager [... some differences ...] For now I just removed the file from the branch: merkaba:/etc#1> bzr remove --keep resolv.conf removed resolv.conf merkaba:/etc> bzr revert .bzrignore - .bzrignore merkaba:/etc> rm .bzrignore merkaba:/etc> But thats not the optimal solution in my viewpoint. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From Martin at lichtvoll.de Tue Sep 6 13:11:34 2011 From: Martin at lichtvoll.de (Martin Steigerwald) Date: Tue, 6 Sep 2011 15:11:34 +0200 Subject: how to ignore a file thats checked in In-Reply-To: <201109061450.29110.Martin@lichtvoll.de> References: <201109061450.29110.Martin@lichtvoll.de> (sfid-20110906_145042_814412_35A83F84) Message-ID: <201109061511.34805.Martin@lichtvoll.de> Am Dienstag, 6. September 2011 schrieb Martin Steigerwald: > Hi! > > I wish to have a file in my bazaar branch that is changes my network > manager, cause I like to record my home default configuration of it. > > But I like to ignore any automatic changes. Thus I thought I bzr ignore > it, but bzr ignore doesn't seem to let me ignore file that are still in > the branch. Why? > > Can bzr be told to ignore is *nonetheless* instead of insisting that it > knows better whats good for me? > > > merkaba:/etc> bzr ignore resolv.conf > Warning: the following files are version controlled and match your > ignore pattern: > resolv.conf > These files will continue to be version controlled unless you 'bzr > remove' them. Hmmm, with explicetely specifying root directory aka merkaba:/etc> bzr uncommit 94 Martin Steigerwald 2011-09-06 Kleiner Test. Wieder hinzu. The above revision(s) will be removed. Uncommit these revisions? [y/n]: y You can restore the old tip by running: bzr pull . -r revid:martin at lichtvoll.de-20110906130847-4yqb3z7jswu0ay7d merkaba:/etc> bzr commit -m "Mit /resolv.conf gehts offenbar." Committing to: /etc/ added .bzrignore added resolv.conf Committed revision 94. merkaba:/etc> bzr diff this appears to work. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From eliz at gnu.org Wed Sep 7 06:11:01 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 07 Sep 2011 02:11:01 -0400 Subject: Address resolution problem with bzr-git In-Reply-To: (message from Eli Zaretskii on Sun, 04 Sep 2011 01:59:44 -0400) References: Message-ID: > Date: Sun, 04 Sep 2011 01:59:44 -0400 > From: Eli Zaretskii > Reply-To: Eli Zaretskii > > This strange problem happens only on one machine out of 3 I tried. > The other work with this repository with no connectivity problems. > > D:\usr\eli\bzr>bzr branch http://git.gnus.org/gnus.git > bzr: ERROR: Connection error: Couldn't resolve host 'git.gnus.org' [Errno 11001] getaddrinfo failed For the record: the problem was with a bad setting of the http_proxy variable in the environment. Once it was unset, the problem disappeared. From bastian.dev at googlemail.com Thu Sep 8 14:50:28 2011 From: bastian.dev at googlemail.com (Bastian B) Date: Thu, 8 Sep 2011 16:50:28 +0200 Subject: Difftools plugin alternative Message-ID: Hi, I would like to know if I can or should integrate my new bazaar feature directly in bazaar or if I should make it available as a separate plugin. I really like to have the functionality provided by the https://code.launchpad.net/bzr-difftools plugin to do a recursive directory diff and see more complex changes in kdiff. Unfortunately it has some annoying bugs and isn't well integrated into bazaar. After I've spend some time fixing bugs I decided to try a different approach. What I came up with is a diff-format that doesn't really format the code but copies the differing files to temporary folder and then starts the external diff tool (at the moment kdiff is hard coded and has to be in the path). So one would have to call bzr diff -r 1..2 --format=recursdiff At the moment I've implemented that as a separate plugin that registers the diff format. This has the benefit that I have all diff command's options and features available and don't have to worry about a lot of bazaar internas. But there are some problems, for which I hope you can give me some advise to solve them: * The implementation is at the moment tightly coupled to bzrlib's diff.DiffFromTool and diff.DiffTree implementation as it subclasses them and uses some private methods. That way I avoid to copy code from the classes mentioned as I need a similar behavior. * At the moment I can't supply the --using parameter as it's mutally exclusive to --format. So I have no way to specify the difftool. * Would it be helpful to have the the external merge tool management module (bzr repo Revision 5632 revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply for diff --using and my --format=recursdiff? What is that module used for at all? If you're curious to see my plugin you can see the code here http://bazaar.launchpad.net/~baztian/+junk/bzr-recursdiff/files or do a bzr branch lp:~baztian/+junk/bzr-recursdiff Regards Bastian From vila+bzr at canonical.com Thu Sep 8 17:53:27 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Thu, 08 Sep 2011 19:53:27 +0200 Subject: [ANN] 2.4.1 has gone gold Message-ID: <874o0mq5t4.fsf@canonical.com> Now is the time for our first minor release in the 2.4 series: 2.4.1 Packagers and installers builders, it's up to you again ! We're catching up with the delay for 2.4.0 and this should put us back in track on the overall schedule. See the Changelog at https://launchpad.net/bzr/2.4/2.4.1 for more details about what is included and for the tarball. I'll make the official announcement next Tuesday morning UTC (2011-09-12) with... whatever packages/installers are available at this point. Have fun ! Vincent From john at arbash-meinel.com Fri Sep 9 07:10:05 2011 From: john at arbash-meinel.com (John Meinel) Date: Fri, 9 Sep 2011 09:10:05 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: I think it is reasonable that if you want to *build* a package, then you need to have the build tools, such as a compiler and standalone python. I think pre-built packages for dulwich and bzr-git could be made without requiring them to be part of the standard windows installer. That said, somebody would have to do it, and so far nobody has done so. John =:-> On Sep 5, 2011 7:41 AM, "Eli Zaretskii" wrote: >> From: "Stephen J. Turnbull" >> Cc: Martin Pool , >> bazaar at lists.canonical.com >> Date: Mon, 05 Sep 2011 13:05:05 +0900 >> >> I don't recall any traffic on python-devel regarding building Python >> with non-MS toolchains, except for the occasional statement that it's >> possible (maybe even supported in some sense). The PSF and Active >> State Python installers are built with MS tools, and I would guess >> that the great majority of Windows installs are one of those two. It >> would be asking for trouble for Python-based projects to distribute >> extension binaries built with third-party toolchains. I suppose there >> are very few Python-based projects that do so, in or out of GNU. >> >> So your best bet is FS advocates who also use Python a lot, and c.l.py >> is most likely where you'll find them. HTH > > Thanks. There are a few pages floating around that explain how to use > MinGW, but they all describe how to tweak distutils to invoke MinGW > rather than MSVC. That requires to have Python installed, so this is > not what I'm looking for. > > This comes the closest to what I need: > > http://docs.python.org/extending/windows.html#using-dlls-in-practice > > although it uses MSVC. But "translation" to MinGW is simple. The > example indicates that the Python include directory and import library > are needed, even for such manual techniques... > > So it looks like having such extension as part of the standalone > installer is the only practical way that doesn't require a Python > installation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petrikvandervelde at gmail.com Fri Sep 9 07:16:01 2011 From: petrikvandervelde at gmail.com (Patrick van der Velde) Date: Fri, 9 Sep 2011 19:16:01 +1200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? Message-ID: Hi All Is there an alternative to Launchpad for bzr hosting. I just tried to log in to Launchpad and it timed out several times and now it still won't load my page. I wish this happened only this one time but it happens pretty much every time I do anything on Launchpad. So if anybody knows of a bzr hosting site that actually works please let me know. I'd really like to use bzr for my public code but Launchpad is just to crappy compared to bitbucket or github. Thanks Patrick From robert.collins at canonical.com Fri Sep 9 07:38:39 2011 From: robert.collins at canonical.com (Robert Collins) Date: Fri, 9 Sep 2011 19:38:39 +1200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: On Fri, Sep 9, 2011 at 7:16 PM, Patrick van der Velde wrote: > Hi All > > Is there an alternative to Launchpad for bzr hosting. I just tried to > log in to Launchpad and it timed out several times and now it still > won't load my page. I wish this happened only this one time but it > happens pretty much every time I do anything on Launchpad. So if > anybody knows of a bzr hosting site that actually works please let me > know. I'd really like to use bzr for my public code but Launchpad is > just to crappy compared to bitbucket or github. Hi Patrick. Firstly, thats a real shame with Launchpad timing out. I'd like to know more about what page was timing out. If it was the login process itself that timed out, that is https://bugs.launchpad.net/bugs/767454 - the openid provider is having some issues. If its something else, we should be able to fix it - about 1 page render in 1 million is timing out at the moment, which is a fairly low rate. Secondly, to answer your question: http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar http://bzr.bz http://savannah.gnu.org/ http://www.mergebox.net (thats offhand - there may well be more) Cheers, Rob From petrikvandervelde at gmail.com Fri Sep 9 07:53:01 2011 From: petrikvandervelde at gmail.com (Patrick van der Velde) Date: Fri, 9 Sep 2011 19:53:01 +1200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: Hi Robert Normally it's the home page (launchpad.net) but I've had it happen when trying to view the bug list for a project and the login page seems to be too slow too. In many cases hitting refresh will fix the problem (but not always). I'm not on launchpad very often but when I do go there I normally experience a page time out, so maybe I'm your one in a million time-out problem ;). Might have something to do with the fact that I'm in New Zealand though. In general I have the feeling that Launchpad is much slower than either github or bitbucket but I don't have hard data to prove it. If there is any other information you need let me know. Thanks Patrick On Fri, Sep 9, 2011 at 19:38, Robert Collins wrote: > On Fri, Sep 9, 2011 at 7:16 PM, Patrick van der Velde > wrote: >> Hi All >> >> Is there an alternative to Launchpad for bzr hosting. I just tried to >> log in to Launchpad and it timed out several times and now it still >> won't load my page. I wish this happened only this one time but it >> happens pretty much every time I do anything on Launchpad. So if >> anybody knows of a bzr hosting site that actually works please let me >> know. I'd really like to use bzr for my public code but Launchpad is >> just to crappy compared to bitbucket or github. > > Hi Patrick. Firstly, thats a real shame with Launchpad timing out. I'd > like to know more about what page was timing out. If it was the login > process itself that timed out, that is > https://bugs.launchpad.net/bugs/767454 - the openid provider is having > some issues. If its something else, we should be able to fix it - > about 1 page render in 1 million is timing out at the moment, which is > a fairly low rate. > > Secondly, to answer your question: > http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar > http://bzr.bz > http://savannah.gnu.org/ > http://www.mergebox.net > > (thats offhand - there may well be more) > > Cheers, > Rob > From eliz at gnu.org Fri Sep 9 07:54:26 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Fri, 09 Sep 2011 10:54:26 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <83obyu5ex9.fsf@gnu.org> > Date: Fri, 9 Sep 2011 09:10:05 +0200 > From: John Meinel > Cc: bazaar at lists.canonical.com, mbp at canonical.com, > "Stephen J. Turnbull" > > I think it is reasonable that if you want to *build* a package, then you > need to have the build tools, such as a compiler and standalone python. But Python itself is not used to build the shared library of dulwich C code (except to run some magic compilation commands that could be easily typed by hand). The build process needs only the header files that come with Python, AFAIU. And I already have a C compiler that is in perfect working order; I use it every day. Let me put it another way. There are 3 C files in dulwich. Normally, to make a DLL from them would be a 15-second job, even if I had to type the compilation/link command by hand. All I need is a few sentences of instructions in some README and a few header files. Instead, I need to install the exact version of Python used to produce the bzr I have, or maybe switch to using Python-based bzr installation, and then go figure out myself how to compile with GCC instead of MSVC. IOW, the changes to my workflows and the amount of effort needed are very large for such a simple and basic job. So I'm afraid I'm going to disagree that this is "reasonable", at least in this particular case. In yet other words, the dulwich setup procedure clearly assumes that the bzr installation is Python based, and thus the standalone installation on Windows is barely supported by bzr-git (so much so that Jelmer originally didn't even understand how I could install dulwich without running setup.py). > I think pre-built packages for dulwich and bzr-git could be made > without requiring them to be part of the standard windows > installer. That said, somebody would have to do it, and so far > nobody has done so. I would very much appreciate if someone did. I couldn't myself, as installing MSVC is not an option for me. From robert.collins at canonical.com Fri Sep 9 08:04:11 2011 From: robert.collins at canonical.com (Robert Collins) Date: Fri, 9 Sep 2011 20:04:11 +1200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: On Fri, Sep 9, 2011 at 7:53 PM, Patrick van der Velde wrote: > Hi Robert > > Normally it's the home page (launchpad.net) but I've had it happen > when trying to view the bug list for a project and the login page > seems to be too slow too. In many cases hitting refresh will fix the > problem (but not always). I'm not on launchpad very often but when I > do go there I normally experience a page time out, so maybe I'm your > one in a million time-out problem ;). Might have something to do with > the fact that I'm in New Zealand though. In general I have the feeling > that Launchpad is much slower than either github or bitbucket but I > don't have hard data to prove it. > > If there is any other information you need let me know. I'm in NZ too, and I very rarely encounter timeouts myself - the distribution of timeouts isn't flat across all pages, so some pages do timeout more. What would help me is if the next time it happens, grab the 'OOPS' id that the timeout gives, and let me know it. If you don't see an OOPS id, then whatever is happening to you *isn't* being captured by our automatic diagnostics, and is something different to what we know about and are fixing: so letting me know when that happens would be awesome - and I can look at getting some diagnostics together for you to see whats happening (e.g. we've seen SSL client-side issues in the past cause connection issues for users). -Rob From mbp at canonical.com Fri Sep 9 09:22:24 2011 From: mbp at canonical.com (Martin Pool) Date: Fri, 9 Sep 2011 19:22:24 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83obyu5ex9.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: I hope we don't get into a "what is reasonable" debate, because there are a lot of things about Windows development that are not reasonable, and also not under our control. I believe the technical facts are: * you can't use cygwin or mingw gcc to build extensions for a Python built with msvc * all the python.org distributions are built with msvc (perhaps because there are some limitations of w32 gcc; at any rate we hit some in the past) * you need a close match between the Python interpreter and the Python headers/etc used to build the dll so > Normally, to make a DLL from them would be a 15-second job, even if I had to type the compilation/link command by hand. might be true for DLLs in general, but as far as I know it's not true for Python extensions. Martin From bialix at ukr.net Fri Sep 9 10:09:40 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 09 Sep 2011 13:09:40 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: <4E69E5E4.3000608@ukr.net> Martin Pool ?????: > I hope we don't get into a "what is reasonable" debate, because there > are a lot of things about Windows development that are not reasonable, > and also not under our control. > > I believe the technical facts are: > > * you can't use cygwin or mingw gcc to build extensions for a Python > built with msvc I don't think it's true. At least for Python 2.5 it was possible to build python c-extensions with mingw. I don't know about Python 2.6-2.7 though. > * all the python.org distributions are built with msvc (perhaps > because there are some limitations of w32 gcc; at any rate we hit some > in the past) > * you need a close match between the Python interpreter and the > Python headers/etc used to build the dll > > so > >> Normally, to make a DLL from them would be a 15-second job, even if I had to type the compilation/link command by hand. > > might be true for DLLs in general, but as far as I know it's not true > for Python extensions. > > Martin > > From eliz at gnu.org Fri Sep 9 10:16:22 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Fri, 09 Sep 2011 13:16:22 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E69E5E4.3000608@ukr.net> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> Message-ID: <83d3fa58cp.fsf@gnu.org> > Date: Fri, 09 Sep 2011 13:09:40 +0300 > From: Alexander Belchenko > CC: Eli Zaretskii , Bazaar > > Martin Pool ?????: > > I hope we don't get into a "what is reasonable" debate, because there > > are a lot of things about Windows development that are not reasonable, > > and also not under our control. > > > > I believe the technical facts are: > > > > * you can't use cygwin or mingw gcc to build extensions for a Python > > built with msvc > > I don't think it's true. At least for Python 2.5 it was possible to > build python c-extensions with mingw. I'm not surprised. AFAIK, MinGW is fully compatible with MSVC in this regard, if not by default, then with the -mms-bitfields command-line option. From bialix at ukr.net Fri Sep 9 10:25:19 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 09 Sep 2011 13:25:19 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83d3fa58cp.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> Message-ID: <4E69E98F.80504@ukr.net> Eli Zaretskii ?????: >> Date: Fri, 09 Sep 2011 13:09:40 +0300 >> From: Alexander Belchenko >> CC: Eli Zaretskii , Bazaar >> >> Martin Pool ?????: >>> I hope we don't get into a "what is reasonable" debate, because there >>> are a lot of things about Windows development that are not reasonable, >>> and also not under our control. >>> >>> I believe the technical facts are: >>> >>> * you can't use cygwin or mingw gcc to build extensions for a Python >>> built with msvc >> I don't think it's true. At least for Python 2.5 it was possible to >> build python c-extensions with mingw. > > I'm not surprised. AFAIK, MinGW is fully compatible with MSVC in this > regard, if not by default, then with the -mms-bitfields command-line > option. I recall that for some specific purpose python c-extensions should be linked against exactly the same C run-time dll as Python itself. So that mingw I was talking about has the option in the installer to be compatible either with Python 2.3 (MSVC 6.0 + msvcrt.dll) or with Python 2.4-2.5 (MSVC 2003 + msvcr71.dll). Python 2.6-2.7 are built with MSVC 2008 IIRC, so another version of run-time library should be used (msvcr90.dll IIRC). From eliz at gnu.org Fri Sep 9 11:14:27 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Fri, 09 Sep 2011 14:14:27 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E69E98F.80504@ukr.net> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> <4E69E98F.80504@ukr.net> Message-ID: <83bouu55nw.fsf@gnu.org> > Date: Fri, 09 Sep 2011 13:25:19 +0300 > From: Alexander Belchenko > CC: mbp at canonical.com, bazaar at lists.canonical.com > > Python 2.6-2.7 are built with MSVC 2008 IIRC, so another version of > run-time library should be used (msvcr90.dll IIRC). Shouldn't be a problem, as MinGW comes with import libraries for msvcr90.dll as well. It's a matter of telling the right linker switches in the appropriate README. From bialix at ukr.net Fri Sep 9 11:39:06 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Fri, 09 Sep 2011 14:39:06 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83bouu55nw.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> <4E69E98F.80504@ukr.net> <83bouu55nw.fsf@gnu.org> Message-ID: <4E69FADA.7010508@ukr.net> Eli Zaretskii ?????: >> Date: Fri, 09 Sep 2011 13:25:19 +0300 >> From: Alexander Belchenko >> CC: mbp at canonical.com, bazaar at lists.canonical.com >> >> Python 2.6-2.7 are built with MSVC 2008 IIRC, so another version of >> run-time library should be used (msvcr90.dll IIRC). > > Shouldn't be a problem, as MinGW comes with import libraries for > msvcr90.dll as well. It's a matter of telling the right linker > switches in the appropriate README. Python's distutils library can build C-extensions using mingw with appropriate switches. Maybe those switches could be extracted from some source, I can't say. -- All the dude wanted was his rug back From jelmer at canonical.com Fri Sep 9 11:43:08 2011 From: jelmer at canonical.com (Jelmer Vernooij) Date: Fri, 09 Sep 2011 13:43:08 +0200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: <4E69FBCC.5040405@canonical.com> On 09/09/2011 09:38 AM, Robert Collins wrote: > On Fri, Sep 9, 2011 at 7:16 PM, Patrick van der Velde > wrote: >> Hi All >> >> Is there an alternative to Launchpad for bzr hosting. I just tried to >> log in to Launchpad and it timed out several times and now it still >> won't load my page. I wish this happened only this one time but it >> happens pretty much every time I do anything on Launchpad. So if >> anybody knows of a bzr hosting site that actually works please let me >> know. I'd really like to use bzr for my public code but Launchpad is >> just to crappy compared to bitbucket or github. > Hi Patrick. Firstly, thats a real shame with Launchpad timing out. I'd > like to know more about what page was timing out. If it was the login > process itself that timed out, that is > https://bugs.launchpad.net/bugs/767454 - the openid provider is having > some issues. If its something else, we should be able to fix it - > about 1 page render in 1 million is timing out at the moment, which is > a fairly low rate. > > Secondly, to answer your question: > http://sourceforge.net/apps/trac/sourceforge/wiki/Bazaar > http://bzr.bz > http://savannah.gnu.org/ > http://www.mergebox.net > > (thats offhand - there may well be more) FWIW There is also a list of hosting sites here: http://wiki.bazaar.canonical.com/Hosting Cheers, Jelmer From bernhard.voelker at siemens-enterprise.com Fri Sep 9 11:51:34 2011 From: bernhard.voelker at siemens-enterprise.com (Voelker, Bernhard) Date: Fri, 9 Sep 2011 13:51:34 +0200 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: <7856072A9D04C24B82DFE2B1112FE38A0C2AFF9D48@MCHP058A.global-ad.net> Robert Collins wrote: > On Fri, Sep 9, 2011 at 7:16 PM, Patrick van der Velde wrote: > > Hi All > > > > Is there an alternative to Launchpad for bzr hosting. I just tried to > > log in to Launchpad and it timed out several times and now it still > > won't load my page. I wish this happened only this one time but it > > happens pretty much every time I do anything on Launchpad. So if > > anybody knows of a bzr hosting site that actually works please let me > > know. I'd really like to use bzr for my public code but Launchpad is > > just to crappy compared to bitbucket or github. > > Hi Patrick. Firstly, thats a real shame with Launchpad timing out. I'd > like to know more about what page was timing out. If it was the login > process itself that timed out, that is > https://bugs.launchpad.net/bugs/767454 - the openid provider is having > some issues. If its something else, we should be able to fix it - > about 1 page render in 1 million is timing out at the moment, which is > a fairly low rate. just a quick shot, but this sounds like a "random vs. urandom" issue. Bye, Berny From jelmer at samba.org Fri Sep 9 11:57:29 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Fri, 09 Sep 2011 13:57:29 +0200 Subject: Difftools plugin alternative In-Reply-To: References: Message-ID: <4E69FF29.2010704@samba.org> Hi Bastian, On 09/08/2011 04:50 PM, Bastian B wrote: > I would like to know if I can or should integrate my new bazaar > feature directly in bazaar or if I should make it available as a > separate plugin. It would be nice to have something like this in the core. There are several bugs open about this and several people have attempted to work on it, but nothing really seems to have made it into the tree. > At the moment I've implemented that as a separate plugin that > registers the diff format. This has the benefit that I have all diff > command's options and features available and don't have to worry about > a lot of bazaar internas. But there are some problems, for which I > hope you can give me some advise to solve them: > * The implementation is at the moment tightly coupled to bzrlib's > diff.DiffFromTool and diff.DiffTree implementation as it subclasses > them and uses some private methods. That way I avoid to copy code from > the classes mentioned as I need a similar behavior. That seems reasonable, I'm not sure why this is listed as a problem. :-) > * At the moment I can't supply the --using parameter as it's mutally > exclusive to --format. So I have no way to specify the difftool. I don't think that the --format option is the right place to specify this kind of thing at a UI level - as a user I wouldn't look there if I wanted to have an external tool generate my diffs I think. It would probably make more sense to add a new option to "bzr diff" to this effect; this shouldn't be too hard if you already have a custom format registered. > * Would it be helpful to have the the external merge tool management > module (bzr repo Revision 5632 > revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply for > diff --using and my --format=recursdiff? What is that module used for > at all? I'm not really familiar with the merge tools, perhaps somebody else can answer this. Cheers, Jelmer From jriddell at ubuntu.com Fri Sep 9 11:59:07 2011 From: jriddell at ubuntu.com (Jonathan Riddell) Date: Fri, 9 Sep 2011 12:59:07 +0100 Subject: stuck on i18n-nulltranslations Message-ID: <20110909115907.GJ3728@starsky.19inch.net> I'm stuck on a failure on this patch https://code.launchpad.net/~jr/bzr/i18n-nulltranslations/+merge/72697 The patch reinstates gettext.NullTranslations in i18n to allow use of i18n even when translations are not turned on, which I think is an important first step to having full i18n. However it fails on bzrlib.tests.test_transport.TestTransport.test_transport_fallback but only when $LANGUAGE is not set, which seems to be the case on PQM. When $LANGUAGE is not set i18n.install() will load up the config file to check for a setting there (I think this is wrong, I think the config file should override the environement variable but that's for another patch.) This seems to cause a circular error where UnsupportedProtocol gets raised for the config file. So I don't know why this problem only affects my i18n-nulltranslations patch in PQM, it should affect all. And I don't know how to fix it. Any help appreciated. Jonathan From gordon at doxxx.net Fri Sep 9 12:17:14 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Fri, 09 Sep 2011 08:17:14 -0400 Subject: Difftools plugin alternative In-Reply-To: References: Message-ID: <4E6A03CA.4010202@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/8/2011 10:50 AM, Bastian B wrote: > * Would it be helpful to have the the external merge tool management > module (bzr repo Revision 5632 > revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply for > diff --using and my --format=recursdiff? What is that module used for > at all? That module contains helper functions for executing external merge tools using command-lines with filename substitution markers (e.g. {this} {other} etc.). It is conceivable that its code could be re-used to execute external diff tools as well, with some refactoring. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOagPKAAoJEIrPJfWinA2uHxYH/0JTMi6j09AITW4oo4sr3EqG 1ZEOjY/Ey9m9vIxp5nIpWYNbiIxnJ1NueSmsCFWFJncg/sNvWzDHx5I047RzCzSA Ncaw1rF9uShLTCNcaDzX1/wb6YDJij4xMqlUuYJZ3Jvk2GZWe0EcnQTkkLT0mnK6 SX1QbWF3MEkIEdENpOsw2T7ZXKJUvwj6rUBiNfc1UEC6wS58ocMV47cavTWZa1N0 jNuUSmMqk+p29q5XFaIfyszIsUhXhdlNsi1LyRsrrPFrC0ekYdf6d0h2r3BpHDir Z1oCg1W3rxpb3lfuRUm8ZYNysaVVUzb2FPT4LPfwiyodXRRayEErucTC1VSk5t4= =aBkp -----END PGP SIGNATURE----- From gordon at doxxx.net Fri Sep 9 12:23:58 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Fri, 09 Sep 2011 08:23:58 -0400 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: References: Message-ID: <4E6A055E.7040503@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/2011 3:16 AM, Patrick van der Velde wrote: > Is there an alternative to Launchpad for bzr hosting. I just tried to > log in to Launchpad and it timed out several times and now it still > won't load my page. I wish this happened only this one time but it > happens pretty much every time I do anything on Launchpad. So if > anybody knows of a bzr hosting site that actually works please let me > know. I'd really like to use bzr for my public code but Launchpad is > just to crappy compared to bitbucket or github. One alternative that I know of is: https://www.mergebox.net/ Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOagVeAAoJEIrPJfWinA2ukBsH/R+2KlaTmFmGIC+Rgzf4imBJ VPLXFf63CiKqFsL215OjoV0DTTyj6xtTTPvOCJn4bT9xD2Y78RE/qUCRsPDoTMgi t2TKZYRMi3td1is0T+VVPT/AcWHeRlQBv9czOSBPRxoMgG5qseP00b/hWNOi8kTk gmf9vGV7FttKa40B70uawRFmdiEDKKPPt09Q3zkFNX+/powej2hVqWAZW2ZwBQ7S 1PfNqAE2TJ6k/KNGo9Re/pUFvdrOrYcF7kAD1yxm66iRpbnn8NaCqJaSfn7D7ijS 8LiqnAWXmWc0jqWZkKRiPrUyCXa9aNQ37KksdgyBwJe0GjtXmn0P2xIr7BNNeLo= =dCpq -----END PGP SIGNATURE----- From russel at russel.org.uk Fri Sep 9 13:46:52 2011 From: russel at russel.org.uk (Russel Winder) Date: Fri, 09 Sep 2011 14:46:52 +0100 Subject: Does anybody know of code hosting for bzr that is not Launchpad? In-Reply-To: <4E6A055E.7040503@doxxx.net> References: <4E6A055E.7040503@doxxx.net> Message-ID: <1315576013.14821.194.camel@anglides.russel.org.uk> On Fri, 2011-09-09 at 08:23 -0400, Gordon Tyler wrote: > One alternative that I know of is: https://www.mergebox.net/ To date on the three attempts I have tried, I have been unable to upload a branch or branch a branch created on MergeBox. I had been hoping MergeBox could do for Bazaar what GitHub has done for Git and BitBucket may be doing for Mercurial. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder at ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel at russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From aaron at aaronbentley.com Fri Sep 9 14:45:21 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Fri, 09 Sep 2011 10:45:21 -0400 Subject: Difftools plugin alternative In-Reply-To: References: Message-ID: <4E6A2681.7010306@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-08 10:50 AM, Bastian B wrote: > I really like to have the functionality provided by the > https://code.launchpad.net/bzr-difftools plugin I was also inspired by difftools when I implemented --using, and I always envisioned supporting full-tree diffing as well. I would recommend making these changes in the core. Perhaps recursive diffing could be indicated in the --using format, e.g. "bzr diff --using 'kdediff @recursive @old_path @new_path'" > * Would it be helpful to have the the external merge tool > management module (bzr repo Revision 5632 > revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply > for diff --using and my --format=recursdiff? What is that module > used for at all? It doesn't seem so. Tools that can perform merges aren't the same as tools that do diffs. For more info on that module, see its merge proposal: https://code.launchpad.net/~doxxx/bzr/mergetools/+merge/40923 Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5qJoEACgkQ0F+nu1YWqI3GMwCfalHecnUoIt+oFMGgNnfYE9uo b0IAnRtFmx0gpM6ZLhB2YboBwSlI9FpT =PbtX -----END PGP SIGNATURE----- From jelmer at samba.org Fri Sep 9 14:48:25 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Fri, 09 Sep 2011 16:48:25 +0200 Subject: Difftools plugin alternative In-Reply-To: <4E6A2681.7010306@aaronbentley.com> References: <4E6A2681.7010306@aaronbentley.com> Message-ID: <4E6A2739.7010606@samba.org> On 09/09/2011 04:45 PM, Aaron Bentley wrote: > >> * Would it be helpful to have the the external merge tool >> management module (bzr repo Revision 5632 >> revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply >> for diff --using and my --format=recursdiff? What is that module >> used for at all? > It doesn't seem so. Tools that can perform merges aren't the same as > tools that do diffs. For more info on that module, see its merge > proposal: > > https://code.launchpad.net/~doxxx/bzr/mergetools/+merge/40923 Perhaps some of the code for configuring these tools can be reused though. Cheers, Jelmer From gordon at doxxx.net Fri Sep 9 17:04:49 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Fri, 9 Sep 2011 13:04:49 -0400 Subject: Difftools plugin alternative In-Reply-To: <4E6A2739.7010606@samba.org> References: <4E6A2681.7010306@aaronbentley.com> <4E6A2739.7010606@samba.org> Message-ID: The external tool execution with parameter substitution code could be refactored out into something that could be shared by mergetools and difftools. On 2011-09-09, at 10:48 AM, Jelmer Vernooij wrote: > On 09/09/2011 04:45 PM, Aaron Bentley wrote: >> >>> * Would it be helpful to have the the external merge tool >>> management module (bzr repo Revision 5632 >>> revid:pqm at pqm.ubuntu.com-20110125135932-0o8d07i3j1flp6ou) apply >>> for diff --using and my --format=recursdiff? What is that module >>> used for at all? >> It doesn't seem so. Tools that can perform merges aren't the same as >> tools that do diffs. For more info on that module, see its merge >> proposal: >> >> https://code.launchpad.net/~doxxx/bzr/mergetools/+merge/40923 > Perhaps some of the code for configuring these tools can be reused though. > > Cheers, > > Jelmer > > From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:31 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:31 -0400 (EDT) Subject: [Success!] Re: [MERGE] Update PPA documentation and scripts In-Reply-To: <20090603102801.GA7552@inodes.org> References: <20090603102801.GA7552@inodes.org> Message-ID: <20110910051631.AEBDE8B852@aaronbentley.com> This change has been merged. Previous status: Conditionally approved For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090603102801.GA7552%40inodes.org%3E Project: Bazaar From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:32 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:32 -0400 (EDT) Subject: [Success!] Re: [MERGE/RFC] Add support for Launchpad API to plugin, including 'mirror branch now' command In-Reply-To: References: Message-ID: <20110910051632.553B08B854@aaronbentley.com> This change has been merged. Previous status: Semi-approved For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cd06a5cd30907040326n43b4cce8pe9ba9faeec3528f3%40mail.gmail.com%3E Project: Bazaar From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:29 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:29 -0400 (EDT) Subject: [Success!] Re: [MERGE][Bug #183559] Add a -r option to bzr switch In-Reply-To: <1234234315.3552.20.camel@sophie.daniel-watkins.co.uk> References: <1234234315.3552.20.camel@sophie.daniel-watkins.co.uk> Message-ID: <20110910051630.107AF8B75A@aaronbentley.com> This change has been merged. Previous status: Resubmit For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1234234315.3552.20.camel%40sophie.daniel-watkins.co.uk%3E Project: Bazaar From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:30 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:30 -0400 (EDT) Subject: [Success!] [MERGE/RFC] Use _read_records_iter_unchecked in _get_remaining_record_stream. In-Reply-To: <20090306005040.GA857@steerpike.home.puzzling.org> References: <20090306005040.GA857@steerpike.home.puzzling.org> Message-ID: <20110910051630.B16B88B75B@aaronbentley.com> This change has been merged. Previous status: Conditionally approved For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090306005040.GA857%40steerpike.home.puzzling.org%3E Project: Bazaar From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:31 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:31 -0400 (EDT) Subject: [Success!] Re: [MERGE] DWIM revspecs In-Reply-To: <20090818082414.GA65209@over-yonder.net> References: <20090818082414.GA65209@over-yonder.net> Message-ID: <20110910051631.EF9758B853@aaronbentley.com> This change has been merged. Previous status: Waiting For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090818082414.GA65209%40over-yonder.net%3E Project: Bazaar From bundlebuggy at aaronbentley.com Sat Sep 10 05:16:32 2011 From: bundlebuggy at aaronbentley.com (Bundle Buggy) Date: Sat, 10 Sep 2011 01:16:32 -0400 (EDT) Subject: [Success!] [PATCH] [Bug 176292] Allow use of BZR_SSH as path to ssh client In-Reply-To: References: Message-ID: <20110910051632.92BE48B855@aaronbentley.com> This change has been merged. Previous status: Waiting For details, see: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Cd80792120908062317h7a283441pb2ecef262fbb0ac3%40mail.gmail.com%3E Project: Bazaar From mbp at canonical.com Mon Sep 12 02:54:09 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 12 Sep 2011 12:54:09 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83obyu5ex9.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: On 9 September 2011 17:54, Eli Zaretskii wrote: > Let me put it another way. ?There are 3 C files in dulwich. ?Normally, > to make a DLL from them would be a 15-second job, even if I had to > type the compilation/link command by hand. ?All I need is a few > sentences of instructions in some README and a few header files. > Instead, I need to install the exact version of Python used to produce > the bzr I have, or maybe switch to using Python-based bzr > installation, and then go figure out myself how to compile with GCC > instead of MSVC. What actually goes wrong when you try to make a DLL in the 'normal' way? Are you speaking of building Python extensions, or other DLLs? m From eliz at gnu.org Mon Sep 12 06:08:07 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 02:08:07 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (message from Martin Pool on Mon, 12 Sep 2011 12:54:09 +1000) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: > From: Martin Pool > Date: Mon, 12 Sep 2011 12:54:09 +1000 > Cc: John Meinel , bazaar at lists.canonical.com, stephen at xemacs.org > > What actually goes wrong when you try to make a DLL in the 'normal' > way? I didn't try because I don't know how to do that in this specific case: what compiler switches to use, which libraries to link against, and (last, but not least) where to place the resulting DLL. There isn't a word about that in the dulwich distro, only a Makefile where I found that it invokes setup.py, which in turn invokes some magic in a Python module I don't have (distutils). If someone could run this on Unix or GNU system and tell me what was the GCC command line run by setup.py, that would be a huge step forward. > Are you speaking of building Python extensions, or other DLLs? Just the C extensions supplied with dulwich, nothing else. Thanks. From andrew at bemusement.org Mon Sep 12 06:48:17 2011 From: andrew at bemusement.org (Andrew Bennetts) Date: Mon, 12 Sep 2011 16:48:17 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: <20110912064817.GA17571@flay.puzzling.org> I'm no expert in Dulwich-related matters, but hopefully this is more helpful than not: On Mon, Sep 12, 2011 at 02:08:07AM -0400, Eli Zaretskii wrote: > > From: Martin Pool [?] > > What actually goes wrong when you try to make a DLL in the 'normal' > > way? > > I didn't try because I don't know how to do that in this specific > case: what compiler switches to use, which libraries to link against, > and (last, but not least) where to place the resulting DLL. There > isn't a word about that in the dulwich distro, only a Makefile where I > found that it invokes setup.py, which in turn invokes some magic in a > Python module I don't have (distutils). Distutils is part of the Python standard library. If you don't have distutils then it's highly unlikely you have Python.h, which I'm sure Dulwich needs. i.e. a standard Python installation is a build dependency, if you want to think of it in those terms. [?] > > Are you speaking of building Python extensions, or other DLLs? > > Just the C extensions supplied with dulwich, nothing else. To the best of my knowledge, those C extensions *are* Python extensions ? that's the point of Dulwich. Certainly a quick glance at the source suggests all the *.c files directly require Python.h. -Andrew. From eliz at gnu.org Mon Sep 12 07:39:05 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 03:39:05 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <20110912064817.GA17571@flay.puzzling.org> (message from Andrew Bennetts on Mon, 12 Sep 2011 16:48:17 +1000) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> Message-ID: > Date: Mon, 12 Sep 2011 16:48:17 +1000 > From: Andrew Bennetts > Cc: Martin Pool , bazaar at lists.canonical.com > > I'm no expert in Dulwich-related matters, but hopefully this is more > helpful than not: Thanks. > Distutils is part of the Python standard library. If you don't have > distutils then it's highly unlikely you have Python.h, which I'm sure > Dulwich needs. Yes, Python.h is needed, I already saw that by looking at the C sources. But there's a world of difference between a single header (and maybe a bunch of others it pulls in) and a whole Python installation. I'm guessing that distutils is a thin wrapper over compilation commands, in this particular case. So showing the compilation command that is needed to build the shared library would allow hackers such as myself to hack a workable solution without the need to switch to a Python-based bzr installation. Of course, having a pre-built DLL available somewhere would be much better, but failing that, I'm prepared to invest a reasonable amount of effort in having my private solution. Been there, done that before. > i.e. a standard Python installation is a build dependency, if you > want to think of it in those terms. Yes, that was my conclusion. And therein lies the problem: it means one cannot have bzr-git with reasonable performance on Windows, unless one installs Python 2.6 and Python-based bzr. And even then, building the extensions with a Free Software compiler on Windows is not supported out of the box, so some non-trivial effort would still be needed to pull that out. > > > Are you speaking of building Python extensions, or other DLLs? > > > > Just the C extensions supplied with dulwich, nothing else. > > To the best of my knowledge, those C extensions *are* Python extensions Sorry, that's my ignorance of the terminology showing up. From john at arbash-meinel.com Mon Sep 12 07:44:13 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 12 Sep 2011 09:44:13 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> Message-ID: <4E6DB84D.3080607@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/12/2011 09:39 AM, Eli Zaretskii wrote: >> Date: Mon, 12 Sep 2011 16:48:17 +1000 >> From: Andrew Bennetts >> Cc: Martin Pool , bazaar at lists.canonical.com >> >> I'm no expert in Dulwich-related matters, but hopefully this is more >> helpful than not: > > Thanks. > >> Distutils is part of the Python standard library. If you don't have >> distutils then it's highly unlikely you have Python.h, which I'm sure >> Dulwich needs. > > Yes, Python.h is needed, I already saw that by looking at the C > sources. But there's a world of difference between a single header > (and maybe a bunch of others it pulls in) and a whole Python > installation. I'm guessing that distutils is a thin wrapper over > compilation commands, in this particular case. So showing the > compilation command that is needed to build the shared library would > allow hackers such as myself to hack a workable solution without the > need to switch to a Python-based bzr installation. > > Of course, having a pre-built DLL available somewhere would be much > better, but failing that, I'm prepared to invest a reasonable amount > of effort in having my private solution. Been there, done that > before. Where will you get "Python.h" and all of the include files it pulls it? It seems easy enough to grab the .msi installer, and you have what you need. > >> i.e. a standard Python installation is a build dependency, if you >> want to think of it in those terms. > > Yes, that was my conclusion. And therein lies the problem: it means > one cannot have bzr-git with reasonable performance on Windows, unless > one installs Python 2.6 and Python-based bzr. And even then, building > the extensions with a Free Software compiler on Windows is not > supported out of the box, so some non-trivial effort would still be > needed to pull that out. You need it to *build* the extension. After that, the files can be copied around, or possibly packaged into an installer. > >>>> Are you speaking of building Python extensions, or other DLLs? >>> >>> Just the C extensions supplied with dulwich, nothing else. >> >> To the best of my knowledge, those C extensions *are* Python extensions > > Sorry, that's my ignorance of the terminology showing up. > John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5tuE0ACgkQJdeBCYSNAAMXXACfeP8/L5JIM5QXKfjubaxNvJ5M 5KQAoNWt7dJXhkd8NNepkkIB5mwkc5r+ =sNmU -----END PGP SIGNATURE----- From viktor.nagy at gmail.com Mon Sep 12 07:45:56 2011 From: viktor.nagy at gmail.com (Bika) Date: Mon, 12 Sep 2011 09:45:56 +0200 Subject: create/switch b/w branches like in git Message-ID: Hi, I really like git's easy to create&switch b/w feature branches. Is there a way to accomplish this w/ bazaar? I would like something like a 1 directory bzr worktree where I can easily check out different branches. (of course only related branches would be checked out into a single working tree) is there a solution or usage scenario to accomplish this? thx, Viktor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vila+bzr at canonical.com Mon Sep 12 06:54:02 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Mon, 12 Sep 2011 08:54:02 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (Eli Zaretskii's message of "Mon, 12 Sep 2011 02:08:07 -0400") References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: >>>>> Eli Zaretskii writes: >> From: Martin Pool >> Date: Mon, 12 Sep 2011 12:54:09 +1000 >> Cc: John Meinel , bazaar at lists.canonical.com, stephen at xemacs.org >> >> What actually goes wrong when you try to make a DLL in the 'normal' >> way? > I didn't try because I don't know how to do that in this specific > case: what compiler switches to use, which libraries to link against, > and (last, but not least) where to place the resulting DLL. Which should be described in distutils.py, that's the point ! > There isn't a word about that in the dulwich distro, only a > Makefile where I found that it invokes setup.py, That's the standard way to do it to let python invoke the right compiler/linker depending on the platform, > which in turn invokes some magic in a Python module I don't have > (distutils). /me blinks That's the bug. I thought distutils was part of the standard python distribution. If you don't have this file, I should be wrong. Still, there should be an easy way to install it ('easy_install distutils' ?) > If someone could run this on Unix or GNU system and tell me what was > the GCC command line run by setup.py, that would be a huge step > forward. No, it will only tell you what runs on a GNU system, not what you need to run on windows, but anyway, running 'python setup.py build_ext -i -v' in bzr trunk: running build_ext building 'bzrlib._annotator_pyx' extension creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/bzrlib gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_annotator_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o ... etc Hth, Vincent From vila+bzr at canonical.com Fri Sep 9 14:00:21 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Fri, 09 Sep 2011 16:00:21 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E69FADA.7010508@ukr.net> (Alexander Belchenko's message of "Fri, 09 Sep 2011 14:39:06 +0300") References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> <4E69E98F.80504@ukr.net> <83bouu55nw.fsf@gnu.org> <4E69FADA.7010508@ukr.net> Message-ID: >>>>> Alexander Belchenko writes: > Eli Zaretskii ?????: >>> Date: Fri, 09 Sep 2011 13:25:19 +0300 >>> From: Alexander Belchenko >>> CC: mbp at canonical.com, bazaar at lists.canonical.com >>> >>> Python 2.6-2.7 are built with MSVC 2008 IIRC, so another version of >>> run-time library should be used (msvcr90.dll IIRC). >> >> Shouldn't be a problem, as MinGW comes with import libraries for >> msvcr90.dll as well. It's a matter of telling the right linker >> switches in the appropriate README. > Python's distutils library can build C-extensions using mingw > with appropriate switches. Maybe those switches could be > extracted from some source, I can't say. To refresh my dusted memory, I grepped the distutils dir for python2.7: """Python was built with Visual Studio 2008; extensions must be built with a compiler than can generate compatible binaries. Visual Studio 2008 was not found on this system. If you have Cygwin installed, you can try compiling with MingW32, by passing "-c mingw32" to setup.py.""") The same warning exist for Visual Studio 2003. I also vaguely recall being able to put this flag into some dot file to avoid modifying the setup.py invocations (but it's so vague I wonder if it was for perl instead...). Hth, Vincent From vila+bzr at canonical.com Fri Sep 9 14:20:56 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Fri, 09 Sep 2011 16:20:56 +0200 Subject: stuck on i18n-nulltranslations In-Reply-To: <20110909115907.GJ3728@starsky.19inch.net> (Jonathan Riddell's message of "Fri, 9 Sep 2011 12:59:07 +0100") References: <20110909115907.GJ3728@starsky.19inch.net> Message-ID: >>>>> Jonathan Riddell writes: > I'm stuck on a failure on this patch > https://code.launchpad.net/~jr/bzr/i18n-nulltranslations/+merge/72697 > The patch reinstates gettext.NullTranslations in i18n to allow use > of i18n even when translations are not turned on, which I think is > an important first step to having full i18n. > However it fails on > bzrlib.tests.test_transport.TestTransport.test_transport_fallback This test inherits from tests.TestCase which means it doesn't need any file on disk. > but only when $LANGUAGE is not set, which seems to be the case on > PQM. I keep forgetting the exact invocation but I think LC_ALL is set instead ? > When $LANGUAGE is not set i18n.install() will load up the config > file Beeeeep. You're not supposed to try to load a config file while in a tests.TestCase > to check for a setting there (I think this is wrong, I think the > config file should override the environement variable but that's > for another patch.) I agree. This is one case where the env variables should be used to provide default values if the user didn't mention anything else. > This seems to cause a circular error where UnsupportedProtocol > gets raised for the config file. Well, the test clears all the protocol handlers and defines a single one for a very specific purpose, trying to get any transport during this test will fail. > So I don't know why this problem only affects my i18n-nulltranslations > patch in PQM, it should affect all. Because that's the only test that mutter() the error you're trying to translate. > And I don't know how to fix it. Well, since this test want to mutter(), it arguably needs to be able to write to .bzr.log so it should not inherit from TestCase but from at least from TestCaseInTempDir or even TestCaseWithTransport. Then, since the transport factory is screwed, you probably want to either: - disable any translation, or - install them while the transport factory is not broken. Overall, I'm a bit surprised you didn't encounter more cases like that... As far as tests are concerned, I'd be inclined to force the installation of a null translation by default. Tests specific to the translation should install their own anyway (and already ;). Vincent From vila+bzr at canonical.com Sat Sep 10 07:36:42 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Sat, 10 Sep 2011 09:36:42 +0200 Subject: Difftools plugin alternative In-Reply-To: (Gordon Tyler's message of "Fri, 9 Sep 2011 13:04:49 -0400") References: <4E6A2681.7010306@aaronbentley.com> <4E6A2739.7010606@samba.org> Message-ID: >>>>> Gordon Tyler writes: > The external tool execution with parameter substitution code could > be refactored out into something that could be shared by > mergetools and difftools. +1, preferably unifying the reference syntax used for both which will require some care for transition. From eliz at gnu.org Mon Sep 12 07:56:36 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 03:56:36 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6DB84D.3080607@arbash-meinel.com> (message from John Arbash Meinel on Mon, 12 Sep 2011 09:44:13 +0200) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> Message-ID: > Date: Mon, 12 Sep 2011 09:44:13 +0200 > From: John Arbash Meinel > CC: Andrew Bennetts , mbp at canonical.com, > bazaar at lists.canonical.com > > Where will you get "Python.h" and all of the include files it pulls it? Don't worry about that ;-) > It seems easy enough to grab the .msi installer, and you have what you need. Even if I need to install Python, grab the files, then uninstall it, it's easier than switching to Python-based bzr. > You need it to *build* the extension. After that, the files can be > copied around Copied where? That information is also missing. Anyway, I don't want to keep you-all busy people occupied with this issue, instead of doing more useful things with your time. My conclusion is that it is impractical to do what I wanted, and the only way to have those extensions on Windows is to have them packaged with the standalone installer. I hope Someone? will do that some day, TIA. Thanks for all your help. From eliz at gnu.org Mon Sep 12 08:00:03 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 04:00:03 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (message from Vincent Ladeuil on Mon, 12 Sep 2011 08:54:02 +0200) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: > From: Vincent Ladeuil > Cc: Martin Pool , bazaar at lists.canonical.com > Date: Mon, 12 Sep 2011 08:54:02 +0200 > > > If someone could run this on Unix or GNU system and tell me what was > > the GCC command line run by setup.py, that would be a huge step > > forward. > > No, it will only tell you what runs on a GNU system, not what you need > to run on windows I use GCC for many years, on several different platforms. So seeing a command that runs on a GNU system tells me enough to adapt it to Windows. > running 'python setup.py build_ext -i -v' in bzr trunk: > > running build_ext > building 'bzrlib._annotator_pyx' extension > creating build/temp.linux-x86_64-2.7 > creating build/temp.linux-x86_64-2.7/bzrlib > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_annotator_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o Thanks, that's a beginning. The final commands that create a .so file from *.o object files would be nice, as well as command(s) that copy the .so to its final destination. From john at arbash-meinel.com Mon Sep 12 08:13:19 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Mon, 12 Sep 2011 10:13:19 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> Message-ID: <4E6DBF1F.4080407@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> You need it to *build* the extension. After that, the files can be >> copied around > > Copied where? That information is also missing. Copied to "C:\Program Files\Bazaar\site-packages" where I mentioned in the first place. John =:-> > > Anyway, I don't want to keep you-all busy people occupied with this > issue, instead of doing more useful things with your time. My > conclusion is that it is impractical to do what I wanted, and the only > way to have those extensions on Windows is to have them packaged with > the standalone installer. I hope Someone? will do that some day, TIA. > > Thanks for all your help. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5tvx8ACgkQJdeBCYSNAAOg9QCgu9x5BYVp3ssCgjY/8oqyOXAu MOoAoNPpDl5NZ4mQ9yyD0HILZ99raYl8 =RmYX -----END PGP SIGNATURE----- From mbp at canonical.com Mon Sep 12 08:16:25 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 12 Sep 2011 18:16:25 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6DBF1F.4080407@arbash-meinel.com> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> Message-ID: I think what you can do is: * install Python * build the extension using that Python and gcc * see if the gcc-built version actually loads into python (eg 'python -c "import dulwich.whatever"') * copy the extension file into your standalone-bzr directory, and also onto however many other machines you like * even put up the extension for others to use Martin From vila+bzr at canonical.com Mon Sep 12 08:21:35 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Mon, 12 Sep 2011 10:21:35 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (Eli Zaretskii's message of "Mon, 12 Sep 2011 04:00:03 -0400") References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: >>>>> Eli Zaretskii writes: > I use GCC for many years, on several different platforms. So > seeing a command that runs on a GNU system tells me enough to > adapt it to Windows. Ok ! >> running 'python setup.py build_ext -i -v' in bzr trunk: >> >> running build_ext >> building 'bzrlib._annotator_pyx' extension >> creating build/temp.linux-x86_64-2.7 >> creating build/temp.linux-x86_64-2.7/bzrlib >> gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_annotator_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o > Thanks, that's a beginning. The final commands that create a .so file > from *.o object files would be nice, as well as command(s) that copy > the .so to its final destination. Bah, sorry: $ python setup.py build_ext -i -v running build_ext building 'bzrlib._annotator_pyx' extension creating build/temp.linux-x86_64-2.7 creating build/temp.linux-x86_64-2.7/bzrlib gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_annotator_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/bzrlib/_annotator_pyx.o -o /home/vila/src/bzr/trunk/bzrlib/_annotator_pyx.so building 'bzrlib._bencode_pyx' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_bencode_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_bencode_pyx.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/bzrlib/_bencode_pyx.o -o /home/vila/src/bzr/trunk/bzrlib/_bencode_pyx.so building 'bzrlib._chunks_to_lines_pyx' extension gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_chunks_to_lines_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_chunks_to_lines_pyx.o gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/bzrlib/_chunks_to_lines_pyx.o -o /home/vila/src/bzr/trunk/bzrlib/_chunks_to_lines_pyx.so .. and so on for all extensiosn, i.e. each extension is a single .so and it's stored in the bzrlib directory itself (i.e. when running from sources it's found there). Vincent From eliz at gnu.org Mon Sep 12 08:23:42 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 04:23:42 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (message from Martin Pool on Mon, 12 Sep 2011 18:16:25 +1000) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> Message-ID: > From: Martin Pool > Date: Mon, 12 Sep 2011 18:16:25 +1000 > Cc: Eli Zaretskii , andrew at bemusement.org, bazaar at lists.canonical.com > > I think what you can do is: > > * install Python > * build the extension using that Python and gcc > * see if the gcc-built version actually loads into python (eg 'python > -c "import dulwich.whatever"') > * copy the extension file into your standalone-bzr directory, and > also onto however many other machines you like > * even put up the extension for others to use Thanks, will try that when I have time. From mbp at canonical.com Mon Sep 12 08:26:34 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 12 Sep 2011 18:26:34 +1000 Subject: create/switch b/w branches like in git In-Reply-To: References: Message-ID: On 12 September 2011 17:45, Bika wrote: > Hi, > > I really like git's easy to create&switch b/w feature branches. Is there a > way to accomplish this w/ bazaar? > > I would like something like a 1 directory bzr worktree where I can easily > check out different branches. (of course only related branches would be > checked out into a single working tree) > > is there a solution or usage scenario to accomplish this? Yes, there is, bzr-colo: m From eliz at gnu.org Mon Sep 12 08:51:22 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 04:51:22 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: (message from Vincent Ladeuil on Mon, 12 Sep 2011 10:21:35 +0200) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: > From: Vincent Ladeuil > Cc: bazaar at lists.canonical.com > Date: Mon, 12 Sep 2011 10:21:35 +0200 > > gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c bzrlib/_chunks_to_lines_pyx.c -o build/temp.linux-x86_64-2.7/bzrlib/_chunks_to_lines_pyx.o > gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions build/temp.linux-x86_64-2.7/bzrlib/_chunks_to_lines_pyx.o -o /home/vila/src/bzr/trunk/bzrlib/_chunks_to_lines_pyx.so > > .. and so on for all extensiosn, i.e. each extension is a single .so and > it's stored in the bzrlib directory itself (i.e. when running from > sources it's found there). Thanks! From mbp at canonical.com Mon Sep 12 08:55:47 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 12 Sep 2011 18:55:47 +1000 Subject: patch pilot un-report Message-ID: I had the flu last week and barely reviewed (or wrote) any code, so there's quite a lot of stuff in that needs some help. I'm handing over now to Jelmer, and I'll try to do a few more reviews than usual this week. Martin From bialix at ukr.net Mon Sep 12 09:08:46 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Mon, 12 Sep 2011 12:08:46 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> <4E69E98F.80504@ukr.net> <83bouu55nw.fsf@gnu.org> <4E69FADA.7010508@ukr.net> Message-ID: <4E6DCC1E.6020901@ukr.net> Vincent Ladeuil ?????: >>>>>> Alexander Belchenko writes: > > > Eli Zaretskii ?????: > >>> Date: Fri, 09 Sep 2011 13:25:19 +0300 > >>> From: Alexander Belchenko > >>> CC: mbp at canonical.com, bazaar at lists.canonical.com > >>> > >>> Python 2.6-2.7 are built with MSVC 2008 IIRC, so another version of > >>> run-time library should be used (msvcr90.dll IIRC). > >> > >> Shouldn't be a problem, as MinGW comes with import libraries for > >> msvcr90.dll as well. It's a matter of telling the right linker > >> switches in the appropriate README. > > > Python's distutils library can build C-extensions using mingw > > with appropriate switches. Maybe those switches could be > > extracted from some source, I can't say. > > To refresh my dusted memory, I grepped the distutils dir for python2.7: > > """Python was built with Visual Studio 2008; > extensions must be built with a compiler than can generate compatible binaries. > Visual Studio 2008 was not found on this system. If you have Cygwin installed, > you can try compiling with MingW32, by passing "-c mingw32" to setup.py.""") > > The same warning exist for Visual Studio 2003. Right. > I also vaguely recall being able to put this flag into some dot file to > avoid modifying the setup.py invocations (but it's so vague I wonder if > it was for perl instead...). You're talking about setup.cfg. But I never used it directly and have no idea about its syntax. -- All the dude wanted was his rug back From bialix at ukr.net Mon Sep 12 09:17:36 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Mon, 12 Sep 2011 12:17:36 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> Message-ID: <4E6DCE30.2020204@ukr.net> Eli Zaretskii ?????: >> From: Martin Pool >> Date: Mon, 12 Sep 2011 12:54:09 +1000 >> Cc: John Meinel , bazaar at lists.canonical.com, stephen at xemacs.org >> >> What actually goes wrong when you try to make a DLL in the 'normal' >> way? > > I didn't try because I don't know how to do that in this specific > case: what compiler switches to use, which libraries to link against, > and (last, but not least) where to place the resulting DLL. There > isn't a word about that in the dulwich distro, only a Makefile where I > found that it invokes setup.py, which in turn invokes some magic in a > Python module I don't have (distutils). > > If someone could run this on Unix or GNU system and tell me what was > the GCC command line run by setup.py, that would be a huge step > forward. Usually all you need is to run the following command: python setup.py build_ext -c mingw32 And you don't have to have proprietary compiler. HTH From john at szakmeister.net Mon Sep 12 10:15:08 2011 From: john at szakmeister.net (John Szakmeister) Date: Mon, 12 Sep 2011 06:15:08 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6DCC1E.6020901@ukr.net> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E69E5E4.3000608@ukr.net> <83d3fa58cp.fsf@gnu.org> <4E69E98F.80504@ukr.net> <83bouu55nw.fsf@gnu.org> <4E69FADA.7010508@ukr.net> <4E6DCC1E.6020901@ukr.net> Message-ID: On Mon, Sep 12, 2011 at 5:08 AM, Alexander Belchenko wrote: [snip] > You're talking about setup.cfg. But I never used it directly and have no > idea about its syntax. It's a standard ini file. I believe the section headers correspond to commands, and the entries correspond to options. I've used it for other things in the past. I haven't tried this, but for "build_ext -c mingw32", it might be: [build_ext] compiler=mingw32 HTH! -John From eliz at gnu.org Mon Sep 12 10:52:00 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 12 Sep 2011 06:52:00 -0400 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6DCE30.2020204@ukr.net> (message from Alexander Belchenko on Mon, 12 Sep 2011 12:17:36 +0300) References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <4E6DCE30.2020204@ukr.net> Message-ID: > Date: Mon, 12 Sep 2011 12:17:36 +0300 > From: Alexander Belchenko > CC: Martin Pool , bazaar at lists.canonical.com > > Usually all you need is to run the following command: > > python setup.py build_ext -c mingw32 > > And you don't have to have proprietary compiler. Thanks. From paul.hummer at canonical.com Mon Sep 12 18:48:41 2011 From: paul.hummer at canonical.com (Paul Hummer) Date: Mon, 12 Sep 2011 12:48:41 -0600 Subject: create/switch b/w branches like in git In-Reply-To: References: Message-ID: <4E6E5409.8020309@canonical.com> On 9/12/11 1:45 AM, Bika wrote: > I really like git's easy to create&switch b/w feature branches. Is > there a way to accomplish this w/ bazaar? > > I would like something like a 1 directory bzr worktree where I can > easily check out different branches. (of course only related branches > would be checked out into a single working tree) > > is there a solution or usage scenario to accomplish this? The bzr-colo[1] plugin will do just this. It's been my default way of setting up branch since I started using git regularly (a few months ago). I also have a few aliases that I use with it that make my life a bit easier, which I wrote about a few weeks ago[2]. [1] http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html [2] http://iamtherockstar.com/blog/2011/08/21/bazaar-workflow-revisited/ Cheers, Paul From vila+bzr at canonical.com Tue Sep 13 09:25:11 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Tue, 13 Sep 2011 11:25:11 +0200 Subject: Standup 2011-09-13 Message-ID: Bazaar Standup 2011-09-13 poolie ====== * flu most of the week * wiki upgraded, pqm upgraded, worked with mthaddon about tmpfs * next: hiring paperwork, * got the SRU for http://pad.lv/736216 finished (timeout in curl SSL connect during lp-login, many failures) * NEXT: finish inprogress bugs (especially ssh reconnect), look at more udd failures, QBR preparation Riddell ======= * more i18n stuff (including fixing the test framework to make babune happy), propose to enable translations everywhere, * uadw talk about using bazaar, * upate openSuse package to bzr-2.4.1 an some other plugins, * update release notes about translation process/workflow, * diagnose bzip2 issue with pristine-tar for kde packages built on openSUSE (http://pad.lv/845625), * next: if i18n patches are accepted, i18nize more of the code; also write a bzr-builddeb do for non-merge mode https://bugs.launchpad.net/bzr-builddeb/+bug/816376 jelmer ==== * wrap up the work on code imports for launchpad, * finished up porting bzr for lucid and hardy (python-2.5) which will allow bzr-2.4 to be deployed on jubany and the launchpad buildds * fixed failures to build from source for various bzr packages on oneiric * fix some UI paper-cuts (daily !), * reach < 100 failures for bzr-svn against the full bzr test suite, * next: quilt support and build from branch in the archive (bfbia) vila === "firefighting week" * Upgrade to oneiric beta (epic failure for both laptop and desktop on apple hardware :-/) * Assist mthaddon for the new pqm migration (lading in 23 mins instead of 45mins, suspiciously inconclusive attempt to use tmpfs), weird branch histories (no big deal), all 2.x branches migrated * help Riddell unbreak babune ;) * Fixed a few issues including append_revisions_only that fixed ~140 udd importer failures * released 2.4.1; still waiting for packagers and install builders to do this; * slow but significant progress on config * NEXT: couple of proposals regarding config; needs some discussions about library_state with poolie; trying to make udd driver more robust against lp downtime; adding more concurrency jam === * Away at sprint * Landed the get_parent_map estimates * NEXT: Looking at spiv's improved branch --stacked streaming. UDD UnicodeDecode errors. AOB === process discussion pristine-tar issues and whether we should fix them ourselves or wait for upstream From john at arbash-meinel.com Tue Sep 13 14:45:29 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 13 Sep 2011 16:45:29 +0200 Subject: [ANN] 2.4.1 has gone gold In-Reply-To: <874o0mq5t4.fsf@canonical.com> References: <874o0mq5t4.fsf@canonical.com> Message-ID: <4E6F6C89.4050506@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/08/2011 07:53 PM, Vincent Ladeuil wrote: > Now is the time for our first minor release in the 2.4 series: 2.4.1 > > Packagers and installers builders, it's up to you again ! > > We're catching up with the delay for 2.4.0 and this should put us back > in track on the overall schedule. > > See the Changelog at https://launchpad.net/bzr/2.4/2.4.1 for more > details about what is included and for the tarball. > > I'll make the official announcement next Tuesday morning UTC > (2011-09-12) with... whatever packages/installers are available at this > point. > > Have fun ! > > Vincent > > Windows installers bzr-2.4.1-1-* have been built and uploaded. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5vbIkACgkQJdeBCYSNAAOtBwCfRs9DSsKBm2oWg8FpS8NlvU77 nKIAnj0clnzx5ZrYPJKadrl5FfgVOflV =So1+ -----END PGP SIGNATURE----- From aaron at aaronbentley.com Tue Sep 13 14:58:41 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 13 Sep 2011 10:58:41 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats Message-ID: <4E6F6FA1.1010104@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm investigating the possibility of doing a mass upgrade of all Launchpad branches into up-to-date formats. Thereafter, we would either forbid old formats to be uploaded, or automatically upgrade them. Why are we considering this? - ---------------------------- The way Launchpad currently handles branch formats is broken. We permit stacked branches to have different formats from the branches they are stack on, which makes them unusable (Bug 828409). There are other ways of addressing these issues, like converting all stacked branches into formats compatible with their stacked-on branches, but these would be more complicated. Who would this break? - --------------------- Bazaar versions prior to 1.16.1, from June 2009. There is no supported desktop version of Ubuntu with a version that old, however Hardy Server is still supported, and it shipped with 1.3.1. RHEL 4 and 5 may also be affected. What are the next steps? - ------------------------ Examine Launchpad's current inventory of branches, determine whether there are major active branches on Launchpad in stale formats, and if so, why. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5vb5oACgkQ0F+nu1YWqI3IlgCfa55gbUFI/OL1h4qIUs53ERGg /VAAniVW0PSDwXaafOQkFThfTiVWCOXi =OXaq -----END PGP SIGNATURE----- From john at arbash-meinel.com Tue Sep 13 15:09:23 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 13 Sep 2011 17:09:23 +0200 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F6FA1.1010104@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> Message-ID: <4E6F7223.1080605@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/13/2011 04:58 PM, Aaron Bentley wrote: > Hi all, > > I'm investigating the possibility of doing a mass upgrade of all > Launchpad branches into up-to-date formats. Thereafter, we would > either forbid old formats to be uploaded, or automatically upgrade them. I'm personally in favor of auto-upgrading all branches. With the small caveat of actually looking at the repositories that are in old formats and checking if those projects are currently active (which you've mentioned you're looking to do). > > Why are we considering this? > ---------------------------- > The way Launchpad currently handles branch formats is broken. We > permit stacked branches to have different formats from the branches > they are stack on, which makes them unusable (Bug 828409). There are > other ways of addressing these issues, like converting all stacked > branches into formats compatible with their stacked-on branches, but > these would be more complicated. Right. If the 'master' branch is upgraded, then all the stacked branches would be inaccessible (until you 'bzr upgrade' them as well.) > > Who would this break? > --------------------- > Bazaar versions prior to 1.16.1, from June 2009. There is no > supported desktop version of Ubuntu with a version that old, however > Hardy Server is still supported, and it shipped with 1.3.1. RHEL 4 > and 5 may also be affected. One small bit. bzr-1.6 was the first one to introduce stacking. So branches/repositories created with a bzr older than 1.6 cannot be stacked. Thus Hardy Server cannot be creating stacked branches which could then get broken by upgrading the stacked-on location. I don't think we have an SRU for bzr-2.0 into Hardy, but I do believe we have packages for it. Our ppa currently has: 2.3.4-0~bazaar1~hardy1. I'm pretty sure we have equivalent packages for RHEL. So if we say "You must use 2a format on Launchpad", I'm pretty sure people that use Launchpad could have access to an upgraded version of bzr. > > What are the next steps? > ------------------------ > Examine Launchpad's current inventory of branches, determine whether > there are major active branches on Launchpad in stale formats, and if > so, why. > > Aaron Right. As much as possible, if we can get feedback from people about old versions of bzr, that can drive how we use it on Launchpad. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5vciMACgkQJdeBCYSNAANa0gCgrDnsPrR82tpcfNYdIqGMKj2H +Q0AnjOtoQy3/amZvWKHNbWj7UxFGbyL =/SLV -----END PGP SIGNATURE----- From jelmer at canonical.com Tue Sep 13 15:26:16 2011 From: jelmer at canonical.com (Jelmer Vernooij) Date: Tue, 13 Sep 2011 17:26:16 +0200 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F7223.1080605@arbash-meinel.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E6F7223.1080605@arbash-meinel.com> Message-ID: <4E6F7618.3080504@canonical.com> On 09/13/2011 05:09 PM, John Arbash Meinel wrote: > On 09/13/2011 04:58 PM, Aaron Bentley wrote: >> I'm investigating the possibility of doing a mass upgrade of all >> Launchpad branches into up-to-date formats. Thereafter, we would >> either forbid old formats to be uploaded, or automatically upgrade them. > I'm personally in favor of auto-upgrading all branches. With the small > caveat of actually looking at the repositories that are in old formats > and checking if those projects are currently active (which you've > mentioned you're looking to do). I think auto-upgrading all branches is a good idea, too. > >> Who would this break? >> --------------------- >> Bazaar versions prior to 1.16.1, from June 2009. There is no >> supported desktop version of Ubuntu with a version that old, however >> Hardy Server is still supported, and it shipped with 1.3.1. RHEL 4 >> and 5 may also be affected. > One small bit. bzr-1.6 was the first one to introduce stacking. So > branches/repositories created with a bzr older than 1.6 cannot be > stacked. Thus Hardy Server cannot be creating stacked branches which > could then get broken by upgrading the stacked-on location. > > I don't think we have an SRU for bzr-2.0 into Hardy, but I do believe we > have packages for it. Our ppa currently has: 2.3.4-0~bazaar1~hardy1. Both hardy and hardy-updates have 1.3. Debian oldstable (lenny) has 1.5. Cheers, Jelmer From gary.poster at canonical.com Tue Sep 13 15:29:58 2011 From: gary.poster at canonical.com (Gary Poster) Date: Tue, 13 Sep 2011 11:29:58 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F6FA1.1010104@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> Message-ID: Sounds good. The only thing I can think of to be especially careful of is sourcecode branches. Hiccups there can affect ec2, buildbot, and production. The only thing I can think of happening is just some slow branch updates until we migrate the local branches, so no really big deal. (I have a vague memory of other pain from changes like this back in Foundations days, but nothing helpful.) Gary From eliz at gnu.org Tue Sep 13 15:54:04 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 13 Sep 2011 18:54:04 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> Message-ID: <83r53kwi8z.fsf@gnu.org> > From: Martin Pool > Date: Mon, 12 Sep 2011 18:16:25 +1000 > Cc: Eli Zaretskii , andrew at bemusement.org, bazaar at lists.canonical.com > > I think what you can do is: > > * install Python > * build the extension using that Python and gcc > * see if the gcc-built version actually loads into python (eg 'python > -c "import dulwich.whatever"') ^^^^^^^^ Can you or someone else please tell what that "whatever" part might be, and how do I use this command to verify that the extensions indeed load into python? Also, which bzr-git commands are expected to gain performance due to the extensions, and what kind of speedup I should expect? I think I succeeded to build the extensions using the above instructions (I will report the details in a separate message when I'm done testing), but I have difficulty convincing myself that the extensions are indeed used and work. So I need help in that department, please. TIA From aaron at aaronbentley.com Tue Sep 13 15:59:40 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 13 Sep 2011 11:59:40 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F7223.1080605@arbash-meinel.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E6F7223.1080605@arbash-meinel.com> Message-ID: <4E6F7DEC.4020608@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-13 11:09 AM, John Arbash Meinel wrote: >> Who would this break? --------------------- Bazaar versions prior >> to 1.16.1, from June 2009. There is no supported desktop version >> of Ubuntu with a version that old, however Hardy Server is still >> supported, and it shipped with 1.3.1. RHEL 4 and 5 may also be >> affected. > > One small bit. bzr-1.6 was the first one to introduce stacking. So > branches/repositories created with a bzr older than 1.6 cannot be > stacked. Thus Hardy Server cannot be creating stacked branches > which could then get broken by upgrading the stacked-on location. Sure. I mean that stock Hardy doesn't support 2a format, so if we upgrade all Launchpad branches to 2a (or the subtree version), Hardy will no longer be able to use Launchpad branches. > I don't think we have an SRU for bzr-2.0 into Hardy, but I do > believe we have packages for it. Our ppa currently has: > 2.3.4-0~bazaar1~hardy1. Yes, I meant to mention that, but it must have gotten lost in editing. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk5vfewACgkQ0F+nu1YWqI1CKgCY2fdrod/AJHve8S8t8WSg+sWL 2ACfbLbFPk9f1fiLY6X6+wirUnVYiGg= =drFF -----END PGP SIGNATURE----- From vila+bzr at canonical.com Tue Sep 13 16:02:23 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Tue, 13 Sep 2011 18:02:23 +0200 Subject: [ANN] bzr 2.4.1 released Message-ID: Hi all, Here comes our new stable release: 2.4.1 Bazaar is part of the GNU project to produce a free operating system. After the slight delay for the 2.4.0 release, we're back on our regular release schedule. This is a bugfix release. Upgrading is recommended for all users on earlier 2.4 releases. 2.4.1 contains all known bug fixes for all stable releases (including the ones we made for the previous stable series). Thanks to all participants, whether you sent merge proposals, comments, suggestions and feedback, we very much appreciate all of them. Bazaar is now available for download from https://launchpad.net/bzr/2.4/2.4b4/ as a source tarball. Installers are available for windows from the url above, OSX ones are on their way. 2.4.1 has also been uploaded to debian and ubuntu. The detailed changelog is available below, Vincent Bug Fixes ********* * ``config.LocationMatcher`` properly excludes unrelated sections. (Vincent Ladeuil, #829237) * ``dirstate.fdatasync`` and ``repository.fdatasync`` can now properly be disabled. (Vincent Ladeuil, #824513) * Disable ``os.fsync`` and ``os.fdatasync`` by default when running ``bzr selftest``. You can use ``--sync`` to re-enable them. (John Arbash Meinel, #837293) * Fix i18n use when no environment variables are set. (Jelmer Vernooij, #810701) * Avoid UnicodeDecode error when reporting EINVAL from transports. (IWATA Hidetaka, #829237) Documentation ************* * Corrected documentation for BZR_PROGRESS_BAR. (Dennis Benzinger, #735417) Testing ******* * The test suite should now be able to run under weird environments where ``/etc/passwd`` doesn't contain the ``uid`` for the user running selftest or where ``fakeroot`` is used but ``/root`` is inacessible. (Vincent Ladeuil, #825027) From a.badger at gmail.com Tue Sep 13 17:27:14 2011 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 13 Sep 2011 10:27:14 -0700 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F7DEC.4020608@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E6F7223.1080605@arbash-meinel.com> <4E6F7DEC.4020608@aaronbentley.com> Message-ID: <20110913172714.GR4570@unaka.lan> On Tue, Sep 13, 2011 at 11:59:40AM -0400, Aaron Bentley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11-09-13 11:09 AM, John Arbash Meinel wrote: > >> Who would this break? --------------------- Bazaar versions prior > >> to 1.16.1, from June 2009. There is no supported desktop version > >> of Ubuntu with a version that old, however Hardy Server is still > >> supported, and it shipped with 1.3.1. RHEL 4 and 5 may also be > >> affected. > > RHEL4 cannot support bzr out-of-the-box since it ships with python-2.3. RHEL5 does not ship bzr but the Fedora project ships it in our popular EPEL repositories as addons to RHEL. It's at version 2.1.1 RHEL6 shipped with bzr. It's at version 2.1.1 as well. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From aaron at aaronbentley.com Tue Sep 13 17:33:01 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Tue, 13 Sep 2011 13:33:01 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <20110913172714.GR4570@unaka.lan> References: <4E6F6FA1.1010104@aaronbentley.com> <4E6F7223.1080605@arbash-meinel.com> <4E6F7DEC.4020608@aaronbentley.com> <20110913172714.GR4570@unaka.lan> Message-ID: <4E6F93CD.8070405@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-13 01:27 PM, Toshio Kuratomi wrote: > RHEL4 cannot support bzr out-of-the-box since it ships with > python-2.3. > > RHEL5 does not ship bzr but the Fedora project ships it in our > popular EPEL repositories as addons to RHEL. It's at version > 2.1.1 > > RHEL6 shipped with bzr. It's at version 2.1.1 as well. Excellent. Thanks for the info, I had trouble finding it. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5vk80ACgkQ0F+nu1YWqI2IcQCfXvpWDHZgY1IvaCL/ILst4+Sh R54AnA42qeucUIhDin1N/DWKemhiwCpa =4Ebz -----END PGP SIGNATURE----- From bialix at ukr.net Tue Sep 13 19:35:55 2011 From: bialix at ukr.net (Alexander Belchenko) Date: Tue, 13 Sep 2011 22:35:55 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83r53kwi8z.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> Message-ID: <4E6FB09B.6000607@ukr.net> 13.09.2011 18:54, Eli Zaretskii ?????: >> From: Martin Pool >> Date: Mon, 12 Sep 2011 18:16:25 +1000 >> Cc: Eli Zaretskii , andrew at bemusement.org, bazaar at lists.canonical.com >> >> I think what you can do is: >> >> * install Python >> * build the extension using that Python and gcc >> * see if the gcc-built version actually loads into python (eg 'python >> -c "import dulwich.whatever"') > ^^^^^^^^ > Can you or someone else please tell what that "whatever" part might > be, and how do I use this command to verify that the extensions indeed > load into python? I think it will be almost impossible to do without having bzrlib accessible to your python installation (most likely you'll get ImportError: no module named bzrlib). > > Also, which bzr-git commands are expected to gain performance due to > the extensions, and what kind of speedup I should expect? > > I think I succeeded to build the extensions using the above > instructions (I will report the details in a separate message when I'm > done testing), but I have difficulty convincing myself that the > extensions are indeed used and work. So I need help in that > department, please. > > TIA > > From gordon at doxxx.net Wed Sep 14 00:17:03 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Tue, 13 Sep 2011 20:17:03 -0400 Subject: [ANN] 2.4.1 has gone gold In-Reply-To: <4E6F6C89.4050506@arbash-meinel.com> References: <874o0mq5t4.fsf@canonical.com> <4E6F6C89.4050506@arbash-meinel.com> Message-ID: <4E6FF27F.4060304@doxxx.net> Mac OS X 10.6 installer uploaded. From eliz at gnu.org Wed Sep 14 03:03:16 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 14 Sep 2011 06:03:16 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E6FB09B.6000607@ukr.net> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> Message-ID: <83litrx1u3.fsf@gnu.org> > Date: Tue, 13 Sep 2011 22:35:55 +0300 > From: Alexander Belchenko > CC: Martin Pool , bazaar at lists.canonical.com > > 13.09.2011 18:54, Eli Zaretskii ?????: > >> From: Martin Pool > >> Date: Mon, 12 Sep 2011 18:16:25 +1000 > >> Cc: Eli Zaretskii , andrew at bemusement.org, bazaar at lists.canonical.com > >> > >> I think what you can do is: > >> > >> * install Python > >> * build the extension using that Python and gcc > >> * see if the gcc-built version actually loads into python (eg 'python > >> -c "import dulwich.whatever"') > > ^^^^^^^^ > > Can you or someone else please tell what that "whatever" part might > > be, and how do I use this command to verify that the extensions indeed > > load into python? > > I think it will be almost impossible to do without having bzrlib > accessible to your python installation (most likely you'll get > ImportError: no module named bzrlib). Jelmer suggested (off-list) to use this: python -c "import dulwich._pack" and it does not error out. From mbp at canonical.com Wed Sep 14 05:04:44 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 14 Sep 2011 15:04:44 +1000 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83litrx1u3.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> Message-ID: On 14 September 2011 13:03, Eli Zaretskii wrote: >> I think it will be almost impossible to do without having bzrlib >> accessible to your python installation (most likely you'll get >> ImportError: no module named bzrlib). (You probably can't actually do much with it, but you ought to be able to load the C extensions; generally speaking extension modules don't actually import Python modules. In this case it looks like it works.) > > Jelmer suggested (off-list) to use this: > > ?python -c "import dulwich._pack" > > and it does not error out. That's great. So then if you install those .pyd(?) files inside the selfcontained bzr install, you should be in business. (There is some chance the compiler or Python is ABI-incompatible but it's worth a go.) m From vila+bzr at canonical.com Wed Sep 14 05:35:09 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Wed, 14 Sep 2011 07:35:09 +0200 Subject: [ANN] bzr 2.4.1 released (errata) In-Reply-To: (Vincent Ladeuil's message of "Tue, 13 Sep 2011 18:02:23 +0200") References: Message-ID: >>>>> Vincent Ladeuil typo'ed: > Bazaar is now available for download from > https://launchpad.net/bzr/2.4/2.4b4/ as a source tarball. Errata, this should read: https://launchpad.net/bzr/2.4/2.4.1 of course, Vincent From mbp at canonical.com Wed Sep 14 06:07:40 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 14 Sep 2011 16:07:40 +1000 Subject: [ANN] bzr 2.4.1 released In-Reply-To: References: Message-ID: On 14 September 2011 02:02, Vincent Ladeuil wrote: > Hi all, > > Here comes our new stable release: 2.4.1 Thanks for managing the release. I am really pleased by how smoothly releases seem to come out now. > Bazaar is part of the GNU project > to produce a free operating system. Can you add to your template that it's sponsored by Canonical, with a link? That's roughly as important as being a GNU project. > 2.4.1 has also been uploaded to debian and ubuntu. I see it is in Debian already (which is excellent) but Ubuntu's branch and packages only have 2.4.0-3ubuntu1. Since we're past BetaFreeze, I think we need a freeze exception[1] - which can very likely be granted since these are safe changes, but it does need to be done. Is that already underway? [1] https://wiki.ubuntu.com/FreezeExceptionProcess m From mbp at canonical.com Wed Sep 14 08:34:27 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 14 Sep 2011 18:34:27 +1000 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F6FA1.1010104@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> Message-ID: On 14 September 2011 00:58, Aaron Bentley wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > > I'm investigating the possibility of doing a mass upgrade of all > Launchpad branches into up-to-date formats. ?Thereafter, we would > either forbid old formats to be uploaded, or automatically upgrade them. Hi, I'm enormously glad you're looking in to this: it will speed things up, remove a support burden, and just be a lot tidier. > What are the next steps? > - ------------------------ > Examine Launchpad's current inventory of branches, determine whether > there are major active branches on Launchpad in stale formats, and if > so, why. .... I guess after that we need some announcement that it will happen, and possibly to contact people who are using old clients. I think that you may be able to look at the xmlrpc access logs for user-agents to see how many old clients are out there. Martin From aaron at aaronbentley.com Wed Sep 14 13:10:27 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Wed, 14 Sep 2011 09:10:27 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: References: <4E6F6FA1.1010104@aaronbentley.com> Message-ID: <4E70A7C3.2060203@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-14 04:34 AM, Martin Pool wrote: > .... I guess after that we need some announcement that it will > happen, and possibly to contact people who are using old clients. Certainly if we decide to execute this, we'll announce it. I hadn't thought of contacting users of old clients, though. > I think that you may be able to look at the xmlrpc access logs for > user-agents to see how many old clients are out there. I actually thought bzr didn't send a version string. Happy to be wrong about that. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk5wp78ACgkQ0F+nu1YWqI2tywCfVKfqUxYWInhwnDT8pWvjp8o+ UMoAl3fBxQsov4kaRmPPUmB1ySburaw= =Yrhs -----END PGP SIGNATURE----- From john at arbash-meinel.com Wed Sep 14 13:31:35 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Wed, 14 Sep 2011 15:31:35 +0200 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E70A7C3.2060203@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E70A7C3.2060203@aaronbentley.com> Message-ID: <4E70ACB7.6060201@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/14/2011 3:10 PM, Aaron Bentley wrote: > On 11-09-14 04:34 AM, Martin Pool wrote: >> .... I guess after that we need some announcement that it will >> happen, and possibly to contact people who are using old >> clients. > > Certainly if we decide to execute this, we'll announce it. I > hadn't thought of contacting users of old clients, though. > >> I think that you may be able to look at the xmlrpc access logs >> for user-agents to see how many old clients are out there. > > I actually thought bzr didn't send a version string. Happy to be > wrong about that. > > Aaron Since we implemented "Protocol version 3" of the bzr:// protocol, it sends a header section. As near as I can tell, nothing is actually done with those headers. It looks like both the client and the server are using the default of: self._headers = {'Software version': bzrlib.__version__} However: MESSAGE_VERSION_THREE = 'bzr message 3 (bzr 1.6)\n' That also means that the older clients for bzr 1.3, etc, won't be setting the version headers. Then again, for old versions like that, we can just tell that they are using: REQUEST_VERSION_TWO = 'bzr request 2\n' As their first request. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5wrLcACgkQJdeBCYSNAAN6twCgu+gtbX/7caDFooaE6LlEHVtn QJMAn3ypllrWLT03OHlIYNy9xbN3XyRc =285h -----END PGP SIGNATURE----- From mbp at canonical.com Wed Sep 14 20:52:27 2011 From: mbp at canonical.com (Martin Pool) Date: Thu, 15 Sep 2011 06:52:27 +1000 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E70ACB7.6060201@arbash-meinel.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E70A7C3.2060203@aaronbentley.com> <4E70ACB7.6060201@arbash-meinel.com> Message-ID: On 14 September 2011 23:31, John Arbash Meinel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/14/2011 3:10 PM, Aaron Bentley wrote: >> On 11-09-14 04:34 AM, Martin Pool wrote: >>> .... I guess after that we need some announcement that it will >>> happen, and possibly to contact people who are using old >>> clients. >> >> Certainly if we decide to execute this, we'll announce it. ?I >> hadn't thought of contacting users of old clients, though. >> >>> I think that you may be able to look at the xmlrpc access logs >>> for user-agents to see how many old clients are out there. >> >> I actually thought bzr didn't send a version string. ?Happy to be >> wrong about that. >> >> Aaron > > Since we implemented "Protocol version 3" of the bzr:// protocol, it > sends a header section. As near as I can tell, nothing is actually > done with those headers. The reason I suggest looking specifically at the lp directory xmlrpc queries, rather than ssh connections, is: * we do send the bzrlib version in the user-agent string and I think always have since it was introduced * this query is sent on all connection attempts, including read-only connections (but not by bzr ~>2.4, but that's irrelevant to this) * if it's not already logged by launchpad's http server it should be trivial to do so m From aaron at aaronbentley.com Wed Sep 14 21:37:13 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Wed, 14 Sep 2011 17:37:13 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: References: <4E6F6FA1.1010104@aaronbentley.com> <4E70A7C3.2060203@aaronbentley.com> <4E70ACB7.6060201@arbash-meinel.com> Message-ID: <4E711E89.6000304@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-14 04:52 PM, Martin Pool wrote: >>>> I think that you may be able to look at the xmlrpc access >>>> logs for user-agents to see how many old clients are out >>>> there. > The reason I suggest looking specifically at the lp directory > xmlrpc queries, rather than ssh connections, is: Ah. The SSH service is built on XML-RPC, so I thought you meant that. > * we do send the bzrlib version in the user-agent string and I > think always have since it was introduced Cool. I'll check it out. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5xHokACgkQ0F+nu1YWqI0a2wCcDS3e0+7+iVJ/aLqZcfhBimq6 MCQAnA0ew26ZMjyJIAnr66jIOhjFmkPL =Sj59 -----END PGP SIGNATURE----- From eliz at gnu.org Thu Sep 15 17:27:46 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 15 Sep 2011 20:27:46 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> Message-ID: <83zki5vhpp.fsf@gnu.org> > From: Martin Pool > Date: Wed, 14 Sep 2011 15:04:44 +1000 > Cc: Alexander Belchenko , bazaar at lists.canonical.com > > > Jelmer suggested (off-list) to use this: > > > > ?python -c "import dulwich._pack" > > > > and it does not error out. > > That's great. So then if you install those .pyd(?) files inside the > selfcontained bzr install, you should be in business. (There is some > chance the compiler or Python is ABI-incompatible but it's worth a > go.) Well, it does work. I've been using it for a couple of days with several git repositories, and didn't see any problems. The speedup is moderate (around 30% to 40%), which is less than what I hoped for; e.g., the initial branch from gnulib still takes around 1 hour. But it's better than 2 ;-) I made sure that the *.pyd files are indeed loaded by bzr: first, with a 3-line "plugin" that just imported all three of them, and then by using the "Find handle" feature of the Process Explorer utility that clearly shows that bzr.exe has them open when bzr-git is being used. If there's a good place where I can upload these *.pyd files, perhaps to the bzr-git page on Launchpad, where others could download them, please tell me what to do. Finally, for the record, I'm going to describe here how to build and install these extensions using MinGW. Most of the info came from the advice I got here and from Python docs, but not all of it was correct or optimal. I would highly recommend to add what's below to the dulwich distro, in some README.mingw file or something. Here's the final recipe I came up with: 1) Install Python. It should be the precise version displayed by "bzr version", which is currently 2.6.6. (I tried Python 2.7 at first, but bzr would not load the *.pyd files produced by that.) There's no link on the Python download page to version 2.6.6, but by looking around I found its installer here: http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi 2) Customize Python's distutils to use MinGW. There are several ways of doing that, all of them documented on this page: http://docs.python.org/install/index.html#install-index The method which was suggested on this list, i.e. to use the "-c mingw32" switch to the setup.py script's "build" commands, is not the best one, because (a) you need to remember to type it every time, and (b) because only the "build" commands accept that switch, "install" does not. A better way is to add this to the distutils configuration file: [build] compiler = mingw32 This can be added either to %HOME%\pydistutils.cfg file (assuming you have HOME defined) or to the Lib\distutils\distitils.cfg file under the main Python installation directory. I did the former. If the configuration file does not exist, create it. 3) Make sure to add Python's installation directory to Path. Then go to the directory where you unpacked dulwich -- that's where the setup.py script lives -- and type these commands: python setup.py build python setup.py build_ext -i Alternatively, if you have a Make utility, you can type this one command: make Any of these 2 ways creates the 3 *.pyd files in this sub-directory of dulwich: build\lib.win32-2.6\dulwich 4) Make sure Python can load the *.pyd files you produced: python -c "import dulwich._pack" python -c "import dulwich._diff_tree" python -c "import dulwich._objects" 5) Copy those 3 *.pyd files from build\lib.win32-2.6\dulwich to your site-packages\dulwich sub-directory of the Bazaar installation. 6) That's it! You are set. Last, but not least: I'd like to thank everyone here who helped by information and advice. From jelmer at vernstok.nl Thu Sep 15 17:36:23 2011 From: jelmer at vernstok.nl (Jelmer Vernooij) Date: Thu, 15 Sep 2011 19:36:23 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83zki5vhpp.fsf@gnu.org> References: <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> <83zki5vhpp.fsf@gnu.org> Message-ID: <20110915173623.GA11571@vernstok.nl> On Thu, Sep 15, 2011 at 08:27:46PM +0300, Eli Zaretskii wrote: > > From: Martin Pool > > Date: Wed, 14 Sep 2011 15:04:44 +1000 > > Cc: Alexander Belchenko , bazaar at lists.canonical.com > > > Jelmer suggested (off-list) to use this: > > > ?python -c "import dulwich._pack" > > > and it does not error out. > > That's great. So then if you install those .pyd(?) files inside the > > selfcontained bzr install, you should be in business. (There is some > > chance the compiler or Python is ABI-incompatible but it's worth a > > go.) > Well, it does work. I've been using it for a couple of days with > several git repositories, and didn't see any problems. The speedup is > moderate (around 30% to 40%), which is less than what I hoped for; > e.g., the initial branch from gnulib still takes around 1 hour. But > it's better than 2 ;-) > I made sure that the *.pyd files are indeed loaded by bzr: first, with > a 3-line "plugin" that just imported all three of them, and then by > using the "Find handle" feature of the Process Explorer utility that > clearly shows that bzr.exe has them open when bzr-git is being used. > If there's a good place where I can upload these *.pyd files, perhaps > to the bzr-git page on Launchpad, where others could download them, > please tell me what to do. > Finally, for the record, I'm going to describe here how to build and > install these extensions using MinGW. Most of the info came from the > advice I got here and from Python docs, but not all of it was correct > or optimal. I would highly recommend to add what's below to the > dulwich distro, in some README.mingw file or something. Glad to hear you got it working, and thanks for writing this down. I'll have a look at adding this as README.mingw to bzr-git, though I wonder if the instructions could be simplified: > Here's the final recipe I came up with: > 1) Install Python. It should be the precise version displayed by > "bzr version", which is currently 2.6.6. (I tried Python 2.7 at > first, but bzr would not load the *.pyd files produced by that.) > There's no link on the Python download page to version 2.6.6, but > by looking around I found its installer here: > http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi > 2) Customize Python's distutils to use MinGW. There are several ways > of doing that, all of them documented on this page: > http://docs.python.org/install/index.html#install-index > The method which was suggested on this list, i.e. to use the > "-c mingw32" switch to the setup.py script's "build" commands, is > not the best one, because (a) you need to remember to type it > every time, and (b) because only the "build" commands accept that > switch, "install" does not. > A better way is to add this to the distutils configuration file: > [build] > compiler = mingw32 > This can be added either to %HOME%\pydistutils.cfg file (assuming > you have HOME defined) or to the Lib\distutils\distitils.cfg file > under the main Python installation directory. I did the former. > If the configuration file does not exist, create it. Is there a reason you can't just run "python setup.py install" after this, as the final step, perhaps specifying a different --root ? Cheers, Jelmer From john at arbash-meinel.com Thu Sep 15 18:03:32 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Thu, 15 Sep 2011 20:03:32 +0200 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <83zki5vhpp.fsf@gnu.org> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> <83zki5vhpp.fsf@gnu.org> Message-ID: <4E723DF4.1070801@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > 3) Make sure to add Python's installation directory to Path. Then go > to the directory where you unpacked dulwich -- that's where the > setup.py script lives -- and type these commands: > > python setup.py build > python setup.py build_ext -i > > Alternatively, if you have a Make utility, you can type this one > command: > > make > > Any of these 2 ways creates the 3 *.pyd files in this > sub-directory of dulwich: > > build\lib.win32-2.6\dulwich I'm pretty sure you can run: python setup.py bdist_msi or python setup.py bdist_wininst Which would create an installer for the files for another Python installation. This won't install them into the bazaar package directory, but it might be a start for something that would. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5yPfQACgkQJdeBCYSNAAOa2gCgiacbsXDtR9rEzkdRs+izy97t ZxwAn0mFveGzHlW9S9+mmP0LZvd+0WDj =osbe -----END PGP SIGNATURE----- From eliz at gnu.org Thu Sep 15 19:59:07 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 15 Sep 2011 22:59:07 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <20110915173623.GA11571@vernstok.nl> References: <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> <83zki5vhpp.fsf@gnu.org> <20110915173623.GA11571@vernstok.nl> Message-ID: <83wrd9vapg.fsf@gnu.org> > Date: Thu, 15 Sep 2011 19:36:23 +0200 > From: Jelmer Vernooij > Cc: Martin Pool , bialix at ukr.net, > bazaar at lists.canonical.com > > > [build] > > compiler = mingw32 > > > This can be added either to %HOME%\pydistutils.cfg file (assuming > > you have HOME defined) or to the Lib\distutils\distitils.cfg file > > under the main Python installation directory. I did the former. > > If the configuration file does not exist, create it. > > Is there a reason you can't just run "python setup.py install" after this, as > the final step, perhaps specifying a different --root ? Maybe, I didn't try that. The distutils documentation page doesn't document this switch, and "setup.py --help" says just this: --root install everything relative to this alternate root directory which of course is indecipherable for someone whose knowledge of Python conventions is nil. And since it was just a matter of copying 3 files... It's possible that if the Makefile mentioned this switch I would have tried harder, though. From eliz at gnu.org Thu Sep 15 20:05:00 2011 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 15 Sep 2011 23:05:00 +0300 Subject: Dulwich C extensions and stand-alone Windows installation of bzr In-Reply-To: <4E723DF4.1070801@arbash-meinel.com> References: <838vq3zolg.fsf@gnu.org> <871uvvk51q.fsf@uwakimon.sk.tsukuba.ac.jp> <83obyu5ex9.fsf@gnu.org> <20110912064817.GA17571@flay.puzzling.org> <4E6DB84D.3080607@arbash-meinel.com> <4E6DBF1F.4080407@arbash-meinel.com> <83r53kwi8z.fsf@gnu.org> <4E6FB09B.6000607@ukr.net> <83litrx1u3.fsf@gnu.org> <83zki5vhpp.fsf@gnu.org> <4E723DF4.1070801@arbash-meinel.com> Message-ID: <83vcstvafn.fsf@gnu.org> > Date: Thu, 15 Sep 2011 20:03:32 +0200 > From: John Arbash Meinel > CC: Martin Pool , bialix at ukr.net, > bazaar at lists.canonical.com > > I'm pretty sure you can run: > > python setup.py bdist_msi > or > python setup.py bdist_wininst > > Which would create an installer for the files for another Python > installation. Thanks. Only the latter is shown by "setup.py --help-commands", FWIW. > This won't install them into the bazaar package directory, > but it might be a start for something that would. Well, an installer for Python sounds not very useful, as whoever has Python doesn't really need these *.pyd files, unless she is using bzr-git. A Bazaar installer would be nice, but I have no idea how to do that. Hopefully, someone would. From vila+bzr at canonical.com Fri Sep 16 13:37:52 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Fri, 16 Sep 2011 15:37:52 +0200 Subject: [ANN] bzr-2.5b1 has gone gold ! Message-ID: Heads up ! Now that I have your attention: thanks again to packagers and installer builders for releasing 2.4.1 in record time. Don't stop too fast, here comes 2.5b1 ! This is an announcement for the packaging people for them to get binary packages built so that we can get the beta release announcement out. The release will be announced on Tuesday morning UTC with whatever installers are available at this point. The tarball has been uploaded at https://launchpad.net/bzr/2.5/2.5b1 To all contributors: I noticed too late in the release process that our whatsnew document is almost empty :-( Can everybody have a look at the release notes and summarized the most important achievements for this 2.5 series we are starting ? I'll summarize your answers in a merge proposal asap. Also, for yet unknown reasons the release-notes/bzr-2.5.txt had several sections not sorted (fixed in the tarball), any idea ? Thanks in advance, Vincent From john at arbash-meinel.com Fri Sep 16 14:01:34 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Fri, 16 Sep 2011 16:01:34 +0200 Subject: [ANN] bzr-2.5b1 has gone gold ! In-Reply-To: References: Message-ID: <4E7356BE.7010604@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/16/2011 3:37 PM, Vincent Ladeuil wrote: > Heads up ! > > Now that I have your attention: thanks again to packagers and > installer builders for releasing 2.4.1 in record time. > > Don't stop too fast, here comes 2.5b1 ! > > This is an announcement for the packaging people for them to get > binary packages built so that we can get the beta release > announcement out. > > The release will be announced on Tuesday morning UTC with whatever > installers are available at this point. I probably won't get to it until Monday at the earliest. Its almost EOD Friday now, and I don't want to leave the EC2 instance running all weekend 'in case' I get time to poke at it. I'll also note for plugin authors, if you want updated plugins in the installer, please email me, or even better provide a patch to 'lp:bzr-windows-installers'. > > The tarball has been uploaded at > https://launchpad.net/bzr/2.5/2.5b1 > > To all contributors: I noticed too late in the release process that > our whatsnew document is almost empty :-( > > Can everybody have a look at the release notes and summarized the > most important achievements for this 2.5 series we are starting ? gpg changes, i18n changes, bzr log --match-authors, bzr add skips large files, work on supporting "location,branch=XXX" to reference colocated branches, bzr uncommit/push/pull now talk about tags, branching into an empty repository from a stacked branch is *much* faster. Those seem to be the primary user-visible changes. > > I'll summarize your answers in a merge proposal asap. > > Also, for yet unknown reasons the release-notes/bzr-2.5.txt had > several sections not sorted (fixed in the tarball), any idea ? Jonathan Riddell didn't realize it was supposed to be in sorted order. I've informed him, and I think he's been submitting new ones sorted. > > Thanks in advance, > > Vincent > John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zVr4ACgkQJdeBCYSNAAOK9wCcDo6oVECyQhSwDIzIt0+NhiGX 1CAAoMfx/2Gbg/9UINC8x3rp8TWZput1 =Qfd+ -----END PGP SIGNATURE----- From jriddell at ubuntu.com Fri Sep 16 15:49:48 2011 From: jriddell at ubuntu.com (Jonathan Riddell) Date: Fri, 16 Sep 2011 16:49:48 +0100 Subject: bzr ready for translations Message-ID: <20110916154948.GM3728@starsky.19inch.net> Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be translated. If you want to help bring bzr to those who prefer to work in non-English languages please help translate at Launchpad (you will need to be in the appropriate Launchpad translations team). The translation will involve quite a bit of specialist language (what is French for "colocated branch"?) and I expect there are strings yet that need to be added to the translation file. I also need to look at translations for plugins. Jonathan From david.planella at ubuntu.com Fri Sep 16 16:13:56 2011 From: david.planella at ubuntu.com (David Planella) Date: Fri, 16 Sep 2011 18:13:56 +0200 Subject: bzr ready for translations In-Reply-To: <20110916154948.GM3728@starsky.19inch.net> References: <20110916154948.GM3728@starsky.19inch.net> Message-ID: <1316189636.2153.1222.camel@avenc> El dv 16 de 09 de 2011 a les 16:49 +0100, en/na Jonathan Riddell va escriure: > Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be > translated. If you want to help bring bzr to those who prefer to work > in non-English languages please help translate at Launchpad (you will > need to be in the appropriate Launchpad translations team). > > The translation will involve quite a bit of specialist language (what > is French for "colocated branch"?) and I expect there are strings yet > that need to be added to the translation file. I also need to look at > translations for plugins. > > Jonathan > That is absolutely awesome, thanks Jonathan and anyone involved in the effort of internationalising Bazaar! Cheers, David. -- David Planella Ubuntu Translations Coordinator www.ubuntu.com / www.davidplanella.wordpress.com www.identi.ca/dplanella / www.twitter.com/dplanella -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From david.planella at ubuntu.com Fri Sep 16 16:19:35 2011 From: david.planella at ubuntu.com (David Planella) Date: Fri, 16 Sep 2011 18:19:35 +0200 Subject: bzr ready for translations In-Reply-To: <1316189636.2153.1222.camel@avenc> References: <20110916154948.GM3728@starsky.19inch.net> <1316189636.2153.1222.camel@avenc> Message-ID: <1316189975.2153.1223.camel@avenc> El dv 16 de 09 de 2011 a les 18:13 +0200, en/na David Planella va escriure: > El dv 16 de 09 de 2011 a les 16:49 +0100, en/na Jonathan Riddell va > escriure: > > Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be > > translated. If you want to help bring bzr to those who prefer to work > > in non-English languages please help translate at Launchpad (you will > > need to be in the appropriate Launchpad translations team). > > > > The translation will involve quite a bit of specialist language (what > > is French for "colocated branch"?) and I expect there are strings yet > > that need to be added to the translation file. I also need to look at > > translations for plugins. > > > > Jonathan > > > > That is absolutely awesome, thanks Jonathan and anyone involved in the > effort of internationalising Bazaar! > Translatable here: https://translations.launchpad.net/bzr -- David Planella Ubuntu Translations Coordinator www.ubuntu.com / www.davidplanella.wordpress.com www.identi.ca/dplanella / www.twitter.com/dplanella -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From gzlist at googlemail.com Fri Sep 16 17:17:09 2011 From: gzlist at googlemail.com (Martin (gzlist)) Date: Fri, 16 Sep 2011 18:17:09 +0100 Subject: bzr ready for translations In-Reply-To: <20110916154948.GM3728@starsky.19inch.net> References: <20110916154948.GM3728@starsky.19inch.net> Message-ID: On 16/09/2011, Jonathan Riddell wrote: > Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be > translated. If you want to help bring bzr to those who prefer to work > in non-English languages please help translate at Launchpad (you will > need to be in the appropriate Launchpad translations team). Good work Naoki and Jonathan! I wondered if the bug number had been truncated for a second, but no, it really is a five digit one from 2007. > The translation will involve quite a bit of specialist language (what > is French for "colocated branch"?) and I expect there are strings yet > that need to be added to the translation file. I also need to look at > translations for plugins. Translators may find checking existing usage in bzr-explorer and qbzr helpful. Philippe Lhoste did a nice post a while back about the issues around translating some of these technical terms into French that might be a useful reference as well: Martin From aaron at aaronbentley.com Fri Sep 16 20:09:08 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Fri, 16 Sep 2011 16:09:08 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E6F6FA1.1010104@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> Message-ID: <4E73ACE4.50603@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-13 10:58 AM, Aaron Bentley wrote: > I'm investigating the possibility of doing a mass upgrade of all > Launchpad branches into up-to-date formats. I've determined that there are ~450 projects whose development focus is not in 2a, but has been updated in the past year. Many of these may be in older formats due to inertia, i.e. the branch was created before 2a was the default. There are ~20 projects *created* in the past year whose development focus is not in 2a. These don't appear to be cases of inertia, so they may be deliberately using old formats. I've emailed the project owners for comment. So far, I haven't been able to locate logs for the lp: directory service backend, so I've been unable to determine what Bazaar versions are commonly used with Launchpad. (If that's even logged.) I plan to ask Jonathan Lange about that on Monday. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zrOQACgkQ0F+nu1YWqI3q1gCeMvbzB7N+2GLuD56ElOfgbVwS H7oAnjO6R83vIYBjjUKGyY2WzEPo5oRo =h77m -----END PGP SIGNATURE----- From gordon at doxxx.net Fri Sep 16 23:25:24 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Fri, 16 Sep 2011 19:25:24 -0400 Subject: [ANN] bzr-2.5b1 has gone gold ! In-Reply-To: <4E7356BE.7010604@arbash-meinel.com> References: <4E7356BE.7010604@arbash-meinel.com> Message-ID: <4E73DAE4.7040208@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/16/2011 10:01 AM, John Arbash Meinel wrote: > I'll also note for plugin authors, if you want updated plugins in the > installer, please email me, or even better provide a patch to > 'lp:bzr-windows-installers'. Please reply to the list as well so I can update the plugin(s) in the Mac installer. I'll also accept patches to lp:bzr-mac-installers. Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOc9rkAAoJEIrPJfWinA2uaRsH/28zpixwxOMS/4oHkURpO49M +fCWQjiqlsYNaV/cTs6Bh/xikzAx2hMZhSAuRh7wXBPH1QJ2S7WJ2tKAisJr7RBH Qe1j8WZ635cvd/s58X5Vha1Dmf6V2unZORAFZlaTABhuAntOJi1zB/wetz7XgCEe PMWEboSv5DaMjhZmWMH1+c6J+loD6garrza4OLBJkGUdTIFpNU8yLxuvlsIcmLy8 Gv3zkl0CNR95P3eF2dfiCfL2N76a0kqjLO+3TtNVf/2W8R+hPSXjCkDZOeAK4SpF PnqkqDPlx8Kuo2OAE5Jf2k45s0O1l8WnPJGI1xqMLajbZDUEwbwzaibmJUhekGY= =Wbyu -----END PGP SIGNATURE----- From michael.hudson at canonical.com Sun Sep 18 22:04:36 2011 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Mon, 19 Sep 2011 10:04:36 +1200 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E73ACE4.50603@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E73ACE4.50603@aaronbentley.com> Message-ID: <87d3execcr.fsf@canonical.com> On Fri, 16 Sep 2011 16:09:08 -0400, Aaron Bentley wrote: > So far, I haven't been able to locate logs for the lp: directory > service backend, so I've been unable to determine what Bazaar versions > are commonly used with Launchpad. (If that's even logged.) I plan to > ask Jonathan Lange about that on Monday. The xml-rpc service is run on the same appservers as the rest of Launchpad. XML-RPC and httpd logs don't get on in a very informative way, but resolve_lp_path is the single method of the xmlrpc.launchpad.net/bazaar endpoint, so we know that lines like this: 91.189.89.30 - "XXX.XXX.XXX.XXX" "xmlrpc.launchpad.net" [18/Sep/2011:05:11:41 +0000] "POST /bazaar/ HTTP/1.1" 200 649 6 0.0294139385223 84 101 "Anonymous" "BazaarApplication:PublicCodehostingAPI" "" "bzr/2.3.4 (urllib)" is bzr resolving a lp: URL. HTH, mwh From mbp at canonical.com Mon Sep 19 07:45:10 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 19 Sep 2011 17:45:10 +1000 Subject: bzr ready for translations In-Reply-To: <20110916154948.GM3728@starsky.19inch.net> References: <20110916154948.GM3728@starsky.19inch.net> Message-ID: On 17 September 2011 01:49, Jonathan Riddell wrote: > Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be > translated. If you want to help bring bzr to those who prefer to work > in non-English languages please help translate at Launchpad (you will > need to be in the appropriate Launchpad translations team). > > The translation will involve quite a bit of specialist language (what > is French for "colocated branch"?) and I expect there are strings yet > that need to be added to the translation file. I also need to look at > translations for plugins. Awesome, thanks. I put your announcement into a draft blog post - could you see if you want to add more? > (you will > need to be in the appropriate Launchpad translations team). How would a person actually do that? m From abdlquadri at yahoo.com Mon Sep 19 08:54:54 2011 From: abdlquadri at yahoo.com (Abdul Quadri) Date: Mon, 19 Sep 2011 01:54:54 -0700 (PDT) Subject: resume a branching Message-ID: <1316422494.72873.YahooMailNeo@web39412.mail.mud.yahoo.com> Hi All, I have never used bzr before. I was running this set of commands to get a software. * hg clone http://hg.assembla.com/MadButterfly * bzr branch lp:~inkscape-pybind/inkscape/pybind inkscape-pybind * cd inkscape-pybind * ./configure ?with-python * make * set PYTHONPATH=$PWD/../MadButterfly/pyink * export PYTHONPATH * ./src/inkscape ?I?guess?the second line is the bzr part of the whole thing. I ran the command and the download started but unfortunately my network access was?interrupted. Trying again I get this error? > bzr branch lp:~inkscape-pybind/inkscape/pybind inkscape-pybind You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. ?See "bzr help launchpad-login". bzr: ERROR: Target directory "inkscape-pybind" already exists. I think the last line is what I should be worried about. Please how do I proceed? Thanks all -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbp at canonical.com Mon Sep 19 08:59:34 2011 From: mbp at canonical.com (Martin Pool) Date: Mon, 19 Sep 2011 18:59:34 +1000 Subject: resume a branching In-Reply-To: <1316422494.72873.YahooMailNeo@web39412.mail.mud.yahoo.com> References: <1316422494.72873.YahooMailNeo@web39412.mail.mud.yahoo.com> Message-ID: On 19 September 2011 18:54, Abdul Quadri wrote: > Hi All, > I have never used bzr before. I was running this set of commands to get a > software. > > hg clone http://hg.assembla.com/MadButterfly > bzr branch lp:~inkscape-pybind/inkscape/pybind inkscape-pybind > cd inkscape-pybind > ./configure ?with-python > make > set PYTHONPATH=$PWD/../MadButterfly/pyink > export PYTHONPATH > ./src/inkscape > > ?I?guess?the second line is the bzr part of the whole thing. I ran the > command and the download started but unfortunately my network access > was?interrupted. Trying again I get this error >> bzr branch lp:~inkscape-pybind/inkscape/pybind inkscape-pybind > You have not informed bzr of your Launchpad ID, and you must do this to > write to Launchpad or access private data. ?See "bzr help launchpad-login". > bzr: ERROR: Target directory "inkscape-pybind" already exists. > I think the last line is what I should be worried about. Please how do I > proceed? Hi, You should be able to do cd inkscape-pybind bzr pull lp:~inkscape-pybind/inkscape/pybind It would be better if repeating the branch command just handled this more elegantly and/or if bzr paused and retried the failed operations. (There are bugs; we'll fix them.) m From david.planella at ubuntu.com Mon Sep 19 10:15:54 2011 From: david.planella at ubuntu.com (David Planella) Date: Mon, 19 Sep 2011 12:15:54 +0200 Subject: bzr ready for translations In-Reply-To: References: <20110916154948.GM3728@starsky.19inch.net> Message-ID: <1316427355.2153.1228.camel@avenc> El dl 19 de 09 de 2011 a les 17:45 +1000, en/na Martin Pool va escriure: > On 17 September 2011 01:49, Jonathan Riddell wrote: > > Bug 83941 Bzr doesn't speak my tongue has been closed. Bzr can now be > > translated. If you want to help bring bzr to those who prefer to work > > in non-English languages please help translate at Launchpad (you will > > need to be in the appropriate Launchpad translations team). > > > > The translation will involve quite a bit of specialist language (what > > is French for "colocated branch"?) and I expect there are strings yet > > that need to be added to the translation file. I also need to look at > > translations for plugins. > > Awesome, thanks. I put your announcement into a draft blog post > > - could you see if you want to add more? > > > (you will > > need to be in the appropriate Launchpad translations team). > > How would a person actually do that? > * Go to https://translations.launchpad.net/bzr * Click on the language you want to translate * If you are a member of the translation team, you'll be able to translate straight away * If you are not a member, you can either leave translations suggestions and ask the team members to approve them, or ask to join the team. There are links to the relevant translation team at the top and bottom of the translations page. Cheers, David. -- David Planella Ubuntu Translations Coordinator www.ubuntu.com / www.davidplanella.wordpress.com www.identi.ca/dplanella / www.twitter.com/dplanella -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: From aaron at aaronbentley.com Mon Sep 19 13:58:19 2011 From: aaron at aaronbentley.com (Aaron Bentley) Date: Mon, 19 Sep 2011 09:58:19 -0400 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <87d3execcr.fsf@canonical.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E73ACE4.50603@aaronbentley.com> <87d3execcr.fsf@canonical.com> Message-ID: <4E774A7B.8030306@aaronbentley.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-09-18 06:04 PM, Michael Hudson-Doyle wrote: > The xml-rpc service is run on the same appservers as the rest of > Launchpad. XML-RPC and httpd logs don't get on in a very > informative way, but resolve_lp_path is the single method of the > xmlrpc.launchpad.net/bazaar endpoint, so we know that lines like > this: > > 91.189.89.30 - "XXX.XXX.XXX.XXX" "xmlrpc.launchpad.net" > [18/Sep/2011:05:11:41 +0000] "POST /bazaar/ HTTP/1.1" 200 649 6 > 0.0294139385223 84 101 "Anonymous" > "BazaarApplication:PublicCodehostingAPI" "" "bzr/2.3.4 (urllib)" > > is bzr resolving a lp: URL. Thanks! So according to the logs, here's the breakdown for one of our machines for yesterday: $ zgrep xmlrpc.launchpad.net launchpad-access47.log-20110918|cut -f 19 - -d ' '|sort|uniq -c 100 "bzr/2.1.4 1 "bzr/2.2.2 103 "bzr/2.2.4 2 "bzr/2.2b4 11 "bzr/2.3.1 6 "bzr/2.3.3 475 "bzr/2.3.4 9 "bzr/2.3b2 3 "bzr/2.4.0 15 "bzr/2.4.1 23 "bzr/2.4b5 1 "bzr/2.5.0dev1 As far as I know, this is representative of all our machines. I've looked at the logs for September, and I haven't found any use of bzr 2.0, much less an earlier version. I've heard back from five (of 20) project owners whose projects have old-format trunks, and none of them are concerned about moving to 2a. Aaron -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk53SnsACgkQ0F+nu1YWqI0eLACeJgvT0JK6v6cbbnM+Yx3j6hB0 Br0An1uuCh0NQI1auWlgBus7FOizgDfb =+B8t -----END PGP SIGNATURE----- From mail at kirill-mueller.de Mon Sep 19 21:28:36 2011 From: mail at kirill-mueller.de (=?ISO-8859-1?Q?Kirill_M=FCller?=) Date: Mon, 19 Sep 2011 23:28:36 +0200 Subject: OrderedDict data structure in bzrlib? Message-ID: <4E77B404.4020903@kirill-mueller.de> Hello, I am planning to add a histedit command to the rewrite plugin [1], and a data structure like collections.OrderedDict [2] would help a lot. Unfortunately, OrderedDict is new in Python 2.7. Is there a similar data structure, compatible with all supported versions of Python, already available in bzrlib? I'd appreciate any feedback. Best regards, Kirill [1] https://bugs.launchpad.net/bzr-rewrite/+bug/243150 [2] http://docs.python.org/library/collections.html#collections.OrderedDict From vernooi1 at xs4all.nl Mon Sep 19 21:34:03 2011 From: vernooi1 at xs4all.nl (Jelmer Vernooij) Date: Mon, 19 Sep 2011 23:34:03 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E77B404.4020903@kirill-mueller.de> References: <4E77B404.4020903@kirill-mueller.de> Message-ID: <4E77B54B.6050804@xs4all.nl> On Mon 19 Sep 2011 11:28:36 PM CEST, Kirill M?ller wrote: > I am planning to add a histedit command to the rewrite plugin [1], and > a data structure like collections.OrderedDict [2] would help a lot. > Unfortunately, OrderedDict is new in Python 2.7. Is there a similar > data structure, compatible with all supported versions of Python, > already available in bzrlib? > > I'd appreciate any feedback. I'm pretty sure we don't have anything like that in bzrlib at the moment. What in particular do you need the OrderedDict for? Perhaps there are alternatives. Cheers, Jelmer From mbp at canonical.com Mon Sep 19 21:44:12 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 20 Sep 2011 07:44:12 +1000 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: <4E774A7B.8030306@aaronbentley.com> References: <4E6F6FA1.1010104@aaronbentley.com> <4E73ACE4.50603@aaronbentley.com> <87d3execcr.fsf@canonical.com> <4E774A7B.8030306@aaronbentley.com> Message-ID: On 19 September 2011 23:58, Aaron Bentley wrote: > So according to the logs, here's the breakdown for one of our machines > for yesterday: > $ zgrep xmlrpc.launchpad.net launchpad-access47.log-20110918|cut -f 19 > - -d ' '|sort|uniq -c > ? ?100 "bzr/2.1.4 > ? ? ?1 "bzr/2.2.2 > ? ?103 "bzr/2.2.4 > ? ? ?2 "bzr/2.2b4 > ? ? 11 "bzr/2.3.1 > ? ? ?6 "bzr/2.3.3 > ? ?475 "bzr/2.3.4 > ? ? ?9 "bzr/2.3b2 > ? ? ?3 "bzr/2.4.0 > ? ? 15 "bzr/2.4.1 > ? ? 23 "bzr/2.4b5 > ? ? ?1 "bzr/2.5.0dev1 > > As far as I know, this is representative of all our machines. ?I've > looked at the logs for September, and I haven't found any use of bzr > 2.0, much less an earlier version. To quote spiv's tshirt, Way to go. Seeing those numbers reminds me my previous message was inaccurate: bzr ?2.4 doesn't use xmlrpc for ssh, but it does still use it for http access. (I think there's a separate bug asking to fix that.) So, the numbers will be a bit skewed, but the basic conclusion that there's nothing before 2.0 is still sound. m From gordon at doxxx.net Mon Sep 19 22:50:52 2011 From: gordon at doxxx.net (Gordon Tyler) Date: Mon, 19 Sep 2011 18:50:52 -0400 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E77B54B.6050804@xs4all.nl> References: <4E77B404.4020903@kirill-mueller.de> <4E77B54B.6050804@xs4all.nl> Message-ID: <4E77C74C.7030403@doxxx.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/19/2011 5:34 PM, Jelmer Vernooij wrote: > On Mon 19 Sep 2011 11:28:36 PM CEST, Kirill M?ller wrote: >> I am planning to add a histedit command to the rewrite plugin [1], and a data structure like collections.OrderedDict [2] would help a lot. Unfortunately, OrderedDict is new in Python 2.7. Is there a similar data structure, compatible with all supported versions of Python, already available in bzrlib? >> >> I'd appreciate any feedback. > I'm pretty sure we don't have anything like that in bzrlib at the moment. What in particular do you need the OrderedDict for? Perhaps there are alternatives. > There is this: http://pypi.python.org/pypi/ordereddict Ciao, Gordon -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOd8dMAAoJEIrPJfWinA2uQWQH/Rxjg94vYxtxsw8g87LOsr6h LRcLvE58Szm2I0huWTeE8xK+e6L44xsMktwCDa1QwzPE80KVSWjtvgcEbUl4ryy7 c4ZnWzDLJZ30YLYONWGmj3ltdnBAaTuMZ41rUPT3Y4APXVot6LMCpL2Bx9bnHuY7 rgBQa5gElB5O30LaUQUcmfg5Uxv7I39x9LUhGyoDgjj5IvQ0RByJW6Vp6IFRhsSA eFhi+lPyfvGxqNXkqZZRGEOLsHZ5n+0Igquy1tkSE79JcwCjO6xBV6YWXf+n8+21 AYDuDn/fyb9LLvFg7xhajT28ymkk7Cl+MMs38NTcrXqAAUclHEusXSWMIZJ9ytI= =57n1 -----END PGP SIGNATURE----- From mail at kirill-mueller.de Tue Sep 20 06:58:02 2011 From: mail at kirill-mueller.de (=?UTF-8?B?S2lyaWxsIE3DvGxsZXI=?=) Date: Tue, 20 Sep 2011 08:58:02 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E77B54B.6050804@xs4all.nl> References: <4E77B404.4020903@kirill-mueller.de> <4E77B54B.6050804@xs4all.nl> Message-ID: <4E78397A.4050408@kirill-mueller.de> On 19.09.2011 23:34, Jelmer Vernooij wrote: > On Mon 19 Sep 2011 11:28:36 PM CEST, Kirill M?ller wrote: >> I am planning to add a histedit command to the rewrite plugin [1], >> and a data structure like collections.OrderedDict [2] would help a >> lot. Unfortunately, OrderedDict is new in Python 2.7. Is there a >> similar data structure, compatible with all supported versions of >> Python, already available in bzrlib? >> >> I'd appreciate any feedback. > I'm pretty sure we don't have anything like that in bzrlib at the > moment. What in particular do you need the OrderedDict for? Perhaps > there are alternatives. In bzr-rewrite, the rebase-plan is unmarshalled into a dictionary, destroying the order. Later, it is reordered by topologically sorting the revisions. For rearranging commits in the "histedit" use case, the ordering from the rebase-plan must be maintained during unmarshalling; using OrderedDict instead of dict worked for me right away. Regards Kirill From mbp at canonical.com Tue Sep 20 09:23:46 2011 From: mbp at canonical.com (Martin Pool) Date: Tue, 20 Sep 2011 19:23:46 +1000 Subject: canonical bzr team weekly notes Message-ID: bzr standup 2011-09-20 Canonical's doing internal quarterly review/planning, this week and next. vila- * landed https://bugs.launchpad.net/udd/+bug/836782 bzr-builddeb requires dpkg-dev >= 1.15.7 with help from poolie (just use a local dpkg-mergechangelogs), so this should give better merges and less conflicts during imports * package-importer should back off (and "make tea") if Launchpad's unreachable, https://code.launchpad.net/~vila/udd/795321-make-tea/+merge/76058 waiting for review (should address the peaks in http://webnumbr.com/ubuntu-package-import-failures.from%282011-09-13%29); working on distinguishing transient from ~idempotent failures; * Froze 2.5b1 (should announce today), still need installers/packages from people. * SRU 2.2.5 still pending * jelmer proposed being PP for config stuff, should clarify roadmap and next step(s) * NEXT: testing Launchpad 'make tea' circuit breaker patch. jam- * working on getting the server to disconnect idle clients, which will allow a lot smoother service and upgrades on lp, aside from being generally useful. this causes some glitches during the test suite. some discussion about how to handle it smoothly. ACTION: group discussion offline of disconnect, reconnect, graceful shut down and test handling riddell- * finished up marking translatable strings, and refactoring handling on the long slow task of fixing strings to be translatable; some people have started translation, will see if they have feedback; also should remind Naoki Inada this was done and thank him * NEXT: pp this week; then requiring signature on branches; also bzr builddeb do-mode for non-merge mode; maybe unicode filename support in udd. jelmer- * Bored all week long. * Worked on bzr-builddeb multiple-tarball imports. Fairly tricky. * FTBFS fixes for ubuntu. * Patches for Launchpad to do bzr-git pulling from HTTP smart-server support on LP. * Fixed HTTP redirect handling in lp mirroring * bzr-svn now down to 70 test-suite failures out of roughly 2500 when used as an alternate branch implementation. * only ~15 bzr-svn mirrors failing on lp * NEXT: finish bzr-builddeb multi-tarballs poolie- * some work on hiring for us and other teams, announcement soon * Helped Michael Hudson on Launchpad Feature Flags (anon ssh) * Landed DKIM support for Launchpad, on production now. No more GPG needed for GMail accounts! * Working on QBR * Worked with IS to get various production changes done or at least prioritized. * Little bit of work on recording successful imports in udd importer as well as failures. http://blog.launchpad.net/general/speeding-up-development - lp will now deploy frequently, every few days, with just about a minute of downtime or sometimes no downtime at all, hooray. needs more work (including what John's now on) to make it smooth for code hosting. From mail at kirill-mueller.de Tue Sep 20 12:42:17 2011 From: mail at kirill-mueller.de (=?ISO-8859-1?Q?Kirill_M=FCller?=) Date: Tue, 20 Sep 2011 14:42:17 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: References: Message-ID: <4E788A29.7040101@kirill-mueller.de> > There is this: http://pypi.python.org/pypi/ordereddict Gordon, thank you, this would be a good option. What would be the best way to include this dependency into the bzr-rewrite plugin? I can only think of copying te required modules, but there might be better ways. Cheers Kirill From vila+bzr at canonical.com Tue Sep 20 12:57:29 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Tue, 20 Sep 2011 14:57:29 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E788A29.7040101@kirill-mueller.de> ("Kirill =?iso-8859-1?Q?M=FCller=22's?= message of "Tue, 20 Sep 2011 14:42:17 +0200") References: <4E788A29.7040101@kirill-mueller.de> Message-ID: >>>>> Kirill M?ller writes: >> There is this: http://pypi.python.org/pypi/ordereddict > Gordon, > thank you, this would be a good option. What would be the best way to > include this dependency into the bzr-rewrite plugin? I can only think of > copying te required modules, but there might be better ways. Just catch the import error and display a warning that such and such modules are required for this feature in the plugin to work. That's often called a 'soft' dependency, 'pycurl' is a soft dependency for bzr, it's used when present but we issue a warning (or may be just a note in the .bzr.log file) when it's not installed. At packaging times, add such and such module in the required/optional dependencies. Vincent P.S.: Get in touch with the plugin maintainers to check that this approach is ok with them though. P.P.S.: In case they disagree, you can still define you *own* plugin and import the parts you're interested in from the 'rewrite' plugin. From jelmer at samba.org Tue Sep 20 13:05:02 2011 From: jelmer at samba.org (Jelmer Vernooij) Date: Tue, 20 Sep 2011 15:05:02 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E78397A.4050408@kirill-mueller.de> References: <4E77B404.4020903@kirill-mueller.de> <4E77B54B.6050804@xs4all.nl> <4E78397A.4050408@kirill-mueller.de> Message-ID: <4E788F7E.10105@samba.org> On 20/09/11 08:58, Kirill M?ller wrote: > On 19.09.2011 23:34, Jelmer Vernooij wrote: >> On Mon 19 Sep 2011 11:28:36 PM CEST, Kirill M?ller wrote: >>> I am planning to add a histedit command to the rewrite plugin [1], >>> and a data structure like collections.OrderedDict [2] would help a >>> lot. Unfortunately, OrderedDict is new in Python 2.7. Is there a >>> similar data structure, compatible with all supported versions of >>> Python, already available in bzrlib? >>> >>> I'd appreciate any feedback. >> I'm pretty sure we don't have anything like that in bzrlib at the >> moment. What in particular do you need the OrderedDict for? Perhaps >> there are alternatives. > In bzr-rewrite, the rebase-plan is unmarshalled into a dictionary, > destroying the order. Later, it is reordered by topologically sorting > the revisions. For rearranging commits in the "histedit" use case, the > ordering from the rebase-plan must be maintained during unmarshalling; > using OrderedDict instead of dict worked for me right away. Is there any particular reason it would have to be a dictionary, couldn't it just be a list ? The point of it being a dictionary at the moment is because the future revision ids are already determined, and this gives an easy way to look them up. This can't really be the case for something similar to "git rebase -i" as revisions can "fall out" if their changes have already been applied. This means future revisions (in particular, their parents) can't be planned ahead. Cheers, Jelmer From john at arbash-meinel.com Tue Sep 20 17:33:43 2011 From: john at arbash-meinel.com (John Arbash Meinel) Date: Tue, 20 Sep 2011 19:33:43 +0200 Subject: [ANN] bzr-2.5b1 has gone gold ! In-Reply-To: <4E7356BE.7010604@arbash-meinel.com> References: <4E7356BE.7010604@arbash-meinel.com> Message-ID: <4E78CE77.0@arbash-meinel.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/16/2011 4:01 PM, John Arbash Meinel wrote: > On 9/16/2011 3:37 PM, Vincent Ladeuil wrote: >> Heads up ! > >> Now that I have your attention: thanks again to packagers and >> installer builders for releasing 2.4.1 in record time. > >> Don't stop too fast, here comes 2.5b1 ! > bzr-2.5b1-1 has been uploaded to the usual place. I'll go update the wiki now. John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk54zncACgkQJdeBCYSNAAOLxACguRNKOrmnQ1VOLYSHlj7WD7aU y5EAoL3nfbty4+2GeufAxeUxvdPQNv3/ =VlFm -----END PGP SIGNATURE----- From mbp at canonical.com Tue Sep 20 23:47:43 2011 From: mbp at canonical.com (Martin Pool) Date: Wed, 21 Sep 2011 09:47:43 +1000 Subject: Considering moving all Launchpad branches to 2a - based formats In-Reply-To: References: <4E6F6FA1.1010104@aaronbentley.com> <4E73ACE4.50603@aaronbentley.com> <87d3execcr.fsf@canonical.com> <4E774A7B.8030306@aaronbentley.com> Message-ID: thedac reminded me of which is asking for a bulk-upgrade of graphite. Perhaps you could use graphite as a trial run for a bulk upgrade. m From mail at kirill-mueller.de Wed Sep 21 12:39:17 2011 From: mail at kirill-mueller.de (=?UTF-8?B?S2lyaWxsIE3DvGxsZXI=?=) Date: Wed, 21 Sep 2011 14:39:17 +0200 Subject: OrderedDict data structure in bzrlib? In-Reply-To: <4E788F7E.10105@samba.org> References: <4E77B404.4020903@kirill-mueller.de> <4E77B54B.6050804@xs4all.nl> <4E78397A.4050408@kirill-mueller.de> <4E788F7E.10105@samba.org> Message-ID: <4E79DAF5.8030803@kirill-mueller.de> On 20.09.2011 15:05, Jelmer Vernooij wrote: > On 20/09/11 08:58, Kirill M?ller wrote: >> On 19.09.2011 23:34, Jelmer Vernooij wrote: >>> On Mon 19 Sep 2011 11:28:36 PM CEST, Kirill M?ller wrote: >>>> I am planning to add a histedit command to the rewrite plugin [1], >>>> and a data structure like collections.OrderedDict [2] would help a >>>> lot. Unfortunately, OrderedDict is new in Python 2.7. Is there a >>>> similar data structure, compatible with all supported versions of >>>> Python, already available in bzrlib? >>>> >>>> I'd appreciate any feedback. >>> I'm pretty sure we don't have anything like that in bzrlib at the >>> moment. What in particular do you need the OrderedDict for? Perhaps >>> there are alternatives. >> In bzr-rewrite, the rebase-plan is unmarshalled into a dictionary, >> destroying the order. Later, it is reordered by topologically sorting >> the revisions. For rearranging commits in the "histedit" use case, >> the ordering from the rebase-plan must be maintained during >> unmarshalling; using OrderedDict instead of dict worked for me right >> away. > Is there any particular reason it would have to be a dictionary, > couldn't it just be a list ? > > The point of it being a dictionary at the moment is because the future > revision ids are already determined, and this gives an easy way to > look them up. This can't really be the case for something similar to > "git rebase -i" as revisions can "fall out" if their changes have > already been applied. This means future revisions (in particular, > their parents) can't be planned ahead. > > Cheers, > > Jelmer I planned to design the command so that most of the current rewrite code remains "as-is". Introducing a new rebase plan format would probably break more than I'd be keen on fixing myself :-) This means that I'll try to plan ahead all of the rebase plan. Could you give a specific example where you think this might be impossible? Thanks again for your advice. Regards Kirill From vila+bzr at canonical.com Wed Sep 21 14:35:14 2011 From: vila+bzr at canonical.com (Vincent Ladeuil) Date: Wed, 21 Sep 2011 16:35:14 +0200 Subject: [ANN] bzr 2.5b1 released Message-ID: Hi, I'm pleased to announce the first beta for the 2.5 series: 2.5b1. Bazaar is a Canonical project and part of the GNU project to produce a free operating system. 2.5.0 is planned to be released in February 2012. 2.5b1 contains all know bug fixes including the ones made for the previous stable releases. A warm thank you to all people that send feedback, suggestions, even merge proposals making bzr better ! Bazaar is now available for download from https://launchpad.net/bzr/2.5/2.5b1/ as a source tarball. Installers are available for windows and OSX and packages are on their way for the usual GNU/Linux distributions that propose our beta releases as well as the beta PPA for Ubuntu. ObChangeLogEntries: External Compatibility Breaks ***************************** None New Features ************ * A ``from_unicode`` parameter can be specified when registering a config option. This implements boolean, integer and list config options when the provided ``bool_from_store``, ``int_from_store`` and ``list_from_store`` are used for this parameter. (Vincent Ladeuil) * Accessing a packaging branch on Launchpad (eg, ``lp:ubuntu/bzr``) now checks to see if the most recent published source package version for that project is present in the branch tags. This should help developers trust whether the packaging branch is up-to-date and can be used for new changes. The level of verbosity is controlled by the config item ``launchpad.packaging_verbosity``. It can be set to one of off disable all checks minimal only display if the branch is out-of-date short also display single-line up-to-date and missing, all (default) display multi-line content for all states (John Arbash Meinel, #609187, #812928) * Add a config option gpg_signing_key for setting which GPG key should be used to sign commits. Also default to using the gpg user identity which matches user_email() as set by whoami. (Jonathan Riddell, #68501) * An ``invalid`` parameter can be specified when registering a config option to decide what should be done when invalid values are encountered. 'warning' and 'error' will respectively emit a warning and ignore the value or errors out. (Vincent Ladeuil) * bzr add now skips large files in recursive mode. The default "large" size is 20MB, and is configurable via the add.maximum_file_size option. A value of 0 disables skipping. Named items passed to add are never skipped. (Shannon Weyrick, #54624) * ``bzr help configuration/