[01:09] <Peng_> lifeless: I'm not sure. I only converted two repos to btrees, and I didn't keep non-btree versions around, so I can't compare. I think diffing in the larger one is much faster though.
[01:09] <Peng_> (Well, I did keep non-btree versions around, but in a backup way, not a usable way.)
[01:39] <ub3rst4r> hi, yesterday i doing a commit to my launchpad account. i accidentally used the del to remove some files that i didnt want to commit. I restored them, but they are the wrong files and i cant find the another file that I had.
[01:45] <ub3rst4r> anyone?
[02:03] <grettke> Hi folks.
[02:04] <ub3rst4r> wtf is everyone
[02:04] <grettke> I created a new repo using the 'svn-import' command. I want to push each of my "trunk projects" from that repo I just created into my normal repo. But it is complaining that the repository format is not correct (different rich-root-pack). That is true, my main repo is not rich-root-pack, I don't need it to be. Is there a workaround here?
[02:05] <jelmer> grettke, yes, you can upgrade your normal repository to rich root pack
[02:05] <jelmer> grettke, bzr upgrade --rich-root-pack
[02:06] <ub3rst4r> hi, yesterday i doing a commit to my launchpad account. i accidentally used the del to remove some files that i didnt want to commit. I restored them, but they are the wrong files and i cant find the another file that I had.
[02:06] <grettke> jelmer: I see, so I should have created it initially, at least. Understood. Thanks jelmer.
[02:06] <grettke> jelmer: Wonderful that an upgrade path exists!
[02:06] <jelmer> ub3rst4r, you mean "bzr rm" ?
[02:07] <ub3rst4r> yes
[02:07] <jelmer> ub3rst4r, did you commit the removal?
[02:07] <ub3rst4r> jelmer no, i should of! now i cant find the files anywhere
[02:08] <jelmer> ub3rst4r, but the files were versioned before?
[02:08] <jelmer> ub3rst4r, you can get an older version of a file by running "bzr cat -r<old-rev> <filename>"
[02:08] <ub3rst4r> ill try that
[02:09] <ub3rst4r> bzr: ERROR: u'HiveManager.cs' is not present in revision
[02:10] <jelmer> ub3rst4r, the file was not versioned at that revision?
[02:10] <grettke> jelmer: Potentially dumb question. I created my mainline repo using 'init-repo', and then each project with just 'init'. Do I upgrade the whole repo, or the individual branches. The thing is that I know you can create the whole repo with rich-root-pack...
[02:10] <ub3rst4r> well i added it, but then i removed it
[02:10] <jelmer> grettke, you have to upgrade the repository
[02:11] <ub3rst4r> and then they were moved to the recycle bin and i restored all but 1 file which i cant find
[02:11] <grettke> jelmer: I see. Thanks.
[02:11] <ub3rst4r> and the files that i did restore are older
[02:11] <jelmer> ub3rst4r, and you specified an old-rev in which the file did exist?
[02:12] <ub3rst4r> yea
[02:13] <ub3rst4r> i dunno what to do
[02:15] <grettke> jelmer: Are you guys getting many SVN->BZR switchers?
[02:15] <jelmer> grettke, yeah, quite a few
[02:15] <jelmer> ub3rst4r, sorry, it's probably better to email the list
[02:15] <grettke> jelmer: What had you used before BZR? What were you favorites?
[02:16] <jelmer> grettke, I've used cvs, svn and darcs before bzr
[02:16] <ub3rst4r> jelmer what do u mean, email the list?
[02:16] <jelmer> ub3rst4r, please email the bazaar mailing list, as there don't appear to be a ot of people around at the moment
[02:16] <grettke> jelmer: What did you like *most* about SVN?
[02:21] <jelmer> grettke, ease of use I guess
[02:25] <grettke> jelmer: What is the standard procedure for "moving" a project. I want to move it from /repo/proj to /proj, move is not the right command. Should I create the new proj, just branch and push to the new project, then delete the old one?
[02:27] <jelmer> grettke, not sure I understand - moving a branch in bzr should be as simple as doing a filesystem move
[02:28] <grettke> grettke: I see. I am stuck in svn land.
[02:28] <AfC> jelmer: (well, no, not exactly; if there's a shared repo at .. or somewhere, then just moving the "branch" directory is insufficient. Using `bzr branch` will always work)
[02:29] <grettke> jelmer: Sames goes for renaming it?
[02:29] <AfC> grettke: yes, renaming is transparent.
[02:29] <grettke> AfC: It is a shared repository
[02:29] <AfC> grettke: then if you are moving the branch _outside_ of that shared repository, then you'll need to use branch.
[02:30] <AfC> grettke: if you're just moving it around within (below) that shared repository, then it'll have no impact.
[02:30] <AfC> grettke: there are three things in Bazaar that you need to be aware of (if doing such shenanigans).
[02:30] <AfC> 1) "Working Tree" (ie, a checkout of the sources)
[02:31] <AfC> 2) a "Branch" (usually co-located with the Working Tree; it lives in .bzr/branch/)
[02:31] <AfC> and
[02:31] <AfC> 3) a "Repository" (which can be anywhere from . on up; it lives in .bzr/repository/)
[02:32] <AfC> If the Repository is co-located with the Branch (is co-located with the Working Tree) then you have the situation that is commonly created when you just do a standalone `bzr init .` or `bzr branch`
[02:32] <grettke> AfC: Thanks. That notion is slowing sinking in.
[02:32] <AfC> in THAT common scenario, then yes, you can happily move the branch (carrying the  working tree and repository with it) to your hearts content.
[02:33] <AfC> but if you've used the equally common shared repository idea,
[02:33] <AfC> [which is a good idea]
[02:33] <grettke> AfC: My mainline repo is --no-trees. All of my working trees are elsewhere.
[02:33] <AfC> then you have the catch that the directory containing the Working Tree and Branch does not contain the Repository (which stores the revision data) and so if you go and move that directory somewhere else
[02:33] <AfC> it'll be at a loss to find its revisions.
[02:34] <AfC> Hence, for that case, use `bzr branch`.
[02:38] <grettke> AfC: I see. The repository is different than the .bzr directory. If I had not used the --not-trees, then every branch would have its on repository?
[02:40] <grettke> AfC, jelmer: So why choose a common shared repository over a repo in every branch?
[02:42] <AfC> No. If you had not used no-trees then every Branch in the Repository would have a full Working Tree present as well.
[02:43] <AfC> Branches outside from under that shared Repository will [have to] have their own repositories (copies of all the  revisions making up that branch) along for the ride.
[02:44] <grettke> AfC: More is sinking in...
[02:45] <grettke> AfC: So for my mainline repo, if I init it with --no-trees, that just means when I create branches that working copies won't also get created, and that there is a single repository shared by all branches, and when I back up that repo, I can just file-copy that directory and I will be finished. What is the benefit of a shared repo, space saving?
[02:46] <AfC|out> There's no "mainline repo". There is a "mainline branch".
[02:46] <AfC|out> That lives somewhere.
[02:46] <grettke> AfC: Right... thanks.
[02:46] <AfC|out> It's either got all it's own revisions, or they're at ../ or ../../ or ... somewhere
[02:46] <grettke> I will have mainline branches that have a shared repo, that is it.
[02:47] <AfC|out> No. There is a single mainline branch. Singular. Other branches (forks of it, hopefully someday to be merged back into it) living along side it can avoid duplicating all the revision data if you share it at ..
[02:48] <grettke> AfC: I read the user guide, but clearly I'm not getting. What else should I read?
[02:51] <AfC|out> {shrug} In one project I'm involved in we have a brief getting started note, http://java-gnome.sourceforge.net/4.0/HACKING.html but I think what you need to do is stop worrying so much about setup and just get on with using it. The other stuff will become clear in due course.
[02:53] <grettke> AfC: That is what I've been doing. I've got my svn stuff I want to move over, too.
[02:53]  * AfC|out goes out
[04:05] <lampliter> how do you tell if the main image (what I have on launch pad) is different from the branch I have locally?
[09:19] <Rolly> lampliter: bzr missing?
[11:06] <Peng_> jelmer: ping?
[13:23] <jelmer> Peng_, hi
[13:23] <Peng_> jelmer: Hello.
[13:24] <Peng_> Err
[13:24] <Peng_> jelmer: I have an odd bzr-svn issue
[13:24] <Peng_> (I was able to work around it, but anyway..)
[13:25] <Peng_> I haev a shared repo where I have copies of Python's various branches, both imported myself using bzr-svn, and using the imports on http://code.python.org/
[13:26] <Peng_> Today, I was trying to branch http://code.python.org/python/2.6/ , but it failed with a RevisionNotPresent.
[13:26] <Peng_> I already had a copy of http://svn.python.org/projects/python/branches/release26-maint (the svn version of that branch) in the same repo. After pulling the latest changes, I was able to branch the code.python.org branch successfully.
[13:27] <Peng_> RevisionNotPresent: Revision {svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Fbranches%2Frelease26-maint:66865} not present in "2166@6015fed2-1504-0410-9fe1-9d1591cc4771:p
[13:27] <Peng_> ython%2Ftrunk:Lib".
[13:27] <Peng_> Erk
[13:27] <Peng_> So yeah. :D
[13:27] <LarstiQ> luks: I've got a very very ugly hack to do search for qannotate on file texts. It currently just pops up a QLineEdit without a parent to prompt for the search text ;)
[13:55] <jelmer> Peng_, One of the two was probably made with a buggy (older) version of bzr-svn
[13:57] <Peng_> jelmer: How did doing the other pull fix it?
[18:04] <eudoxos1> Hi there, I've been googling around for shallow branches and I am wondering what is the progress on that front (blueprints, wiki, blogs, all silent on that). Stacked branches are related to that, right? Is that on schedule for whatever comes after 1.9?
[20:31] <faheem_> Hi. Is bzr-gtk the recommended tool for viewing a repos dag? I've had some difficulties with it, debian lenny.
[20:32] <faheem_> !bzr-gtk
[20:33] <faheem_> Using olive-gtk, that is.
[20:33] <faheem_> Should I be using the versions in experimental?
[20:35] <faheem_> To be more specific, if I do olive-gtk, and click on log, I get "Please wait, loading ancestry graph.." which then hangs.
[20:36] <faheem_> This is with the Debian apt repos.
[20:37] <faheem_> I also get a traceback.
[20:50] <jelmer> faheem_, please file a bug
[20:56]  * awilkins prefers qbzr for viewing a repos dag
[20:57] <awilkins> But I still prefer gconflicts because qbzr doesn't have one ;-)
[21:12] <jelmer> awilkins, qbzr as in qlog ?
[21:16] <awilkins> jelmer: Yes
[21:50] <faheem_> jelmer: File a bug where, with Debian or upstream?
[21:51] <jelmer> faheem_, debian
[21:51] <faheem_> awilkins: Is qbzr in Debian?
[21:52] <faheem_> jelmer: Ok, will do.
[21:54] <jelmer> faheem_, no, qbzr isn't packaged for debian
[22:17] <faheem_> What is the bzr equivalent of hg paths?
[22:18] <faheem_> jelmer: Severity normal Ok?
[22:19] <Neil> I have baz Bazaar version 1.4.2 and Bazaar (bzr) 1.8.  How do I import my change history from one to the other?  The BAzaar webpage points to bzrtools, but bzrtools 1.8 seems to have no such command.
[22:23] <jelmer> Neil, it's split out into a separate plugins these days
[22:23] <jelmer> faheem_: Yeah, sounds fine
[22:23] <jelmer> faheem_, what does "hg paths" do?
[22:23] <Neil> jelmer: Do you know where I can get that then? Thank you
[22:24] <faheem_> jelmer: the repositories which hg knows about - specifically, the repos it was cloned from.
[22:24] <faheem_> bzr info looks like it gives me what I want.
[22:24] <jelmer> faheem_, I think "bzr info" comes closest
[22:24] <jelmer> Neil, http://code.aaronbentley.com/bzr/bzrrepo/bazimport/ seems like it contains a version of that plugin
[22:24] <Neil> thank you
[22:24] <jelmer> but I'm not sure whether or not that is the latest
[22:24] <Neil> well I'll try it, heh
[22:27] <faheem_> jelmer: Done. Are you a developer?
[22:27] <jelmer> faheem_, yep
[22:28] <faheem_> Shall I post the bug number here when I get it?
[22:29] <jelmer> faheem_: no - thanks, but I should already be automatically notified by email
[22:29] <faheem_> jelmer: Ok. Take care. Thanks.
[22:30] <Neil> dang.  Unable to load plugin 'bazimport' from '/usr/local/bzr-1.8/lib/python2.5/site-packages/bzrlib/plugins'
[22:31] <LarstiQ> it used to be in bzrtools
[22:32] <Neil> I wish it still was in there since bzrtools is working :-)
[22:33] <LarstiQ> Neil: could you pastebin the traceback (from ~/.bzr.log)
[22:33] <Neil> how do I get a traceback for it?
[22:34] <LarstiQ> Neil: it should be in ~/.bzr.log
[22:34] <Neil> ah thank you, looking
[22:35] <Neil> http://www.hakubi.us/temp/bzr-log
[22:36] <LarstiQ> Neil: or, what also would have worked, is -Derror
[22:36] <LarstiQ> Neil: ah, it expects a recent bzr
[22:37] <LarstiQ> Neil: introduced in revision 658 in bazimport
[22:37] <Neil> hmm
[22:37] <LarstiQ> Neil: so, you could use a slightly older version of bazimport, or a newer version of bzr.
[22:37] <Neil> thank you very much
[22:37] <LarstiQ> Neil: try bzr revert -r 657 for the former
[22:37] <Neil> guess I get to start learning bzr manipulations right away :-)
[22:37] <LarstiQ> (in bazimport)
[22:39] <Neil> hooray, it shows up without error in bzr help commands
[22:39] <Neil> now the real test though :-)
[22:45] <LarstiQ> right, that bzr can import the plugin doesn't guarantee the plugin can do the conversion between two version control systems :)
[22:45] <LarstiQ> but if it can't, that is certainly a bug, and not api drift
[22:57] <Neil> I've been using arch actually for 6 years, but I'm co founding a new company and need to share the tree with someone on Windows.  So I have to pull out some of my work, and Bazaar looked like the best best.
[22:57] <Neil> I'll probably end up moving over my personal stuff as well
[23:20] <LarstiQ> Neil: cool
[23:20]  * LarstiQ calls it a night
[23:21]  * Odd_Bloke calls it a fish.


