| lifeless | pickscrape: I'm not aware of any BB maintainers, no. | 00:02 |
|---|---|---|
| kfogel | lifeless: can I pick your brains for a sec about bzr+ssh and hooks? about 5 min | 00:20 |
| lifeless | kfogel: no. | 00:20 |
| lifeless | kfogel: you can read my reply to beuc, then come and pick my brains after that. | 00:20 |
| kfogel | lifeless: I did. | 00:20 |
| lifeless | ok cool | 00:20 |
| kfogel | lifeless: oh, wait -- you mean in the last half hour or so? | 00:20 |
| lifeless | 120 seconds ago | 00:20 |
| kfogel | lifeless: I was writing a reply, then wanted to confirm something... heh | 00:20 |
| kfogel | lifeless: cool | 00:20 |
| kfogel | lifeless: you may have made my whole reply unnecessary. I'll go read now. | 00:21 |
| lifeless | kfogel: bzr-hookless-email is totally different, btw. | 00:25 |
| kfogel | lifeless: I know (I'm well-acquainted with it, and have a patch in it actually). I think it is what Stefan is using for commit emails, but am not positive. | 00:26 |
| kfogel | I'm pretty sure we're *not* using bzr-email. | 00:26 |
| lifeless | well, you can't, until bzr-ssh is enabled. | 00:26 |
| lifeless | at which point you probably should :P | 00:26 |
| kfogel | lifeless: actually, I like Stefan's solution much better, because then mods to our commit email system do not have to block on savannah admins! | 00:27 |
| lifeless | kfogel: I don't see the connection, but I don't care either. | 00:27 |
| lifeless | whatever you like is what you should get | 00:27 |
| kfogel | (my description of how bzr-hookless-email works to Sylvain is a bit too shorthand; unfortunately savannah tracker doesn't allow comment editing either :-( ) | 00:28 |
| lifeless | neither does lp. | 00:28 |
| lifeless | wikis they are not | 00:29 |
| igc | morning | 00:56 |
| === timchen119 is now known as nasloc__ | ||
| === oubiwann_ is now known as oubiwann | ||
| a7p | hi everyone - is there a way to generate a revisionnumber into a file? I want it to get printed out each time the program is started. | 02:10 |
| a7p | so the user can see which revision he is running. | 02:10 |
| bob2 | bzr version-info | 02:11 |
| dOxxx_afk | http://bazaar-vcs.org/KeywordExpansion | 02:11 |
| === dOxxx_afk is now known as dOxxx | ||
| a7p | dOxxx: exactly what I'm looking for, thx | 02:13 |
| phoenixz | I did a bzr tag --force.. ever since, every push and pull I get "conflicting tags: blah"... how can I fix this? | 02:32 |
| spiv | push --overwrite | 02:32 |
| spiv | Or pull --overwrite | 02:32 |
| spiv | Depending on which tags you want to keep and which you want to overwrite :) | 02:32 |
| jamesh | lifeless: the patch on the "disable pymalloc" bug does have a configure switch to enable it. The issue about the tuple cache is certainly something that would be a useful extension, but the patch is useful on its own | 02:56 |
| lifeless | jamesh: cool. I'm chatting to gutworth about it | 02:57 |
| gutworth | ssh: connect to host bazaar.launchpad.net port 22: Connection refused | 03:00 |
| gutworth | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 03:00 |
| gutworth | ? | 03:00 |
| gutworth | ah, launchpad is down | 03:00 |
| lifeless | yes :( | 03:01 |
| lifeless | we're doing a db schema change amongst other things | 03:01 |
| lifeless | and zope is blowing up | 03:01 |
| lifeless | I'm told we're rolling back and it will be back very soon | 03:01 |
| * gutworth is so glad he's not in charge of administering large websites | 03:02 | |
| lifeless | somehow encodings.utf_8.codecs became None | 03:03 |
| lifeless | not during vm shutdown either | 03:03 |
| gutworth | that happens in our tests all the time, too | 03:03 |
| lifeless | does it? thats very interesting | 03:03 |
| lifeless | does anyone have any idea /how/ ? | 03:03 |
| gutworth | you should ask __ap__ when he's up | 03:04 |
| gutworth | I think he fixed it | 03:04 |
| a7p | mmm ... ~/.bazaar/rules is written, but $Date$ does not get replaced upon a commit - do I miss something concerning keywords? | 03:04 |
| lifeless | shall | 03:04 |
| a7p | selftest ran fine. | 03:04 |
| gutworth | we're very proud of __ap__. This is his handywork http://python.org/dev/buildbot/stable/ | 03:05 |
| gutworth | lifeless: http://bugs.python.org/issue6551 | 03:09 |
| lifeless | thanks! | 03:10 |
| a7p | is there any way to check if the rules file is applied? | 03:15 |
| spiv | a7p: it should be if your working tree is in a new enough format, IIRC. | 03:16 |
| a7p | *sigh* | 03:17 |
| spiv | a7p: (2a, the default format in 2.0.0, is new enough) | 03:17 |
| lifeless | a7p: what bzr version do you have? | 03:18 |
| lifeless | a7p: what does 'bzr info' report for you? | 03:18 |
| spiv | a7p: I don't think there's a command to find out what filters are active or applied to a particular file, although maybe there should be. | 03:18 |
| a7p | pack-0.92 - I'm running 1.18 | 03:18 |
| spiv | 'bzr upgrade --1.14' would work for you I think. | 03:19 |
| gutworth | yep you need a later version | 03:19 |
| spiv | (Although I'd recommend upgrading to bzr 2.0.0 and using the current format when you can, as it is faster and smaller.) | 03:20 |
| a7p | thx, - thanks I'll try that ... just have 1.18 installed since it's the default in macports | 03:20 |
| poolie | mwhudson: the bugs attached to lp:ubiquity seem to imply we need to think a bit more about the user model too | 03:26 |
| a7p | *sigh* - still does not work. | 03:27 |
| poolie | a7p: what specifically is not working? | 03:28 |
| poolie | you're not seeing the file being filtered? | 03:28 |
| poolie | there were several bugs in 1.18 with filters not been applied enough | 03:28 |
| poolie | sorry, but that's how it was | 03:28 |
| poolie | several are fixed in 2.0.x | 03:28 |
| a7p | poolie: i've just upgraded to 2.0.2 | 03:29 |
| a7p | http://paste.ubuntu.com/333592/ | 03:29 |
| a7p | rules is configured to [name *] keywords = on | 03:30 |
| poolie | % bzr plugins | 03:30 |
| a7p | to my understanding $Date$ should get the current date added upon commit | 03:30 |
| a7p | git, hg, keywords, launchpad, net_credential_store, svn, xmloutput | 03:31 |
| spiv | a7p: I think you can also do 'rm foo; bzr revert foo' to regenerate a file with the current filters. | 03:31 |
| poolie | yes it'd be good to see if that works | 03:31 |
| a7p | ah, I should run the selftest with 2.0.2 | 03:31 |
| poolie | selftest is quite an internally-facing test | 03:31 |
| poolie | it probably won't find anything related to bad installation | 03:32 |
| a7p | okay - theres' something messed up - was fine with 1.18 | 03:32 |
| a7p | I'll remove the other plugins | 03:32 |
| spiv | selftest is mainly a tool for developers rather than users | 03:32 |
| poolie | james_w: i guess you're asleep? | 03:32 |
| james_w | hi poolie | 03:33 |
| james_w | guess again :-) | 03:33 |
| poolie | hi | 03:33 |
| poolie | blame canada? :) | 03:33 |
| poolie | anyhow | 03:33 |
| poolie | regarding the udd stuff | 03:33 |
| * a7p is confused - just removed most plugins from ~/.bazaar/plugins, but they still appear upon bzr plugins | 03:33 | |
| poolie | james_w: i realize there is more to do than the two items i raised and the ones vincent added | 03:34 |
| a7p | ah, sry, my wrong | 03:34 |
| spiv | a7p: 'bzr plugins -v' | 03:34 |
| poolie | i should have made it more clear that i'm just trying to work out what specifically to do in the medium term | 03:34 |
| spiv | (that shows you where they seem to be installed) | 03:34 |
| poolie | to get from a longish set of stories to what we do this week and next week | 03:34 |
| james_w | poolie: yeah, I think I may have phrased my mail badly | 03:36 |
| poolie | it happens :) | 03:36 |
| a7p | ahhh ... *g* | 03:36 |
| james_w | I felt I was missing a step, I saw "here's a bunch of things we could work on," then "here's what we are going to work on," and didn't feel I knew how the two were joined | 03:37 |
| poolie | oh | 03:37 |
| james_w | I appreciate I wasn't at the sprint | 03:37 |
| a7p | $Date: (evaluation error) $ - it's a big step forward ;) | 03:37 |
| poolie | well, it was kind of a straw man for you to object to | 03:37 |
| poolie | if you were to file say 3 high priority bugs tagged udd we'd probably just do them | 03:37 |
| poolie | i don't know if you feel ready or able to do that | 03:38 |
| spiv | a7p: heh | 03:38 |
| poolie | but we do need to cross that somehow | 03:38 |
| james_w | poolie: I'm currently writing my second spec, which should distill out some of the other things that we would like | 03:38 |
| james_w | I think it would be good to see how that tallies with the list that you had, and see what changed at UDS | 03:38 |
| james_w | I'm concious of time passing, but the spec will be done tonight, and I'll fire off a mail to udd before bed | 03:39 |
| james_w | https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-lucid-distributed-development is one | 03:39 |
| poolie | that's ok | 03:39 |
| poolie | we have useful stuff to do | 03:39 |
| poolie | i'm writing a mail about this at the moment | 03:39 |
| james_w | see "Migration" for one set of things that I'm not entirely sure about | 03:39 |
| poolie | i just feel a bit like the bzr team is doing business as usual on bzr | 03:39 |
| james_w | yeah | 03:40 |
| poolie | when we should be reorienting a bit more towards udd | 03:40 |
| mwhudson | poolie: yeah | 03:40 |
| a7p | grrr, I'm giving up for now - got to write some code for money. | 03:48 |
| a7p | thanks for your help | 03:48 |
| a7p | puh, just switched from bzr+ssh to sftp to avoid having to upgrade the servers bzr. | 04:07 |
| james_w | poolie: do you think one mail with all the issues I want to discuss to udd is the best thing | 04:22 |
| james_w | or start a thread per-issue? | 04:22 |
| * Kamping_Kaiser shakes his head at bzr. 3 step upgrade is a bit silly | 04:22 | |
| james_w | ooh, thanks mwhudson | 04:24 |
| mwhudson | james_w: i hope you're not in bristol | 04:24 |
| james_w | nope :-) | 04:25 |
| maxb | Is there any UI for "make this repository as small as possible", or must I manually rm the contents of obsolete_packs to achieve this? | 04:25 |
| mwhudson | james_w: good | 04:26 |
| mwhudson | james_w: and you're talking about the AttributeError thing? | 04:26 |
| james_w | yeah | 04:26 |
| james_w | though I like the cleanups anyway :-) | 04:26 |
| mwhudson | james_w: ah, np :) | 04:26 |
| bob2 | maxb: it'll clear it out on the next pull or commit | 04:26 |
| mwhudson | i was impressed there wasn't more flakes | 04:26 |
| james_w | I use vim-pyflakes now | 04:26 |
| poolie | maxb: there's a bug for an option to pack to rm them | 04:27 |
| poolie | um | 04:27 |
| lifeless | maxb: not really, why? | 04:27 |
| poolie | james_w: whatever you think best | 04:27 |
| Peng | bob2: No, it'll clear out on the next pack. | 04:28 |
| Peng | (including auto-packs) | 04:28 |
| bob2 | oh | 04:28 |
| maxb | It just feels like a UI wart | 04:28 |
| maxb | and rm-ing things inside .bzr is scary-ish | 04:28 |
| Peng | maxb: But...why would you want to? | 04:29 |
| bob2 | Peng: it can take up significant amounts of space | 04:30 |
| lifeless | only if you run 'bzr pack' :) | 04:30 |
| bob2 | (I thought the next operation that altered the repo data cleared obsolete_packs) | 04:30 |
| lifeless | generally it will be ~ 1% of the repo | 04:30 |
| lifeless | bob2: the next that /deletes/ from the repo | 04:30 |
| lifeless | packing involves deleting pack files | 04:30 |
| maxb | james_w: I would like to do something about the copy-pasted code from "bzr import" (bzrtools) to "bzr import-dsc" (bzr-builddeb). I see two options: A) Push the changes into bzrtools, and depend on a *really* new bzrtools, or B) Separate out the code into a .py file which is deliberately maintained to be as close as possible to the bzrtools version, but sever the actual dependency. What do you think? | 04:34 |
| james_w | maxb: I'd like to push the changes to bzrtools, so at least we could depend on it after a dwell period | 04:35 |
| james_w | and because it's the right thing to do :-) | 04:35 |
| james_w | I just haven't previously had time to separate out the changes and propose them back, sorry | 04:36 |
| maxb | james_w: Do you think option B might make sense in the interim, to make it easier to see what we still need to push back? | 04:38 |
| james_w | maxb: I would have no problem with doing that | 04:38 |
| maxb | I'll do a MP | 04:38 |
| dOxxx | good night all | 04:55 |
| mwhudson | james_w: have you seen https://code.edge.launchpad.net/~mwhudson/pyflakes/support-lazy-imports ? | 05:02 |
| james_w | I've heard about it | 05:03 |
| james_w | haven't ever felt the need to use it though | 05:03 |
| mwhudson | hm, i should merge trunk into it again it seems | 05:03 |
| mwhudson | instead i'm going to go and see spamalot though :) | 05:03 |
| james_w | enjoy | 05:04 |
| poolie | spiv, hi? | 05:14 |
| poolie | quick call? | 05:14 |
| spiv | poolie: sure | 05:21 |
| james_w | good night | 06:17 |
| vila | hi all | 07:20 |
| vila | james_w: wow, where are you ? Or should I say when ? | 07:20 |
| RAOF | There's currently no way to embed a branch within a branch, is there (ie: foo/ being a branch, and branching bar into foo/bar)? | 07:21 |
| Peng | RAOF: Well, bzr won't mind if you put "bar" in "foo", but they won't be linked together in any way like svn:external. | 07:30 |
| * igc dinner | 08:39 | |
| bialix | hello | 09:41 |
| * fullermd waves at bialix. | 09:45 | |
| * bialix warmly waves back | 09:46 | |
| * bialix hopes he learn this "waves" phrases correctly | 09:46 | |
| fullermd | Well, except for the 'warmly' part. This time of year, I don't believe anything around you is warm :p | 09:48 |
| bialix | even if you in the building? | 09:50 |
| vila | bialix: hey ! | 09:59 |
| bialix | heya vila!!! | 09:59 |
| vila | fullermd: ha ha ! You didn't escape quickly enough today ! | 09:59 |
| bialix | got my mail? | 09:59 |
| bialix | fullermd: vila: LOL | 10:00 |
| vila | which one ? :) I just replied to the selftest related one | 10:00 |
| bialix | about extra libs | 10:00 |
| vila | not yet | 10:00 |
| fullermd | Eep! I mean, I'm not fullermd. I just broke into his house, and am using his keyboard. Yeah. That's it. | 10:00 |
| bialix | wanna chat? | 10:00 |
| vila | I filed a bug about it this morning, let me find that back, but yes, a quick chat will be welcome, we can always update the bug with a summary of it | 10:01 |
| bialix | link to a bug please? | 10:01 |
| vila | fullermd: right, so get out of that house, quick ! You don't know what the guy will do if he finds you!!!! | 10:02 |
| vila | fullermd: he's known to be a freaking lunatic, member of the NRA and very active there ! | 10:02 |
| vila | fullermd: and that's without mentioning his remotely controlled webcam, man, you're so already dead.... | 10:03 |
| fullermd | Webcam?! Ack! | 10:04 |
| * fullermd puts on pants real quick. | 10:04 | |
| vila | bialix: bug #491797 | 10:04 |
| ubottu | Launchpad bug 491797 in bzr-windows-installers "Allows bzr.exe to take additional plugins (and their required libraries) into account" [Undecided,New] https://launchpad.net/bugs/491797 | 10:04 |
| bialix | vila: just this morning I've thought about standard location for extra libs | 10:06 |
| bialix | maybe bzr needs to use something like PythonXY/site-packages | 10:07 |
| vila | bialix: aaah, execellent, I was afraid some technical reason was escaping me making it impossible ! | 10:07 |
| bialix | inside C:\Program Files\Bazaar | 10:07 |
| vila | yup, exactly my thoughts | 10:07 |
| vila | may be I expressed it too poorly in the bug report ? | 10:08 |
| bialix | there will be several difficulties IMO, but nothing really critical | 10:08 |
| vila | It's kind of related to that BZR_PLUGIN_PATH discussion we had some weeks ago | 10:08 |
| bialix | sorry, I don't remember | 10:08 |
| bialix | last 2 months I was overloaded on my job | 10:08 |
| vila | plugins can be searched into 'core', 'user', 'site', I seem to remember 'site' didn't make sense for you in the bzr.exe context | 10:09 |
| bialix | vila: perhaps | 10:14 |
| bialix | what is user there? | 10:14 |
| bialix | core means inside bzrlib/plugins/ ? | 10:15 |
| bialix | I don't remember what is site | 10:15 |
| bialix | silly me, forget everything :-( | 10:15 |
| vila | 'core' is bzrlib/plugins, 'user' is ~/.bazaar/plugins and 'site' is ... well site-dependent obviously but that's the place where plugins are installed when you want all users to be able to access them | 10:16 |
| vila | bialix: I think you forget it because you have no use for it yourself :) | 10:17 |
| bialix | yep, I'm happy with BZR_PLUGIN_PATH | 10:17 |
| bialix | for bzr.exe there is no use for core then | 10:18 |
| bialix | because bzrlib/plugins resides inside library.zip | 10:18 |
| bialix | I've explicilty extracted launchpad plugin from there | 10:18 |
| bialix | so now 'site' for bzr.exe is C:\PF\Bazaar\plugins | 10:19 |
| bialix | PF == Program Files (too much to type) | 10:19 |
| bialix | and user in APPDATA\bazaar\2.0\plugins | 10:19 |
| vila | hmm, great, so can you add c:\PF\Bazaar\lib to sys.path ? | 10:19 |
| bialix | never really likes this 2.0 | 10:19 |
| bialix | it was not very good from jam side | 10:20 |
| vila | and similarly APPDATA\bazaar\2.0\lib ? | 10:20 |
| bialix | PF\Bazaar\lib should not be added | 10:20 |
| vila | why ? | 10:20 |
| bialix | because there all our standard c-extension lives | 10:20 |
| bialix | wait a sec | 10:21 |
| vila | so you mean it's already there and doesn't need to be added ? | 10:21 |
| bialix | vila: here is PF\Bazaar | 10:23 |
| bialix | http://pastebin.com/d6d2dc13c | 10:23 |
| vila | what's in lib ? | 10:23 |
| bialix | here is lib: http://pastebin.com/d2d2ef24d | 10:24 |
| bialix | scary | 10:24 |
| bialix | yes, lib is used for bundled libs for bzr.exe | 10:24 |
| bialix | there is lib\library.zip where all python-only libs stored | 10:25 |
| bialix | and too much of other c-extensions and dlls | 10:25 |
| vila | excellent ! That's exactly where we *could* add more libs, except it will be far cleaner to have another one in sys.path | 10:25 |
| bialix | I've explicitly move those libs from PF\Bazaar to PF\Bazaar\lib | 10:25 |
| bialix | vila: we should not use lib | 10:25 |
| bialix | it's for standard things | 10:26 |
| vila | Yeah, so what ? If I want to kill my install who will forbid that ? :-) Kidding, that's why I say we should add one more | 10:26 |
| vila | So APPDATA\bazaar\2.0\lib sounds perfect no ? | 10:27 |
| vila | Ha no, that's 'user', where would be 'site' then ? | 10:27 |
| vila | bialix: anyway, we are indeed back to that discussion, the needed concepts are 'core', 'user' and 'site' otherwise we're running into cycles | 10:28 |
| vila | 'core' is protected (that's your arguments about putting nothing more there), so you have to provide 'site' | 10:29 |
| vila | That could be PF\Bazaar\site-lib | 10:29 |
| vila | or PF\Bazaar\site\{lib,plugins} | 10:30 |
| vila | bialix: still there ? | 10:30 |
| bialix | vila: bbiab | 10:31 |
| vila | bialix: ok, no worries | 10:32 |
| === jelmer_ is now known as jelmer | ||
| vila | fullermd: how can I use tmfs on freeBSD (i.e. in memory file system for /tmp) ? | 10:56 |
| vila | fullermd: looks like I need to add that to the kernel ? | 10:58 |
| vila | fullermd: I hardly believe it's not there by default >-/ | 11:00 |
| fullermd | Or load it as a module, I guess. I've never actually used it myself. | 11:00 |
| fullermd | I just use a md-backed regular FS for mine. | 11:00 |
| vila | that's what I want: /tmp in memory, whatever the mean ! | 11:01 |
| vila | fullermd: how do you do that ? | 11:01 |
| fullermd | See the tmpmfs flag (and probably tmpsize) for rc.conf. | 11:02 |
| fullermd | (the default size is 20 megs, so that's probably a little tighter than you usually want in practice... | 11:02 |
| vila | fullermd: so in defaults/rc.conf the doc for tmpmfs says: Set to YES to always create an mfs /tmp, NO to never | 11:07 |
| vila | fullermd: and the default is AUTO.... color me confused :) | 11:07 |
| vila | what does that mean exactly ? | 11:07 |
| vila | df /tmp says 1M 512-blocks, so 512M, but that looks like real disk to me (as real as a VM can go that is...) | 11:08 |
| vila | fullermd: anwyay, using tmpmfs="YES", tmpsize="256m" and rebooting, I now have a /dev/md0 | 11:14 |
| vila | fullermd: so last question: when doing df I now have: | 11:15 |
| vila | /dev/ad0s1e 1015260 5848 928192 1% /tmp | 11:15 |
| vila | /dev/md0 507356 300 466468 0% /tmp | 11:15 |
| vila | fullermd: could that be a problem ? Is the later mounted on top of the former ? Do the former act as an extension area for the former (ha ha, dream !) ? | 11:16 |
| vila | OR should I just comment out the line in fstab for the former? | 11:16 |
| === suBMUNDO is now known as SuBmUnDo | ||
| fullermd | Yeah... having two things mounted on the same point is usually not what you really want :p | 11:32 |
| vila | fullermd: ok, commented out for next reboot, df /tmp points to /dev/md0 for now, so I'm good :) | 11:35 |
| === mrevell is now known as mrevell-lunch | ||
| poseidm | can I use bazaar also as a backup system for directories with binary files? | 12:23 |
| spiv | poseidm: yes | 12:28 |
| poseidm | do you use it for backup? or some other tool? | 12:34 |
| === statik` is now known as statik | ||
| === mrevell-lunch is now known as mrevell | ||
| bialix | vila: ping, I'm back | 14:05 |
| vila | bialix: wow, that was a big biffy ;-) | 14:06 |
| bialix | biffy? | 14:06 |
| vila | bialix: what is the last message you read in the conversation this morning ? | 14:06 |
| bialix | what means biffy? | 14:06 |
| vila | bialix: bbiab means be back in a biffy, biffy being a very short time AIUI | 14:07 |
| beuno | vila, spiffy? | 14:07 |
| beuno | (hi!) | 14:07 |
| vila | http://www.internetslang.com/BBIAB.asp says bit not biffy... | 14:08 |
| bialix | bbiab means be back in a bit? | 14:08 |
| vila | where did I get that then.... | 14:08 |
| bialix | yes, vila, my in a bit was a bit longer than biffy | 14:08 |
| vila | anyway, glad you're back :) | 14:09 |
| vila | bialix: what is the last message you read in the conversation this morning ? | 14:09 |
| bialix | [2009-12-03 12:30:39] <vila> bialix: still there ? | 14:09 |
| bialix | :-D | 14:09 |
| bialix | I have log | 14:09 |
| vila | hehe, so, how about PF\Bazaar\site\{lib,plugins} ? That seems to clearly defines the 'site' needed directories no ? | 14:10 |
| bialix | vila: So APPDATA\bazaar\2.0\lib sounds perfect no ? -- no, it seems wrong | 14:10 |
| bialix | esp on Vista where it could be roaming | 14:10 |
| vila | yeah, yeah, keep reading :) | 14:10 |
| bialix | ok | 14:10 |
| bialix | so | 14:10 |
| bialix | that's why I said at start of our chat that good name is needed | 14:11 |
| bialix | maybe PF\Bazaar\python25-libs | 14:11 |
| bialix | maybe | 14:11 |
| bialix | any other variant is good, but having python version specified may help to avoid confusion | 14:11 |
| bialix | if people start installing package for 2.6 | 14:11 |
| bialix | PF\Bazaar\lib -- is our core | 14:12 |
| bialix | PF\Bazaar\plugins is our site | 14:12 |
| bialix | I mean for bzr.exe | 14:12 |
| vila | so, if you want to take that into account, the blessed names are: | 14:12 |
| bialix | core is inside r/o blackbox, let me say that | 14:13 |
| vila | <bialix> PF\Bazaar\lib -- is our core | 14:13 |
| vila | <bialix> PF\Bazaar\plugins is our site | 14:13 |
| bialix | beuno: what is spiffy? | 14:13 |
| vila | meh, don't mix up core and site there, one is for libraries, the other for plugins, so both should be 'core' | 14:13 |
| bialix | if you insist that bzrlib/plugins/* is core then I can say that PF\Bazaar\lib\library.zip -> bzrlib/plugins/* is the core | 14:15 |
| vila | then you can have site\lib and site\plugins for 'site' and if needed lib\py25 lib\py26 but that would mean that bzr.exe exists for both 2.5 and 2.6, is that the case ? | 14:15 |
| bialix | and hi beuno | 14:15 |
| bialix | vila: no, bzr.exe bundled only one interpreter | 14:15 |
| vila | bialix: I don''t understand the meaning of -> here | 14:15 |
| beuno | bialix, http://www.urbandictionary.com/define.php?term=spiffy | 14:15 |
| bialix | beuno, ah thx, it was spiffy | 14:16 |
| vila | beuno: In fact I think I meant be back in a jiffy | 14:16 |
| === pickscrape_ is now known as pickscrape | ||
| bialix | pfffffffffffffffffffffff | 14:16 |
| beuno | vila, that's it! jiffy! :) | 14:16 |
| beuno | bialix, http://www.urbandictionary.com/define.php?term=jiffy | 14:16 |
| beuno | :) | 14:16 |
| bialix | vila: I've used -> to indicate it's inside zip archive | 14:16 |
| vila | bialix: ha ! ok ! FUll agreement ! core is r/o blackbox-cant-be-modified | 14:17 |
| * bialix shakes vila's hand, cool | 14:18 | |
| vila | but BZR_PLUGIN_PATH allows the user to put 'site'/'user' *before* 'core' if needed | 14:18 |
| * vila re-reading plugin.py | 14:19 | |
| vila | bialix: can you look at plugin.py get_core_plugin_path() and get_site_plugin_path() too ? | 14:20 |
| vila | I think we are pretty close so let's make these last steps | 14:21 |
| bialix | vila: I'm not quite understand your remark about BZR_PLUGIN_PATH | 14:21 |
| bialix | vila: bb in 15 minutes | 14:21 |
| vila | bialix: forget it for a minute, just think that the default path is: ''user' 'core' 'site' and read the comment in get_standard_plugins_path() | 14:22 |
| bialix | ok, will do, after short lunch | 14:22 |
| vila | bialix: bon appetit ! | 14:23 |
| fullermd | Hm, lunch. That's sounding like a goodish idea... | 14:24 |
| rubbs | Morning | 14:24 |
| bialix | fullermd: lunch for whimps? | 14:37 |
| * bialix reading plugin.py | 14:38 | |
| bialix | vila: ok | 14:49 |
| bialix | vila: get_core_plugin_path insist core on bzr.exe is PF\Bazaar\plugins | 14:50 |
| bialix | that's fine | 14:50 |
| vila | right | 14:50 |
| bialix | user is APPDATA\bazaar\2.0\plugins | 14:50 |
| bialix | no problem here | 14:51 |
| vila | right | 14:51 |
| bialix | site is still puzzling for me | 14:51 |
| vila | let's leave aside for a minute | 14:51 |
| bialix | ok | 14:52 |
| bialix | so where we now? again | 14:52 |
| vila | do you agree that bzr.exe can look at APPDATA\bazaar\2.0\lib for additional libraries ? | 14:52 |
| bialix | it can but I think it's bad idea | 14:52 |
| vila | why ? | 14:52 |
| bialix | because it can be roaming | 14:52 |
| vila | hmm, but in that case the plugins can be wrong too right ? | 14:53 |
| vila | So it's the user responsability to be coherent between the plugins he install and the bzr.exe he install on his various hosts, right ? | 14:53 |
| bialix | well | 14:54 |
| bialix | honestly to say | 14:54 |
| bialix | I'm hate APPDATA\bazaar\2.0 location | 14:54 |
| vila | ok, for the sake of the discussion, let's call it USER\plugins then :) | 14:55 |
| vila | Don't you feel better ? | 14:55 |
| vila | do you agree that bzr.exe can look into USER\lib for additional libraries ? | 14:56 |
| bialix | on my machine this is C:\Documents and Settings\myname\Application Data\bazaar\2.0\ | 14:57 |
| bialix | it's so boring to cd to this directory even via decent file mamanger | 14:57 |
| bialix | so I'm keep all my plugins in C:\work\Bazaar\plugins and has specified BZR_PLUGIN_PATH | 14:57 |
| bialix | how's your proposal will lokk given in mind my habit of BZR_PLUGIN_PATH? | 14:58 |
| bialix | vila: ^ | 14:58 |
| bialix | what | 14:58 |
| bialix | what's USER\lib | 14:59 |
| bialix | ? | 14:59 |
| vila | <bialix> I'm hate APPDATA\bazaar\2.0 location | 14:59 |
| vila | <vila> ok, for the sake of the discussion, let's call it USER\plugins then :) | 14:59 |
| vila | USER == APPDATA\bazaar\2.0 | 14:59 |
| bialix | why every user should have separate copy of third-party libs? | 14:59 |
| bialix | why not PF\Bazaar\extra ? | 14:59 |
| bialix | why not PF\Bazaar\extra-libs ? | 15:00 |
| vila | because bzr.exe don't have a concept for 'site' which is where additional plugins and libraries can be installed in order to be shared between several users and several versions of bzr.exe | 15:00 |
| vila | That's the whole point of the damn concept ! | 15:00 |
| bialix | another problem with APPDATA -- this folder is usually hidden | 15:00 |
| bialix | so you can't get there on vanilla windows machine | 15:01 |
| vila | Can we focus on solutions to already identified problems before raising new ones ? | 15:01 |
| bialix | until you enable option to show hidden files in Explorer, or put the full path to address line | 15:01 |
| bialix | let's try to invent site for bzr.exe then | 15:01 |
| bialix | PF\Bazaar\site | 15:02 |
| bialix | ok? | 15:02 |
| vila | <vila> or PF\Bazaar\site\{lib,plugins} | 15:02 |
| bialix | that's fine, though PF\Bazaar\site\plugins is useless | 15:03 |
| vila | right, that was my last proposal this morning and that's what plugin.get_site_plugin_path() can return | 15:03 |
| bialix | there is PF\Bazaar\plugins tight here | 15:03 |
| bialix | s/tight/right/ | 15:03 |
| bialix | if you wish -- why not? but it seems useless | 15:04 |
| vila | :-( | 15:04 |
| bialix | we started from the question: where we would like to put extra 3rd party libs | 15:04 |
| vila | PF\Bazaar\plugins exists and is not empty ? | 15:05 |
| vila | what's in there ? | 15:05 |
| bialix | all plugins provided by installer | 15:05 |
| bialix | lp, netrc, bzrtools, qbzr, svn, upload, xmloutput | 15:06 |
| bialix | and explorer | 15:06 |
| vila | right, so that's core | 15:06 |
| bialix | yes | 15:06 |
| vila | and you said you want to keep that read-only, ok, so we can't put anything there, ok ? | 15:06 |
| bialix | vila: no I said this about PF\Bazaar\lib | 15:07 |
| bialix | precisely about PF\B\lib\library.zip | 15:07 |
| bialix | PF\B\plugins is user editable | 15:07 |
| vila | Can't you see that's precisely why we can't add more libraries ? | 15:08 |
| bialix | there is another std location on windows for all users if you wish site | 15:08 |
| bialix | C:\Documents and Settings\All users\... | 15:08 |
| bialix | there is also Application Data, etc | 15:09 |
| bialix | [17:08]<vila>Can't you see that's precisely why we can't add more libraries ? <--- I don't understand this question | 15:09 |
| vila | We want to be able to add plugins that aren't known by bzr.exe and these plugins requires some libraries | 15:10 |
| vila | they should go into XXX\plugins and the libraries into XXX\lib | 15:10 |
| vila | Since you don't want to add libraries into PF\B\lib, we can't add plugins into PF\B\plugins | 15:11 |
| bialix | your term "plugins that aren't known" makes me uncomfortable | 15:11 |
| bialix | does that implied bzr.exe knows about some plugins? it's not true | 15:11 |
| vila | <bialix> all plugins provided by installer | 15:12 |
| vila | <bialix> lp, netrc, bzrtools, qbzr, svn, upload, xmloutput | 15:12 |
| bialix | this is known by installer | 15:12 |
| vila | are you making a disctinction between bzr.exe and the installer ?? | 15:12 |
| bialix | yes | 15:12 |
| vila | I didn't | 15:12 |
| bialix | it's up to you | 15:12 |
| vila | s/bzr.exe/installre | 15:12 |
| bialix | ok | 15:13 |
| bialix | if you wish to install plugins to "plugins" and libraries to "lib" (or "libs"?) that's makes sense | 15:13 |
| bialix | where I should install libraries if I'm using BZR_PLUGIN_PATH | 15:14 |
| bialix | ? | 15:14 |
| vila | I want names to be coherent between 'core', 'site' and 'user' so lib and plugins for each of them, do you agree ? | 15:14 |
| bialix | vila: I don't understand why you want tie them together | 15:14 |
| vila | For consistency, because I dislike: | 15:15 |
| vila | <bialix> precisely about PF\B\lib\library.zip | 15:15 |
| vila | <bialix> PF\B\plugins is user editable | 15:15 |
| vila | I want to be able to install a plugin and its libs that will override the one provided by the installer | 15:16 |
| bialix | you're late for 3 years | 15:16 |
| vila | ok, too bad, bye | 15:16 |
| bialix | we may talk about where to put extra libs | 15:16 |
| bialix | regardless of plugins | 15:16 |
| bialix | this is 2 loosely related things | 15:17 |
| bialix | install things in PF\B\lib may be wrong idea because there is already too much things | 15:17 |
| bialix | you need clean location to ensure user won't delete some important file | 15:18 |
| bialix | I guess so | 15:18 |
| bialix | ok, too bad, bye -- sorry for this | 15:18 |
| bialix | vila: I'm really sorry | 15:23 |
| === weigon__ is now known as weigon | ||
| kfogel | jelmer: no sign of bzr 2.0.2 at http://packages.debian.org/lenny-backports/bzr yet... Any ideas? | 15:31 |
| jelmer | kfogel: Not sure why it's not listed there, but the archive appears to have it: | 15:32 |
| jelmer | http://www.backports.org/debian/pool/main/b/bzr/ | 15:32 |
| kfogel | jelmer: thank you. | 15:34 |
| kfogel | jelmer: you might know off the top of your head: savannah.gnu.org is currently running 1.16.1, and has been having some severe loggerhead crashing problems lately. Is loggerhead with 2.0.2 stable? That will be an additional motivation to upgrade, if so. | 15:35 |
| jelmer | kfogel: I wouldn't know, sorry | 15:36 |
| kfogel | jelmer: np | 15:36 |
| kfogel | Does anyone here know if loggerhead is stable with Bazaar 2.0.2? Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2? | 15:42 |
| === beuno is now known as beuno-lunch | ||
| P4C0 | Hello, is it possible to revert the changes done in a branch? or should I just rm the branch and create it again? | 15:59 |
| Pilky | P4C0: bzr revert | 15:59 |
| rubbs | P4C0: bzr revert | 15:59 |
| rubbs | Pilky: beat me | 16:00 |
| Pilky | rubbs: w00t, what do I win? | 16:00 |
| P4C0 | Pilky, rubbs thanks, and if I don't want a branch anymore, can I just rm it? | 16:00 |
| Pilky | P4C0: yep | 16:01 |
| P4C0 | Pilky: thanks | 16:01 |
| rubbs | Pilky: brownie points. you get 5. If you get 1000, I'll send you some brownies ;) | 16:01 |
| Pilky | P4CO: not sure what happens to any revisions just in that branch that are stored in the repo, you'd have to ask one of the bzr devs | 16:02 |
| P4C0 | ok, thanks | 16:02 |
| rubbs | Pilky: P4C0: The revisions stay there | 16:02 |
| rubbs | Pilky: P4C0: They just don't have any children | 16:03 |
| rubbs | at least thats what it looks like when I did it. | 16:03 |
| rubbs | I could be wrong | 16:03 |
| Pilky | rubbs: yeah that's what I thought, I was just wondering if bzr did anything to clean them up | 16:03 |
| rubbs | Pilky: I'm not 100% sure, I'm gonna do a quick test and check. | 16:11 |
| Pilky | rubbs: if any command was to do it I'd have a guess at pack | 16:12 |
| rubbs | Pilky: that would be my guess as well | 16:12 |
| fullermd | It doesn't. | 16:13 |
| fullermd | gc is discussed from time to time. It hadn't topped anybody's todo yet. | 16:14 |
| rubbs | Ah, that's what I thought, I just couldn't remember for sure | 16:17 |
| === deryck is now known as deryck[lunch] | ||
| hazmat | so i'm trying to push a branch upstream back to launchpad, but i get an odd error bzr: ERROR: RemoteRepository is not compatible with CHKInventoryRepository different rich-root support.. any ideas on how to resolve? | 16:22 |
| fullermd | hazmat: That means your local repo is in the 2a format, while the LP is in an earlier format without RR support. | 16:30 |
| fullermd | Basically, the options boil down to 'upgrade the LP branch' or 'redo local changes in a poor-root branch'. RR revs can't be moved into a non-RR repo. | 16:30 |
| hazmat | fullermd, thanks for the info.. upgrading the lp branch isn't an option for me.. re redoing the local changes.. to get my local branch, i branched a co of a launchpad repo in a shared repo dir, what would i have to do differently to get the same repo format as launchpad.. also is there a way i can downgrade my existing repo to something compatible? | 16:34 |
| fullermd | Well, to answer the last first, no; the poor-root -> rich-root transition is a trap door. We've supported both back to 1.0 (and even further, sorta), and it was just time (or well past time) to pull the default switch. | 16:35 |
| fullermd | When you branch into an existing repo, it will use that existing format. So that's how you ended up in the situation; you had an existing 2a repo, so the 'branch' process upgraded the data as it came in. | 16:36 |
| fullermd | So to get the same, you'd either (a) branch to a standalone location with no existing repo (which would preserve the source format), or (b) lookup the format manually first and make sure your repo can talk back to it. | 16:36 |
| === tommieb is now known as t0mm13b | ||
| P4C0 | is there a command to remove all the local files that are not under the repo control? | 17:01 |
| Pilky | P4C0: bzr clean-tree I think | 17:03 |
| Pilky | or something along those lines | 17:03 |
| jelmer | bzr clean-tree- --unknown | 17:04 |
| P4C0 | thanks | 17:04 |
| jelmer | --ignored for ignored files | 17:04 |
| bialix | hello jam | 17:07 |
| P4C0 | hmm I just compile the code on my local branch but bzr clean-tree says there's nothing to clean | 17:09 |
| Pilky | P4C0: are the compiled files ignored? | 17:09 |
| P4C0 | --ingored did it ;) | 17:09 |
| P4C0 | Pilky: seems so... bzr status doesn't say anything | 17:10 |
| Pilky | yeah, by default it doesn't list the ignored files | 17:11 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| kfogel | Does anyone here know if loggerhead is stable with Bazaar 2.0.2? Latest release is "loggerhead-1.17" from August 2009... Does one have to run trunk code to work with bzrlib 2.0.2? | 17:31 |
| kfogel | rockstar: ^^ | 17:34 |
| rockstar | kfogel, I'm pretty sure it is. I think our loggerhead instance might be running on 2.0.1 or 2.0.2 now. | 17:34 |
| rockstar | kfogel, I can't imagine that part of the API has changed much. | 17:35 |
| kfogel | rockstar: thanks. The question is, are we running the last release of loggerhead, or trunk code? | 17:35 |
| rockstar | kfogel, we're running a variant of trunk, but, like I said, I can't imagine there were that many changes. | 17:35 |
| beuno | kfogel, latest release of LH, AFAIK | 17:35 |
| beuno | and the latest LH works fine with the latest bzr | 17:36 |
| kfogel | beuno, rockstar: thanks | 17:37 |
| beuno | kfogel, I'd be happy to help out getting LH working in the emacs world | 17:40 |
| beuno | (or adapt some things if needed, within reason) | 17:41 |
| kfogel | beuno: they don't make it easy for knowledgeable volunteers to assist, but I keep offering our help; maybe they'll take us up on it. | 17:43 |
| quicksilver | it seems that sometimes cd into a very old branch and bzr pull --overwrite is slow | 18:19 |
| quicksilver | slower than rm -rf branch; pull fresh branch | 18:19 |
| quicksilver | that seems counterintuitive? | 18:19 |
| mwhudson | quicksilver: is there a format conversion going on? | 18:25 |
| quicksilver | yes, I think so. | 18:25 |
| quicksilver | actually pulling a fresh branch is slower than I remembered. | 18:26 |
| quicksilver | 7 minutes so far and counting. | 18:26 |
| === oubiwann_ is now known as oubiwann | ||
| === EdwinGrubbs is now known as Edwin-lunch | ||
| lifeless | james_w: hi | 20:21 |
| james_w | morning lifeless | 20:22 |
| lifeless | james_w: can you explain where the concern about 'good bug reports' comes from, I think it may be impeding communication/'getting things done'. | 20:22 |
| lifeless | james_w: also, how are you :) | 20:22 |
| james_w | good thanks, how are you? | 20:22 |
| lifeless | Good - back down to 91kg yesterday morning | 20:22 |
| lifeless | the 90kg barrier is my nemesis | 20:23 |
| james_w | you mean the udd thread "Bugs for daily build packages" | 20:23 |
| james_w | ? | 20:23 |
| lifeless | Not precisely ;). its turned up a few times; you mentioned in a bug I filed on -builder, I think, and then again in the thread about what stuff bzr folk are doing | 20:24 |
| lifeless | I'd like to understand more about it, about what you mean, and so forth | 20:24 |
| james_w | oh | 20:26 |
| james_w | got it now | 20:26 |
| james_w | so, my worry is that some things are too imprecise currently | 20:29 |
| james_w | "<thing> could be better" type reports | 20:29 |
| james_w | I could report that, and then use the bug report to discuss ways to tackle it | 20:29 |
| james_w | but that probably isn't the best forum | 20:29 |
| james_w | there's also a question of when the bug can be considered fixed | 20:30 |
| james_w | with something like that, what does "better" mean | 20:30 |
| james_w | I'm trying to find a bug I'm sure I remember where you were discussing whether having a bug "bzr <operation> is too slow" open was worthwhile, as my recollection is that you touched on similar issues there | 20:37 |
| lifeless | yes | 20:37 |
| lifeless | and those are good, valid concerns | 20:37 |
| lifeless | OTOH bug reports are essentially just conversations; I agree that the list is ~ the best the forum to be discussing 'what should be done' | 20:38 |
| lifeless | and I don't want you to tear through the specs and turn everything into bugs - I don't think thats efficient either. | 20:38 |
| jam | morning lifeless | 20:39 |
| jam | hi james_w | 20:39 |
| lifeless | but I'd like to encourage you to file a bug for anything that is adding friction, or causing issues | 20:39 |
| jam | what are you still doing up? | 20:39 |
| lifeless | hi jam | 20:39 |
| james_w | hi jam | 20:39 |
| lifeless | even if its a big amorphous, its still data to the bzr devs | 20:40 |
| jam | james_w: so one of the good things about filing separate bugs is that it allows you to split the discussion by thread, and have a way to make progress on part of it without all of it | 20:40 |
| james_w | lifeless: I will file bugs in future where appropriate | 20:40 |
| lifeless | in the performance case we knew it all :P | 20:40 |
| jam | it also gives a checklist of "these are things to work on" | 20:40 |
| jam | which can be done in mailing list threads, but it is a lot harder to get a summary and overview | 20:41 |
| rubbs | so in this case what is the difference between a bug report and a blueprint? (sorry to just jump in here) | 20:42 |
| james_w | rubbs: you could probably use either. Historically bzr hasn't used blueprints | 20:44 |
| rubbs | james_w: ok, cool. I was just curious | 20:45 |
| jam | rubbs: blueprints are very underdeveloped as a launchpad feature | 20:46 |
| jam | they are meant to capture the concept of "feature development" separate from a "bugfix" | 20:46 |
| yojimbo-san | I have a beginners question -- I've used lots of centralised VCS (e.g. svn) but not a DVCS; As a sysadmin, I have /etc under VCS on multiple servers, but I'd like to have one central place where I can (check out/see) all the machines configs with a single tool, such as Trac. I'm probably using the wrong terminology, but can I "join" multiple repositories together into one other one? (it can be read-only if that's easier) ... so from my Trac machine, I see one | 20:48 |
| rubbs | jam: that makes sense thank you | 20:48 |
| rubbs | yojimbo-san: I think I understand your question but let me make sure: You wish to be able to keep multiple different configurations together in one central location so you can view them all. Is that correct? | 20:52 |
| yojimbo-san | yes; just for viewing purposes. Each machine should be otherwise stand-alone (local repository) and independant | 20:53 |
| yojimbo-san | But I'd like to see the version history for each file from the central place | 20:53 |
| rubbs | I'm not an expert here, but maybe this would help. Instead of trying to pull from many to one, you could push from one to many. Here's what I mean: | 20:54 |
| NfNitLoop | it's basically a centralized configuration, with a different repo for each machine. | 20:55 |
| NfNitLoop | all with copies hosted on the 'trac' server. | 20:55 |
| NfNitLoop | they can have a standalone branch/local-copy for faster/disconnected operation. | 20:55 |
| rubbs | you could make a central location (shared repository) that has a main file. Then branch off a new branch for each configuration and then push them to the servers. | 20:55 |
| yojimbo-san | So, if the central location sees a file as "/machine1/etc/hosts", how would machine1 see this as "/etc/hosts"? (Or should I cheat by symlinking /etc? :-) ) | 20:57 |
| yojimbo-san | Or is that not a relevant question with bzr? | 20:57 |
| NfNitLoop | with bzr... | 20:58 |
| NfNitLoop | you can put your branches anywhere. | 20:58 |
| NfNitLoop | so on each host, I woulddo: | 20:58 |
| NfNitLoop | cd /etc; bzr init .; bzr add files you want to track; bzr commit -m "Initial Checkin" | 20:58 |
| NfNitLoop | then you can either do a 'bzr push' up to your server... | 20:59 |
| NfNitLoop | or from your server do a "bzr pull" | 20:59 |
| rubbs | so for example, say you have server1 and server2. | 20:59 |
| NfNitLoop | actually, the advantage of doing a bzr pull from the server is that it'll update your working copy. | 20:59 |
| NfNitLoop | so I'd recommend that. | 20:59 |
| rubbs | you can make a change on server1 and then push it to server2 | 21:00 |
| rubbs | A better example might be that you have a central repository on server1 at /var/configfiles | 21:01 |
| rubbs | then you can have branches on server2 and server3 at /etc | 21:01 |
| rubbs | Then if you want to update server2 from server1's repo, you can do this from server2: cd /etc; bzr pull sftp://server1/var/configfiles; | 21:02 |
| yojimbo-san | Ok, that gives me something to try ... | 21:02 |
| rubbs | DVCS took me a while. The best way to learn is to just fool around with it until you get it. | 21:03 |
| yojimbo-san | :-) | 21:03 |
| rubbs | that and keep asking questions | 21:03 |
| rubbs | ;) | 21:03 |
| yojimbo-san | Are things like file owners/permissions tracked well? | 21:03 |
| bob2 | no | 21:04 |
| rubbs | no | 21:04 |
| yojimbo-san | so that makes pulling files dangerous ... | 21:04 |
| bob2 | use etckeeper | 21:04 |
| * rubbs slaps head | 21:04 | |
| rubbs | I should have remembered that | 21:04 |
| rubbs | etckeeper was designed for pretty much exactly what you are asking about | 21:05 |
| yojimbo-san | bob2: does etckeeper track permissions? I thought it was just a handy wrapper around having VCS in the first place ... | 21:05 |
| bob2 | yes, no | 21:05 |
| yojimbo-san | Mmm, I must go do some more reading then :-) | 21:05 |
| yojimbo-san | So if I use etckeeper to create local bzr repositories, I then want some way of hooking them all back to my central Trac ... | 21:06 |
| rubbs | there, I can not help, but I'm guessing it's possible | 21:07 |
| yojimbo-san | probably, especially if I create the branch for each machine's etckeeper repository on the central place, push it out (empty) to the target machine, then initialise etckeeper to use it ... then push it back centrally ... | 21:08 |
| yojimbo-san | Sounds like a bit of a juggling act, but I'll go figure something out. Thanks for your time, rubbs, bob2 NfNitLoop. | 21:09 |
| rubbs | np | 21:09 |
| NfNitLoop | yojimbo-san: It's only about 1 command more than working with centralized svn. | 21:11 |
| NfNitLoop | if you're going to store them all on a central server anyway, you could get away with using svn. | 21:12 |
| NfNitLoop | bzr just buys you the nice features of DSCM (and bzr itself) | 21:12 |
| yojimbo-san | NfNitLoop: Well, as a non-coder, finding a decent opportunity to learn about bzr in a way that's different from simple svn isn't always easy :-) So having a target problem motivates me to actually learn stuff ... | 21:24 |
| lifeless | james_w: actually, we used blueprints for a bit; they didn't fit all that well | 21:35 |
| * igc breakfast | 21:51 | |
| poolie | james_w: I agree with you that "X could be better" or "something should be done" bugs are poor | 22:10 |
| poolie | also that blueprints don't help much in our system | 22:10 |
| poolie | perhaps they match UDS well | 22:11 |
| lifeless | poolie: I prefer 'x could be better' to silence though, which is my point | 22:12 |
| lifeless | one can iterate to improve the resolution | 22:12 |
| mtaylor | lifeless: I just got another complaint from someone about error messages when branch formats don't match | 23:19 |
| lifeless | mtaylor: yes | 23:32 |
| mtaylor | lifeless: just thought I'd continue to be annoying about it :) | 23:33 |
| lifeless | mtaylor: if they upgrade... :P | 23:34 |
| mtaylor | lifeless: if they upgrade the error messages get better? :) | 23:35 |
| mtaylor | lifeless: that's exciting! | 23:35 |
| mvo | bazaar.launchpad.net give me connection refused errors, is that just me or is this a general problem? | 23:39 |
| mvo | (on port 22) | 23:39 |
| spiv | mvo: I think Launchpad is down for a code update atm? | 23:39 |
| spiv | That's what /topic in #launchpad claims, at leastd. | 23:40 |
| lifeless | mtaylor: if they upgrade, they have 2a and don't have trouble :P | 23:41 |
| mtaylor | lifeless: :P | 23:42 |
| mtaylor | lifeless: do you want me to actually file another bug about it though? or can I assume everyone is well aware... | 23:42 |
| lifeless | mtaylor: its in the 'wishlist' pile at the moment; its something we'd take a patch to make better | 23:42 |
| lifeless | (and there are bugs) | 23:42 |
| lifeless | but its not something we're devoting time to | 23:42 |
| mtaylor | lifeless: k. as long as it's in a pile somewhere. just didn't want to assume it was and be wrong | 23:43 |
| lifeless | the pile grows... :P | 23:43 |
| lifeless | mysql could file a ticket on it, if its plaguing you guys | 23:43 |
| mtaylor | lifeless: oh, I don't know if it's plaguing mysql | 23:45 |
| mvo | spiv: aha, ok, thanks! its time for bed for me anyway :) | 23:52 |
| * mvo waves | 23:52 | |
| blueyed | I'm getting content conflicts, and I don't know how to resolve them: http://pastebin.com/m726a3dee | 23:55 |
| blueyed | (answers.lp.net is down) | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!