| jml | lifeless, hello :) | 00:04 |
|---|---|---|
| spiv | jml: pong | 00:22 |
| spiv | jml: how was EuroPython? | 00:23 |
| jml | spiv, it was great :) | 00:23 |
| jml | spiv, I just sent my trip report to warthogs & am about to send my Bazaar sprint report | 00:23 |
| jml | spiv, regarding the --allow-writes patch. I'm thinking of marking the bug as wontfix, you filed the original bug IIRC -- what do you think? | 00:24 |
| jelmer | 'evening spiv, jml | 00:24 |
| jelmer | spiv: Do you perhaps know what the state/plans for nested trees is? | 00:25 |
| jml | jelmer, g'day. | 00:25 |
| spiv | jml: I did? I vaguely thought it was poolie... | 00:25 |
| jml | spiv, you are right. | 00:26 |
| jml | and I am daft. | 00:26 |
| spiv | jelmer: morning :) | 00:27 |
| spiv | jelmer: abentley's was working on addressing the various concerns people had, the details of that are in his devnotes branch I think. It certainly won't make 2.0, but given that abentley has a fair bit of code already and the design questions are largely worked out it's hopefully not too far into the future. | 00:28 |
| spiv | It probably depends on abentley's other priorties more than anything else... | 00:29 |
| jelmer | spiv: ah, ok - thanks | 00:29 |
| spiv | spm: ping; where did we get to with lp: URLs and bzr's PQM? | 00:58 |
| spiv | spm: (it's still not working) | 00:58 |
| poolie | hello | 01:34 |
| poolie | hello jml, welcome back | 01:35 |
| poolie | i think regarding --allow-writes there is still an issue there that should be addressed | 01:35 |
| poolie | but | 01:35 |
| poolie | perhaps not in the way recommended by the bug | 01:35 |
| poolie | how about just giving a warning if it's used in --serve mode/ | 01:36 |
| poolie | i mean, in non-inetd mode | 01:36 |
| jml | poolie, yeah. I've reverted the bug back to 'Triaged'. | 01:36 |
| jml | poolie, that sounds fine to me. Simple & to the point. | 01:36 |
| poolie | did you pick this because it looked easy, or was there some stronger motivation? | 01:39 |
| SpamapS | I want to make a copy of my current working copy and then revert so I can build the old version.. can I just 'cp -arf working working2' and then 'bzr revert' in working, and still keep my local changes in working2? | 01:52 |
| poolie | yes | 01:53 |
| lifeless | you can also branch and then use 'bzr merge --uncommitted' | 01:54 |
| lifeless | jml: bug 307166 | 01:55 |
| ubottu | Launchpad bug 307166 in bzr "bzr fails when attempting to fetch branch using lp:" [Undecided,New] https://launchpad.net/bugs/307166 | 01:55 |
| lifeless | jml: I'm curious why you removed the launchpad tag? | 01:55 |
| jml | lifeless, because I didn't read the stack trace. | 01:56 |
| jml | lifeless, and reading only the error, I assumed that the OP mistook a general network error for a Launchpad-specific thing. | 01:57 |
| jml | In any case, it's a dupe of a bug I just fixed. | 01:57 |
| lifeless | cool | 01:57 |
| lifeless | what about bug 216924 | 01:57 |
| ubottu | Launchpad bug 216924 in bzr ""bzr push lp:" on windows leads to socket.sslerror traceback." [Undecided,New] https://launchpad.net/bugs/216924 | 01:57 |
| jml | wow, untriaged bugs starting with 2 | 01:58 |
| jml | lifeless, do you think it's a bug in the lp plugin? | 01:59 |
| lifeless | yes | 01:59 |
| lifeless | the backtrace shows its the lp plugin calling xmlrpclib | 01:59 |
| lifeless | its got nothing to do with ssh | 02:00 |
| jml | you think the plugin should catch that error and... ? | 02:01 |
| lifeless | I think we should determine the root cause | 02:01 |
| lifeless | my gut says its a dup of the 'lp plugin does not honour proxy settings' | 02:01 |
| lifeless | bug | 02:01 |
| lifeless | what does the 'launchpad' tag mean to you? | 02:01 |
| jml | bug in the launchpad plugin | 02:02 |
| lifeless | to me it means 'fixing this bug will make life easier/nicer for users of bzr with launchpad | 02:02 |
| jml | I see. | 02:03 |
| poolie | to me just 'related to launchpad' | 02:03 |
| lifeless | the lp plugin is just 'code that is unique to working with lp' | 02:03 |
| lifeless | not the entire set of related to lp | 02:03 |
| lifeless | jml: I'm tagging that launchpad again | 02:04 |
| jml | lifeless, ok | 02:04 |
| lifeless | jml: because you can only get that error using lp: | 02:04 |
| lifeless | as only lp: uses xmlrpc | 02:04 |
| jml | lifeless, fair enough. | 02:04 |
| jml | lifeless, re: "the lp plugin is just 'code that is unique to working with lp' not the entire set of related to lp" -- yes that goes without saying, what's your point? | 02:05 |
| lifeless | jml: my point is that the tag, and experience is broader than the plugin | 02:09 |
| jml | lifeless, I'd kind of like a way of saying "this bug affects the launchpad plugin". | 02:16 |
| lifeless | jml: why? | 02:17 |
| jml | lifeless, but I guess that the space of bugs related to launchpad more generally isn't big enough for that to help | 02:17 |
| poolie | jml, i've read your trip report, if you want to chat just give me a call | 02:17 |
| mwhudson | hey guess what | 02:17 |
| mwhudson | lrucache isn't thread safe | 02:17 |
| jml | lifeless, because it matches my mental model of the world :) | 02:17 |
| * mwhudson really really should not have made that mistake :/ | 02:18 | |
| poolie | :/ | 02:18 |
| poolie | mwhudson: there's not really any promise that any bzr class is thread safe | 02:18 |
| mwhudson | poolie: yes, i know | 02:18 |
| poolie | and in general making single classes threadsafe can be an antipattern | 02:18 |
| poolie | k | 02:18 |
| mwhudson | a failure to think straight on my part | 02:18 |
| lifeless | jml: you'd need to explain your model then. | 02:21 |
| lifeless | we're threadsafe like the C++ STL is | 02:22 |
| lifeless | which is to say, we're safe for a single thread :) | 02:22 |
| fullermd | Threadsafe, not threadSsafe :p | 02:23 |
| mwhudson | "not conspicuously stupid about it" | 02:24 |
| jml | abentley, bundlebuggy appears to be down | 02:46 |
| abentley | jml: restarted | 02:47 |
| jml | abentley, thanks. | 02:47 |
| poolie | jml, i filed bug 396335 | 04:09 |
| ubottu | Launchpad bug 396335 in bzr "want a deb that adds the bzr ppa and keys" [Low,Confirmed] https://launchpad.net/bugs/396335 | 04:09 |
| lifeless | poolie: uhm | 04:09 |
| lifeless | poolie: I don't know if you are aware but there are a bunch of other approaches for that | 04:09 |
| lifeless | that don't need maintenance in the same way | 04:09 |
| poolie | i know there's various efforts to have a systematic way to add/remove ppas | 04:10 |
| poolie | this bug is kindof a workaround for the lack of them | 04:10 |
| poolie | what kind of maintenance are you talking about though? | 04:11 |
| lifeless | two things mainly | 04:11 |
| lifeless | one is that the deb is introducing static data, so it has to be at least a little careful because users may remove the data without removin the deb | 04:12 |
| lifeless | and the other is that the keys it adds are static | 04:12 |
| lifeless | but archive keys are often rotated | 04:12 |
| poolie | really? | 04:12 |
| lifeless | and even if lp isn't rotating ppa keys today, I fully expect it will have to at some point | 04:12 |
| lifeless | (it being whatever deb is created) | 04:12 |
| poolie | for values of often = never :) | 04:13 |
| poolie | well, | 04:13 |
| lifeless | ubuntu and debian archive keys are rotated | 04:13 |
| poolie | if they start doing that, they'll have to work out some some solution for the thousands of people who've manually added the keys now | 04:13 |
| jml | wow. | 04:15 |
| jml | just came across the first time I've ever wanted to sort bugs by id | 04:16 |
| lifeless | jml: thanks for the slides; looks like you created a really good narrative | 04:16 |
| jml | lifeless, my pleasure. | 04:18 |
| jml | btw, I just came across this bug: https://bugs.edge.launchpad.net/bzr/+bug/183831 | 04:20 |
| ubottu | Ubuntu bug 183831 in bzr "bzr add <softlink> follows the link" [Undecided,Confirmed] | 04:20 |
| jml | it has a patch that hasn't been responded to. | 04:20 |
| jml | the author of the patch asked me about it at EuroPython, I think. | 04:20 |
| RenatoSilva | How do I unpush? | 04:43 |
| lifeless | push --overwrite -r -2 | 04:43 |
| lifeless | or whatever is the right revision | 04:43 |
| RenatoSilva | I pushed a new revision, I want to uncommit and push the revision again to lp | 04:43 |
| RenatoSilva | lifeless: thank you! | 04:43 |
| lifeless | or if you have a new revision locally, just push --overwrite | 04:43 |
| RenatoSilva | lifeless: ? | 04:46 |
| RenatoSilva | lifeless: pushed revision was 130... | 04:47 |
| RenatoSilva | lifeless: I uncommited, commited again (a new 130) | 04:47 |
| RenatoSilva | lifeless: if worked without specifying the rev number | 04:47 |
| RenatoSilva | *it | 04:47 |
| lifeless | yes | 04:54 |
| lifeless | the rev number is when you want to specify a rev other than tip | 04:55 |
| lifeless | --overwrite is all that is needed to force the push | 04:55 |
| RenatoSilva | lifeless: thank you | 05:04 |
| * spiv -> lunch | 05:06 | |
| RenatoSilva | When a bug is invalid for a project, but there's a watch in the project for a external bug, what does this mean? | 05:11 |
| lifeless | it means the bug is recorded in two places | 05:12 |
| RenatoSilva | I mean it's like the bug itself is invalid | 05:14 |
| lifeless | I'm not sure what you mean | 05:15 |
| lifeless | but perhaps an example would help | 05:15 |
| RenatoSilva | lifeless: in bug 388300, Eclipse was checked as invalid, however I reported it initially as general error "bzr-eclipse does not work with accented paths" | 05:15 |
| ubottu | Launchpad bug 388300 in bzr-xmloutput "Encoding problems in xmloutput: non-ascii URLs and unchecked string decodings" [High,Confirmed] https://launchpad.net/bugs/388300 | 05:15 |
| RenatoSilva | lifeless: now we know it's an xmloutput issue, but the external bug may also be affecting bzr-eclipse | 05:16 |
| RenatoSilva | lifeless: eclipse was marked as invalid, because the title changed...that's ok, I just wonder if I should generalize the title again (and change eclipse's invalid status), or either open a new bug pointing to that bug | 05:18 |
| RenatoSilva | to the eclipse external bug | 05:18 |
| lifeless | RenatoSilva: if changes are needed to eclipse to close the bug | 05:21 |
| lifeless | RenatoSilva: then it would be appropriate for a task to be open (not invalid) on eclipse | 05:22 |
| lifeless | however the external bug is marked resolved | 05:22 |
| lifeless | perhaps the external link needs to be updated | 05:23 |
| poolie | jml, any reason you're using BB rather than lp reviews? | 05:26 |
| poolie | i hear they're rather good :) | 05:26 |
| jml | poolie, well, I'm not really. | 05:31 |
| poolie | oh, i just thought i saw one from you | 05:32 |
| poolie | also, maybe you shoud send your report somewhere else too | 05:33 |
| jml | poolie, yeah, that was an RFC patch | 05:33 |
| poolie | like a europython list? | 05:33 |
| jml | poolie, I guess I could have used a merge proposals | 05:33 |
| jml | but I hoped I'd get responses more quickly on the ML | 05:34 |
| jml | I guess I was wrong | 05:34 |
| poolie | mm | 05:34 |
| jml | good idea re forwarding | 05:35 |
| RenatoSilva | lifeless: it's just about organizing the issues, maybe it's better to create a new bug | 05:35 |
| lifeless | RenatoSilva: I don't know | 05:35 |
| RenatoSilva | lifeless: is is resolved as duplicate of another bug (also watched in lp bug) | 05:35 |
| poolie | jeez i'm sick of launchpad repeating the bug description in the first bugmail | 05:37 |
| === abentley1 is now known as abentley | ||
| RenatoSilva | lifeless: most of bug content is about xmloutput, eclipse's bug is a little part | 05:37 |
| jml | poolie, yeah. | 05:39 |
| lifeless | I don't mind it being included | 05:39 |
| lifeless | it helps when you are added to an already inflight bug | 05:40 |
| poolie | it's provably stupid when it's including *the exact same text* twice | 05:40 |
| poolie | ffs | 05:40 |
| poolie | seriously | 05:41 |
| lifeless | oh, I haven't noticed that | 05:41 |
| poolie | sending you the description when you're added to a bug would be useful i agree | 05:41 |
| poolie | and even when i have 'include bug descriptions' turned off | 05:41 |
| === abentley1 is now known as abentley | ||
| poolie | </grump> | 05:51 |
| poolie | going back to reconfigure | 05:51 |
| === abentley1 is now known as abentley | ||
| poolie | lifeless: in the context of unstacking | 06:44 |
| poolie | at the moment unstacking fails with revisionnotfound if you have any tags pointing to not-present revisions | 06:44 |
| poolie | this should probably not happen... | 06:45 |
| lifeless | I think fetch is still broken wrt that case | 06:46 |
| poolie | at any rate it should be consistent with branch, which seems to only copy things referenced in the branch | 06:46 |
| poolie | it looks like fetch makes no effort to copy the revs referenced by tags? | 06:47 |
| lifeless | thats right; there is a bug open on that | 06:48 |
| lifeless | ciao | 07:13 |
| spiv | Woah, "repo.add_inventory(...)" on a stacked gc repo is adding the inventory to repo's fallback, not repo. | 07:20 |
| spiv | Hmm, something is weird here. | 07:21 |
| vila | spiv: isn't the fallback read-only ? | 07:21 |
| vila | err, Hi all ! :) | 07:21 |
| spiv | Hmm, or it's just the way I'm introspecting the vf that's the issue. | 07:22 |
| poolie | hello spiv | 07:28 |
| poolie | hello vila, spiv | 07:28 |
| poolie | spiv, how's stuff? | 07:28 |
| jml | is https://bugs.edge.launchpad.net/bzr/+bug/393349 a dupe of something deeper? | 07:30 |
| ubottu | Ubuntu bug 393349 in bzr "exceptions.AttributeError: 'AbsentContentFactory' object has no attribute 'get_bytes_as'" [High,Triaged] | 07:30 |
| poolie | probably | 07:35 |
| jml | poolie, spiv, vila: could one of you please review https://lists.ubuntu.com/archives/bazaar/2009q3/060202.html | 08:01 |
| jml | it's one of the patches from the sprint. | 08:02 |
| vila | I think spiv is the usual suspect here :) | 08:02 |
| spiv | poolie: alright, that stacking cross-format test is passing finally. I'm just trying to figure out why more mundane (pack-0.92 to pack-0.92, for instance) tests are failing, which I only just noticed after fixing the stacking bug. | 08:03 |
| spiv | jml: heh, coincidentally I updated my bzr-ping plugin to report that just a few days ago. | 08:04 |
| spiv | Aah, ghosts. I see the bug. | 08:09 |
| * spiv fixes | 08:09 | |
| spiv | Ok, just one failing test left. | 08:15 |
| spiv | Well, 1 x every format :) | 08:15 |
| spiv | Weird, only one format fails when I run just those tests. | 08:20 |
| lifeless | spiv: global state | 08:28 |
| spiv | lifeless: you'd think so, but it turns out be pebkac (well, that and test names that are very similar to the eye, particuarly in the rather noisy output of multiple test failures) :) | 08:32 |
| * spiv exhales and pushes the branch with all interrepo and fetch tests passing, finally. | 08:51 | |
| * vila cries, one more bug in python http server... | 08:54 | |
| === awilkins_train is now known as awilkins | ||
| awilkins | vila: Heh, and the bugs in the RFC implementations bump into the bugs in IIS's implementations :-) | 09:28 |
| vila | awilkins: err, any specific in mind ? I just fixed one where the http server weren't inserting a Content-Length header (which I more or less think is kind of mandatory in 1.1 which presumably is needed for https) | 09:30 |
| * vila sounds very confident isn't it ? :-D | 09:30 | |
| awilkins | vila: It's the one I worked around somewhere... | 09:30 |
| * awilkins looks up the revision | 09:31 | |
| vila | awilkins: really ? The only case where it seems to cause a problem is pycurl+https client hanging, all other combinations are fine | 09:31 |
| awilkins | r 3539 | 09:31 |
| awilkins | It's a problem with it serving ranges in IIS | 09:32 |
| awilkins | RFC822 in Python is wrong, as is RFC2046 in IIS | 09:32 |
| awilkins | It's essentially about the way it quotes multipart content boundary lines | 09:33 |
| vila | awilkins: Oh, I remember that one | 09:33 |
| awilkins | But it has a workaround ; and really, you're not going to get it fixed in IIS | 09:33 |
| vila | Sure, but the one I just fixed is in the python's http server | 09:33 |
| vila | And *that* means that our http clients are tolerant about that, except pycurl for https :-) | 09:34 |
| fullermd | Funny how every time I hear 'pycurl' here or on the list or anywhere, it's followed by "is screwing up XYZ for me"... | 09:35 |
| awilkins | Off the top of my head the only thing I can think of for your automatic make-a-tunnel problem is that you may want to have a private key with no passphrase ; the part where it's automatically starts the tunnel is escaping me | 09:36 |
| vila | fullermd: that's called rumors and I suspect someone is trying to get pycurl deprecated | 09:36 |
| awilkins | pycurl screws things up for me on Windows | 09:37 |
| vila | awilkins: Oh, good, I end up to that conclusion too (no pass-phrase) as for the automatic start, I found 2 possible solutions: 1) use inetd, 2) a perl script called autotunnel (a bit hackish though and not because it's written in perl ;-) | 09:37 |
| vila | on the other hand, the automatic part is really needed only for my laptop usage and less important | 09:38 |
| vila | awilkins: what is pycurl screwing ? | 09:38 |
| awilkins | I'm content with manually establishing tunnels tvbh | 09:38 |
| awilkins | vila: I don't recally, I abandoned using it about a year ago | 09:39 |
| vila | tvbh ? | 09:39 |
| vila | tbvh I can translate to 'to be very honest' with my crystal ball but... tvbh... | 09:40 |
| awilkins | vila: Was meant to be tbh but I'm suffer from fat fingers. Too many sausage sandwiches I think. | 09:46 |
| fullermd | Through Verbose Barnyard Hovels? | 09:46 |
| vila | :) | 09:47 |
| awilkins | And pycurl must have annoyed me, the folder is now called "curl_off" | 09:48 |
| bialix | vila: bonjour | 10:10 |
| vila | Hello bialix ! | 10:10 |
| bialix | I have a question about review process on LP | 10:10 |
| vila | Are you asking if you can ask ? | 10:11 |
| bialix | what should be done to mark patch as approved | 10:11 |
| bialix | ? | 10:11 |
| vila | :-) | 10:11 |
| bialix | e.g. https://code.launchpad.net/~bialix/bzr/lp-bzr.exe/+merge/8259 | 10:11 |
| bialix | 2 approve votes is not enough now? | 10:11 |
| spiv | vila: I don't think Content-Length is mandatory; e.g. if the transfer-encoding is chunked you don't need it to reliably determine end-of-body. | 10:13 |
| vila | bialix: the second rapprover should land the patch :) | 10:13 |
| Peng_ | (testing my IRC client, sorry) bzr+ssh://example.com/ | 10:13 |
| vila | spiv: yeah, chunked and Content-Length are exclusive | 10:13 |
| * fullermd fails Peng_'s client. | 10:13 | |
| Peng_ | fullermd: :D | 10:14 |
| bialix | vila: wait, there is 2 queues now: https://code.launchpad.net/bzr/+activereviews and https://code.launchpad.net/bzr/+approvedmerges | 10:14 |
| bialix | my patch in the former | 10:14 |
| bialix | what should be done to take it into the latter?> | 10:14 |
| bialix | and what is "Review type" when I'm adding manually additional reviewers? | 10:15 |
| knielsen | Hi, I'm a bit worried about this bug: https://bugs.launchpad.net/bzr/+bug/375898 ... it has been sitting there for a couple of month now, and it's basically a showstopper, crash on merge into tree with no known work-around :-( | 10:15 |
| ubottu | Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged] | 10:16 |
| vila | bialix: ha, yes, the proposal status should be update, that's not the same as the review status | 10:16 |
| bialix_ | rats, my new patch for unicode locks affected by difference between lp:bzr and http//bzr.dev | 10:16 |
| knielsen | There is a reproducible test case ... it's been blocking our merge of PBXT into MariaDB for two months now :-( ... so any help would be much appreciated | 10:17 |
| bialix_ | what should I do now? | 10:17 |
| vila | bialix: ha, yes, the proposal status should be update, that's not the same as the review status | 10:17 |
| bialix_ | vila: sorry, I have been disconnected for some time | 10:17 |
| vila | as for "Review type", I have no idea :) Try searching lp help :D | 10:18 |
| bialix_ | vila: so, I'm not bzr-core member, so I have no rights to change proposal status, it seems | 10:18 |
| spiv | bialix_: for bzr just leave the review-type blank; some projects (e.g. launchpad) have separate UI review and database schema review on top of basic code review. | 10:19 |
| spiv | But for bzr we just have reviews, no special differentiation. | 10:20 |
| bialix_ | ok, my new patch https://code.launchpad.net/~bialix/bzr/lock-unicode-win32/+merge/8297 affected by divergence between bzr.dev and lp:bzr. Should I resubmit it later? | 10:20 |
| vila | generally yes | 10:21 |
| knielsen | importance for https://bugs.launchpad.net/bzr/+bug/375898 is "medium" which seems too low, as it basically makes your tree corrupt and unusable ... sounds more like critical to me ... ? | 10:21 |
| ubottu | Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged] | 10:21 |
| bialix_ | vila: ok, will do later today | 10:22 |
| bialix_ | jam is working these days? | 10:22 |
| vila | knielsen: it would be best to check with jam and abentley in a couple of hours US TZs | 10:23 |
| knielsen | vila: ok, will do, thanks | 10:23 |
| poolie | hello vila | 10:30 |
| vila | poolie: hi again :) | 10:30 |
| poolie | if you have a chance, robert would appreciate you doing his check review | 10:32 |
| poolie | it's kind of big | 10:32 |
| poolie | he got an initial review from ian, but ian is away this week | 10:33 |
| vila | poolie: I'm already reviewing it :-) | 10:33 |
| fullermd | Hopefully that doesn't mean reviewing it drives people away :p | 10:33 |
| poolie | on the other hand it cures cancer :) | 10:34 |
| vila | fullermd: in fact it does... I'll be in vacations the week after next week :) | 10:34 |
| === bialix_ is now known as bialix | ||
| poolie | :) | 10:38 |
| fullermd | Hm. I'll review it then; I could use an escape week... | 10:38 |
| * LarstiQ fumbles about with the launchpad review ui | 10:49 | |
| === abentley1 is now known as abentley | ||
| maxb | I have bzr-gtk installed to be able to use "bzr visualize", but I don't want the popup notifications when I bzr pull - where can I stop those? Thanks. | 11:11 |
| Wellark^1 | hi! I'm planning to start a project which uses bazaar for version control. I'm interested about the current state of GPG integration. This page http://bazaar-vcs.org/BzrGpgSigning seems to be outdated and I would like to know what's the current status. Particularly I'm interested whether or not is it possible to demand and force every commit which land to shared repositories on remote server to be signed. Thanks. | 11:11 |
| poolie | Wellark^1: it's probably possible by writing a hook on the server | 11:15 |
| poolie | i think there may be one already | 11:15 |
| Wellark^1 | ok. cool! | 11:22 |
| Wellark^1 | I'm sure I can work that out when I begin deployment | 11:22 |
| poolie | you could send mail... | 11:23 |
| Wellark^1 | I was just worried if GPG side is completely broken or something like that :) | 11:23 |
| lifeless | maxb: disable the applet | 11:50 |
| maxb | what applet? | 11:50 |
| maxb | removing the bzr-dbus package seems to have stopped them | 11:51 |
| lifeless | theres a bzr gtk process being started by your session | 11:51 |
| lifeless | bzr-dbus is just the transport | 11:51 |
| maxb | Oh, so there is. Too much magic :-) | 11:53 |
| lifeless | bzr-dbus has glue to do notifications on cross process, or LAN etc | 11:55 |
| lifeless | and I plan to hook in jabber when I get some time | 11:55 |
| NEBAP|work | is it possible to checkout a shared repository? | 12:49 |
| mzz | NEBAP|work: it's definitely possible to checkout branches living inside a shared repository. | 12:49 |
| mzz | NEBAP|work: checking out an entire shared repository doesn't make sense, but there may be a command that automates checking out all the branches inside one. | 12:50 |
| NEBAP|work | mzz: but then I have to create a shared repository myself in the local location, too. Is there a way to checkout the hole "structure" of a project? | 12:50 |
| mzz | NEBAP|work: see above. | 12:50 |
| NEBAP|work | hmm | 12:51 |
| mzz | NEBAP|work: it's not at all required for your local shared repository layout to match the remote one | 12:51 |
| NEBAP|work | I introduce the layout I want to have for the project, maybe I´m wrong with building it in bazaar | 12:51 |
| mzz | NEBAP|work: for example if the remote repository has /path/to/repo/trunk, /path/to/repo/branches/foo-feature, etc, it'd make perfect sense to put them in local/repo/remote/trunk, local/repo/remote/branches/foo-feature, etc | 12:52 |
| mzz | NEBAP|work: compared to (say) svn: a svn repository is much more like a bzr branch than a bzr repository. bzr repositories are normally purely an optimization | 12:52 |
| NEBAP|work | hmm | 12:54 |
| bob2 | multi-pull plugin | 12:55 |
| NEBAP|work | Can you checkout my preferred layout and tell me what each folder should be (e. g. branch or shared repository)?? http://pastebin.com/d496f0521 | 12:55 |
| NEBAP|work | I´ve started using bazaar for some private projects which worked very well | 12:56 |
| NEBAP|work | now I want to setup a bigger project in our company with bazaar | 12:56 |
| mzz | NEBAP|work: the bazaar manual documents the pros and cons of a handful of repository layouts. Have you read that bit? | 12:56 |
| NEBAP|work | yes | 12:57 |
| NEBAP|work | but there is no hint how to setup those layouts | 12:57 |
| NEBAP|work | the question is | 12:57 |
| vila | NEBAP|work: Both (MyProject) and (Module1, Module2) are good candidates for shared repos | 12:57 |
| mzz | NEBAP|work: unless your projects are pretty large you shouldn't worry too much about repository layout imoh | 12:58 |
| mzz | imho, even | 12:58 |
| NEBAP|work | is it useful for a developer to just use a branch (e. g. bzr branch .../MyProject/Module1/Branches/FeatureX; make changes and commit) | 12:58 |
| vila | the choice mostly depends on the expected volume, the safe bet is to use Module1, Module2 | 12:58 |
| * vila agrees with mzz | 12:58 | |
| NEBAP|work | so it´s ok to use some shared repos in a shared repo? | 12:59 |
| vila | NEBAP|work: you can, but be sure everybody understand the consequences | 12:59 |
| NEBAP|work | ^^ | 12:59 |
| NEBAP|work | what are the consequences? | 13:00 |
| NEBAP|work | I think I´ve understand the usage of a shared repository with some branches | 13:00 |
| vila | Unexpected use of 'MyProject' repository ? | 13:00 |
| vila | Or did you imply some other repos *below* ModuleN | 13:00 |
| NEBAP|work | yes | 13:01 |
| vila | NEBAP|work: let's forget about repos for a minute, | 13:01 |
| NEBAP|work | ok let me tell you about the functionality I want to have | 13:02 |
| vila | imagine that each branch stores the whole history of a project, each time you create a branch you copy that whole history to start with, and then each branch update its history, pull/push/merge occur, the histories are now different | 13:02 |
| NEBAP|work | using the layout I´ve posted before | 13:03 |
| NEBAP|work | I want to have a overall place where the hole project (all modules) are stored | 13:03 |
| NEBAP|work | to let a developer checkout all stuff in a single call (e. g. bzr checkout .../myproject) | 13:04 |
| vila | NEBAP|work: you can't right now | 13:04 |
| NEBAP|work | for each module I want to have a trunk storing the mainline of the project and a container for the branches to let a developer checkout a the trunk, create a feature branch under branches, commit to it and then merge it back to the mainline branch | 13:05 |
| NEBAP|work | hmm | 13:05 |
| NEBAP|work | is it possible to use a shared repository in a branch? | 13:06 |
| vila | NEBAP|work: A standalone branch use its own private repository | 13:06 |
| NEBAP|work | hmm | 13:06 |
| NEBAP|work | a shared repository is useful for the feature branches to use a common place to store the history and prevent the branches to keep a history themselfes, right? | 13:07 |
| vila | right | 13:07 |
| NEBAP|work | so the moduleX folder should be a shared repo | 13:07 |
| vila | I think so | 13:08 |
| NEBAP|work | ok | 13:08 |
| NEBAP|work | what is if I use a branch for the ProjectX folder? | 13:08 |
| NEBAP|work | which contains the shared repositories? | 13:08 |
| vila | :-) | 13:08 |
| NEBAP|work | the ProjectX folder doesn´t have to share the history | 13:08 |
| vila | NEBAP|work: you mean http://bazaar-vcs.org/NestedTreesDesign/ | 13:08 |
| NEBAP|work | because there is no code in the container folder :) | 13:08 |
| vila | NEBAP|work: define ProjectX | 13:09 |
| NEBAP|work | ProjectX is just a container for the ModuleX folders (shared repos) | 13:10 |
| NEBAP|work | but shouldn´t hold a common history | 13:10 |
| NEBAP|work | because Module1 and Module2 have nothing to do with each other | 13:11 |
| NEBAP|work | the only thing I can´t do in this layout is "bzr commit" in the ProjectX folder to commit each modules changes | 13:12 |
| NEBAP|work | right? | 13:12 |
| vila | right | 13:13 |
| NEBAP|work | here is my updated example http://pastebin.com/d63396cf8 | 13:14 |
| vila | NEBAP|work: that sounds a lot like a server layout though, developers don't have to fully mirror it | 13:14 |
| NEBAP|work | yes | 13:14 |
| NEBAP|work | but they can if they want :) | 13:14 |
| NEBAP|work | does this layout make sense? | 13:14 |
| vila | MyProject is not a branch, it's just a directory | 13:14 |
| vila | of course they can if they want | 13:15 |
| NEBAP|work | but does it make sense to set MyProject up as branch? | 13:15 |
| vila | but I suspect they don't want a copy of all feature branches even if they want all trunks | 13:15 |
| vila | not really, what will you put into it ? | 13:15 |
| NEBAP|work | to let developers do the following: "bzr branch .../MyProject" ? | 13:16 |
| NEBAP|work | to load the hole project | 13:16 |
| NEBAP|work | or doesn´t it work? | 13:16 |
| vila | no, that will not work | 13:16 |
| NEBAP|work | k | 13:16 |
| vila | but the developers can use the multi-pull plugin | 13:16 |
| vila | which address, I think, your need | 13:16 |
| NEBAP|work | my current layout looks similar to the posted but "MyProject" is just a folder and "Branches" is just a folder is that fine? | 13:16 |
| NEBAP|work | k | 13:17 |
| NEBAP|work | maybe they won´t need | 13:17 |
| NEBAP|work | but thank you for the hint :) | 13:17 |
| NEBAP|work | but now this is the layout on my server | 13:17 |
| NEBAP|work | what has a developer to do if he / she wants to start a new feature branch? | 13:17 |
| NEBAP|work | building up a local shared repository | 13:18 |
| vila | err, "similar..but...is that fine?" is quite a tricky question :) | 13:18 |
| NEBAP|work | ^^ | 13:18 |
| NEBAP|work | sorry, I´m not the best english speaker ;) | 13:18 |
| NEBAP|work | I just wanted you to ask if you think this layout is ok: http://pastebin.com/d3bed7893 | 13:19 |
| vila | mkdir MyProject ; cd My project ; bzr init-repo Module1 ; bzr branch <server_url>/MyProject/Module1/Trunk Module1/Trunk | 13:19 |
| NEBAP|work | ok | 13:20 |
| vila | yup, layout ok | 13:20 |
| NEBAP|work | so the developer has to setup a local branch :) | 13:20 |
| NEBAP|work | thank you | 13:20 |
| NEBAP|work | if I´m right, the developer shouldn´t use the --no-tree option as this doesn´t show the folders .. | 13:21 |
| vila | has to setup a local shared repo, yes, that's better if he intend to use several branches, but that's not required | 13:21 |
| NEBAP|work | k | 13:21 |
| vila | exact, the developer is *supposed* to work with the trees :-0) | 13:21 |
| NEBAP|work | but holding the trunk as a mirror and using some branches is "better" in a shared repository, because the history is just hold one time in the shared repo | 13:22 |
| NEBAP|work | ? | 13:22 |
| vila | It is more important when working disconnected from a central server but still not mandatory (ok, I will stop to mention the non-mandatory part from now :) | 13:22 |
| NEBAP|work | k :) | 13:23 |
| NEBAP|work | thank you alot | 13:23 |
| NEBAP|work | very helpful | 13:23 |
| vila | On a LAN, you care less about having a local mirror | 13:23 |
| vila | because your network bandwidth/latency may be better than your disk's :-) | 13:23 |
| NEBAP|work | it´s very hard to understand all the useful functions of bazaar in a short time ;) | 13:23 |
| NEBAP|work | hehe | 13:23 |
| NEBAP|work | yeah | 13:23 |
| vila | That's why we try to start from the workflow before chosing the layout, but it's not, oops | 13:24 |
| NEBAP|work | ^^ | 13:26 |
| NEBAP|work | I just want to setup the server layout at first to avoid problems later | 13:26 |
| NEBAP|work | loosing a history can be a very big problem .. | 13:26 |
| mzz | imho as long as you get what goes into what branch right you'll be mostly ok | 13:28 |
| mzz | that is: as long as you figure out if you want separate branches per project or need one branch containing multiple projects for some reason | 13:29 |
| NEBAP|work | hmm | 13:29 |
| * vila agrees with mzz | 13:29 | |
| mzz | you can reorganize at what level repositories live transparently, and to some extent move branches around on the filesystem too | 13:29 |
| mzz | splitting up or joining branches is much more of a headache | 13:29 |
| NEBAP|work | I´ve just seen the cool log entries if you using the feature branch layout | 13:29 |
| mzz | oh, yes, you definitely want feature branches | 13:30 |
| NEBAP|work | :) | 13:30 |
| mzz | but where on the fs those branches live is much less important | 13:30 |
| NEBAP|work | it´s just a few times more readable using this feature | 13:30 |
| NEBAP|work | ah k | 13:30 |
| mzz | it's just that any checkouts that are currently bound to them get upset if they move around | 13:31 |
| NEBAP|work | we´ve just used subversion before, bazaar gives us a bunch of new possibilities :) | 13:31 |
| mzz | (I forgot just how badly confused a non-lightweight checkout gets) | 13:31 |
| mzz | a heavyweight checkout can probably just be unbound if the branch it is bound to goes away, and an unbound branch doesn't care | 13:31 |
| mzz | so those filesystem paths don't matter that much, they don't make it into history (the branch nick does, but the full branch location shouldn't) | 13:32 |
| mzz | so if you change your mind on how you organize branches you'll have to deal with some temporary pain as people currently using them switch to the new location, but it won't show up in history | 13:33 |
| mzz | makes sense? | 13:33 |
| NEBAP|work | yes, I just hope I got you right :), as I said, I´m not the best english speaker .. | 13:34 |
| NEBAP|work | you mean that checkouts have problems if the corresponding server location changes? | 13:35 |
| mzz | I don't recall if heavyweight ones do. Let me try. | 13:35 |
| NEBAP|work | don´t think, because you can use the unbind function to let them stay standalone (imho) | 13:36 |
| vila | NEBAP|work: I you use plain branches, you won't run into the problems mzz mentioned | 13:36 |
| NEBAP|work | k | 13:36 |
| NEBAP|work | which type of branches does mzz use? | 13:36 |
| vila | lightweigth or heavyweigth checkouts I presume which allow an indirection between the working tree and the branch itself | 13:37 |
| mzz | a heavyweight branch will just unbind and rebind if the underlying branch moves | 13:38 |
| mzz | so that's not an issue (no more of one than when using regular branches, and you have to respecify the push/pull location) | 13:38 |
| === mrevell is now known as mrevell-lunch | ||
| mzz | lightweight branches get a bit upset | 13:39 |
| mzz | that's probably a bug, and there might be a workaround for it | 13:39 |
| NEBAP|work | hmm | 13:40 |
| mzz | my local setup is slightly odd (I store code in working-tree-less branches on a fileserver on my lan, and hack in lightweight checkouts on the local drive) | 13:41 |
| NEBAP|work | but all those problems are just present if I change the server location, right? | 13:41 |
| mzz | you might want to not duplicate that setup :) | 13:41 |
| NEBAP|work | ^^ | 13:41 |
| mzz | it's really a nonissue unless you use lightweight checkouts, and I should file a bug on those actually | 13:41 |
| mzz | if you use heavyweight checkouts or regular branches you can just tell bzr where the parent branch went if it moves | 13:42 |
| NEBAP|work | hmm I just want to use the a lightweight checkout to mirror the trunk in each module | 13:42 |
| NEBAP|work | k | 13:42 |
| NEBAP|work | ok, but server location shouldn´t change | 13:42 |
| NEBAP|work | so there should be no problem with my setup :) | 13:42 |
| mzz | lightweight branches you'd have to recreate, unless you're feeling adventurous and change the location in .bzr/branch/location (but that's pretty horrible) | 13:42 |
| NEBAP|work | ^^ | 13:43 |
| mzz | but I'm pretty sure that's just a bug and I should file it | 13:43 |
| NEBAP|work | yeah, should be possible to reroute the lightweight checkout like the heavyweight one | 13:43 |
| NEBAP|work | just one last question, should the developers in my layout store there branches on the server? | 13:44 |
| NEBAP|work | I think they should for backup reasons | 13:44 |
| vila | s/should/can/ they want to do that either for backup or because they are ready to share or because they want it to be reviewed before merging, etc | 13:45 |
| NEBAP|work | k | 13:45 |
| NEBAP|work | thank you both for your very good help | 13:45 |
| NEBAP|work | safed me a lot of time and probably a lot of trouble :) | 13:46 |
| vila | NEBAP|work: always happy yo help (tm) | 13:47 |
| NEBAP|work | :D | 13:47 |
| vila | s/yo/to/ | 13:48 |
| mzz | ah, interesting | 13:49 |
| mzz | NEBAP|work: https://bugs.launchpad.net/bzr/+bug/105192/comments/7 if you do want to use lightweight checkouts and end up rearranging | 13:50 |
| ubottu | Ubuntu bug 105192 in bzr "bzr bind should work for lightweight checkouts" [Undecided,Confirmed] | 13:50 |
| NEBAP|work | mzz thanks | 13:50 |
| NEBAP|work | I think most commercial projects / softwares can learn from the great support some open source projects offer .. | 13:51 |
| NEBAP|work | or better the communities behind those projects | 13:51 |
| NEBAP|work | one last question | 13:53 |
| NEBAP|work | if I want to create a branch of the trunk | 13:53 |
| NEBAP|work | should I create this branch from the server location of the trunk | 13:53 |
| NEBAP|work | or from my local trunk mirror? | 13:53 |
| NEBAP|work | the trunk mirror is a lightweight checkout from the server | 13:53 |
| vila | a lightweight checkout is *not* a mirror (at least, that's not what is generally called a mirror whose purpose is to avoid accessing the mirrored server) | 13:55 |
| vila | since in both cases you are accessing the server, it doesn't matter | 13:55 |
| NEBAP|work | ^^ | 13:55 |
| NEBAP|work | so I shouldn´t use the lightweight checkout for the mirror? | 13:56 |
| NEBAP|work | what should I use instead? | 13:56 |
| vila | a standalone branch | 13:56 |
| vila | and pull regularly | 13:56 |
| NEBAP|work | I´m trying to use the feature branch layout | 13:56 |
| NEBAP|work | ok | 13:56 |
| NEBAP|work | so make a branch from the server trunk | 13:56 |
| NEBAP|work | make the feature branch | 13:56 |
| vila | that's what *I* do | 13:56 |
| NEBAP|work | commit | 13:56 |
| NEBAP|work | merge the feature branch into the trunk mirror | 13:57 |
| NEBAP|work | and push the trunk mirror back on the server? | 13:57 |
| vila | haaaa, now you're exposing your workflow :) | 13:57 |
| NEBAP|work | ^^ | 13:57 |
| NEBAP|work | so you see, your help isn´t just wasted time ;) | 13:58 |
| vila | in that case you'b better keep your trunk as a lightweight checkout :) | 13:58 |
| NEBAP|work | k | 13:58 |
| NEBAP|work | so after commiting to the feature branch is just | 13:59 |
| vila | but don't call it a mirror and think about 'bzr update'ing it on a regular basis and especially before merging | 13:59 |
| NEBAP|work | s/is/I | 13:59 |
| NEBAP|work | just merge the feature branch in the trunk checkout | 13:59 |
| vila | right | 13:59 |
| NEBAP|work | and then commit the trunk checkout to send changes to the server | 13:59 |
| vila | yes | 13:59 |
| NEBAP|work | ah cool :) | 13:59 |
| NEBAP|work | but using push in a brunch doesn´t just overwrite the target, it does more like a commit, right? | 14:00 |
| vila | at worst you will run into diverged branches if someone else committed between your last update/pull and your commit | 14:00 |
| vila | push *add* revisions to the target putting both branches (local and remote) back in sync | 14:01 |
| NEBAP|work | hmm | 14:02 |
| NEBAP|work | so maybe is push more safe then using a lightweight checkout? | 14:02 |
| NEBAP|work | to use the send command (using a readonly branch on the server), have I to use a branch or a checkout? | 14:03 |
| mzz | a checkout of a readonly branch is itself pretty readonly | 14:04 |
| mzz | well, I guess there's --local, but if you want to commit I'd just use a plain old branch | 14:05 |
| NEBAP|work | ah ok, sound logically ^^ | 14:05 |
| NEBAP|work | ok | 14:05 |
| mzz | in fact generally when in doubt just use a plain old branch | 14:05 |
| NEBAP|work | thank you guys | 14:05 |
| NEBAP|work | ^^ | 14:05 |
| NEBAP|work | I just tried to use the cool send feature and run into some troubles | 14:06 |
| NEBAP|work | s/run/ran | 14:06 |
| vila | What do you want to use 'send' for ? | 14:06 |
| mzz | and yeah, who or what are you sending to? | 14:06 |
| NEBAP|work | to avoid problems when more people commit to the trunk, my idea was to make the trunk readonly and force the developers to send the changes to the "committer" which then, can also do some code review | 14:07 |
| vila | NEBAP|work: send needs a public branch and a submit branch | 14:08 |
| NEBAP|work | but in contrast it becames a very complex layout then, if I don´t want to lose the possibilty to backup the feature branches .. | 14:09 |
| vila | the submit branch is where your want the merge proposal to be applied, the public branch is where you will find revisions not included in the bundle if you need them | 14:09 |
| NEBAP|work | public branch -> read only on the server, submit branch? | 14:09 |
| NEBAP|work | ah ok | 14:10 |
| NEBAP|work | seems to be a bit hard with my layout ^^ | 14:10 |
| NEBAP|work | just an idea :) | 14:10 |
| NEBAP|work | thank you | 14:11 |
| === mrevell-lunch is now known as mrevell | ||
| bialix | hello jam | 14:39 |
| Tak | jelmer: ping | 14:40 |
| bialix | jam: thank you. | 14:51 |
| Tak | ok, so `bzr pull` from a branch of an svn repo fails with an unknown branch id | 15:30 |
| Tak | but `bzr rebase` gives "Base branch is descendant of current branch. Pulling instead" and succeeds | 15:31 |
| vila | jam: += 1 in pyx ? What pyrex version are you using :-D | 15:42 |
| jam | vila: 0.9.8.5 | 15:52 |
| jam | I'll certainly fix those for landing | 15:52 |
| jam | anyway, I'm in-and-out, (mostly out) this morning because my son is sick again | 15:53 |
| jam | If you want, you can call my cell phone right now | 15:53 |
| vila | :-/ | 15:53 |
| jam | I'll have 30min or so to talk | 15:53 |
| vila | jam: I'm reviewing your rework-annotate proposal | 15:53 |
| jam | sure | 15:53 |
| jam | I thought you might want to talk directly about it | 15:53 |
| flutherben | Hi all--I have a question: Is there a way to make the output of "bzr revno" not show the progress bar and all the download statistics? | 16:11 |
| beuno | flutherben, maybe if you add -q? | 16:12 |
| flutherben | Thanks, beuno, I tried --quiet, didn't seem to do it | 16:13 |
| flutherben | I think it's some kind of global bzr setting | 16:13 |
| beuno | flutherben, then you will likely have to do it through python to avoid getting a progress bar | 16:14 |
| mzz | iirc there's some magical env var to disable progress bars | 16:16 |
| mzz | sec | 16:16 |
| * beuno does not know the encantation | 16:16 | |
| beuno | vila, hi :) | 16:16 |
| mzz | BZR_PROGRESS_BAR=something, I think, sec | 16:17 |
| mzz | of course I'm not getting any progress bar on "bzr revno" anyway. Hmm, what gets me a progress bar | 16:18 |
| flutherben | it's only since I moved to 1.16 | 16:18 |
| flutherben | now I'm seeing a bug about "not respecting BZR_PROGRESS_BAR", though it's not clear what the options are yet | 16:18 |
| mzz | hmm, yes. | 16:19 |
| mzz | the one function looking at BZR_PROGRESS_BAR is marked deprecated | 16:19 |
| mzz | err, or maybe not. sec. | 16:19 |
| mzz | "bzr help configuration" still documents BZR_PROGRESS_BAR | 16:20 |
| flutherben | hmmm, what's strange it is only seems to be happy on my server, though it's the same version of bzr | 16:24 |
| awilkins | Holy dungbeetle, verterok, bzr-hudson makes Maven download lots of stuff | 16:35 |
| vila | hi beuno :) | 16:36 |
| verterok | awilkins: yes, hudson plugins download a lot of stuff :) | 16:36 |
| awilkins | Bah, no bzr-java-lib | 16:36 |
| * awilkins sets up a Hudson job for that too | 16:37 | |
| verterok | awilkins: bzr-java-lib? btw, some changes landed in bzr-java-lib trunk, now it's using commons-logging | 16:37 |
| flutherben | I can't find any way to turn it off (the BZR_PROGRESS_BAR) | 16:40 |
| vila | flutherben: 'BZR_PROGRESS_BAR=none bzr revno' should work | 16:40 |
| flutherben | doesn't work | 16:40 |
| vila | which bzr version ? | 16:41 |
| flutherben | 1.16.1 | 16:41 |
| flutherben | http://dpaste.com/64136/ | 16:42 |
| vila | flutherben: fixed in bzr.dev, will be part of bzr 1.17 | 16:42 |
| flutherben | ah, that explains it | 16:42 |
| flutherben | thanks | 16:42 |
| vila | there was bug #321935 and bug #339385 at least, both are fixed | 16:43 |
| ubottu | Launchpad bug 321935 in bzr "[master] Progress bar leaves artifacts in output" [High,Fix released] https://launchpad.net/bugs/321935 | 16:43 |
| ubottu | Launchpad bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [High,Fix released] https://launchpad.net/bugs/339385 | 16:43 |
| flutherben | alright, I guess it's time I move to the dev version | 16:51 |
| CalicoJck | hello, i was hoping someone might be able to point me in the right direction here...i'm trying to integrate to a subversion server that doesn't have a consistent repository layout. Depending on which subtree of the repository you are in, branches and tags exist in different locations (or sometimes not at all). Is there a way to specify the repository layout in subversion.conf for different subtrees of the same subversion repository? | 17:03 |
| flutherben | Great, using the dev version, now it works | 17:04 |
| flutherben | thanks | 17:04 |
| flutherben | also, is bzr co --lightweight the fastest way to get a copy of a branch? | 17:05 |
| exarkun | Can I specify a custom Python function implementing a merge algorithm to be applied to files which match a particular pattern? | 17:05 |
| beuno | flutherben, you just want a working tree? | 17:05 |
| flutherben | yeah | 17:05 |
| beuno | if so, maybe "bzr branch BRANCH --stacked" is faster. Not sure | 17:05 |
| flutherben | cool, thx | 17:05 |
| === thekorn_ is now known as thekorn | ||
| huf | hi. what's the best way to backup a bzr repo? | 19:07 |
| huf | just copy the files as they are? | 19:07 |
| huf | or is there some command i can use that converts to a more future-proof format? | 19:07 |
| beuno | huf, I just rsync .bzr | 19:08 |
| beuno | bzr isn's very nice to rsync, but it works | 19:09 |
| knielsen | abentley: someone suggested I ask you about https://bugs.launchpad.net/bzr/+bug/375898 ... any ideas? It's been sitting for about two months, it is a case where repo gets basically corrupt/unusable due to bzr merge crashing, there is a reproducible test case ... | 20:19 |
| ubottu | Ubuntu bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [Medium,Triaged] | 20:19 |
| knielsen | I'm asking, as it is somehow blocking our merging of PBXT into MariaDB ... | 20:20 |
| knielsen | jam: ^^^ your name was also suggeste :) | 20:21 |
| abentley | knielsen: Problems like that are quite subtle, so I have no idea how easy or hard it would be to fix. | 20:22 |
| knielsen | abentley: hm, really? | 20:22 |
| knielsen | abentley: well, I agree the test case is far from minimal :-( probably >50k commits | 20:22 |
| knielsen | and not at all clear how to reduce it | 20:23 |
| abentley | knielsen: I'm not sure how to respond. | 20:24 |
| knielsen | abentley: no worries, I think you responded fine, the issue has been looked at, but the root cause is not known .... | 20:25 |
| knielsen | that means probably that we should look into an alternative way to solve the problem, as a fix is not likely to appear soon. Maybe we will have to track merging manually, which ought to avoid the problem | 20:26 |
| alecwh | Hi, I want to branch my code to work on a site redesign. In git, all I do is "git branch feature_x" (where feature_x would be the experimental feature) in the working directory, and then "git branch" to see which one I'm currently "on". Then I want to merge my branch back in when I'm done with the site redesign. how do I do this in bzr? | 20:29 |
| knielsen | abentley: It does worry me somewhat so see repository corruptions like this, was quite fortunate that I happened to test that particular merge before pushing into our main repository and potentially having to roll back lots of commits | 20:29 |
| Peng_ | alecwh: "bzr branch" and "bzr merge". It's just that it's more equivalent to "git clone". | 20:30 |
| abentley | knielsen: This is not a repository corruption. It's all to do with merge and the working tree. | 20:30 |
| knielsen | abentley: hm... are you saying you can see from the bug that the branch is ok, and once the bug in bzr is fixed, the merge could complete? | 20:31 |
| alecwh | Peng_: when I do this in bzr, inside my working directory, it says, "bzr: ERROR: Not a branch: "/var/www/redesign/"." (from this command: bzr branch redesign) | 20:31 |
| Peng_ | alecwh: bzr help branch :P | 20:31 |
| alecwh | Peng_: good point, thanks. =) | 20:31 |
| abentley | knielsen: I am saying there's no reason to suspect this is anything other than a bug in merge. | 20:31 |
| Peng_ | alecwh: cd .. && bzr branch $OLDPWD redesign && cd redesign | 20:32 |
| Peng_ | alecwh: :D | 20:32 |
| knielsen | abentley: ok, thanks for your help! | 20:32 |
| alecwh | Peng_: Thanks, I'll be sure to check the docs next time. | 20:32 |
| alecwh | Does bazaar support topic branching (like git's "branch feature_x")? | 20:40 |
| dash | alecwh: sure. 'bzr branch oldbranch/ newbranch' | 20:40 |
| SamB | git doesn't support topic branching in particular -- it just supports branching | 20:41 |
| SamB | more-or-less correctly | 20:41 |
| Peng_ | alecwh: Bazaar just doesn't support having multiple branches in the same directory. | 20:41 |
| alecwh | dash: no, I don't want bzr to create another physical branch. With git, I can do a "git branch" and it will show me what branch I am currently on, and then I can switch to one very easily without navigating directories. | 20:42 |
| SamB | how you use it is your bussiness | 20:42 |
| alecwh | Peng_: ah, dang. | 20:42 |
| Peng_ | (Well, you can sort of do it with a lightweight checkout and "bzr switch", but...) | 20:42 |
| SamB | alecwh: I usually use a repo dir full of treeless branch directories in parallell with a lightweight checkout of one of them | 20:42 |
| dash | weird | 20:42 |
| Peng_ | I'm lazy. I just have lots of trees sucking disk space. :D | 20:42 |
| dash | same here | 20:43 |
| Peng_ | I usually "bzr remove-tree" them when I'm done, at least on the larger projexts. | 20:43 |
| RenatoSilva | join #launchpad | 21:24 |
| RenatoSilva | verterok: hi | 21:53 |
| RenatoSilva | clear | 21:53 |
| verterok | RenatoSilva: hi | 21:54 |
| RenatoSilva | verterok: I've written the other test... | 21:55 |
| RenatoSilva | verterok: they're running ok for me | 21:56 |
| verterok | RenatoSilva: thanks!, I have the email in my TODO queue, just that I wasn't hable top take a look yet, I think in a few hours (after my "work day") | 21:56 |
| RenatoSilva | verterok: ok | 22:09 |
| flutherben | I was moving hard drives, and I copied over a bzr directory, and now when I commit I'm seeing "aborting commit write group: NoSuchId" | 22:41 |
| flutherben | any simple way to fix this? | 22:42 |
| LarstiQ | flutherben: could you paste the traceback? | 22:45 |
| flutherben | http://dpaste.com/64303/ | 22:46 |
| LarstiQ | interesting | 22:46 |
| LarstiQ | flutherben: the ~/.bzr.log should have a fuller traceback | 22:47 |
| LarstiQ | flutherben: what does `bzr info` say? | 22:47 |
| flutherben | ah | 22:47 |
| * LarstiQ wild guess would be that it's a branch without its repository | 22:47 | |
| flutherben | bzr info is pointing to a renamed home repository | 22:47 |
| flutherben | can I re-brand this brand to a new repo? | 22:48 |
| LarstiQ | depends on what is going on | 22:48 |
| flutherben | ok, I'll paste the output | 22:49 |
| LarstiQ | if I'm right, then no, because the branch's revisions are not in the repo it is finding | 22:49 |
| flutherben | this is the output from bzr-info: | 22:49 |
| flutherben | http://dpaste.com/64306/ | 22:49 |
| flutherben | (and panda-mirror has been renamed to panda-trunk | 22:49 |
| flutherben | but it's a new hard drive | 22:50 |
| flutherben | so it's not the exact same tree | 22:50 |
| flutherben | and here's my bzr.log | 22:51 |
| LarstiQ | right, so it is using a shared repository | 22:54 |
| LarstiQ | flutherben: do you know which repository it was using on the old harddrive? | 22:54 |
| flutherben | yeah, and I still have access to it | 22:54 |
| flutherben | panda_mirror | 22:54 |
| flutherben | er, panda-mirror | 22:55 |
| LarstiQ | so if you cp -a this branch there, does it give the same error? | 22:57 |
| flutherben | lemme see | 22:58 |
| flutherben | I'd prefer to use this new repository, but that would actually be fine | 22:58 |
| flutherben | hold on | 22:58 |
| LarstiQ | just trying to confirm my suspicions | 22:59 |
| LarstiQ | flutherben: how did you copy this branch over from the old to the new one? | 22:59 |
| flutherben | I just copied it (using os x finder) from the old repo into the new repo | 22:59 |
| flutherben | seems kinda foolish when I think about it now | 22:59 |
| flutherben | but the repos are both checkouts of the same branch | 23:00 |
| LarstiQ | flutherben: yeah, I thought that might be the case. | 23:00 |
| LarstiQ | flutherben: repo != branch | 23:00 |
| flutherben | yeah, that makes sense | 23:00 |
| LarstiQ | flutherben: the repository is what contains the actual revisions, a branch just references them | 23:00 |
| LarstiQ | flutherben: so if you copy a reference to a place that doesn't have the actual data, boom | 23:01 |
| === RAOF__ is now known as RAOF | ||
| LarstiQ | flutherben: using `bzr branch` instead of os cp would prevent that from happening | 23:01 |
| flutherben | got it | 23:01 |
| flutherben | lemme try and move it back to the old repo | 23:01 |
| flutherben | check in there | 23:01 |
| flutherben | and then bzr branch it in | 23:02 |
| flutherben | ok, moving it and committing worked | 23:05 |
| flutherben | I'm getting confused about the bzr branch command | 23:05 |
| flutherben | is it bzr branch old_dir new_dir? | 23:05 |
| flutherben | and it will just know to switch repos? | 23:05 |
| flutherben | wow, it all just worked | 23:09 |
| flutherben | thanks a lot, LarstiQ | 23:09 |
| flutherben | I was about to start manually changing things | 23:09 |
| flutherben | great! | 23:09 |
| LarstiQ | flutherben: yes, it will know about which repos to use | 23:10 |
| LarstiQ | flutherben: pleased to be of help | 23:11 |
| LarstiQ | flutherben: in the future, please don't cp/mv branches out of their repositories, but either copy the repository too or use `bzr branch` :) | 23:11 |
| flutherben | yeah, for sure | 23:11 |
| === beaumonta is now known as abeaumont | ||
| lifeless | bbs | 23:36 |
| poolie | good morning | 23:58 |
| LarstiQ | moin poolie | 23:59 |
| poolie | i'm hoping to fix the rest of bug 391411 and other stacking issues today | 23:59 |
| ubottu | Launchpad bug 391411 in bzr "want "reconfigure --unstacked" or --stacked-on" [High,In progress] https://launchpad.net/bugs/391411 | 23:59 |
| poolie | hi LarstiQ | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!