Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Mon, 28 Aug 2006, Adeodato Simó wrote: * Brian May [Mon, 28 Aug 2006 13:22:55 +1000]: Adeodate Also, do you remember having root Adeodato bzr as root? Huh? Sorry, that should have read: do you remember having *run* bzr as root. It's the most likely cause for those .pyc files to be there, since bzrtools did not. What helper tool did you to use to byte-compules modules before python-support? (dh_python v1, python-central, nothing) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Le dimanche 27 août 2006 à 19:12 +0200, Adeodato Simó a écrit : bzrtools 0.9 does not put files under /usr/lib/python2.4, since it uses python-support; and its maintainer scripts for 0.9 did not bytecompile the modules, so the most plausible explanation for .pyc files in /usr/lib/python2.4 is having run bzr 0.8 as root. To debian-python: this is presumably a bug in bzrtools? This is a bug in the former version, since it should have cleaned up those .pyc files at prerm time. However it can now only be fixed with a workaround in the new version, e.g. by removing the /usr/lib/python2.X/site-packages/bzrlib/plugins/bzrtools directories. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Did I do something wrong? [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. Adeodato No. You just need to upgrade your bzrtool package to 0.9 Adeodato as well. I had 0.9 installed already when doing this: ii bzrtools0.9.0-1 Collection of tools for bzr So what is going wrong? Anyway, I tried the revert operation again with 0.9-2. Memory usage was still high (205meg at one point), but bounded - much better. The operation successfully completed this time. Adeodato Sounds acceptable to close ##380412, then? Yes, sounds good to me. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Version: 0.9-1 * Brian May [Sun, 27 Aug 2006 17:43:24 +1000]: Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Did I do something wrong? [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. Adeodato No. You just need to upgrade your bzrtool package to 0.9 Adeodato as well. I had 0.9 installed already when doing this: ii bzrtools0.9.0-1 Collection of tools for bzr Hm. I'd say that you have .pyc files left in: /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools Can you check, please? Also, do you remember having root bzr as root? bzrtools 0.9 does not put files under /usr/lib/python2.4, since it uses python-support; and its maintainer scripts for 0.9 did not bytecompile the modules, so the most plausible explanation for .pyc files in /usr/lib/python2.4 is having run bzr 0.8 as root. To debian-python: this is presumably a bug in bzrtools? So what is going wrong? Anyway, I tried the revert operation again with 0.9-2. Memory usage was still high (205meg at one point), but bounded - much better. The operation successfully completed this time. Adeodato Sounds acceptable to close ##380412, then? Yes, sounds good to me. Done, thanks. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Los Caramelos - Cherry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Adeodato Hm. I'd say that you have .pyc files left in: Adeodato Adeodato /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools Adeodato Can you check, please? Yes, see below. Adeodate Also, do you remember having root Adeodato bzr as root? Huh? Adeodato bzrtools 0.9 does not put files under Adeodato /usr/lib/python2.4, since it uses python-support; and Adeodato its maintainer scripts for 0.9 did not bytecompile the Adeodato modules, so the most plausible explanation for .pyc Adeodato files in /usr/lib/python2.4 is having run bzr 0.8 as Adeodato root. Adeodato To debian-python: this is presumably a bug in bzrtools? [EMAIL PROTECTED]:~$ ls -l /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools total 288 -rw-r--r-- 1 root root 31767 2006-07-16 18:58 baz_import.py.bak -rw-r--r-- 1 root root 29959 2006-08-12 12:08 baz_import.pyc -rw-r--r-- 1 root root 830 2006-08-12 12:08 branches.pyc -rw-r--r-- 1 root root 2198 2006-08-12 12:08 branchhistory.pyc -rw-r--r-- 1 root root 4167 2006-08-12 12:08 branch_mark.pyc -rw-r--r-- 1 root root 13906 2006-08-12 12:08 bzrtools.pyc -rw-r--r-- 1 root root 1232 2006-08-12 12:08 cbranch.pyc -rw-r--r-- 1 root root 4167 2006-08-12 12:08 clean_tree.pyc -rw-r--r-- 1 root root 8687 2006-08-12 12:08 dotgraph.pyc -rw-r--r-- 1 root root 1637 2006-08-12 12:08 errors.pyc -rw-r--r-- 1 root root 4235 2006-08-12 12:08 fai.pyc -rw-r--r-- 1 root root 2275 2006-08-12 12:08 fetch_ghosts.pyc -rw-r--r-- 1 root root 8827 2006-08-12 12:08 graph.pyc -rw-r--r-- 1 root root 5466 2006-08-12 12:08 hunk_selector.pyc -rw-r--r-- 1 root root 16502 2006-07-16 18:52 __init__.py.bak -rw-r--r-- 1 root root 18867 2006-08-12 12:08 __init__.pyc -rw-r--r-- 1 root root 20311 2006-08-12 12:08 patches.pyc -rw-r--r-- 1 root root 7321 2006-08-12 12:08 patch.pyc -rw-r--r-- 1 root root 2573 2006-08-12 12:08 patchsource.pyc -rw-r--r-- 1 root root 1460 2006-08-12 12:08 progress.pyc -rw-r--r-- 1 root root 1545 2006-08-12 12:08 rspush.pyc -rw-r--r-- 1 root root 626 2006-08-12 12:08 setup.pyc -rw-r--r-- 1 root root 9907 2006-08-12 12:08 shelf.pyc -rw-r--r-- 1 root root 10210 2006-08-12 12:08 shell.pyc -rw-r--r-- 1 root root 3846 2006-08-12 12:08 switch.pyc -rw-r--r-- 1 root root 1822 2006-08-12 12:08 terminal.pyc -rw-r--r-- 1 root root 1367 2006-08-12 12:08 test.pyc -rw-r--r-- 1 root root 5083 2006-08-12 12:08 userinteractor.pyc -rw-r--r-- 1 root root 3674 2006-08-12 12:08 zap.pyc [EMAIL PROTECTED]:~$ dpkg -S /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools bzrtools: /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools [EMAIL PROTECTED]:~$ dpkg -L bzrtools /. /usr /usr/lib /usr/lib/python2.4 /usr/lib/python2.4/site-packages /usr/lib/python2.4/site-packages/bzrlib /usr/lib/python2.4/site-packages/bzrlib/plugins /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools /usr/share [...] Not sure what those *.bak files are, but I suspect that was some hackish debugging I did for a previous problem. I would speculate that upgrading the package didn't result in the compiled files being deleted. [EMAIL PROTECTED]:~$ dpkg -l bzrtools Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii bzrtools 0.9.0-1 Collection of tools for bzr -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Brian May [Mon, 28 Aug 2006 13:22:55 +1000]: Adeodate Also, do you remember having root Adeodato bzr as root? Huh? Sorry, that should have read: do you remember having *run* bzr as root. It's the most likely cause for those .pyc files to be there, since bzrtools did not. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org The total accumulated knowledge of all the men that ever walked the Earth on the topic of women can fit in the period at the end of this sentence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Adeodato Sorry, that should have read: do you remember having Adeodato *run* bzr as root. It's the most likely cause for Adeodato those .pyc files to be there, since bzrtools did not. No - I don't recall running bzr as root, nor have I had any reason to do so. This doesn't mean I didn't do it accidently, but I don't think so. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote: Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Did I do something wrong? [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. Anyway, I tried the revert operation again with 0.9-2. Memory usage was still high (205meg at one point), but bounded - much better. The operation successfully completed this time. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Brian May [Sun, 27 Aug 2006 13:53:01 +1000]: Robert == Robert Collins [EMAIL PROTECTED] writes: Robert On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote: Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Did I do something wrong? [EMAIL PROTECTED]:~/bzr/diary-data$ bzr upgrade /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:21: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/__init__.py:22: DeprecationWarning: Modifying DEFAULT_IGNORE was deprecated in version 0.9. Consider using bzrlib.ignores.add_unique_user_ignores o r bzrlib.ignores.add_runtime_ignores bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. No. You just need to upgrade your bzrtool package to 0.9 as well. Anyway, I tried the revert operation again with 0.9-2. Memory usage was still high (205meg at one point), but bounded - much better. The operation successfully completed this time. Sounds acceptable to close ##380412, then? Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org One way to make your old car run better is to look up the price of a new model. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote: Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Are there any Debian packages of 0.9rc1 available? -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
la, 2006-08-12 kello 15:59 +1000, Brian May kirjoitti: Are there any Debian packages of 0.9rc1 available? http://packages.debian.org/unstable/devel/bzr says 0.9~rc1-1. (Lookup time: about ten seconds. :) -- On a clear disk, you seek forever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Sat, 2006-08-12 at 15:59 +1000, Brian May wrote: Robert == Robert Collins [EMAIL PROTECTED] writes: Robert On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote: Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. Robert Could you please run 'bzr upgrade' while using bzr Robert 0.9rc1. If my guess at your situation is right this will Robert take a while to run, but correct your performance issues. Are there any Debian packages of 0.9rc1 available? 0.9 has been released, I believe 'dato is working on an upload now. Cheers, Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Sun, 2006-08-06 at 12:01 +1000, Brian May wrote: Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. Could you please run 'bzr upgrade' while using bzr 0.9rc1. If my guess at your situation is right this will take a while to run, but correct your performance issues. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Sat, 2006-08-05 at 10:58 +1000, Brian May wrote: Robert == Robert Collins [EMAIL PROTECTED] writes: Robert Are you doing conversions from SVN? Current bzr uses 20MB Robert of ram to do a native branch operation in similar Robert circumstances. (bug report gets fixed, new at 11 :)). No, this was a conversion from baz. Might be the same bug though, hopefully. Its likely to be a different bug - the conversion approach used for svn/baz is very different. That said, conversion from $any system is going to use more memory than native bzr operations, simply because of the overhead of having two data structures in memory at once. If you do a conversion from baz though, once converted you should have no troubles. Also, please do file bugs on the conversion logic if it fails to operate for you. Cheers, Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert Its likely to be a different bug - the conversion approach Robert used for svn/baz is very different. That said, conversion Robert from $any system is going to use more memory than native Robert bzr operations, simply because of the overhead of having Robert two data structures in memory at once. If you do a Robert conversion from baz though, once converted you should have Robert no troubles. Robert Also, please do file bugs on the conversion logic if it Robert fails to operate for you. Already done so - the Debian bug report I quoted. Curiously though, the problems continue even after the archive appears to be converted successfully - if I do a diff operation, it reports all files as deleted, but if I try to revert it, it slows to a grinding halt. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert == Robert Collins [EMAIL PROTECTED] writes: Robert Are you doing conversions from SVN? Current bzr uses 20MB Robert of ram to do a native branch operation in similar Robert circumstances. (bug report gets fixed, new at 11 :)). No, this was a conversion from baz. Might be the same bug though, hopefully. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert Collins [EMAIL PROTECTED] writes: bzr is also working on a high performance server at the moment, which will operate over either a socketpair - i.e. tunnelling via ssh (which can still be done without granting shell access), or over plain http via an apache rewrite rule. Is it already working? How we can try? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote: Robert Collins [EMAIL PROTECTED] writes: bzr is also working on a high performance server at the moment, which will operate over either a socketpair - i.e. tunnelling via ssh (which can still be done without granting shell access), or over plain http via an apache rewrite rule. Is it already working? How we can try? typo - I meant 'bzr developers are also'... Its partially functional at this point - we have it passing all the transport selftests, which means it can be used [by the brave!] as an alternative to sftp for read-write access, but it no faster. The higher-level semantic operations are coming along nicely - we hope to have it in 0.10 due out 4th september. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Robert Collins [EMAIL PROTECTED] writes: On Thu, 2006-08-03 at 08:27 -0300, Otavio Salvador wrote: Robert Collins [EMAIL PROTECTED] writes: bzr is also working on a high performance server at the moment, which will operate over either a socketpair - i.e. tunnelling via ssh (which can still be done without granting shell access), or over plain http via an apache rewrite rule. Is it already working? How we can try? typo - I meant 'bzr developers are also'... Its partially functional at this point - we have it passing all the transport selftests, which means it can be used [by the brave!] as an alternative to sftp for read-write access, but it no faster. The higher-level semantic operations are coming along nicely - we hope to have it in 0.10 due out 4th september. Great! -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato == Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: Adeodato But if you have a set of equal developers, bzr can be Adeodato also used in a very similar way to Subversion, where all Adeodato commits go to a central repository, and nobody has to Adeodato collect them. It's just a matter of setting up a Adeodato directory somewhere with the appropriate write Adeodato permissions, and say This is our canonical archive, the Adeodato uploader will include what it's in there, nothing more, Adeodato nothing less. For documentation on checkouts and bound branches, see http://bazaar-vcs.org/CheckoutTutorial http://bazaar-vcs.org/BzrUsingBoundBranches However, I am not convinced the following paragraph in the first page is correct: Getting a checkout is generally faster than making a copy of a branch. The catch though is that whenever the checkout needs to look at the RCS data it will do so by accessing the branch. This holds true even if the branch is on some distant network that you accessed over the internet. To me, this sounds like it might be talking about a lightweight checkout, as I believe a checkout is a complete copy of the branch, and network access is only required for commits or updates. Bound branches in bzr take the place of remote 'checkouts' in systems like CVS or SVN and we refer to them as 'checkouts'. (bzr also supports lightweight checkouts, which are like local checkouts, and aren't branches at all.) Can anyone confirm/deny? My central dislike of bzr is bugs like: http://bugs.debian.org/380412 https://launchpad.net/products/bzr/+bug/54253 ...which unfortunately makes it unusable for some of my applications. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Fri, 2006-08-04 at 09:56 +1000, Brian May wrote: For documentation on checkouts and bound branches, see http://bazaar-vcs.org/CheckoutTutorial http://bazaar-vcs.org/BzrUsingBoundBranches However, I am not convinced the following paragraph in the first page is correct: Getting a checkout is generally faster than making a copy of a branch. The catch though is that whenever the checkout needs to look at the RCS data it will do so by accessing the branch. This holds true even if the branch is on some distant network that you accessed over the internet. Yes, thats bogus. Getting a heavyweight checkout is identical to getting a new branch. Getting a lightweight one *may* be cheaper, depending on how much history is needed to reconstruct file versions. To me, this sounds like it might be talking about a lightweight checkout, as I believe a checkout is a complete copy of the branch, and network access is only required for commits or updates. Bound branches in bzr take the place of remote 'checkouts' in systems like CVS or SVN and we refer to them as 'checkouts'. (bzr also supports lightweight checkouts, which are like local checkouts, and aren't branches at all.) Can anyone confirm/deny? A checkout --lightweight over the net is currently not a good thing to do. When the smart server is released, that will be about the same performance as traditional client-server vcs's like CVS or SVN. My central dislike of bzr is bugs like: http://bugs.debian.org/380412 https://launchpad.net/products/bzr/+bug/54253 ...which unfortunately makes it unusable for some of my applications. Are you doing conversions from SVN? Current bzr uses 20MB of ram to do a native branch operation in similar circumstances. (bug report gets fixed, new at 11 :)). 0.9RC1 is out, and 0.9 will be out Monday/Tuesdau. As soon as that lands in debian the bug should be closed. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]: Adeodato Simó [EMAIL PROTECTED] writes: Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools We're using that for LTSP. But we're using it in our htdocs dir. How do you set this repository up? Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP access, so if you want that, better stick to htdocs for a while. I hope to be able to bribe buxy to provide HTTP access when he comes back, though. ;-) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Polar - 41 (Forty-One) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato Simó [EMAIL PROTECTED] writes: * Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]: Adeodato Simó [EMAIL PROTECTED] writes: Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools We're using that for LTSP. But we're using it in our htdocs dir. How do you set this repository up? Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP access, so if you want that, better stick to htdocs for a while. I hope to be able to bribe buxy to provide HTTP access when he comes back, though. ;-) So you only have sftp access? that make it difficult to other to branch from our development branch. I'll wait until we have HTTP as a offer to move to it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Wednesday 02 August 2006 21:44, Otavio Salvador wrote: Adeodato Simó [EMAIL PROTECTED] writes: * Otavio Salvador [Tue, 01 Aug 2006 15:43:56 -0300]: Adeodato Simó [EMAIL PROTECTED] writes: Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools We're using that for LTSP. But we're using it in our htdocs dir. How do you set this repository up? Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP access, so if you want that, better stick to htdocs for a while. I hope to be able to bribe buxy to provide HTTP access when he comes back, though. ;-) So you only have sftp access? that make it difficult to other to branch from our development branch. I'll wait until we have HTTP as a offer to move to it. That's in fact an issue that made me feel sceptical about bzr, darcs and mercury. All of them require a shell account or some scripting through a special mail address to commit changes. And it's not only the recent kernel vulnerability that makes me a happy repository user over WebDAV (hoping it's less vulnerable). And it works over a proxy, too. Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato Simó, 2006-08-02 21:20:09 +0200 : % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools [...] Ask in #alioth. Note, however, that TTBOMK still does not offer HTTP access, so if you want that, better stick to htdocs for a while. I hope to be able to bribe buxy to provide HTTP access when he comes back, though. ;-) I just enabled HTTP access for bzr: $ bzr get http://arch.debian.org/bzr/pkg-xiph/vorbis-tools Branched 22 revision(s). bzr.debian.org doesn't exist, so I chose arch.d.o instead. Roland. -- Roland Mas [...] ou une dent pourrie [...] -- in Variations sur un thème imposé -- Signatures à collectionner, série n°2, partie 2/3.
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Wed, 2006-08-02 at 22:29 +0200, Christoph Haas wrote: That's in fact an issue that made me feel sceptical about bzr, darcs and mercury. All of them require a shell account or some scripting through a special mail address to commit changes. And it's not only the recent kernel vulnerability that makes me a happy repository user over WebDAV (hoping it's less vulnerable). And it works over a proxy, too. Well, I dont know darcs well enough to argue there, but neither bzr nor mercurial require a shell account nor scripting. bzr requires sftp access *which can be granted without granting shell access*. mercurial has a http cgi script that can be used to push commits. bzr is also working on a high performance server at the moment, which will operate over either a socketpair - i.e. tunnelling via ssh (which can still be done without granting shell access), or over plain http via an apache rewrite rule. HTH, Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Adeodato Simó [Tue, 01 Aug 2006 20:31:37 +0200]: they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. Not that I'd particularly recommend that scheme, but it _is_ possible. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
also sprach Adeodato Simó [EMAIL PROTECTED] [2006.08.01.1936 +0100]: Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. This is what upstream calls bound branches, btw. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system obviously i was either onto something, or on something. -- larry wall on the creation of perl signature.asc Description: Digital signature (GPG/PGP)
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato Simó [EMAIL PROTECTED] writes: Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools We're using that for LTSP. But we're using it in our htdocs dir. How do you set this repository up? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Tue, 2006-08-01 at 19:44 +0100, martin f krafft wrote: also sprach Adeodato Simó [EMAIL PROTECTED] [2006.08.01.1936 +0100]: Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. This is what upstream calls bound branches, btw. Well, we call them 'checkouts' :). bound branches is somewhat of an internal description. We implemented checkouts to be a precise workflow match for what you get from SVN/CVS - a branch shared between developers with the system ensuring you have merged everything. If you have a situation where a shared branch is what you want, and you like bzr in other respects... I would recommend trying checkouts. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