[00:43] <mcint> I'm having trouble getting lxd (and initially MaaS) to recognize and run my cloud-init. I'm running based on what's here https://cloudinit.readthedocs.io/en/latest/topics/datasources/lxd.html, `lxc launch ubu:20.04 my-inst -c cloud-init.user-data="$(cat ci.yml)"`. I `lxc exec my-inst -- cloud-init -w`, and then `cloud-init query -a` but don't see my user-data. I do see it if I curl as described on the
[00:43] <mcint> linked page. And my changes are not applied
[00:53] <mcint> Is there an obvious error in what I've shared?
[00:57] <mcint> colleague clarified, I may have been passing in subiquiti's format. an extra parent/grandparent
[06:08] <gsz> Hi! I’m trying to setup automated Ubuntu installer. In general it works well, but it seems to use the APT proxy specified in autoinstall->apt->proxy (the user-data file) only to fetch the metadata (dists), not the actual packages (pool). Is there any way I could make it use the proxy for all APT traffic? I see I can achieve this using autoinstall->proxy option instead, but I’m afraid the installer
[06:08] <gsz> would use the proxy for all network traffic, not only for APT (I’m not sure if there is any other network traffic though).


[17:15] <snikker> hi, the ols script in "/etc/init.c/" work also with upstart without any conversion?
[17:15] <snikker> *old
[17:16] <snikker> i mean, how what i do for get my old init script to work with upstart?
[17:48] <omani> lol
[18:11] <wasabi> snikker, your old init scripts don't work with upstart directly. Upstart does however implement sysv startup.
[18:12] <wasabi> Through the rc* scripts in /etc/init
[18:12] <wasabi> The rc system still runs.
[18:13] <snikker> wasabi: oh, ok i'm under ubuntu and i'd like convert my init scripts (/etc/init.d) for upstart
[18:13] <wasabi> Go for it.
[18:15] <wasabi> Folks, do we have a page outlining the current upstart structure in Ubuntu? Common events, common jobs, time periods, etc?
[19:46]  * keesj discovers upstart-udev-bridge