| spiv | Peng: you can use branches to do the same thing as looms, but it's a lot more convenient with looms. | 00:03 |
|---|---|---|
| Peng | Okay. | 00:03 |
| spiv | igc: https://bugs.edge.launchpad.net/bzr/+bug/230550 | 00:05 |
| ubottu | Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,Confirmed] | 00:05 |
| igc | bbiab | 01:04 |
| * igc lunch | 03:11 | |
| lifeless | hey guyes | 04:17 |
| lifeless | spiv: ah good, you found the bug report :) | 04:18 |
| igc | hi lifeless | 04:22 |
| spiv | lifeless: yep :) | 04:33 |
| lifeless | spiv: -> food, but happy to discuss later if you need to chat about it | 05:34 |
| * igc pick up kids - bbian | 05:40 | |
| lifeless | spiv: back; so how is that bug going ? | 06:13 |
| spiv | lifeless: _SmartClient._base is getting out of sync with _SmartClient._medium's URL | 06:15 |
| spiv | lifeless: so it appears that the client/medium sharing logic in RemoteBzrDir isn't quite right. | 06:15 |
| lifeless | spiv: excelennt; that was my suspicion :) | 06:15 |
| vila | lifeless: http://paste.ubuntu.com/13090/ | 08:01 |
| vila | Note that the http benchmark spend 212 seconds waiting for a 502 Bad gateway. So subtract that. | 08:01 |
| vila | After the substraction I can't see huge differences so I'm wondering about wether there is such a discrepancy between sftp and http. | 08:02 |
| uniscript | how do I bzr ignore .svn directories? | 08:03 |
| vila | In other words, either the kenisson (sp?) experiment was flawed or I need better info on how to reproduce it. | 08:03 |
| bob2_ | "bzr ignore .svn" doesn't cut it? | 08:03 |
| uniscript | I get errors with the bzr-svn plugin | 08:04 |
| uniscript | with bzr add . | 08:04 |
| uniscript | tries to do a PROPFIND | 08:04 |
| uniscript | bzr add --dry-run -v . | 08:05 |
| uniscript | bzr: ERROR: libsvn._core.SubversionException: ("PROPFIND request failed on '/svn/repos/keith/DocCharConvert/trunk/DocCharConvert'", 175002) | 08:05 |
| spiv | vila: you mean Kinnison? | 08:05 |
| vila | spiv: yeah! Thanks. Thanks for your review and invalidating my bug report too ;-) | 08:06 |
| vila | Kinnison: apologies for the typo, I need another coffee :) | 08:06 |
| spiv | vila: You're welcome :) | 08:08 |
| spiv | vila: that's the easy part compared to actually fixing a bug :) | 08:08 |
| spiv | vila: I had a quick look at it when it was reported and couldn't see what was needed, but you made the solution look pretty easy. | 08:09 |
| vila | spiv: yeah, I had a wtf moment when realizing that _post wasn't calling _raise_curl_http_error and then another when I realized that _post wasn't using accepted_errors, that made the bug quite subtle | 08:11 |
| vila | but overall, I'm gulty of not working more on the hpss ;-) | 08:11 |
| spiv | If _post isn't reusing stuff that it should, then it would be great to fix that :) | 08:13 |
| poolie | i'm going to do a couple of reviews of ian's work then call it a day | 08:14 |
| vila | spiv: now that I can write tests, I may as well refactor _post, I think we shouldn't annex _post just for the smart server when we already have send_http_smart_request... | 08:16 |
| spiv | vila: that sounds good. | 08:16 |
| vila | ... even if that means having two send_http_smart_request implementations ;-) | 08:16 |
| spiv | vila: although I'd be tempted to land a short-term fix first, before embarking on a bigger change | 08:17 |
| spiv | Depends on how quickly you can do the proper fix :) | 08:17 |
| gour | is anyone using fish shell? (there is no tab-completion for bzr :-( | 08:19 |
| lifeless | vila: is your http cached perhaps ? | 08:21 |
| lifeless | vila: kinnison is usually quite good ;P | 08:21 |
| vila | lifeless: no cache here, never, pipe is big enough (which explains why I'm so bad at undersanding squid issues and high latencies problems ;) | 08:22 |
| gour | hmm, it looks that bash-completion is also not up to date :-/ | 08:23 |
| vila | lifeless: I don't doubt Kinnison, it's just that I can't reproduce ;-) | 08:24 |
| vila | Kinnison: when you come back, let's discuss a bit, I'd be interested in some stats via the transportstats plugin | 08:25 |
| visik7 | I'm new to vcs, I would using it to fork my project to have 2 version: one for experimental purpose the other for production | 08:25 |
| visik7 | but before this I've some questions: | 08:27 |
| visik7 | 1st: I've a so called "projects" folder | 08:27 |
| visik7 | is more logical to put the dir under a unique bzr branch or to create a bzr branch for each project ? | 08:28 |
| Peng | The latter. | 08:28 |
| visik7 | 2nd: how can I fork my project ? should I use the switch command ? | 08:30 |
| poolie | visik7: use 'bzr branch production experimental' | 08:32 |
| poolie | well | 08:32 |
| poolie | first put your code in a directory called eg 'production' | 08:32 |
| poolie | then that will create another copy of it called experimental | 08:32 |
| visik7 | and when I need to merge some or all the code from experimantal to production ? | 08:33 |
| jamesh | visik7: the workflow I usually use is to develop features on their own branches | 08:35 |
| jamesh | this makes it easy to merge them on their own | 08:35 |
| visik7 | jamesh: so no split the code into 2 dirs ? becouse I would to continue to develop on devel and production as well | 08:38 |
| visik7 | maybe I've not understand your workflow | 08:38 |
| visik7 | :( | 08:39 |
| bob2_ | merging only part of one branch into another is a bit problematic (in bzr at the moment) | 08:43 |
| === emgent is now known as emgent`UDS | ||
| Kinnison | vila: hi, bug me when you're around and we can discuss | 08:57 |
| igc | night all | 09:00 |
| vila | Kinnison: installing stuff on a windows machine in parallel, let's discuss | 09:00 |
| Kinnison | okies | 09:01 |
| Kinnison | So what are you after me for? | 09:01 |
| vila | lifeless told me you were observing different behaviors between sftp and http regarding bandwidth usage. I can reproduce it. Can you tell me more about your experiment ? | 09:02 |
| vila | grr, s/can reproduce/can't reproduce/ | 09:02 |
| spiv | vila: I make that typo lots too. | 09:03 |
| vila | broadcast: read my mind while I'm using windows | 09:04 |
| Kinnison | vila: sure, let me prep, I've reinstalled my PC since then. | 09:08 |
| vila | ok | 09:09 |
| Kinnison | Okay, so here's the deal, when I did the test, I was branching bzr.dev over my 'net connection which is a 10Mbit cable service from my Colo box which has plenty of bandwidth and reasonable enough CPU etc. | 09:09 |
| Kinnison | Now, this is plain http (I.E. not smart) and it seemed to take around twice (wallclock) that of sftp | 09:11 |
| Kinnison | I have an http_proxy set, which is on my local network to my seriously overpowered core server which runs a reasonably well configured squid | 09:12 |
| Kinnison | Now when it's fetching the packs, the HTTP fill the 1.2MB/s | 09:12 |
| === emgent`UDS is now known as emgent | ||
| Kinnison | But once it's on to the smaller files, it slows down dramatically | 09:13 |
| Kinnison | As though it's not pipelining or something | 09:14 |
| spiv | Kinnison: (btw, I've seen the opposite effect: a bug in the way some versions of squid handle "Range: 0-..." request causing fetching of data from packs to be extremely slow) | 09:14 |
| Kinnison | This is an initial branch | 09:14 |
| Kinnison | so presumably it fetches the whole pack, no? | 09:15 |
| spiv | Depends on the pack. | 09:15 |
| Kinnison | oh | 09:15 |
| spiv | e.g. if it's shared repo | 09:15 |
| Kinnison | standalone branch | 09:15 |
| spiv | There will almost certainly be revisions in there you don't need, so bzr won't fetch the whole pack. | 09:15 |
| * Kinnison runs the branch again to re-time | 09:16 | |
| visik7 | bob2_: are other vcs less problematic with this kind of usage ? | 09:16 |
| Kinnison | since last one got moosed by presence of updatedb | 09:16 |
| vila | Kinnison: Wait ! Can you do that with the transportstats plugin installed and prefix your urls with 'stats+' ? | 09:17 |
| Kinnison | where do I get that plugin? | 09:17 |
| vila | as I did in http://paste.ubuntu.com/13090/ | 09:17 |
| vila | bzr branch lp:~vila/bzr/transportstats | 09:18 |
| bob2_ | visik7: I'm not sure. jamesh was suggesting that you develop each feature in different branch, then you can choose which whole branch to merge into production or experimental | 09:20 |
| visik7 | bob2_: I think that will drive me crazy 'couse I would use this as a one man developer tool | 09:21 |
| visik7 | :) | 09:21 |
| Kinnison | vila: running the http branch now | 09:21 |
| vila | Kinnison: You said "seemed to take around twice (wallclock)", so we may not be dealing with bandwidth problems here... | 09:23 |
| vila | Regarding the transportstats plugin, it creates a '.transport_stats_for_bzr' file cumulating the operations measured, so let's try to be clean about how we use it, i.e. run your operations in different directories as much as possible | 09:25 |
| vila | .. or alternatively and surely easier for you rename the file between each operation when necessary | 09:29 |
| Kinnison | okay, how do I get the stats for this op? | 09:29 |
| visik7 | ops | 09:30 |
| poolie | night | 09:34 |
| vila | Kinnison: bzr ts-display | 09:38 |
| sabdfl | visik7: it's actually nice to work on features separately | 09:39 |
| sabdfl | you can merge them if two features become interdependent | 09:39 |
| visik7 | sabdfl: someone point me to hg queues | 09:42 |
| === bob2_ is now known as bob2 | ||
| Kinnison | vila: http://rafb.net/p/D4vKEA23.html | 09:42 |
| Kinnison | vila: woah, that's huge latency | 09:43 |
| * Kinnison tries the same op again, without the http proxy | 09:43 | |
| Kinnison | For reference, that took 4:29.06 wallclock to branch bzr.dev | 09:43 |
| sabdfl | visik7: i think you'll find independent branches better, it's easier to keep track of the thread of development of each feature | 09:43 |
| sabdfl | but, try everything | 09:43 |
| vila | Kinnison: Beware! It's not your usual latency, that's the "real" latency as measured between when we send a request and when we receive the response, not to be confused with ping | 09:44 |
| visik7 | sabdfl: and on #git they told me that "you can cherry-pick every commit you want from one branch to another" | 09:44 |
| Kinnison | vila: indeed, hence it seems huge | 09:44 |
| Kinnison | considering my average ping time is 15ms | 09:44 |
| vila | ouch, yes, that's huge | 09:44 |
| * Kinnison tries without squid now | 09:45 | |
| visik7 | sabdfl: I wouldn't to start with a vcs to realize that don't do what I look for | 09:45 |
| vila | you can try 'bzr ts-display -v' but be prepared to receive a huge output | 09:45 |
| sabdfl | visik7: i'm sure every tool has a way to achieve your goal | 09:47 |
| vila | Kinnison: do you know if you use the pycurl or the urllib based implementation ? | 09:47 |
| sabdfl | my recommendation would be to setup a share repo, with branches in directories under that | 09:47 |
| Kinnison | I haven't a clue, this is a fresh hardy install, with bzr.dev | 09:47 |
| sabdfl | have a trunk branch, then branches for each of the features you are working on | 09:47 |
| sabdfl | you can merge the features into trunk when they are ready | 09:47 |
| sabdfl | works really well for me | 09:47 |
| vila | try 'import pycurl', if it's there it's used | 09:47 |
| Kinnison | vila: right, without squid in the way, it takes 2:24 wallclock with an average latency of 420ms | 09:47 |
| visik7 | sabdfl: thanks for the advice | 09:48 |
| sabdfl | sure | 09:48 |
| Kinnison | vila: not present | 09:49 |
| vila | hmmm, squid playing tricks again :-/ Yet 420 seems still huge, let me check from here (you branched from lp:bzr ?) | 09:49 |
| Kinnison | No, from my server | 09:49 |
| vila | Kinnison: good, so you're using the urllib based one | 09:49 |
| Kinnison | since I can monitor that and be sure it's not overloaded when I do the trials | 09:49 |
| Kinnison | :-) | 09:49 |
| vila | Kinnison: apache ? | 09:49 |
| Kinnison | Zeus | 09:50 |
| Kinnison | (very high performance web server) | 09:50 |
| vila | Kinnison: I don't know that one :-/ | 09:50 |
| Kinnison | SFTP is 1:53.21 wallclock with 107ms average latency | 09:51 |
| vila | let start again then, let's forget stats, there is chances that Zeus does not handle range requests as we want, try 'bzr branch -Dhttp' and mail me the relevant .log | 09:51 |
| Kinnison | where does the .log end up? | 09:52 |
| vila | sftp/ 1.53, http/2.24, that's more reasonable | 09:52 |
| vila | bzr version will tell you, but on linux it's ~/.bzr.log | 09:52 |
| Kinnison | I'll clear that down first then | 09:52 |
| vila | you can delete it before | 09:52 |
| vila | z:) | 09:52 |
| vila | Kinnison: perfect | 09:52 |
| Kinnison | branching -Dhttp now | 09:53 |
| vila | great | 09:53 |
| uniscript | I dimly remember there is a way to disable plugins for a bzr command? | 09:56 |
| vila | uniscript: bzr --no-plugins | 09:57 |
| uniscript | ta | 09:57 |
| Kinnison | vila: http://www.digital-scurf.org/files/http-proxied-debug.log | 10:00 |
| Kinnison | vila: http://www.digital-scurf.org/files/http-direct-debug.log | 10:00 |
| Kinnison | vila: of use? | 10:02 |
| vila | Kinnison: just downloaded, let me look :) | 10:02 |
| Kinnison | for reference, that http-direct took 1:54.8 and the http proxied took 4:06.67 | 10:02 |
| vila | the proxied one seems to choke on some very big range requests, triggering a retry that is accepted | 10:08 |
| vila | the timings appears in the log, I need more time for a more precise analysis, I'll kept you informed | 10:09 |
| Kinnison | Okay, be sure to prefix with my name, I'll go off to do other things and i'll come back if this window goes red :-) | 10:09 |
| vila | Kinnison: ok, it may not be today though, tonight at best (i.e. in ~10 hours) | 10:10 |
| === pmatulis_ is now known as pmatulis | ||
| Kinnison | Heh, okay, I'll try and spot in scrollback | 10:10 |
| vila | Kinnison: But one important thing already: Zeus seems to happily handle our range requests, so comparing sftp with zeus-not-proxied should be relevant in terms of relative performances *today* | 10:12 |
| visik7 | sabdfl: I realized that maybe multibranch is a little bit complicated for the task that I want to acheeve: I have a project, I want to "fork" it and develop 2 different version, but only one feature is in the new branch, I would keep the 2 branch synced is it possible ? | 10:14 |
| visik7 | sabdfl: sorry if I bother you | 10:14 |
| jml | hi | 10:20 |
| jml | statik: sorry about the plugin name thing. | 10:20 |
| mwhudson | jml: hello! | 10:27 |
| mwhudson | jml: how is europe? | 10:27 |
| jml | mwhudson: europe is wonderful and european. | 10:31 |
| jml | mwhudson: I wish I could spend more time here | 10:31 |
| mwhudson | jml: are you going to get out of the city at all? | 10:32 |
| jml | mwhudson: unlikely. | 10:33 |
| jml | mwhudson: it'll take a fair bit of effort to make sure I see the city, in fact. | 10:33 |
| mwhudson | jml: :/ | 10:34 |
| mwhudson | at least prague is worth seeing | 10:34 |
| jml | mwhudson: *nod* | 10:34 |
| mwhudson | (i hear, not been there myself) | 10:34 |
| jml | mwhudson: it is. | 10:34 |
| jml | mwhudson: also, I think that the pubs here rival and perhaps best English pubs | 10:34 |
| mwhudson | heh | 10:34 |
| jml | mwhudson: oh btw, I read _Rob Roy_ on the flight over. | 10:35 |
| jml | I want to go to Scotland now. | 10:35 |
| mwhudson | i've seen his grave, i think | 10:35 |
| mwhudson | rob roy is wallace? | 10:35 |
| mwhudson | er, scott | 10:36 |
| jml | yes. | 10:36 |
| lifeless | poolie: hi; I may have come across badly in my latest email | 10:36 |
| lifeless | poolie: please forgive :) | 10:37 |
| mwhudson | jml: scotland is well worth seeing | 10:38 |
| ToyKeeper | visik7: You might want http://bazaar-vcs.org/Rebase | 10:38 |
| mwhudson | the valley containing the church where rob roy's grave is is beautiful | 10:38 |
| mwhudson | jml: http://www.lochsidecottages.co.uk/Image8.jpg for example | 10:39 |
| jml | mwhudson: yeah. indeed. | 10:42 |
| lifeless | visik7: all you need to do is merge from one brancht o the other on a regular bssis | 10:42 |
| lifeless | visik7: this sort of synchronisation is the reason bzr exists :) - its core functionality | 10:42 |
| ToyKeeper | visik7: bzr rebase and git-rebase and hg patch queues are all very similar... but it's better not to use them if you don't really need to. | 10:46 |
| ToyKeeper | visik7: Er, the rebase features basically help you work around certain problems... but why work around a problem when you can avoid it entirely? | 10:58 |
| visik7 | ToyKeeper: how ? | 10:58 |
| ToyKeeper | If you have write access to the main branch, there is probably no need to maintain a stack of patches separate from the trunk. | 10:59 |
| ToyKeeper | But if upstream is read-only, and you have extensive local changes which upstream won't accept, 'rebase' features can help you keep your local patches up to date. | 11:01 |
| visik7 | follow my reasoning: I've a project up and running, I would develop new features on a parallel brench keep syncing with the "trunk" and I need to develop new features also on trunk | 11:02 |
| visik7 | so rebasing or merging seems the right solution isn't it? | 11:03 |
| ToyKeeper | In that case, regular merging should be fine. That's what bzr is best at. | 11:03 |
| visik7 | so I've not understood the difference between merge and rebase | 11:03 |
| ToyKeeper | Merging is the normal process in bzr. You can push/pull/branch/merge freely. | 11:04 |
| ToyKeeper | Rebase is for pretty specific types of use. | 11:05 |
| ToyKeeper | For example, you get foo-1.3.tar.gz, unpack it, and make changes... then foo-1.4.tar.gz is released. | 11:05 |
| ToyKeeper | 'foo' is not in bzr, but your patches are. | 11:05 |
| ToyKeeper | Rebase makes it easier to take your foo-1.3 patches and make them work on foo-1.4. | 11:06 |
| === AnMaster_ is now known as AnMaster | ||
| visik7 | I got it | 11:07 |
| spiv | visik7: rebase writes a new history for a branch | 11:10 |
| spiv | visik7: which is detrimental to regular merging | 11:10 |
| visik7 | thank you guys for all those infos, time to dive into bzr | 11:14 |
| visik7 | see you soon | 11:14 |
| brilliantnut | spiv: I see that you have a fix for bug 230550 ... does this means it goes into 1.6? | 11:34 |
| ubottu | Launchpad bug 230550 in bzr "bzr+http repeatedly queries the wrong location for BzrDir.find_repositoryV2" [Critical,In progress] https://launchpad.net/bugs/230550 | 11:34 |
| spiv | brilliantnut: yes | 11:34 |
| brilliantnut | hmm, and is there a chance that I can try it out before? | 11:36 |
| brilliantnut | I have a branch off bzr.dev, if it makes a difference... | 11:36 |
| spiv | brilliantnut: it's a work in progress, but I just registered the branch in LP and linked it to that bug | 11:40 |
| spiv | brilliantnut: http://people.ubuntu.com/~andrew/bzr/bug-230550 is the URL | 11:40 |
| === weigon_ is now known as weigon | ||
| Peng | What would cause .bzr/repository/lock/foo.tmp/info to be left behind from months ago, but not be causing problems when trying to push? | 13:01 |
| lifeless | Peng: that is a tmp file used when obtaining/releasing a lock, not an actual lock | 13:17 |
| statik | jml, no apologies needed for the plugin name, thanks for writing a useful plugin! | 13:19 |
| dennda | Hi. I have settings.py under version control but want to ignore it from now on, without removing it (it's values change from machine to machine.) How do I do that? | 14:08 |
| thekorn | dennda, bzr remove --keep <yourfile> | 14:12 |
| thekorn | bzr ignore <yourefile> | 14:12 |
| thekorn | that's at least what I would do in such a case | 14:13 |
| dennda | thekorn: thanks :) | 14:18 |
| === pmatulis_ is now known as pmatulis | ||
| === wildfire` is now known as wildfire | ||
| siretart | jelmer: hi. would you please commit your latest bzr_1.5-1 upload to debian to bzr.debian.org? TIA! | 16:21 |
| dato | siretart: are you going to upload bzr to backports? | 16:30 |
| siretart | dato: I have just merged bzrtools, and wanted to prepare an bzr upload, so yes | 16:36 |
| siretart | preparing in the sense of building and publishing it on gluck, and having it ready to be uploaded as soon as stuff transitions to testing | 16:37 |
| dato | ah; I've been asked a backport of 1.3.1, that's why I asked | 16:37 |
| demod | hi | 16:48 |
| === weigon_ is now known as weigon | ||
| lifeless | jam: ping | 17:46 |
| lifeless | jam: unping, have test passing remoind me sometime to discuss write_revision_to_string with you | 17:51 |
| vila | 1.5 has been released ? Or is it still in rc ? | 18:02 |
| vila | lp doesn't have 1.5 series defined (hence the question) | 18:02 |
| vila | lp doesn't have 1.6 series defined (hence the question) | 18:02 |
| vila | grr | 18:02 |
| beuno | vila, it's been released, yes | 18:02 |
| vila | 1.6 serie or 1.6 milestone, I'm unclear about the vocabulary, but I need the later for marking a bug as released | 18:03 |
| vila | beuno: thks | 18:04 |
| pickscrape | Would I be right in thinking that 1.6 is going to be quite an exciting release? | 18:05 |
| jam | vila: if we don't have 1.6 marked, I'll go do it | 18:05 |
| jam | we certainly should have a milestone for it | 18:06 |
| jam | and possibly a release series | 18:06 |
| vila | jam: thanks | 18:06 |
| jam | vila: we now have both a release series and a milestone for 1.6 | 18:07 |
| vila | jam: faster than light ;-) | 18:07 |
| jam | In the past, a lot of milestones were based on 'trunk' rather than a specific release series, but the last few have been on the series | 18:07 |
| jam | so I kept it that way | 18:07 |
| jam | vila: it isn't too hard when you've done it several times :) It is a bit tricky when you don't know where to look | 18:08 |
| jam | (like that milestones aren't against the project, they are against 1 release series, etc) | 18:08 |
| jam | man I hate that 'series' has no plural form, and that its singular form *looks* plural | 18:09 |
| jam | stupid English | 18:09 |
| pickscrape | sheep | 18:09 |
| jam | vila: is it any better in French? | 18:09 |
| vila | is that described in the how-do-I-make-a-new-release doc ? I'm under the impression that starting the new release is always a bit ... delayed | 18:09 |
| jam | pickscrape: sure, but at least sheep and moose don't look plural, goose geese is always bad | 18:10 |
| vila | jam: no, in french serie is singular, series is pluaral | 18:10 |
| vila | plural even | 18:10 |
| vila | but we have temps (time) which is both singular and plural | 18:10 |
| vila | and surely a few others, my gf is far better than me in french grammar, I specialized early in computer languages grammars and forget about the rest :) | 18:11 |
| jam | vila: time as in 'occurrence' or time as in "clock" ? | 18:11 |
| vila | time as in clock and weather and music | 18:12 |
| vila | :) | 18:12 |
| jam | vila: I always wondered about time as in weather, as spanish has the same thing (Tiempo) | 18:13 |
| jam | Hace tiempo hay (or something like that) is how is the weather | 18:13 |
| jam | Que tiempo hace ? | 18:14 |
| jam | man my spanish is bad | 18:14 |
| beuno | jam, que tiempo hace is pretty good :) | 18:14 |
| vila | my daughterS also suggest: nez (nose), souris (mouse), vers (rhyme) | 18:16 |
| vila | tapis (carpet) and generally all words ending with 's' :) | 18:16 |
| vila | gee, the things they learn at school today.... | 18:17 |
| vila | jam: funny, time passing express both the clockl and the weather for me... | 18:18 |
| jam | vila: sure, as an English person they seem very different, but I think most Latin languages mix them | 18:18 |
| jam | Just that "what time is it" is very different to me than "how is the weather" | 18:20 |
| jam | In arabic, they actually ask "Which hour is it" | 18:21 |
| jam | vila: to your earlier question, the "mark a new series" may be in the release documents, but they are also rather long | 18:21 |
| jam | There are quite a few steps, and it is pretty easy to miss some | 18:21 |
| jam | I think we have to register the release in about 4+ different places (freshmeat, pypi, Bazaar home page, bazaar-announce@, etc) | 18:22 |
| jam | Also, if it isn't there I just create one | 18:23 |
| jam | NEWS bothers me more | 18:23 |
| === NfNitLoo` is now known as NfNitLoop | ||
| jam | because you have to wait for it to merge to mainline, and then merge it back into your simple bugfix branch | 18:23 |
| jam | or run into merge conflicts because 2 people created the new NEWS section | 18:24 |
| vila | yeah, we have less conflicts in NEWS since we sort it inside each section, but still... | 18:25 |
| jam | vila: right, especially after a release when all the sections are empty | 18:27 |
| vila | "what time is it" and "how is the weather" *are* also different in french, yet, in a movie, I often saw clouds moving faster than normal used to represent some time passing, that's the image I was referring to | 18:27 |
| vila | jam: exactly :) Got bitten recently :) | 18:28 |
| jam | vila: that is very common in movies, but I only view it as time sped up, you can do it with people walking fast, clock hands spinning quickly, etc | 18:28 |
| jam | actually, I think one of the downsides is that we are slightly more likely to merge something into an "old" release | 18:29 |
| jam | when it used to conflict all the time, you would fix it and put it in the right location | 18:29 |
| jam | now older patches can quietly claim to fix old releases | 18:29 |
| vila | jam: Yeah, I'm always afraid of that when working in long lived branches :-/ | 18:30 |
| vila | and I'm quite surprised I never made a mistake there (or may be I did and nobody noticed :-( ) | 18:31 |
| jam | vila: I *try* to be careful when I merge. And certainly for a release we should do "bzr diff -r branch:../last-release" | 18:31 |
| jam | One thing I actually snuck in on this release were tags for '1.5rc1' and '1.5' final | 18:32 |
| jam | though they didn't seem to propogate to bzr.dev for some reason | 18:32 |
| jam | propagate | 18:32 |
| lifeless | woo | 18:33 |
| lifeless | .revisions and .signatures in use, no more _revision_store | 18:33 |
| lifeless | all tests passing | 18:33 |
| lifeless | jam: quirk for you | 18:33 |
| jam | lifeless: what was your 'write_revision_string' comment? | 18:33 |
| lifeless | jam: in repository.get_revision_xml | 18:33 |
| vila | go go... go lifeless go go :) | 18:33 |
| lifeless | jam: if you change it from using a stringIO to do _serializer.write_revision_to_string(), the non_ascii tests fail | 18:34 |
| jam | lifeless: I *think* that is a bug in cElementTree.tostring versus ElementTree.write(f, 'utf-8') | 18:35 |
| jam | lifeless: not sure, though | 18:35 |
| jam | lifeless: you have to pass 'encoding=XXX' to tostring() | 18:36 |
| jam | so I think you need | 18:37 |
| jam | === modified file 'bzrlib/xml_serializer.py' | 18:37 |
| jam | --- bzrlib/xml_serializer.py 2008-03-28 02:10:23 +0000 | 18:37 |
| jam | +++ bzrlib/xml_serializer.py 2008-05-19 17:36:50 +0000 | 18:37 |
| jam | @@ -87,7 +87,7 @@ | 18:37 |
| jam | self._write_element(self._pack_revision(rev), f) | 18:37 |
| jam | def write_revision_to_string(self, rev): | 18:37 |
| jam | - return tostring(self._pack_revision(rev)) + '\n' | 18:37 |
| jam | + return tostring(self._pack_revision(rev), encoding='utf-8') + '\n' | 18:37 |
| jam | def read_revision(self, f): | 18:37 |
| jam | return self._unpack_revision(self._read_element(f)) | 18:37 |
| jam | lifeless: that is my guess, at least | 18:37 |
| jam | lifeless: is get_revision_xml() used in anger anywhere? I think it used to be the basis for get_revision() but now it is defined in terms of get_revision | 18:39 |
| gour | where can one see what do you cook for 1.6? | 18:39 |
| gour | to, at least, smell it a bit | 18:39 |
| lifeless | bzr.dev | 18:39 |
| gour | lifeless: i did not mean to 'cook', just to smell ;) | 18:41 |
| lifeless | yes,I understand | 18:42 |
| LeoNerd | bzr tags --help suggests a --sort=ARG argument, but doesn't give a hint on what ARG can be | 18:51 |
| lifeless | LeoNerd: ugh, indeed | 18:53 |
| jam | lifeless: this is the bug with option formatting | 18:53 |
| jam | where someone wanted a flag to always be true | 18:53 |
| jam | but that allows "--foo" isntead of just "--sort=foo" | 18:53 |
| jam | And the person who wrote the first patch didn't step up to fix the help formatter | 18:53 |
| jam | so that you can get the sub-info when the setup is False | 18:54 |
| jam | I don't remember the specific variables | 18:54 |
| dato | the person that wrote the first patch provided an initial patch to fix the help formatter which went uncommented :P | 18:55 |
| dato | but at this point I guess it may be time to do what somebody proposed on the list a bit ago: use value_switch=True everywhere... | 18:56 |
| jam | dato: but that allows '--foo' which isn't what we want | 18:57 |
| jam | bzr tags --date | 18:57 |
| jam | rather than 'bzr tags --sort=date' | 18:57 |
| dato | particularly, isn't what *I* wanted. I couldn't stand the idea of tags --date, so that's why I used value_switch=False, knowing the options would be undocumented... | 18:58 |
| jam | anyway /away lunch | 18:59 |
| === mw is now known as mw|food | ||
| TheSheep | Hello. I want to a vcs for storing versioned data in my python app. Would it be easy to import some part of bazaar and use it internally? Does bazaar require a working tree to really exist on the disk? | 19:22 |
| TheSheep | s/a vcs/use a vcs | 19:23 |
| jelmer | TheSheep: you should be able to use the VersionedFile API | 19:23 |
| jelmer | TheSheep: If you use the Knit implementation it would just create two files on disk (one for the index, one for the actual data) | 19:23 |
| TheSheep | jelmer: the thing is, I want to make the commits from different users in the app look like commits from different branches, without having to physically create a copy of the repository | 19:25 |
| lifeless | jelmer: there is no VersionedFile api once my branch lands :P | 19:29 |
| lifeless | TheSheep: yes you can do that | 19:29 |
| jelmer | TheSheep: ah, ok. I misunderstood then | 19:29 |
| lifeless | TheSheep: we do it ourselves in the test suite using MemoryTree's | 19:29 |
| TheSheep | great | 19:30 |
| TheSheep | thank you | 19:30 |
| === rockstar_ is now known as rockstar | ||
| TheSheep | hmm... so memorytree.get_file will create a StringIO object, or will it actually create a file somewhere in the filesystem? | 19:55 |
| === mw|food is now known as mw | ||
| Pilky | if I create a project on launchpad, does that automatically create a bazaar repo that I then just have to push my initial branch to? | 20:29 |
| beuno | Pilky, you just have to push | 20:30 |
| beuno | it creates it when you push | 20:30 |
| Pilky | cool, thanks | 20:30 |
| === mtaylor_ is now known as mtaylor | ||
| beuno | http://kubasik.net/blog/2008/05/19/bazaar-and-its-rockage/ | 20:38 |
| beuno | :) | 20:38 |
| Pilky | beuno: I think one of the biggest benefits of bazaar is that it isn't built upon the idea that there is "one true way"™ of doing things | 20:53 |
| LeoNerd | bazaar is the mechanism, not the policy | 20:53 |
| beuno | Pilky, yes, they really got that right... | 20:53 |
| Pilky | the fact that you can get all the benefits of centralised and all the benefits of distributed as and when you need them is pretty damn useful | 20:53 |
| Pilky | though to be honest, having a disk image installer for OS X with a really nice background is what got me most ;) | 20:55 |
| Pilky | I'm a sucker for the little things | 20:55 |
| beuno | hahah | 20:55 |
| beuno | that's the benefits of a great community :) | 20:56 |
| gour | can one use some of launchpad features by not sharing the code? we would like to work on something before opening it to the public...you know that: "premature forking is the root of all evil " :-) | 20:56 |
| beuno | gour, well, can can *not* upload the code | 20:57 |
| beuno | I don't know how that works along the lines of policy, but it's certainly possible | 20:57 |
| gour | ok, then we might wait a bit before using launchpad by using our own roundup tracker | 20:58 |
| beuno | gour, if it's going to be open source, I don't see a problem with it at all | 20:59 |
| Pilky | hmm, ok, I think I might be a little confused by --no-trees... my branch doesn't seem to want to let me do anything | 21:00 |
| gour | beuno: it will be, of course, open-source, most probably GPL | 21:01 |
| Pilky | what exactly is the benefit of --no-trees, besides being able to put branches in branches? | 21:01 |
| beuno | gour, than I'd say go for it | 21:01 |
| gour | Pilky: i read in the user-reference about using --no-trees and then switching checkouts around | 21:01 |
| gour | beuno: cool. thanks | 21:01 |
| Pilky | ah, I think I understand it now, --no-trees is for when you're not working on something, just when you're hosting it and don't need the extra editing related stuff | 21:06 |
| === pickscrap1 is now known as pickscrape | ||
| sabdfl | Pilky: yes, exactly | 21:12 |
| sabdfl | on my laptop, i have a directory ~/foo/ which is a repository of branches of foo | 21:12 |
| sabdfl | so ~/foo/trunk and ~/foo/feature1 and ~/foo/feature2 | 21:12 |
| sabdfl | and each of those branches has all the files in it | 21:13 |
| sabdfl | so i can just cd into the branch, and work / hack / merge / commit | 21:13 |
| sabdfl | on a server, i have a repo ~/foo-storage/ | 21:13 |
| sabdfl | and i have setup my ~/.bazaar/locations.conf so that i can automatically push a branch to the server | 21:14 |
| sabdfl | just cd ~/foo/feature1; bzr push | 21:14 |
| sabdfl | and it automatically goes to the server ~/foo-storage/feature1 | 21:14 |
| sabdfl | and creates that branch on the server if it does not yet exist | 21:14 |
| sabdfl | but on the server i don't need the "working directory" | 21:14 |
| sabdfl | just the revision history | 21:14 |
| sabdfl | so that's a --no-trees repo | 21:14 |
| sabdfl | make sense? | 21:14 |
| Pilky | yeah | 21:15 |
| sabdfl | it's really easy to setup | 21:15 |
| Pilky | was just a little confused by a bit of the documentation that says that Bazaar recommends using --no-trees, but looking at it now I see that it relates to shared repositories | 21:15 |
| sabdfl | in ~/.bazaar.conf: | 21:15 |
| sabdfl | [/home/mark/foo] | 21:16 |
| visik7 | good evening | 21:16 |
| sabdfl | public_branch = bzr+ssh://server.my.com/home/mark/foo-storage | 21:16 |
| visik7 | I can't figure out the difference between init and init-repo | 21:16 |
| sabdfl | push_location = bzr+ssh://server.my.com/home/mark/foo-storage | 21:17 |
| visik7 | I've a project without any vcs | 21:17 |
| sabdfl | push_location:policy = appendpath | 21:17 |
| sabdfl | and voila | 21:17 |
| Pilky | sabdfl: cool, thanks | 21:17 |
| sabdfl | np | 21:17 |
| Pilky | visik7: I had that problem yesterday, let's see if I can explain it | 21:17 |
| sabdfl | visik7: init-repo gives you a shared repo | 21:17 |
| sabdfl | go ahead Pilky :-) | 21:17 |
| gour | Pilky: see this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch." | 21:17 |
| visik7 | Pilky: you have my attention | 21:18 |
| Pilky | visik7: if you use init-repo it creates a shared repository for all revision info | 21:18 |
| Pilky | then you use init to create a branch | 21:18 |
| Pilky | and essentially all that is stored in that branch are the revision numbers | 21:18 |
| Pilky | which reduces disk space and improve performance | 21:19 |
| visik7 | Pilky: so if I need to devel my proj splitting and merging a repo is better than a branch | 21:19 |
| Pilky | well, no, you're developing in a branch, the repo is just a sort of efficient container for many branches | 21:20 |
| sabdfl | if you will have lots of branches of the same code, then use a shared repo | 21:20 |
| sabdfl | make a directory structure like this: | 21:20 |
| sabdfl | - repodir | 21:20 |
| visik7 | but if I've already started a branch how can I import it into a repo ? | 21:20 |
| sabdfl | - branch 1 | 21:20 |
| sabdfl | - branch 2 | 21:20 |
| sabdfl | - branch 3 | 21:21 |
| Pilky | visik7: branch it off into the repo | 21:21 |
| sabdfl | that's each | 21:21 |
| sabdfl | mkdir ~/my-repo | 21:21 |
| sabdfl | cd ~/my-repo | 21:21 |
| sabdfl | bzr init-repo | 21:21 |
| sabdfl | then bzr branch ~/path/to/branch branch | 21:21 |
| sabdfl | you will then have: | 21:21 |
| sabdfl | ~/my-repo | 21:21 |
| sabdfl | [this is where the revisions are all stored, shared, in .bzr] | 21:22 |
| sabdfl | ~/my-repo/branch | 21:22 |
| sabdfl | [this is where the working files for this branch are] | 21:22 |
| sabdfl | and you can make a second branch by going: | 21:22 |
| sabdfl | cd ~/my-repo | 21:22 |
| sabdfl | bzr branch branch new-branch | 21:22 |
| visik7 | 'couse I've already branched by project than rebranch and devel new features but outside of a repo | 21:22 |
| visik7 | now I need to branch both inside the repo ? | 21:23 |
| sabdfl | (eek, calling that first branch "branch" was bad) | 21:23 |
| sabdfl | the first time you branch "into" a repo, it copies all the revisions into the repo store | 21:23 |
| sabdfl | from then on, each new branch just re-uses the previous revisions for everything that's common | 21:23 |
| sabdfl | which is most of history, usually | 21:23 |
| sabdfl | say you have a project with 1000 commits | 21:23 |
| sabdfl | and you make a new branch, with 10 extra commits | 21:23 |
| sabdfl | that's only 1% "new" | 21:24 |
| sabdfl | so it makes sense to share history | 21:24 |
| visik7 | yes yes I got it | 21:24 |
| visik7 | but the problem now is that I've 2 branches of a project outside of a repo | 21:25 |
| visik7 | :( | 21:25 |
| Pilky | visik7: I don't see any problems with branching both into the repo | 21:25 |
| Pilky | you just need to change the default merge location for when you merge back together | 21:26 |
| Pilky | so that you're merging back to the copy in the repo, not the one outside of it | 21:26 |
| visik7 | ops | 21:32 |
| visik7 | how can I undo a merge ? | 21:32 |
| beuno | visik7, bzr revert | 21:32 |
| pickscrape | As long as you haven't committed yet... | 21:33 |
| beuno | actually, bzr revert --forget-merges | 21:33 |
| visik7 | fiu | 21:33 |
| radix | --forget-merges is only if you don't want to revert the changes to the files that the merge made | 21:33 |
| beuno | yes, if you already committed, then you'll have to specify to which revision to revert (bzr revert -r -1 would be the last revision) | 21:33 |
| beuno | radix, oh? that *doesn't* revert the changes made? | 21:34 |
| radix | beuno: right. the point of --forget-merges is that it *only* forgets the metadata about the merge, while keeping the changes to the files. | 21:34 |
| beuno | radix, hrm, I wonder if that's the best name for it... | 21:35 |
| visik7 | I'm really really new to vcs concepts, I was expect some question when I run a merge, instead it do all the work but what really a merge do ? | 21:35 |
| visik7 | a part from coping files ? | 21:35 |
| Pilky | visik7: well, if there are no conflicts then it should perform the merge for you | 21:37 |
| Pilky | which merges directories, but also the files themself | 21:37 |
| Pilky | say you edited line 5 of a.txt in one branch and then line 20 of a.txt in another branch | 21:37 |
| Pilky | when you merge them it will try to put the new stuff in line 5 and line 20 into a.txt | 21:38 |
| radix | visik7: it does more than just copying. It "merges" in all the changes made in another branch, without overwriting other changes that have been made otherwise. | 21:38 |
| Pilky | of course, if you were to edit line 5 in both branches and try to merge, you'd get a conflict as there are two new bits of data and the VCS doesn't know which to choose | 21:39 |
| visik7 | anyway it's request to manually check if everythings works as expected right ? 'couse it can't be aware of what my code relies on | 21:39 |
| Pilky | in this case you'll have to choose yourself and then resolve it | 21:39 |
| radix | visik7: This is why bzr doesn't automatically *commit* the changes when you merge -- | 21:40 |
| radix | visik7: you have a chance to review the changes with "bzr diff" before running "bzr commit". | 21:40 |
| visik7 | good, clear | 21:40 |
| mtaylor | bzr: ERROR: Invalid revision number 447 | 21:45 |
| mtaylor | when pushing a just-merged branch back to launchpad | 21:45 |
| mtaylor | what does that mean? | 21:45 |
| mtaylor | nm - I think it was a local hook | 21:49 |
| mwhudson__ | mtaylor: interesting, we've had a few branches with that problem | 21:50 |
| === mwhudson__ is now known as mwhudson | ||
| mtaylor | mwhudson: oh, ok. then it _wasn't_ my fault :) | 21:51 |
| mwhudson | mtaylor: can you check 'bzr revno' vs 'bzr revision-history | wc -l' ? | 21:51 |
| mwhudson | they should give the same number | 21:51 |
| mwhudson | mtaylor: well, maybe it was :) | 21:51 |
| mtaylor | mwhudson: they equal | 21:51 |
| mwhudson | mtaylor: oh good | 21:51 |
| mtaylor | then it was my fault | 21:51 |
| mwhudson | it's possible | 21:52 |
| mwhudson | mtaylor: which branch? | 21:52 |
| mtaylor | mwhudson: lp:ndb-connectors | 21:52 |
| mtaylor | gah | 21:52 |
| mtaylor | lp:ndb-bindings | 21:52 |
| mwhudson | hm, branch on lp seems ok too | 21:53 |
| mwhudson | so i don't know what you did, but it doesn't seem to be related to our mystery branch problem | 21:54 |
| mwhudson | good news for you :) | 21:54 |
| mtaylor | yay! | 21:54 |
| schmichael | just upgraded to 1.5 and a commit seems to be frozen on pre_commit hooks (stage 3/5) | 21:58 |
| schmichael | afaik i have no pre_commit hooks | 21:58 |
| schmichael | anybody know where i should start looking to fix this? | 21:59 |
| schmichael | i hit ctrl-c, and it seems to have committed just fine | 22:04 |
| schmichael | now bzr push appears frozen (ssh+bzr protocol, bzr 1.5 on the server as well) | 22:05 |
| schmichael | i had also run bzr upgrade on both branches... perhaps thats the problem? | 22:08 |
| LaserJock | jelmer: around? | 22:12 |
| jelmer | LaserJock: hi | 22:13 |
| LaserJock | jelmer: I'd like to upgrade my bzr/bzrtools version to the bzr PPA | 22:13 |
| LaserJock | but bzr-svn doesn't seem to be ready | 22:13 |
| LaserJock | can I get bzr-svn from a bzr branch instead? | 22:13 |
| schmichael | argh! i'm trying to commit with the old copy of my repo, and it still doesn't work | 22:15 |
| schmichael | what have i done to break bzr 1.5? :( | 22:15 |
| jelmer | LaserJock: yes, just use the 0.4 branch | 22:15 |
| schmichael | hm, i have bzr-svn and bzr 1.5 installed... could that be the problem? | 22:16 |
| jelmer | schmichael: that shouldn't matter | 22:16 |
| jelmer | do you have any other plugins installed? | 22:17 |
| schmichael | any package that starts with bzr- in debian sid | 22:17 |
| schmichael | dbus, email, gtk, pqm, rebase, svn, tools | 22:18 |
| schmichael | i probably only use gtk, svn, and tools though | 22:18 |
| schmichael | huh, it appears my push did succeed | 22:22 |
| schmichael | well, i guess everything is working well enough | 22:25 |
| schmichael | i just have to hit ctrl-c to kill commits at the pre_commit hook stage | 22:25 |
| schmichael | for pushing, i guess just count to ten and hit ctrl-c | 22:25 |
| schmichael | i'd love to file a bug but i don't have any clue where to even start diagnosing this | 22:25 |
| beuno | schmichael, you downloaded the bzr 1.5 tarball? | 22:30 |
| schmichael | beuno: using debian sid packages on my desktop and easy_installed 1.5 tar ball on my etch server | 22:30 |
| schmichael | bzr push on my desktop shows 'Using saved location ...', the doesn't-update-working-copy warning, then '/ (0,0)' displays briefly | 22:31 |
| schmichael | that disappears and it just hangs | 22:31 |
| schmichael | the push has already completed (its on the server), so i just hit ctrl-c to exit | 22:32 |
| beuno | schmichael, can you take a look at the ~/.bzr.log? | 22:33 |
| beuno | there might be some information there | 22:33 |
| schmichael | beuno: thanks for the tip, this looks revealing: http://pastebin.com/m310f07c6 | 22:36 |
| schmichael | seems the dbus plugin is to blame? | 22:36 |
| LaserJock | hmm, can you use bzr-svn to separate svn branches into separate bzr branches in a shared repo? | 22:37 |
| beuno | schmichael, yes it is :) | 22:37 |
| schmichael | beuno: removing bzr-dbus fixed it! thanks! | 22:38 |
| jelmer | LaserJock: yes | 22:39 |
| jelmer | schmichael: please file a bug | 22:39 |
| schmichael | jelmer: with debian? | 22:39 |
| * schmichael hates debian's bts | 22:39 | |
| beuno | schmichael, you're welcome :) | 22:40 |
| beuno | jelmer, is a bug in order? he's not using bzr from the debian repo | 22:40 |
| LaserJock | jelmer: I'm trying bzr svn-import --all --trees <svn repo>, would that work? | 22:40 |
| schmichael | beuno: i am actually | 22:40 |
| schmichael | locally its from debian sid | 22:40 |
| LarstiQ | schmichael: the easy_installed one? | 22:40 |
| schmichael | LarstiQ: nope, that one works fine (no dbus plugin installed on the server) | 22:40 |
| schmichael | sorry for the confusion | 22:41 |
| schmichael | its only on my debian sid desktop using debian's bzr 1.5 packages | 22:41 |
| jelmer | LaserJock: yes | 22:42 |
| LaserJock | jelmer: how do I then update my branches? bzr pull ? | 22:43 |
| LaserJock | I'm a little confused as to the relationship between svn-import and just using bzr branch <svn repo> | 22:44 |
| jelmer | LaserJock: yes | 22:45 |
| jelmer | LaserJock: think of "bzr svn-import" as a series of "bzr branch" commands | 22:45 |
| LaserJock | ahhh | 22:45 |
| LaserJock | jelmer: wow, that's pretty sweet | 22:49 |
| LaserJock | jelmer: is there a way to update the whole shared repo? | 22:50 |
| jelmer | LaserJock: only the existing branches in the repo | 22:50 |
| jelmer | "bzr multi-pull" | 22:50 |
| jelmer | although "bzr svn-import" should work incrementally as well | 22:51 |
| LaserJock | yeah, ok I think this is perfect | 22:51 |
| LaserJock | I won't be pull'ing tags and usually only one branch at a time anyway, but multi-pull is just what I was looking for | 22:52 |
| poolie | good morning | 23:02 |
| jam | morning poolie | 23:03 |
| beuno | mornin' poolie | 23:04 |
| poolie | jam, hi, we were going to talk now iirc | 23:04 |
| poolie | hello beuno | 23:04 |
| jam | poolie: I'm sure you're right, I should get this on my schedule :) | 23:05 |
| jam | poolie: I have skype, and I'm ready when you are | 23:07 |
| visik7 | morning ? | 23:07 |
| poolie | morning visik7 | 23:07 |
| visik7 | where are u ? | 23:08 |
| poolie | sydney | 23:08 |
| visik7 | cool I was there last summer | 23:09 |
| visik7 | but too much one way only roads for my liking | 23:11 |
| TheSheep | does bzr allow me to save metainformation on files? like, for example, a comment? | 23:36 |
| mwhudson | TheSheep: no | 23:38 |
| TheSheep | mwhudson: thanks | 23:40 |
| beuno | TheSheep, of course, there is some potention for a plugin there... | 23:40 |
| beuno | you might want to mail the list and see if someone catches on with it ;) | 23:40 |
| TheSheep | beuno: nah, it's not that important | 23:41 |
| TheSheep | beuno: besides, my use case is far from common | 23:41 |
| beuno | well, bzr is all about uncommon use cases, but, I won't insist | 23:43 |
| Peng | Googlebot is having lots of fun downloading all of my knits. :) | 23:44 |
| beuno | mueheheh | 23:44 |
| beuno | should be interesting to see what they do with that | 23:44 |
| Peng | It already indexes some bundle files, and occasionally people search for weird things and find them. | 23:54 |
| LaserJock | dang, bzr multi-pull is so sweet | 23:55 |
| igc | morning | 23:56 |
| LaserJock | I was just going to write shell scripts to go through and update all my VCS checkouts | 23:56 |
| LaserJock | for bzr all I have to do is cd bzr/ && bzr multi-pull | 23:56 |
| jam | morning igc | 23:56 |
| beuno | heya igc | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
