| poolie | well | 00:00 |
|---|---|---|
| poolie | i'm not sure 'common' is the right measure, compared to | 00:00 |
| spiv | Maybe there's something involving graph logic that already would help bzrlib? | 00:00 |
| spiv | I mean, | 00:01 |
| poolie | if there are cases where we need it, how much trouble or friction or | 00:01 |
| spiv | maybe there's already an operation bzrlib does, or would like to do, that could benefit from this? | 00:01 |
| lifeless | sory about interruption | 00:02 |
| lifeless | hardy is not _that_ stable | 00:02 |
| lifeless | I'm saying that the structure I understand you to be heading towards is hand coded | 00:03 |
| lifeless | but needs on the wire the exact same degree of encapsulation | 00:03 |
| lifeless | so why not just define the encapsulation, then let the client and server use them as desired | 00:04 |
| spiv | Basically, the tradeoff is at the moment the encapsulation encoder/decoder has a pretty simple interface with the objects that use it, and there's a single place that knows things like "this message part is a body". If we generalise, we push that work to the individual message handlers. | 00:09 |
| spiv | I guess that's manageable, but I'm also not sure it's work that we'll get much benefit from. | 00:09 |
| lifeless | well | 00:10 |
| lifeless | you could make sure the wire protocol is generalised | 00:11 |
| lifeless | and then only add api complexity as needed | 00:11 |
| spiv | Hmm. | 00:11 |
| lifeless | long as the error-handling cases the protocol object knows how to eat the entire entity we're good to extend it later. | 00:11 |
| lifeless | (extend in the python code I mean) | 00:11 |
| lifeless | so START, TUPLE|BODY+, END | 00:12 |
| spiv | Right, similar to the container format... | 00:12 |
| lifeless | where TUPLE and body are both self delimited | 00:12 |
| lifeless | and BODY is able to be ended_complete and ended_incomplete | 00:12 |
| lifeless | lol https://pqm.bazaar-vcs.org/ refuses to show in ff3 | 00:13 |
| spiv | And if a body is ended_incomplete, then it can be followed by another TUPLE? | 00:14 |
| spiv | (as a convention) | 00:14 |
| lifeless | right | 00:14 |
| lifeless | but even if not we'll know it was incomplete | 00:14 |
| lifeless | and can error regardless | 00:15 |
| spiv | Well... | 00:15 |
| spiv | that's the sort of thing that bugs me :) | 00:15 |
| spiv | More options == more cases == more tests & work :P | 00:15 |
| lifeless | ok | 00:16 |
| lifeless | up to you | 00:16 |
| lifeless | I've exhausted my ideas on this, but it seems pretty clear to me that there are different layers here | 00:17 |
| spiv | It's not so much that that one part is a big concern, but it's the sort of thing that we're enabling with this plan. | 00:17 |
| jelmer | lifeless: wtf | 00:17 |
| jelmer | lifeless: maybe it was just bad timing | 00:17 |
| jelmer | but going to pqm.bazaar-vcs.org just crashed my kernel :-) | 00:18 |
| lifeless | jelmer: LOL | 00:18 |
| poolie | !! | 00:18 |
| spiv | Wow. | 00:18 |
| lifeless | jelmer: get a new kernel | 00:18 |
| poolie | Before You Die, You See... | 00:18 |
| jelmer | maybe it'll work better if I run a kernel out of bzr instead of out of git... | 00:18 |
| poolie | lifeless, i think it's a good point about the protocol | 00:19 |
| poolie | spiv, lifeless, i think we should allow for it in the protocol doc | 00:53 |
| poolie | the actual encoding iirc would already support this | 00:53 |
| spiv | brb, fixing a KnitCorrupt in Mary's PhD branch... | 00:57 |
| mwhudson | ouch | 00:58 |
| === jamesh__ is now known as jamesh | ||
| spiv | Newlines in filenames leads to broken inventory.knit... | 01:16 |
| radix | it seems the dapper packages of bzr on ppa don't work? they're complaining about not having python2.5 when I try to install them | 01:16 |
| poolie | radix, yes, it's bug 189915, i'm working on it | 01:20 |
| radix | poolie: cool, thanks | 01:21 |
| radix | fwiw, the reason it's not working for me is bzr: Depends: python (> 2.5) but 2.4.2-0ubuntu3 is to be installed or | 01:23 |
| radix | python-celementtree but it is not installable | 01:23 |
| radix | which doesn't seem to be exactly what bug #189915 is talking about | 01:24 |
| ubotu | Launchpad bug 189915 in bzr "bzr 1.1 dapper PPA debs FTBFS" [Critical,In progress] https://launchpad.net/bugs/189915 | 01:24 |
| poolie | lifeless, what is the best address for the bzr packaging team? | 01:46 |
| poolie | ^branch | 01:46 |
| poolie | http://bzr.debian.org/pkg-bazaar/bzr/ubuntu/ ? | 01:46 |
| lifeless | http://bzr.debian.org/pkg-bazaar/bzr/unstable/ | 01:48 |
| poolie | ok | 02:11 |
| poolie | the changelog for the pakcage i took from bazaar-vcs.org is somewhat diverged from that | 02:11 |
| poolie | starting with your "New bazaar-vcs.org build" on 3 dec | 02:11 |
| lifeless | poolie: yes, merged numerous times; but theres nothing in the bazaar-vcs.org devel-distro-release packags that wasn't sent back to bazaar-vcs.org | 02:22 |
| lifeless | possibly some dependency differences | 02:22 |
| lifeless | and the dapper package has the patch from the bzr list | 02:23 |
| lifeless | abentley: ping | 02:30 |
| lifeless | abentley: I'm looking for the branch nick on bb, I can't see it | 02:30 |
| LaserJock | anybody around who has experience using the cvs plugin for bzr? | 03:28 |
| abentley | lifeless: I think it's not there. | 03:30 |
| lifeless | LaserJock: do you mean cvsps-import ? | 03:30 |
| abentley | I assume you want the branch nick from the last-committed revision? | 03:30 |
| LaserJock | yes I guess that's the one | 03:30 |
| abentley | We do have the source branch location, if the user provides it. | 03:31 |
| LaserJock | lifeless: I'm assuming I can use cvsps-import to track a CVS repo | 03:32 |
| lifeless | abentley: yes, I'd like it to be visible | 03:33 |
| lifeless | LaserJock: I don't know if it can do incremental or not; it certainly doesn't have the logic to handle all the idiocies people can do to cvs like cscvs does | 03:34 |
| LaserJock | well, I've been using git-cvsimport and it seems to be working well | 03:35 |
| LaserJock | I'm just trying to figure out the bzr equivalent | 03:35 |
| lifeless | LaserJock: well cvsps-import is the plugin to examine | 03:38 |
| lifeless | I've used it for one-shot conversions very successfully | 03:39 |
| LaserJock | k | 03:39 |
| LaserJock | I have about 14 different VCS repos in CVS, SVN, bzr and I thought I might give it a go at trying to just use bzr for everything | 03:45 |
| LaserJock | Riddell keeps saying it's the only way to go :-) | 03:45 |
| lifeless | LaserJock: riddel is right :) | 03:50 |
| lifeless | bzr-svn will get your svn stuff beautifully | 03:51 |
| lifeless | for CVS, just one-shot convert and never look back | 03:51 |
| LaserJock | well, I don't own the CVS repos so I'll have to keep updating periodically | 03:51 |
| lifeless | ok | 03:51 |
| lifeless | have a look at it; or use the launchpad cvs service | 03:51 |
| LaserJock | hmm | 03:52 |
| LaserJock | actually one of them is already in launchpad | 03:52 |
| === asac_ is now known as asac | ||
| abentley | I wonder how hard it is to 0wn a CVS repo | 04:11 |
| lifeless | its ok security wise, if you like crunchy shell | 04:12 |
| thumper | what's a better merge type to use for criss-cross merges (in bzr 1.1) ? | 04:29 |
| spiv | http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01212.html | 04:30 |
| spiv | thumper: --lca | 04:30 |
| thumper | spiv: so `bzr remerge --lca`? | 04:30 |
| spiv | thumper: yeah. | 04:31 |
| thumper | 7 conflicts -> 2 conflicts \o/ | 04:32 |
| thumper | both of which were entirely valid | 04:33 |
| thumper | when is --lca becoming the default? | 04:33 |
| spiv | abentley: ^ | 04:33 |
| poolie | lifeless, how can i avoid dpkg-source complaining about the binaries in the debian/.bzr directory? | 04:36 |
| lifeless | -x .bzr | 04:36 |
| poolie | ok, i have to give that every time? | 04:36 |
| lifeless | or use bzr builddeb to do most of the machiner for you | 04:36 |
| lifeless | bzr builddeb --working --builder="pdebuild-$distro --override-config" | 04:37 |
| lifeless | thats how I built the packages | 04:37 |
| poolie | so to do that i should have the source in one branch, and the debian/ directory in another branch checked out below it? | 04:38 |
| * poolie reads the maunal | 04:40 | |
| poolie | lifeless, so it looks like people are using it in "merge mode", since the packaging is alone in a branch? | 04:42 |
| abentley | thumper: I would give it another release cycle. See I got this new job, and it's been a lot to learn all at once... | 04:45 |
| abentley | Unfortunately, there's some work needed before it's a complete replacement for merge3. It doesn't do reverse-cherrypicks, and there's an edge case where it doesn't give a conflict when it should. | 04:46 |
| lifeless | later all | 04:57 |
| poolie | have a good weekend | 04:57 |
| abentley | lifeless: later | 04:58 |
| lifeless | poolie: you have mail; if you want a call ring now :) | 04:59 |
| poolie | thanks | 05:00 |
| poolie | no i don't think so | 05:00 |
| poolie | am just learning more about builddeb | 05:00 |
| === jamesh_ is now known as jamesh | ||
| appcine | hi! getting "bzr: warning: unknown encoding . Continuing with ascii encoding." every time I call bzr. | 07:58 |
| appcine | echo $LANG reports C | 07:59 |
| appcine | LC_ALL is not set | 07:59 |
| appcine | tried exporting LANG as sv_SE.UTF-8 too, still the same message | 07:59 |
| appcine | Mac OS X 10.5.2 | 07:59 |
| Debolaz | Eww, UTF-8 | 08:05 |
| Debolaz | Latin1++ | 08:05 |
| ubotu | New bug: #188058 in bzr-gentoo-overlay "Launchpad transport error installing bzr-vimdiff-0_pre17 (dup-of: 181945)" [Medium,Incomplete] https://launchpad.net/bugs/188058 | 08:21 |
| appcine_ | So, I've pushed my source to my server -- bzr update doesn't work, what do I run to initialize? | 08:34 |
| kedmccabe | What's the best/recommended way to install bzr on OS X; easy_install or macports? | 08:44 |
| === vila_ is now known as vila | ||
| appcine | kedmccabe: Probably what you're most used to working with | 08:51 |
| appcine | I used ports .. because, well I use it for lots of things and it's easy to keep stuff updated. | 08:51 |
| rotty | how's the support for cherry-picking these times? bzr still does not track them, right? | 10:55 |
| dato | nope | 10:59 |
| rotty | :-/ | 11:01 |
| lifeless | rotty: will be discussing this in the up coming sprint | 11:20 |
| rotty | so it could be implemented in the foreseeable future? | 11:23 |
| appcine_ | How do you ignore all files in a certain directory? Like bzr ignore dir/*, but that adds all specific files to the .bzrignore file .. should I manually edit the file? | 11:38 |
| appcine_ | :) | 11:38 |
| luks | I think bzr ignore 'dir/*' should work | 11:39 |
| luks | or "dir/*" on windows | 11:39 |
| luks | (to disable the * in the shell) | 11:39 |
| appcine_ | sweet | 11:40 |
| appcine_ | worked, thanks :) | 11:40 |
| appcine | can you remove all ".svn" directories from your project somehow? | 11:48 |
| appcine | I added them, and the ingored them .. now I want to remove them :P | 11:48 |
| Peng | appcine: If you're on *nix or something, that would be easy. 'find -name .svn -execdir bzr rm {} +' or something. | 12:16 |
| === asak_ is now known as asak | ||
| rotty | lifeless: I have an ideas for a new feature: tracking the currently-checked-out revision, so when you do "bzr get -r FOO", a subsequent "bzr status" will compare against the revision FOO and not HEAD | 12:28 |
| rotty | does that make sense? | 12:28 |
| dato | jelmer: ping? | 12:30 |
| jelmer | dato: pong | 12:30 |
| dato | jelmer: I have a situation, and I'd like to know whether rebase could help. well. situation. I commited some stuff over a revision that I didn't thought it was there... | 12:31 |
| dato | how much would I need to write to make rebase re-commit the good ones on top of $BAD-1 | 12:31 |
| dato | I don't mind a dirty+ad-hoc solution | 12:31 |
| jelmer | well, there's also the "replay" command that's part of rebase | 12:32 |
| dato | oh | 12:32 |
| dato | ooh | 12:32 |
| jelmer | if you check out $BAD-1 then you can just run "bzr replay -r<revision-to-replay>" | 12:32 |
| dato | right | 12:33 |
| dato | thank you | 12:33 |
| jelmer | for $BAD+1 | 12:33 |
| dato | I get a conflict, whereas I think I shouldn't get one | 12:38 |
| dato | $BAD touches foo1.py | 12:38 |
| dato | and $BAD+1 is a merge that does not touch foo1.py | 12:39 |
| dato | ? | 12:39 |
| dato | jelmer: ^ | 12:40 |
| fullermd | rotty: Err? get == branch; it does do that... | 12:46 |
| rotty | fullermd: but "revert -r" doesn't, does it? | 12:47 |
| hallu | hello, i'm running into a repository compatibility problem with bzr hosted on launchpad. | 12:48 |
| fullermd | Well, what you'd want for that use case isn't revert, it's "update -r". | 12:48 |
| hallu | i used svn-import to create a new branch on my machine. | 12:48 |
| fullermd | Which comes with a minor hitch. | 12:48 |
| hallu | then i push it onto launchpad | 12:48 |
| hallu | but bzr co complains that KnitPackRepository is not compatible with RemoteRepository... | 12:49 |
| rotty | fullermd: according to "bzr update --help", update doesn't have that option "-r" | 12:49 |
| fullermd | rotty: That's the minor hitch 8-} | 12:49 |
| hallu | i should say: I push it *first* and that works, then I try *bzr co* and that fails. | 12:50 |
| dato | oh well, I used WorkingTree.commit for $BAD+1. replay did $BAD+2,3 fine | 12:51 |
| rotty | fullermd: is this implemented in bzr HEAD? | 12:52 |
| * fullermd shakes his head. | 12:52 | |
| fullermd | rotty: https://bugs.launchpad.net/bzr/+bug/45719 | 12:56 |
| ubotu | Launchpad bug 45719 in bzr "update command cannot take a revision number" [Medium,Fix committed] | 12:56 |
| === kiko is now known as kiko-afk | ||
| appcine | Peng: Ah, yes. I'm on unix. Something like the find-command might work, but {} doesn't print the path to the file .. know how to do that? :) | 13:18 |
| Peng | appcine: It doesn't? What? Depending on your shell, you might need to escape it. | 13:20 |
| appcine | find . -name .DS_Store -execdir echo {} + | 13:20 |
| appcine | prints: .DS_Store .DS_Store .DS_Store | 13:20 |
| appcine | bash on os x | 13:20 |
| appcine | ah | 13:21 |
| Peng | appcine: Yeah, exactly. execdir 'cd'es to the directory and then executes it. | 13:21 |
| Peng | appcine: It's supposed to be safer. Shrug. | 13:21 |
| appcine | Peng: Hmm, hehe.. let me try again .. bzr reported that .DS_Store didn't exist | 13:21 |
| appcine | with --exec it worked | 13:22 |
| appcine | Peng: Nevermind me. I'm just sloppy. It works just fine. | 13:23 |
| appcine | Thanks for the tip | 13:23 |
| === mrevell_ is now known as mrevell-lunch | ||
| rotty | fullermd: where can I get a recent version of this patch? | 13:32 |
| rotty | (the repos mentioned in the report don't apply to current HEAD anymore) | 13:33 |
| fullermd | I don't think there is one. | 13:34 |
| rotty | :-( | 13:35 |
| === mrevell-lunch is now known as mrevell | ||
| * fullermd ponders. | 14:01 | |
| fullermd | I guess poolie's long since gone for the night... | 14:02 |
| * lamont wonders when bzr 1.2.0 will hit the ppa | 14:09 | |
| LarstiQ | lamont: it did yesterday | 14:10 |
| LarstiQ | or well, the buildds and then failed | 14:10 |
| lamont | it's not there.... | 14:10 |
| LarstiQ | so eh yeah, can't use it yet :) | 14:10 |
| * lamont notes the lack of a debian directory in the tarball, too | 14:12 | |
| LarstiQ | lamont: which one, upstream? | 14:14 |
| lamont | launchpad.net/bzrtools/... | 14:14 |
| LarstiQ | I'm not clear on what you mean, but fwiw there are something like 4 different debian dirs needed | 14:15 |
| LarstiQ | since dapper/etch/sid are all different enough that there is no universal packaging (yet?) | 14:15 |
| lamont | most people tend to package something that's the latest... | 14:16 |
| LarstiQ | as the Bazaar project, debs for all those distributions need to be made | 14:17 |
| LarstiQ | anyway, I haven't been involved in that area for a while now | 14:18 |
| === kiko-afk is now known as kiko | ||
| lamont | heh. it took longer to test the backport to dapper/edgy than it did to do it. | 14:42 |
| === weigon__ is now known as weigon | ||
| === kiko is now known as kiko-fud | ||
| * fullermd wonders whether 1.2 is officially released. | 15:14 | |
| fullermd | I see the file, but I haven't seen any announcements. | 15:15 |
| ubotu | New bug: #145811 in nautilus-python "python-nautilus: Feisty: Python script's methods seem to be not called by extension." [Undecided,Fix released] https://launchpad.net/bugs/145811 | 15:16 |
| * rotty is annoyed that the "update -r" patch has been abandoned | 15:18 | |
| fullermd | Here's your number; there's the line :p | 15:19 |
| rotty | unfortunatly, I'm not able to forward-port the patch, as I don't have knowledge of bzr internals | 15:19 |
| Peng | I have an entirely off-topic quandary: I created a GPG key for myself 5 days ago. I had a copy of my private key on a server I don't own the whole time. Should I be paranoid and revoke it or not? I'm not using it for much so it would be no big deal if I did revoke it. | 15:20 |
| fullermd | I s'pose it depends on how much you trust whoever has root on it. | 15:22 |
| Peng | Also, if I ever got a VPS, I might need to put the private key on it, which would be just as bad... | 15:24 |
| * fullermd shrugs. | 15:25 | |
| fullermd | Any hardware that anybody else ever has physical access to is insecure and untrustworthy if you're paranoid enough. | 15:25 |
| Peng | I'm trying to find the right level of paranoia. | 15:26 |
| johnny | and the changelog needs to be updated for 1.2 too.. | 15:30 |
| === asak_ is now known as asak | ||
| === kiko-fud is now known as kiko | ||
| radix | is there any recent .deb of bazaar that works on dapper? | 17:50 |
| Peng | radix: https://launchpad.net/~bzr/+archive ? | 17:55 |
| Peng | Huh, Hardy and Dapper are the only ones that have had their 1.2rc1 debs built. | 17:55 |
| * Peng wanders off. | 17:55 | |
| radix | Peng: the dapper debs from ppa are broken | 17:57 |
| radix | they depend on python2.5 | 17:57 |
| Peng | Oh. | 18:00 |
| Peng | Nice. | 18:00 |
| Peng | I dunno nothin' then. | 18:00 |
| * Peng wanders off. | 18:00 | |
| Peng | Sorry I couldn't help. | 18:00 |
| jdong | Are the bazaar-vcs.org branches going to be packs? | 18:32 |
| jdong | I notice that they're still dirstate/knits currently | 18:32 |
| beuno | jdong, bzr.dev has been in packs for a while now | 18:34 |
| beuno | beuno@beuno-laptop:~/bzr_devel/bzr.dev$ bzr info http://bazaar-vcs.org/bzr/bzr.dev/ | 18:34 |
| beuno | Standalone branch (format: pack-0.92) | 18:34 |
| jdong | beuno: what? no way | 18:35 |
| * jdong questions his sanity | 18:35 | |
| * beuno questions it too :p | 18:36 | |
| jdong | beuno: oh I see my idiocy | 18:36 |
| jdong | beuno: I looked at bzr.1.2 | 18:36 |
| jdong | not bzr.dev | 18:36 |
| beuno | jdong, I think 0.92 and on have been in packs on bzr.dev. Especially since at that poing packs<>knits operations where painfully slow | 18:36 |
| jdong | WOW the performance difference with packs over HTTP is very noticeable | 18:37 |
| beuno | jdong, yeap, lifeless and jam did an amazing job at it :D | 18:38 |
| beuno | and I understand the smart server has improved greatly too | 18:38 |
| jdong | yeah I'm impressed at dumb http alone | 18:38 |
| jdong | I haven't branched something big from HTTP since packs came about | 18:38 |
| beuno | I think the "less amounts of round-trips" was the key | 18:39 |
| jdong | right, that's always been the case | 18:39 |
| beuno | gazillion knits vs a dozen packs | 18:39 |
| * beuno wonders why the 1.2 branch is in knits... | 18:40 | |
| beuno | and no poolie around... :/ | 18:40 |
| jdong | beuno: yeah the 1.2 branch took nearly 5 minutes to get, while I just grabbed dev in under a minute | 18:41 |
| jdong | and looking @ how it's 85MB, most of that time would've been simply network transfer | 18:41 |
| beuno | jdong, I'll send an email to the list and see if it just got forgotten or if there is a good reason for it | 18:42 |
| jdong | beuno: cool | 18:42 |
| beuno | thanks for the heads up! | 18:42 |
| jdong | anytime | 18:42 |
| * jdong reconciles bzr.dev for fun | 18:51 | |
| beuno | jdong, if it's in packs, it should be fairly fast. Knits, on the other hand, might take a while. I have 3gb branch that took 40+ hours to reconcile on a AMD 4000+ dual core | 18:52 |
| jdong | beuno: yeah right now the packs are taking over 10 min to reconcile, looks CPU bound | 18:53 |
| jdong | oh well, i twas for fun anway | 18:53 |
| beuno | jdong, you can also run "bzr check" if you feel like making the CPU sweat a while :p | 18:54 |
| mw | someone should change the topic to mention 1.2 | 20:00 |
| johnny | and add a changelog entry | 20:02 |
| johnny | on the site | 20:02 |
| mario_limonciell | is there no way to pass bzr through an authenticating proxy? | 20:06 |
| mario_limonciell | it would seem according to bug 83954 that the support should be there | 20:09 |
| ubotu | Launchpad bug 83954 in bzr "Error while using "bzr branch" through proxy" [Undecided,Fix released] https://launchpad.net/bugs/83954 | 20:09 |
| ubotu | New bug: #156299 in bzr "bzr bash completion error (compgen: --: invalid option)" [Wishlist,Confirmed] https://launchpad.net/bugs/156299 | 20:20 |
| === zmanuel is now known as z-man | ||
| mtaylor | GARRRRR | 21:09 |
| * mtaylor hates that Branch.open_containing() returns a tuple and not a branch. | 21:10 | |
| mtaylor | just FWIW | 21:10 |
| === kiko is now known as kiko-afk | ||
| treeform_ | hey my network is just awful but i need to copy a big bzr repo (300mb) to a server it always disconnect while doing it | 21:59 |
| treeform_ | is there a way to zip up the repo and rsync it there? | 22:00 |
| beuno | treeform_, "pull" has resume integrated | 22:02 |
| beuno | you can of course just rsync the folder | 22:02 |
| beuno | and/or zip it | 22:02 |
| beuno | you don't need anything special | 22:02 |
| treeform_ | beuno, does push has resume integrated? | 22:03 |
| beuno | treeform_, I'm not 100% sure, but I don't see a reason why not | 22:04 |
| treeform_ | it always errors out with a python stack trace so i think it bzr just crashes | 22:04 |
| beuno | treeform_, what version of bzr are you using? | 22:04 |
| beuno | if it's spitting out a traceback it should be a bug | 22:05 |
| treeform_ | 1.1 | 22:05 |
| treeform_ | sorry i would post the trace back but i dont have it | 22:05 |
| beuno | treeform_, would you happen to have a traceback handy that you can paste somewhere? | 22:05 |
| beuno | ah, right | 22:05 |
| treeform_ | i will run it again just wait about 10 min | 22:05 |
| beuno | well, just plain rsyning the dir will work just fine | 22:05 |
| treeform_ | but the dir is about 600mb | 22:06 |
| treeform_ | with the .bzr 300mb and the contents is 300mb | 22:06 |
| beuno | treeform_, can you run "bzr info" and see what repository type it is? | 22:06 |
| beuno | treeform_, I suppose you can rsync the .bzr directory and then just do "bzr revert" (which is sort of what bzr branch would do) | 22:06 |
| beuno | zip up .bzr, rsync that, unzip, "bzr revert" | 22:07 |
| beuno | (I'm sure there are better solutions though) | 22:07 |
| treeform_ | as long as that works | 22:07 |
| treeform_ | "Standalone tree (format: pack-0.92)" | 22:08 |
| treeform_ | oh my format is lower version | 22:08 |
| beuno | treeform_, that's the latest version | 22:09 |
| treeform_ | i been using bzr since .14 and never had reasons to upgrade but it looks like i did at .92 | 22:09 |
| treeform_ | oh ok | 22:09 |
| treeform_ | i think i needed to upgrade it because some one could not read it | 22:10 |
| fullermd | That seems unlikely... | 22:10 |
| beuno | treeform_, if they have a pre 0.92 version than they might not be able to read packs | 22:10 |
| treeform_ | ok but i am up todate? | 22:10 |
| beuno | treeform_, if you have bzr 1.1 and are using the packs repository, yes | 22:11 |
| treeform_ | ok thanks | 22:11 |
| beuno | np | 22:11 |
| fullermd | 1.1? Jeez, that's SO yesterday... | 22:12 |
| treeform_ | fullermd, i should upgrade? | 22:13 |
| beuno | fullermd, :p | 22:13 |
| beuno | treeform_, 1.2 is out _today_ | 22:13 |
| beuno | so 1.1 is _yesterday_ | 22:14 |
| beuno | upgrading is always recommended, but you're good at 1.1 | 22:14 |
| treeform_ | oh i just installed 1.2 on the server | 22:14 |
| treeform_ | that is how it crashes http://dpaste.com/35397/ | 22:14 |
| beuno | treeform_, it says you're using bzr 1.0 | 22:15 |
| beuno | and, a release candidate | 22:15 |
| treeform_ | ok 1.2 it is | 22:15 |
| beuno | I'd recommend upgrading to at least 1.0 final | 22:16 |
| beuno | treeform_, your traceback says: bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (linux2) | 22:16 |
| treeform_ | yes it does | 22:17 |
| treeform_ | i am sure i am wrong | 22:17 |
| treeform_ | grr installing it also fails http://dpaste.com/35399/ | 22:19 |
| treeform_ | i got my current bzr is the latest in my repos | 22:22 |
| rthalley | Assume we have a centralized shared repository for product foo. directory "foo" has been bzr init-repo'd. we then make branch "foo/head", and do work. Now, getting reading for a release, we bzr branch foo/head foo/release-1.0. Question: is there any way to see what branches are available within foo? (within bzr, that is...) | 22:24 |
| mtaylor | rthalley: not that I know of | 22:28 |
| mtaylor | rthalley: but a simple ls of foo will give you some idea | 22:28 |
| vin | how does the bzr_access script work? I've added set up the .ssh/authorized_key file. Do I just invoke the script with the appropriate parameters? | 22:29 |
| abentley | rthalley: bzrtools provides a "branches" command that lists the branches under a given location | 22:29 |
| rthalley | thanks, that's handy. now a "best practices" question... let's say we now finish foo-1.0 and ship it. do I tag foo/release-1.0 to indicate the version that was released? Do we worry about people still being able to commit to foo-release-1.0? | 22:37 |
| jdong | is it clean to clean .bzr/repository/upload by hand or is there a tool for it? | 22:52 |
| jdong | s/clean/safe/ | 22:52 |
| mneptok | jdong: sounds like my dating career | 22:53 |
| jdong | mneptok: that probably explains the global shortage of nitrile gloves :) | 22:54 |
| jdong | some little developing conscience in my head is telling me I shouldn't go into .bzr with /bin/rm and whack out things I don't think belong :D | 22:55 |
| foom | whatcouldpossiblygowrong | 23:01 |
| jdong | lol well ASS-U-ME-ing that nothing is uploading to the location, I would expect the 35MB of packs in upload to be simply in-transit cut-connection junk | 23:02 |
| abentley | jdong: you can't break your repository by removing the contents of upload. | 23:03 |
| * jdong saves this chat log ;-) | 23:03 | |
| abentley | If someone was in the middle of uploading, you might cause their upload to fail with a nasty error. | 23:03 |
| jdong | awesome | 23:04 |
| jdong | this one branch I have, I regularly commit to it via a crappy connection... it's nearly double its pristine size because of cruft in upload | 23:04 |
| jdong | I'm wondering if bzr should have a command for dealing with cruft like that? | 23:05 |
| abentley | Well, perhaps robert can fix that, but it's not an open-and-shut case like obsolete-packs. | 23:05 |
| jdong | granted, else it would've been naturally fixed already | 23:06 |
| jdong | btw if you haven't heard yet, packs rock :) | 23:06 |
| jdong | I am astounded by the performance difference over plain HTTP | 23:06 |
| jdong | now if there's only a way for LP to upgrade all branches to packs rather than me having to sftp them. | 23:07 |
| abentley | Yeah, I did see your talk in the scrollback. | 23:07 |
| jdong | yeah, you guys really came through for me. That was just about the last complaint I had about bzr :) | 23:08 |
| abentley | jdong: You would not believe how snowed-under the launchpad-bazaar team is. | 23:08 |
| abentley | I don't think we'll have time for nice-to-haves in the near future. | 23:08 |
| jdong | I can imagine :( | 23:08 |
| jdong | oh well scrape-and-loop time :) | 23:08 |
| jdong | if there's one skill I've learned in my time around Ubuntu, it's how to abuse Launchpad :) | 23:09 |
| abentley | But create a blueprint, and then we'll at least have it in the system. | 23:09 |
| jdong | yeah, I'll do so in a sec | 23:09 |
| fullermd | Seems like "smart server upgrade verb" would fill that niche pretty well. | 23:10 |
| jdong | well the thing is... | 23:10 |
| jdong | I don't think $average_lp_user knows or cares what the heck a pack is. | 23:10 |
| jdong | and I don't think people are aware in general of this massive speedup. LP should be more active in telling owners of branches to upgrade to packs | 23:11 |
| === kiko-afk is now known as kiko | ||
| abentley | Where would you suggest we tell people about packs? | 23:22 |
| mtaylor | when was rich-root-packs added? | 23:27 |
| lifeless | jdong: yes it should and I think there is a bug open for htat | 23:28 |
| lifeless | mtaylor: 1.0 IIRC | 23:28 |
| lifeless | mtaylor: bzr help formats or so should say | 23:29 |
| lifeless | also bzr should start nagging soon | 23:29 |
| mtaylor | lifeless: thanks | 23:29 |
| beuno | anyone up to helping me brainstorm what tests I should include with the automatic plugin thingie? I've got working code and would like to strap on the tests and send to the list for initial review | 23:49 |
| abentley | beuno: You should test all the commands you add, and the major functions you add. | 23:53 |
| abentley | I'm not sure whether you're doing network stuff. That can be annoying, but you should be able to run your own server if necessary. | 23:53 |
| beuno | abentley, the problem is that I'm not actually adding any commands at this point, just catching unknown commands and checking to see if another plugin provides it | 23:53 |
| abentley | Okay, so you should be testing the command-line functionality you've added. | 23:54 |
| === Verterok_ is now known as Verterok | ||
| beuno | abentley, right, I got that far. The question is a bit more specific. I should make the test execute a command that I know will be caught as a plugin and test if the output is correct? Maybe also commands that I know will be unknown and make sure they are still unknown? | 23:58 |
| abentley | Yes. | 23:58 |
| abentley | You don't necessarily have to do exhaustive tests of the commandline. | 23:59 |
| abentley | But that's pretty key functionality. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!