| === mnepton is now known as mneptok | ||
| poolie | hello igc | 00:01 |
|---|---|---|
| chalkbag_ | Hey folks, is there a way to rewrite author info on locally committed revisions? I got the email wrong there... | 00:06 |
| chalkbag_ | I tried bzr rebase but it doesn't seem to allow that, it looks like it only reapplies the local changes to the tip of the parent tree | 00:06 |
| spiv | chalkbag_: perhaps the bzr-fastimport plugin can help. You could fast-export the revisions, edit the export and then import it again. | 00:11 |
| spiv | chalkbag_: I think the fast-import-filter command may even support rewriting authors directly. | 00:12 |
| chalkbag_ | Ah, interesting - I was actually wondering if there was a way to create smth like a change set of diffs ala git. bzr send seems to be creating a monolitic diff of everything that changed and doesn't preserve individual commits - unless I missed something there | 00:12 |
| spiv | chalkbag_: bzr send will preserve the individual commits | 00:13 |
| spiv | chalkbag_: but as a blob that you can't really edit. | 00:13 |
| chalkbag_ | really? How do I "replay" them? I tried "bzr patch" but is seems to have applied them all at once - will I see individual revisions after I commit? | 00:14 |
| chalkbag_ | So I assume it'll preserve author info as well, right? If not, I can just reapply the patch after changing my email in the config... | 00:14 |
| james_w | chalkbag_: bzr merge or bzr pull | 00:15 |
| bob2 | there's the bzr-rewrite plugin, too | 00:15 |
| chalkbag_ | bob2 - yeah, I tried that one, it's not like git's rebase, i.e., it won't really let me change anything in the commits, it just reapplies them at the tip as far as I can tell | 00:16 |
| chalkbag_ | james_w - I'm not sure I understand how merge/pull would help me? | 00:17 |
| spiv | chalkbag_: you can "bzr merge"/"bzr pull" from the file that "bzr send" outputs. | 00:18 |
| james_w | chalkbag_: that's how you apply what bzr send creates, but you are right that it won't help solve your problem | 00:18 |
| chalkbag_ | Hmm, and it won't preserve the author info? That might indeed be the easiest way to do that then | 00:19 |
| chalkbag_ | Let me give it a quick try :p | 00:19 |
| chalkbag_ | yeah, merge wrote the merge commit with my new author info but whatever it merged contains the original email. I guess I'll have to play with fast-import then... | 00:35 |
| bob2 | do you care that much? | 00:36 |
| chalkbag_ | Not too much but it looks like people on launchpad seem to be using real email addresses and all I've got is smth like foo@mylaptop :( | 00:37 |
| chalkbag_ | I should've thought about that before doing the commits but I expected this would be something quite easy to change later on - I guess I got spoiled by git :o | 00:38 |
| chalkbag_ | besides, it sounds like a challenge of sorts :p | 00:38 |
| chalkbag_ | ok, it looks like fast-export/import should do that, fast-import-filter has an example for rewriting user ids in the --help | 00:40 |
| chalkbag_ | thanks folks! | 00:41 |
| poolie | spiv, re bug 503878, i thought we now did better than TooManyConcurrentRequests when the server dropped the connection | 00:53 |
| ubottu | Launchpad bug 503878 in bzr ""Too many concurrent requests" error during reconcile" [Undecided,New] https://launchpad.net/bugs/503878 | 00:53 |
| spiv | poolie: often, although I see that bzrlib/reconcile.py has a "try: ... finally: collection._unlock_names()" which is what's been tripped here. | 00:56 |
| spiv | poolie: i.e. an unconditional attempt to perform a cleanup over the network even if the network connection has gone away. | 00:57 |
| poolie | right | 00:57 |
| spiv | I'll put together a simple fix for that for trunk. | 00:57 |
| poolie | oh ok | 00:58 |
| poolie | i'll reopen it | 00:59 |
| Akilla | Hey, all, quick question. We're using BZR to make local changes to a public SVN repo. So, we need to maintain the ability to both update from the public SVN server and make our own loacl cchanges with BZR. Some aspects of tihs work fine, but when we try to do individual file commands (i.e. remove) it tries to access the SVN server. Is there any way to disable the SVN functionality of the bzr binaries so that it will just perform B | 01:02 |
| poolie | Akilla: so you have one working tree that's both a svn checkout (controlled by svn) and a bzr checkout (controlled by bzr?) | 01:07 |
| mwhudson | jelmer: hello, did you see http://launchpadlibrarian.net/37520409/squeezebox-7.5-log.txt ? | 01:12 |
| Akilla | yeah... turns out tortoisebzr had a subversion integration installation option. | 01:12 |
| Akilla | just reinstalled adn rebooted and now i'm getting different errors that look like it's trying to actually access the bzr repo. | 01:13 |
| Akilla | yeah, apparently this is just a user error as a result of a default option in the tortoisebzr installer. | 01:17 |
| Akilla | ignore me. :) thanks! | 01:17 |
| === kirkland` is now known as kirkland | ||
| GungaDin | hi | 01:40 |
| GungaDin | I have an old repo (bzr version 1.xx), and now I'm using bzr 2.0.2 and I keep getting bzr: "ERROR: No repository present: "file:///home...." when I'm trying to do something... | 01:41 |
| GungaDin | any ideas what the problem might be? | 01:41 |
| * igc lunch | 01:43 | |
| Peng | GungaDin: Just for fun, try "bzr --no-plugins info" or whatever. | 01:49 |
| Peng | GungaDin: Aside from that, upgrading bzr won't break anything. So, most likely there's no repo present... | 01:50 |
| GungaDin | there always has been... | 01:50 |
| Peng | Well, there have been a couple changes, but if they break anything, it should be pretty obscure. | 01:50 |
| GungaDin | I can see the .bzr dir | 01:50 |
| Peng | GungaDin: OK, but what about .bzr/repository? | 01:50 |
| Peng | GungaDin: And what does "bzr info" say? | 01:50 |
| GungaDin | same error | 01:50 |
| Peng | GungaDin: Oh oh. Did you try to "bzr upgrade"? Does .bzr/repository.backup or backup.bzr exist? | 01:51 |
| GungaDin | no | 01:51 |
| Peng | GungaDin: Did you do "bzr reconfigure" or anything else? | 01:51 |
| GungaDin | bzr upgrade gives the same error | 01:51 |
| GungaDin | no | 01:51 |
| Peng | Erk. Not what I meant! | 01:51 |
| Peng | I was asking if you had run "bzr upgrade", not saying you should. Oh well, doesn't matter. | 01:52 |
| Peng | Whoops. | 01:52 |
| GungaDin | should I try bzr reconfigure? | 01:52 |
| GungaDin | any ideas? | 01:55 |
| maxb | GungaDin: Perhaps you could pastebin the output of 'find path/to/that/.bzr' | 01:55 |
| GungaDin | http://pastebin.com/d30ca28ad | 01:58 |
| maxb | So, that's a branch with no repository internally, so it must be expecting to find a shared repository in a parent directory's .bzr | 02:00 |
| maxb | If there is no such repository, then directories have been moved around on disk in a way which has broken things | 02:01 |
| === mlh_ is now known as mlh | ||
| GungaDin | but I haven't moved anything... | 02:11 |
| GungaDin | shit... | 02:11 |
| GungaDin | something must have happened here... | 02:11 |
| GungaDin | I'm getting this with pretty much all my branches :S | 02:11 |
| Peng | GungaDin: Maybe you accidentally had a shared repo very high up, e.g. /.bzr, /home/.bzr or /home/you/.bzr. | 02:12 |
| GungaDin | *sigh* | 02:13 |
| GungaDin | could be... | 02:13 |
| jdub | what up bzroes! | 02:51 |
| jdub | i have an http smart server issue | 02:51 |
| jdub | after 10 successful POSTs to .bzr/smart, i get a timeout... | 02:52 |
| jdub | i have just upped my proxy timeout to 300s | 02:52 |
| jdub | and trying it again, but it looks like it's going to fail | 02:53 |
| jdub | (the smart server is loggerhead behind nginx with http auth) | 02:53 |
| spiv | jdub: hmm, what smart request, do you know? | 02:53 |
| spiv | jdub: (run the client with -Dhpss and peek in ~/.bzr.log) | 02:54 |
| jdub | will do | 02:54 |
| jdub | aha! | 02:54 |
| jdub | was waiting for a timeout | 02:54 |
| jdub | but the client had actually already returned (nothing in logs) | 02:54 |
| jdub | bzr: ERROR: Could not acquire lock "(remote lock)": | 02:55 |
| jdub | should i try break-lock first? | 02:55 |
| spiv | jdub: ah, yeah, probably | 02:56 |
| spiv | jdub: this is a 'bzr push'? | 02:56 |
| jdub | yeah | 02:56 |
| jdub | ok, i broke the lock | 02:56 |
| jdub | trying again | 02:56 |
| spiv | jdub: my random speculation would be that that insert_stream request might be very large, and would arrive as a single POST — it should be streamed gradually (maybe after a small initial pause), but depending on the various HTTP server bits it's easy to see how that might timeout or cause issues. | 02:57 |
| jdub | rock, that worked | 02:57 |
| spiv | Ah, good :) | 02:57 |
| jdub | so the biggest POST of about 15 that time was 15078 | 02:58 |
| spiv | Oh, pfft :) | 02:58 |
| jdub | is there an "i'm waiting patiently for this lock to go away" delay? | 02:59 |
| spiv | 300 seconds, I think, I don't remember the precise circumstance. | 02:59 |
| jdub | heh | 02:59 |
| spiv | The server won't delay, though (unless your server has a very old bzr!) | 03:00 |
| jdub | 2.0.3 | 03:00 |
| jdub | and was previously running 2.0.2 | 03:00 |
| spiv | I don't think the client will via HPSS either (unless maybe if it's fallen back to non-smart VFS methods for some reason) | 03:00 |
| jdub | (before i restarted loggerhead) | 03:00 |
| spiv | Ok, that's not even close to what I meant by "very old" :) | 03:00 |
| spiv | So, not sure why there was a delay for you. | 03:01 |
| jdub | 8) | 03:01 |
| poolie | hi jdub | 03:06 |
| jdub | yo poolie | 03:09 |
| jdub | poolie: will you be in welly? | 03:10 |
| poolie | hi | 03:10 |
| poolie | no, i have clashing travel | 03:10 |
| jdub | nooooooo | 03:10 |
| poolie | so did you work out your issue with the delay? | 03:10 |
| poolie | i'd probably try stracing the server subprocess | 03:11 |
| poolie | and perhaps put that into a bug | 03:11 |
| jdub | poolie: well, until i cranked up the proxy timeout, it didn't have enough time to tell me about the lock | 03:11 |
| jdub | poolie: once the lock was broken, it worked fine | 03:11 |
| jdub | that it took so long to report about the lock is a bit worrying though | 03:12 |
| poolie | it is | 03:12 |
| poolie | so it would be nice to know what it was doing for all that time | 03:12 |
| jdub | can i just touch a file to create a stray lock? | 03:13 |
| poolie | it needs to be a directory called 'held' containing a file called 'info' | 03:18 |
| poolie | i think the file can be empty, at least for your purposes here | 03:19 |
| === pickscrape_ is now known as pickscrape | ||
| spiv | jdub: python -c "from bzrlib.bzrdir import BzrDir; branch = BzrDir.open($URL).open_branch(); branch.lock_write(); branch.leave_lock_in_place()" | 03:23 |
| spiv | jdub: you'll need to use break-lock to tidy up afterwards, of course. | 03:23 |
| poolie | spiv, re bug 504102 | 03:34 |
| ubottu | Launchpad bug 504102 in bzr "test_format_initialize_find_open has some isolation problems" [High,In progress] https://launchpad.net/bugs/504102 | 03:34 |
| poolie | can you tell me off hand when the network_name should be set in a remotebzrdirformat? | 03:34 |
| spiv | poolie: as soon as it is known, IIRC. | 03:35 |
| spiv | poolie: it varies by circumstance a little, I think, which makes it confusing. | 03:36 |
| poolie | and so either initializing a bzrdir, or doing find_format on an existing one ought to set it? | 03:36 |
| spiv | I think so, yes. | 03:36 |
| igc | hi poolie | 04:08 |
| igc | poolie: can we make Sphinx a dependency for 2.1 packagers? | 04:09 |
| igc | poolie: I'd like to drop the old pure-rest docs because ... | 04:09 |
| igc | supporting them breaks some things in Sphinx (e.g. PDF generation of the User Reference) | 04:09 |
| jam1 | hey igc | 04:12 |
| === jam1 is now known as jam | ||
| igc | hi jam! | 04:12 |
| igc | Happy New Year | 04:12 |
| jam | So did I read correctly that you may show up in Strasbourg? | 04:13 |
| igc | jam: maybe - I need to chat to poolie about it | 04:14 |
| jam | igc: well, so far I still need to find out if *I'm* going | 04:14 |
| jam | my wife has a potential trip around the same time, which she should find out about tomorrow | 04:14 |
| poolie | hello igc | 04:17 |
| poolie | igc, the non-sphinx things do make things a bit more confusing too | 04:17 |
| poolie | there are some index.txts that don't go into the sphinx stuff | 04:17 |
| poolie | you can do what you think best | 04:17 |
| igc | poolie: thanks | 04:17 |
| poolie | i'll also mention, though it's not super urgent, the bug asking for rest->texinfo translation | 04:17 |
| igc | I'll email the list anyway asking for objections | 04:18 |
| poolie | apparently jam looked and there is a tool but it doesn't completely work | 04:18 |
| poolie | shall we talk now? | 04:18 |
| igc | as in on phone? | 04:18 |
| poolie | if you like | 04:18 |
| poolie | or here | 04:18 |
| spiv | Yeah, I've been tripped up by two slightly different doc generation systems, so it would be nice if it were just Sphinx. | 04:18 |
| igc | either is good by me | 04:18 |
| spiv | I think I wanted to use some sort of link to another doc that Sphinx supports, but it turned out that the pure-rest stuff didn't. | 04:19 |
| jam | igc, poolie: yeah, getting to texinfo is tricky, and texinfo likes to have "type" info that we wouldn't have | 04:19 |
| jam | (code vs variable vs etc that all generate fixed-width output) | 04:19 |
| jam | spiv: yeah, I'm a bit surprised plain rest doesn't let you link via a '.txt' and then have that translated to a '.html' link when necessary | 04:20 |
| Guest56789 | ALGUIEN ABLA ESPAÑOL | 04:31 |
| === Guest56789 is now known as ADAN | ||
| poolie | igc, https://edge.launchpad.net/software-center has mvo with the most karma | 04:45 |
| poolie | spiv, don't forget as pilot you can nag other people for a second review | 05:53 |
| poolie | or even when not a pilot :) | 05:53 |
| spiv | poolie: sure, but it's not really worth it for a one-liner :) | 05:53 |
| poolie | yeah i know | 05:53 |
| poolie | just meant in general | 05:53 |
| spiv | Fair enough. | 05:53 |
| poolie | but also, i really like the way you're handling them | 05:54 |
| poolie | that was nicely put | 05:54 |
| vila | hi all ! | 07:01 |
| vila | hmm, I haven't realized that MPs now present the post-review commits in the comments, nice. The sugar on top would be a button to present the associated diff :) | 07:02 |
| jml | locked 145 hours, 58 minutes ago | 07:03 |
| jml | niiiice. | 07:03 |
| jml | vila, you can click on the revno to get the diff | 07:03 |
| vila | ooh, but they are ! revnos are clickable and show just that ! | 07:03 |
| vila | jml: hehe | 07:03 |
| jml | 145 hours ago is not a helpful number | 07:04 |
| vila | I just love those moments where you think: "IWBN if they put it here... try... it works !" | 07:04 |
| jml | (the rule is, if your number makes people want to do arithmetic, it's the wrong number) | 07:04 |
| spiv | jml: sure it is, it means "less than one week"... doesn't everyone know that a week is 168 hours (and that a day is 86400 seconds...)? | 07:05 |
| vila | spiv: wrong, may French still think a week is 35 hours :-D | 07:07 |
| vila | s/may/many/ | 07:07 |
| * vila always made typos in jokes :-/ | 07:08 | |
| jml | vila, :D | 07:10 |
| * igc dinner | 07:10 | |
| spiv | vila: hah | 07:11 |
| vila | spiv: in case things happen without further warnings: enjoy your new life as a dad ! It's certainly one of the most exciting experience in life :-) | 07:29 |
| spiv | vila: thanks! | 07:30 |
| MFen | have a conceptual question | 07:55 |
| MFen | i have a branch of lp:txgenshi, call it O for original. i also have three branches working on different features for it | 07:56 |
| MFen | call them A, B, and C. they build on each other in that order (B contains changes from A, C contains changes from B) | 07:56 |
| MFen | i'm currently working on *B*. however i need changes from C. how do i do that without just making B and C the same? | 07:57 |
| MFen | i want it to be possible to review B without looking at the changes in C | 07:58 |
| MFen | does stacking help me out in any way with this? | 07:58 |
| Peng | No. | 07:58 |
| Peng | Wellll, if you're using Launchpad's review system, when filing the merge proposal for B, you can set C as a prerequisite; then the diff will be against C, so you'll only see B's changes. | 07:59 |
| Peng | Well, I don't know what exactly the diff will be against, but that's the end result. | 08:00 |
| MFen | but that'll be circular. B is already a prerequisite for C | 08:01 |
| spiv | MFen: do you need all of C in B? | 08:03 |
| MFen | probably, yeah | 08:03 |
| MFen | B is a bugfix. C is unit tests. they were opened as separate bugs. i want to add unit tests for the bug fix, but the unit tests didn't exist before I made C | 08:04 |
| spiv | So you really want to the ordering to be A, C, B, rather than A, B, C? | 08:04 |
| Peng | You could add B's unit tests in C. | 08:04 |
| MFen | um. maybe! C hasn't been reviewed yet, though. what if i need to make changes to C after that? | 08:04 |
| Peng | Then C would need B, but B would not need C. | 08:04 |
| MFen | i don't understand what stacking does, if it doesn't allow me to segregate my changes | 08:05 |
| spiv | MFen: stacking is a storage and network transfer optimisation, not a semantic difference. | 08:05 |
| MFen | crap. | 08:05 |
| spiv | MFen: so it allows you to push up just the changes unique to a branch, and say in that branch "you'll find the rest of the history over *there*". | 08:06 |
| MFen | so basically C is B plus some changes. therefore it doesn't make any sense to talk about making changes to B that aren't part of C | 08:06 |
| MFen | right | 08:07 |
| spiv | Hm, I'm having trouble following you. One moment it seems that you say B is meant to contain all of C's changes (and history), then the next you say it's the other way around. | 08:07 |
| MFen | it's both. i *want* to be able to make changes to either one without impacting the other | 08:08 |
| spiv | I guess the question to ask is "what do you want to present to the reviewers?"? | 08:08 |
| MFen | otherwise none of this makes any sense, workflow-wise | 08:08 |
| MFen | it's not just a question of what i present to the reviewers | 08:08 |
| MFen | that only matters if we all assume my changes are perfect | 08:08 |
| MFen | if there are any changes needed post-review, then i need to make them in both places | 08:09 |
| spiv | Well, if your changes are assumed to be perfect, you wouldn't need reviewers ;) | 08:09 |
| MFen | which means "why did i make two branches in the first place" | 08:09 |
| spiv | Well, | 08:09 |
| spiv | if say the branches are ordered A,B,C, and you need to make post-review changes to B... | 08:10 |
| spiv | Then the change you'd make in C, if it is important that C is kept current with those changes, is just a merge from B. | 08:11 |
| lifeless | MFen: you ask 'without making B and C the same' - merge B to C regularly. Don't merge C to B ever. | 08:11 |
| lifeless | MFen: then they won't be the same. | 08:11 |
| spiv | Which might not impact things like the diff of C vs. B at all. | 08:12 |
| MFen | lifeless: if i do that, won't the reviewer reviewing C be looking at the changes from B? | 08:12 |
| lifeless | MFen: depends on how they review | 08:12 |
| spiv | MFen: not if the reviewer is reviewing C with respect to B. | 08:12 |
| lifeless | if they look at (B, C] then they get only stuff new to C | 08:12 |
| lifeless | if they look at (trunk, C] then they get all of A,B,C | 08:12 |
| MFen | well, let's assume they're using lp's diff view | 08:13 |
| spiv | MFen: i.e. assume B as a pre-requisite that is being reviewed separately (Launchpad's review system has good support for this) | 08:13 |
| lifeless | MFen: lp's diff view? do you mean loggerhead? | 08:13 |
| MFen | hells if i know. i made a merge request, and i see a diff button. | 08:13 |
| lifeless | MFen: more precisely, gimme a url to be clear about what you mean. | 08:13 |
| MFen | https://bugs.launchpad.net/txgenshi/+bug/502821 green diff link | 08:13 |
| MFen | that is C | 08:13 |
| MFen | 520823 is B | 08:13 |
| spiv | MFen: then LP will basically show the reviewer the output of "cd lp:.../B && bzr merge --preview lp:.../C" | 08:14 |
| MFen | spiv: how does it know? | 08:14 |
| lifeless | MFen: when you propose the merge, you tell it where B is | 08:14 |
| spiv | MFen: there is a "prerequisite branch" field on the "merge proposal" form | 08:14 |
| MFen | yeah, but i didn't fill it in | 08:14 |
| lifeless | MFen: workaround time: cancel that merge proposal. Do it again. | 08:14 |
| MFen | oh ok, and it is in fact showing my B changes, i think | 08:15 |
| spiv | MFen: https://code.edge.launchpad.net/~corydodt/txgenshi/502823/+merge/16954 looks promising :) | 08:19 |
| MFen | ok, cleaning up those merge requests helped, now the diffs show only (B, C] | 08:20 |
| MFen | spiv: are you claiming the review or just telling me i did it right? | 08:20 |
| spiv | MFen: just saying that appears you've navigated the lp merge proposal stuff successfully. | 08:20 |
| MFen | yeah. i think i did that much right | 08:21 |
| MFen | so moving on to the next step | 08:21 |
| spiv | MFen: although the __provides__ hack looks a bit alarming tbh! | 08:21 |
| MFen | yes. | 08:21 |
| MFen | bzr merge B into C ... the diff for C will still ignore anything merged from B? | 08:21 |
| spiv | MFen: it may well be right, of course, but I'll leave that to someone with some actually knowledge of the situation to review :) | 08:21 |
| MFen | no, it sucks. my proposal for this bug eliminates the need for the hack | 08:21 |
| spiv | MFen: yes, if you update C (including merging a newer B into C) the updated diff will still only show the changes new in C | 08:23 |
| MFen | ah, because it actually does cd into B first like you said. great. | 08:25 |
| spiv | MFen: (well, not cd literally, it uses the bzrlib API, but equivalent to that yeah) | 08:27 |
| MFen | yeah, i get it conceptually | 08:27 |
| spiv | Cool. | 08:28 |
| Peng | Say you have branches a, b and c. You file a proposal to merge c into a, with b as a prerequisite. Is the diff just "cd b; bzr merge --preview ../c", or is it like "cd a; bzr merge b; bzr merge --preview ../c"? | 08:28 |
| Peng | Err, "bzr merge ../b". But you get the point. | 08:29 |
| spiv | Peng: yes ;) | 08:29 |
| Peng | Jerk. :P Heh. | 08:29 |
| spiv | Peng: not sure, abentley or someone else from the lp code team could answer I'm sure, or you could look at the source. My guess is the former, though. | 08:29 |
| Peng | I'm sure I could do an experiment, but I'm too sleepy to figure out how. | 08:30 |
| Peng | Ah. A should have revisions 1-2. B should have 1-X, and C should have 1-Y, I think? | 08:30 |
| MFen | Peng: what you just described is exactly what i've been doing, i think. so i can tell you it's the first one | 08:31 |
| Peng | OK. You sure? | 08:31 |
| MFen | i have a <- b <- c | 08:31 |
| lifeless | Peng: check the code | 08:32 |
| Peng | :( | 08:32 |
| === loxs_wrk is now known as loxs | ||
| MFen | merge request for c into a, depends on b. the diff shows c diff b, not c diff a | 08:32 |
| MFen | it assumes you will land b first, i guess | 08:32 |
| Peng | Not c diff a+b? | 08:32 |
| MFen | nope | 08:32 |
| Peng | Huh. | 08:33 |
| Peng | That would be more complicated and more likely to cause conflicts, but also more correct... | 08:33 |
| MFen | if you're going to land c before b, then you really don't need b at all. landing c will cause b to land | 08:33 |
| MFen | in my case i expect b to land first, so it makes more sense to me | 08:34 |
| MFen | ok, one more question along these lines: | 08:45 |
| MFen | if i use bzr bind, does that automatically merge changes into whatever location i gave it? | 08:46 |
| MFen | (therefore, should i always bind A to B and B to C, forward along the dependency chain)? | 08:47 |
| lifeless | no | 08:51 |
| lifeless | bind makes a branch work like a checkout | 08:51 |
| lifeless | e.g. its useful for a shared branch that multiple people commit to, nothing else. | 08:51 |
| MFen | the glossary says bound branch and checkout are synonyms, so that isn't helping me :) | 08:52 |
| lifeless | checkout is what svn does | 08:52 |
| MFen | ok, so it does a push? | 08:54 |
| lifeless | no | 08:54 |
| MFen | what happens when i commit to a bound branch | 08:54 |
| lifeless | it just changes the behaviour of subsequent commands in that directory | 08:54 |
| lifeless | when you commit in a bound branch it does a 2-phase commit to both the master and the cwd | 08:54 |
| MFen | is there any difference between that and a puh? | 08:59 |
| MFen | push | 08:59 |
| spiv | MFen: bind basically means "keep this branch in sync with the target branch", so when you make a commit both cwd and master are locked, then new revision written to both, then that transaction is committed. | 09:03 |
| MFen | k | 09:04 |
| spiv | MFen: whereas if you are unbound and push, the end result is typically the same (both branches at same rev), but obviously how you get there is a bit different, and if other people might write to your branch then the master can diverge between you doing "bzr commit" and you doing "bzr push". | 09:05 |
| MFen | spiv: is it committed locally in both cases? | 09:08 |
| spiv | I'm not sure what you mean. | 09:11 |
| spiv | (I know what sort of things I'd mean by that phrase, but not what you do) | 09:12 |
| MFen | bzr st will show nothing modified after | 09:12 |
| Raim | if the commit fails on the bound branch, it fails locally, too | 09:12 |
| spiv | MFen: right | 09:12 |
| MFen | ok. so that is a different end result | 09:12 |
| MFen | in commit+push, it is committed locally even if push fails. in bind+commit, it is not. | 09:13 |
| spiv | MFen: (assuming the commit succeeds, as Raim points out, though commits may fail for reasons other than a bound branch with diverged master, e.g. pre-commit hook) | 09:13 |
| spiv | So if you like the big difference is that when things have diverged you'll get a failure at the commit step rather than later. | 09:14 |
| MFen | ok | 09:15 |
| lifeless | MFen: there are two key differences between bound commits and push: | 09:16 |
| lifeless | firstly, parent ordering is preserved (because you do merges with the same parents as the master) | 09:16 |
| lifeless | secondly, out of date branches cannot commit when bound. | 09:16 |
| lifeless | MFen: spiv: sorry for echoing spiv late there, I didn't read to the bottom :) | 09:52 |
| jelmer | mwhudson: no idea, I thought I had fixed all places where that appears | 11:20 |
| henninge | HI, I know I had figured it out before but I can't remember how it worked. | 11:25 |
| henninge | I want to use bzr-pipelines (again) to hack on Launchpad. | 11:25 |
| henninge | I have my lp-branches repository and in there the devel branch (and other's). | 11:26 |
| henninge | (forget the ') | 11:26 |
| henninge | I know pipelines are "just" light-weight check-outs - but of what? | 11:27 |
| henninge | I don't want a light-weight check-out of devel, because then I'd be committing all changes there. | 11:28 |
| henninge | Actually, my situation is even different. I have a (heavy-weight) branch of devel that I have been hacking on but now I want to add a pipe to do extra work. I don't know how. I must be missing something obvious. | 11:29 |
| james_w | bzr reconfigure-pipeline to start I believe | 11:31 |
| jelmer | mwhudson: these issues usually take up quite a bit of time, perhaps we could have a look in NZ? | 11:39 |
| henninge | james_w: appearently not if you already have a repository. | 11:43 |
| henninge | james_w: from bzr help reconfigure-pipeline: | 12:05 |
| henninge | This is suitable if you have a standalone tree, but if you have a | 12:05 |
| henninge | shared repository with its own organization scheme already, it's probably | 12:05 |
| henninge | better to just create a lightweight checkout. | 12:05 |
| henninge | james_w: I figured it out now: | 12:05 |
| henninge | bzr branch devel mywork-pipe1 | 12:06 |
| henninge | bzr checkout --lightweight mywork-pipe1 mywork | 12:06 |
| henninge | cd mywork | 12:06 |
| henninge | bzr add-pipe mywork-pipe2 | 12:06 |
| henninge | This will create all pipes as siblings, so in my repository I now have directories "mywork", "mywork-pipe1" and "mywork-pipe2". | 12:07 |
| henninge | The confusing thing is that that the pipe directories don't show any changes, no matter what I commit in mywork, I guess that's because the pipline commands only work on the branch, not the tree. (Or is it the other way round?) | 12:09 |
| james_w | yeah, I think you "bzr update ../mywork-pipe1" you will see the changes appear | 12:11 |
| henninge | james_w: yes, it does! cool, thanks | 12:13 |
| marek_ | hi i have a problem, i have two computers and one server, every one has repo , from 1 computer i can push and other can merge, but when i try it in other way - while i try to push i can see "no revisions to push" but i changed some files | 13:38 |
| marek_ | can you help me? | 13:38 |
| Peng | marek_: Have you committed? | 13:39 |
| marek_ | locally | 13:43 |
| marek_ | yes | 13:43 |
| marek_ | bzr status -> clean | 13:43 |
| Peng | marek_: Then I guess you've already pushed? | 13:44 |
| Peng | marek_: Do "bzr log -r -1 -n 1 :push". | 13:44 |
| Peng | Hmm, that looks a little Git-like. :P | 13:44 |
| awilkins | You might have a checkout rather than a branch? | 13:45 |
| awilkins | aka "bound branch" | 13:45 |
| Peng | Ah, good point. marek_: What does "bzr info" on your local branh say it is? | 13:45 |
| awilkins | Revisions committed locally automatically committed to remote branch... do `bzr info` in tree | 13:45 |
| marek_ | on server: bzr info: | 13:51 |
| marek_ | http://pastebin.com/m66579407 | 13:52 |
| marek_ | on local i can also see something about | 13:52 |
| marek_ | related branches | 13:52 |
| Peng | marek_: OK, but what's the first line of the client's info? | 13:54 |
| marek_ | standalano tree | 13:54 |
| Peng | Ah. | 13:54 |
| Peng | marek_: Then, most likely, you already pushed. | 13:54 |
| marek_ | but i cannot see it on server | 13:54 |
| marek_ | ecen after update | 13:54 |
| marek_ | on othe computer if i merge changes i dont see modified files :( | 13:55 |
| Peng | marek_: Ohh? What does "bzr log -r -1" say on both branches? | 13:55 |
| marek_ | on local: revno 25 [merge] and commiter - local user | 13:55 |
| marek_ | on server: | 13:55 |
| marek_ | revno 23 and different user | 13:56 |
| Peng | Huh. | 13:56 |
| Peng | It's possible something has gone horribly awry, but most likely it's something basic like you're pushing to the wrong place... | 13:56 |
| awilkins | do `bzr missing --mine <server branch>` | 13:57 |
| marek_ | gosh other pc was using bzr explorer | 14:01 |
| marek_ | and path was .... | 14:01 |
| marek_ | local !!! ^&%&^!%^&@! | 14:01 |
| mok0 | Is there a trick you need to do to update the directory tree in the "central" repo? I have a checkout on my laptop at home, I did a "commit" but I can't seem to extract the changes on my main workstation. | 14:41 |
| mok0 | ... bzr update doesn't do it, I should say. | 14:43 |
| awilkins | mok0, If the revision you committed on your laptop hasn't been pushed to the main workstation (or a repository it can see) then you can't see those changes | 14:53 |
| mok0 | awilkins: it's a checkout | 14:53 |
| mok0 | awilkins: it gets pushed when I commit | 14:53 |
| awilkins | They're both checkouts of the same repo? | 14:53 |
| mok0 | yes | 14:53 |
| mok0 | awilkins: I can check tonite if I did something wrong | 14:54 |
| mok0 | Just puzzled | 14:54 |
| mok0 | awilkins: the laptop dir is a checkout of my working dir on the workstation | 14:54 |
| mok0 | awilkins: just wondering if there's a bzr command I don't know about. | 14:55 |
| awilkins | mok0, Did you do the commit while on the same network as the workstation? | 14:56 |
| mok0 | awilkins: I am using the bzr+ssh protocol. I am not sure I know what you mean by "same network" | 14:56 |
| awilkins | Try "revert" | 14:56 |
| mok0 | awilkins: nothing happens | 14:57 |
| awilkins | Can you see the revision you committed from the laptop in the local log? | 14:57 |
| mok0 | no | 14:57 |
| mok0 | Perhaps there's something in .bzr that could give a clue? | 14:58 |
| awilkins | You have your laptop with you? | 14:58 |
| mok0 | awilkins: No :-) that's the problem. I did some work at home, committed it (AFAIR) and went to work | 14:59 |
| mok0 | w/o the laptop :-) | 14:59 |
| awilkins | The tree on the laptop is either a standalone, or you committed with the --local flag | 14:59 |
| mok0 | awilkins: well, you must be right | 15:00 |
| awilkins | Or it's bound to another branch | 15:00 |
| awilkins | That isn't the one you're working on | 15:00 |
| mok0 | awilkins: apparently :-/ | 15:00 |
| awilkins | Still, merges are easy :-) | 15:00 |
| mok0 | awilkins: fortunately! Oh well I'll figure out what's going on when I get home | 15:01 |
| awilkins | Before policy locked out thumbdrives I used to bind my checkouts to a folder on a thumb drive | 15:01 |
| mok0 | awilkins: what policy is that? | 15:01 |
| awilkins | Our management policy | 15:01 |
| mok0 | Ah | 15:01 |
| mok0 | I guess thumbdrives are inherently unsafe | 15:02 |
| rubbs | so are users, but they don't stop those from connecting ;) | 15:02 |
| awilkins | That worked very nicely... since I take my laptop home I now just run a bzr:// server on it when I want to sync | 15:02 |
| mok0 | "oops I lost my thumbdrive, the entire IP of my company has gone missing" | 15:02 |
| mok0 | :) | 15:02 |
| awilkins | The idiotic bit is that we're working hard to open-source as much of my work as possible | 15:03 |
| rubbs | oops, I just left the company with all the newest ideas in my head. | 15:03 |
| awilkins | And I don't have any confidential data | 15:03 |
| rubbs | haha | 15:03 |
| awilkins | (I work for a government agency) | 15:03 |
| mok0 | Well managers love to enforce stupid rules they think are important | 15:03 |
| awilkins | Since we are the IT arm of this agency we get to guinea-pig all the stupid ideas for the parts that DO have confidential data | 15:04 |
| mok0 | Sysadms are generally opposed to openness. The create restrictions just because it's possible | 15:04 |
| rubbs | I resent that! | 15:04 |
| rubbs | hehe ;) I'm a part time admin | 15:04 |
| awilkins | The fewer degrees of freedom your workstation has, the lower the skill required to adminster it | 15:04 |
| mok0 | rubbs: resent what, my statement or what I'm saying? | 15:05 |
| mok0 | rubbs: so am I | 15:05 |
| mok0 | awilkins: hehe | 15:05 |
| rubbs | just that sysadmins are apposed to openness. I wouldn't quite say that | 15:05 |
| awilkins | I think it's sensible to prevent normal users doing stuff | 15:05 |
| rubbs | this is true | 15:05 |
| mok0 | rubbs: I didn't say _all_ sysadms | 15:05 |
| rubbs | ah, then I'm sorry I over reacted | 15:05 |
| awilkins | But it's a pain in the ass for developers.. we have a different class of support problems though | 15:05 |
| rubbs | awilkins: I've been in your boat too, that's why I try to make it easy. finding the balance is hard. | 15:06 |
| awilkins | Like the time last month when I trashed the stupid full-disk encryption boot block on both my machines... because standard users don't dual-boot Linux from external drives | 15:06 |
| rubbs | luckily I have a pretty small support group, so I don't have to juggle too many needs. | 15:06 |
| rubbs | awilkins: haha | 15:07 |
| awilkins | The knee jerk response would be to prevent booting from external drives.. and would cripple my productivity | 15:07 |
| awilkins | More interesting than "I forgot my password" though | 15:07 |
| awilkins | They're now removing admin rights from our users that need them though, on general principles | 15:08 |
| awilkins | So when you get a new machine on the refresh program, you lose admin rights until you kick up a fuss about it | 15:08 |
| awilkins | Even if you are developer | 15:08 |
| mok0 | I've been admin for our local network (~20 workstations) for 10-15 years. I've had hacker visits 2-3 times. Always amateurs, and it's taken 5 minutes to get rid of them once I discovered them | 15:08 |
| awilkins | Windows? | 15:09 |
| mok0 | That is w/o firewall | 15:09 |
| mok0 | awilkins: No! Linux | 15:09 |
| mok0 | Just using the standard tools like iptables etc. to block intruders | 15:09 |
| awilkins | I just wish our infratructure was friendlier to Linux | 15:10 |
| mok0 | That's why I frown at sysadms who restrict their users in every possible way in fear of hackers | 15:10 |
| awilkins | They got rid of a perfectly good IMAP server that you could access outside the office network | 15:10 |
| awilkins | And replaced it with Exchange | 15:10 |
| mok0 | awilkins: isn't that the PURPOSE of an imap server :-) | 15:10 |
| fullermd | Who needs IMAP? Everybody just uses gmail, right? | 15:10 |
| awilkins | Which you dare not expose on the internet, so it's closeted behind an XMLRPC firewall | 15:10 |
| mok0 | fullermd: I use gmail | 15:11 |
| awilkins | So only Outlook and OWA | 15:11 |
| awilkins | Can't use gmail | 15:11 |
| mok0 | I use gmail's IMAP :-) | 15:11 |
| awilkins | Stupid patient-confidentiality rules, dammit | 15:11 |
| rubbs | awilkins: know that well. I work with PHI too. | 15:11 |
| mok0 | awilkins: can't you encrypt them? | 15:11 |
| fullermd | Pointless. Google Knows All And Sees All anyway. | 15:11 |
| awilkins | Used to be able to use thunderbird inside and out | 15:11 |
| awilkins | Now I use Outlook because otherwise I'll have to use VPN, which is a PITA, or Outlook Web Access which sucketh mightily | 15:12 |
| mok0 | awilkins: :-( | 15:12 |
| awilkins | mok0, We wouldn't have a large enough contingent of people who understand encryption | 15:12 |
| mok0 | awilkins: hmm. People can be educated | 15:13 |
| awilkins | mok0, This is an organisation which advocates using an approved motorbike courier because it's apparently secure | 15:13 |
| awilkins | And destroying _encrypted_ flash media after they served their pupose | 15:13 |
| mok0 | awilkins: what if someone rams him and steals the documents? | 15:13 |
| awilkins | mok0, Indeed.. they also advocate that sending mails to people on our own email domain to be secure | 15:14 |
| * mok0 is for unlimited openess on the internets | 15:14 | |
| awilkins | mok0, But as we know, damn sysadmins will just read it | 15:14 |
| awilkins | mok0, my personal position is GPG for everything | 15:14 |
| mok0 | awilkins: ... and then people print out the confidential mails and bring them home :-) | 15:14 |
| awilkins | And screw the couriers | 15:15 |
| mok0 | awilkins: I agree | 15:15 |
| awilkins | And post | 15:15 |
| mok0 | awilkins: absolutely | 15:15 |
| awilkins | Problem is they take their encryption advice from GCHQ which has the wrong set of requirements | 15:15 |
| awilkins | Like key escrow | 15:15 |
| mok0 | awilkins: there's no remedy for incompetence in the upper cadres | 15:16 |
| awilkins | "GPG for everything confidential" is a lot simpler than memorizing rules about whether it's OK to mail someone with a gmail account or which bike messengers are accredited | 15:16 |
| mok0 | awilkins: indeed. And security != control | 15:16 |
| awilkins | I mean, key escrow for signing keys on medical records... no practitioner will go for that | 15:17 |
| mok0 | I actually don't know key escrow | 15:17 |
| awilkins | They keep a copy of the private keys centrally | 15:18 |
| mok0 | Ah | 15:18 |
| mok0 | awilkins: that's for unsophisticated users | 15:18 |
| awilkins | So, what doctor would be happy with "Hey, your records can be VERIFIED to be from you.. apart from if <agency X> wants to fake them" | 15:18 |
| mok0 | exactly | 15:18 |
| awilkins | Or some hacker steals the escrow DB, which lets face it, would be a FAT target | 15:19 |
| mok0 | Most encryption schemes don't take into consideration that the "bad guy" is the government or some other agency | 15:19 |
| mok0 | That's where GPG differs | 15:19 |
| awilkins | Or some schmuck in the data centre offered a few $10k for the key database | 15:19 |
| mok0 | awilkins: right | 15:20 |
| mok0 | Well, the climate guys from East Anglia are probably sorry that they didn't encrypt their mail correspondence | 15:20 |
| awilkins | Whereas my medical record architecture is so private that the patient can potentially restrict access to his records to everyone, except himself. | 15:21 |
| awilkins | :-) | 15:21 |
| awilkins | Shame it'll never catch on | 15:21 |
| awilkins | I should write it up just as a thought experiment and see if I can get a presentation of it under the wire | 15:21 |
| mok0 | awilkins: I'm in a university and I have to tell the students about GPG | 15:21 |
| mok0 | awilkins: good idea | 15:22 |
| awilkins | I discovered PGP in my first year | 15:22 |
| awilkins | (some time ago) | 15:22 |
| mok0 | My position used to be this: "I have no secrets, I don't care if ppl see my email correspondence" | 15:22 |
| mok0 | Now I'm not so sure. If someone evil got hold of it all, I'm sure they could dig up some dirt to throw at me | 15:23 |
| awilkins | Then you have Eric Schmidt saying "Hey, if people have no secrets, they shouldn't care if we see their email" | 15:23 |
| awilkins | And get worried | 15:23 |
| mok0 | and Eric Schmidt is... | 15:23 |
| mok0 | ? | 15:23 |
| awilkins | Google person? | 15:23 |
| mok0 | ah | 15:23 |
| awilkins | I may have wrong guy | 15:23 |
| awilkins | Nope, right guy | 15:24 |
| mok0 | ... and those statements are meant as a comment to their searching gmail accounts? | 15:24 |
| awilkins | http://gawker.com/5419271/google-ceo-secrets-are-for-filthy-people | 15:25 |
| * mok0 looks | 15:25 | |
| * rubbs goes and checks it out as well. | 15:26 | |
| mok0 | Oh... In principle I agree with Eric Schmidt on this very particular subject | 15:27 |
| awilkins | I do plenty of things that are legal that I wouldn't want people knowing about | 15:27 |
| mok0 | Although I don't agree with the header... it's somewhat misleading anyway | 15:27 |
| mok0 | awilkins: yes | 15:27 |
| awilkins | "If you have something that you don't want anyone to know, maybe you shouldn't be doing it in the first place." | 15:28 |
| mok0 | Of course there are things that are secret. But if they're not, you can't complain that Google finds them | 15:28 |
| mok0 | awilkins: I'm sure that's taken out of context | 15:28 |
| mok0 | Idunno | 15:29 |
| mok0 | Google doesn't index email | 15:29 |
| mok0 | and they shouldnt | 15:29 |
| awilkins | It seems more reasonable when you view the clip | 15:29 |
| awilkins | They don't publicly index email | 15:29 |
| awilkins | They must index it somewhere for you to be able to search it so quickly | 15:30 |
| mok0 | Ah, ok, but my Google Chromium browser wont show it :-D | 15:30 |
| awilkins | Odd, I'm running Chrome and I see it fine | 15:30 |
| mok0 | I disabled falsh | 15:30 |
| mok0 | flash | 15:30 |
| awilkins | Ah | 15:30 |
| awilkins | And they process email so they can show context ads | 15:30 |
| awilkins | (which you don't see over IMAP, natch) | 15:30 |
| mok0 | I use their imap service so I never see it | 15:31 |
| awilkins | His point that the government can technically ask them to cough up their data is fair | 15:31 |
| awilkins | His attitude doesn't seem to have the same tone as the story title | 15:31 |
| mok0 | That is why you should encrypt email that you don't want anyone to see | 15:31 |
| awilkins | And funnily enough, the clip is from a company owned in large part by MS | 15:32 |
| mok0 | ... then if Eric Schmidt thinks you are filthy... I can live with that | 15:32 |
| mok0 | hehe | 15:32 |
| awilkins | They should change the email icon to a postcard instead of an envelope | 15:33 |
| mok0 | hehe | 15:33 |
| mok0 | yes | 15:33 |
| mok0 | That's what email is, anyway | 15:33 |
| awilkins | That envelope icon does more to raise peoples expectations of email privacy than anything else | 15:33 |
| mok0 | "Sending mail in an envelope are for filthy people" | 15:33 |
| mok0 | s/are/is | 15:34 |
| awilkins | The security policy at work... actually suggests LABELLING the envelope you send with a courier as a secure document | 15:34 |
| awilkins | Ahaahahahahahahhahaha | 15:34 |
| awilkins | "STEAL ME" | 15:34 |
| mok0 | Now THAT'S funny!! | 15:35 |
| awilkins | Not that security by obscurity is a good thing | 15:35 |
| mok0 | :-) | 15:35 |
| awilkins | But damn, labelling things as being more valuable? Before handing them to a guy who earns £5 an hour to motorcycle through British weather? | 15:35 |
| * mok0 thinks most investigations are done by traffic analysis anyway | 15:35 | |
| mok0 | The (insert favourite TLA) just needs to locate terrorist/criminal/etc. networks | 15:37 |
| mok0 | they can do that by traffic analysis, and there's nothing you can do about it | 15:37 |
| mok0 | NOTHING | 15:38 |
| J-m-D | We are using svn for versioning. Our useage is a bit "uncommon" - we mainly have binary files, and quite large ones. The central repository is very important for us so we have a central back up aswell as central access to all files. Could bzr bring something to the table that we miss out on in svn? | 15:39 |
| J-m-D | btw - we are all on windows | 15:40 |
| mok0 | J-m-D: the most obvious advantage is the ability to have off-line branches | 15:41 |
| mok0 | J-m-D: "distributed development" | 15:41 |
| J-m-D | something that is not very important for us atm. | 15:41 |
| mok0 | J-m-D: AFAIK tagging and branching is heavy in subversion. Do you use that a lot? | 15:42 |
| rubbs | J-m-D: bzr also allows for easier merges. merging in svn is pretty tough... although I haven't done it in svn in a while admittedly | 15:42 |
| awilkins | Bazaar is less adept at coping with large binary files... but there are some advantages, esp. if they are compressible | 15:42 |
| awilkins | e.g. - I've got a Bazaar working tree + repo with full history that's 2.5GB... the SVN checkout on it's own is 4.0GB | 15:43 |
| J-m-D | Branching and tagging is almost non-existant with us for now. | 15:43 |
| mok0 | J-m-D: if you only need a "data store" then I honestly don't think it matters what VCS you use | 15:44 |
| mok0 | J-m-D: if you are planning to revise your workflow, then bzr offers lots of options | 15:44 |
| mok0 | J-m-D: consider svn a subset of bzr | 15:45 |
| J-m-D | svn seems to handle binary files quite good - revisions are made incrementally which is nice. It makes updates and comitts less heavy. How does bzr handle revisions of binary files? | 15:45 |
| mok0 | J-m-D: ugh. Don't know to be honest. I just know it works | 15:46 |
| mok0 | J-m-D: personally, I use it quite a lot for PDF files | 15:46 |
| J-m-D | What could be interesting is if bzr is more flexible than svn in handling revisions of individual files. If we want to have an older version of something, it is allmost allways just an individual file - we never make a new branch of a project. | 15:48 |
| mok0 | J-m-D: Don't you use the status of the entire directory tree? | 15:50 |
| J-m-D | Nope, very seldom since we mostly work on large graphics files and 3D graphical assets. | 15:51 |
| mok0 | J-m-D: then I'd suggest to use a separate repo for each component | 15:52 |
| mok0 | J-m-D: that you can check out in whatever context you need | 15:52 |
| J-m-D | ohh, I'm afraid that would be totally impractical - there are quite a few components for every project. | 15:53 |
| mok0 | bzr can give you a svn-like workflow, but it can also give you other options | 15:53 |
| rubbs | J-m-D: I think that you could still get individual files, but it would probably be from a branch. | 15:53 |
| mok0 | J-m-D: I see | 15:53 |
| J-m-D | Renaming is allso quite indflexible in svn since it seems to be made by a delet-and-re-comitt-method or something. Takes quite a while to get it done on a large repository. | 15:53 |
| mok0 | J-m-D: the best I can suggest is to try out bzr on your project and see how it performs in practice | 15:54 |
| J-m-D | mok0: I guess I'll have to do that. Thank you for all the imput - much appreciated. | 15:54 |
| litwol | hello | 15:55 |
| mok0 | J-m-D: good luck! Come back later, perhaps ther are more qualified ppl | 15:55 |
| litwol | What command allows me to list available project branches ? | 15:55 |
| litwol | and how can i switch between them ? | 15:55 |
| J-m-D | mok0 - sure will. And your suggestions were good enough for me at least. Thanx again. | 15:56 |
| mok0 | litwol: branches are stored in each their directory | 15:56 |
| rubbs | J-m-D: renames are supported in bzr as fully versioned. | 15:56 |
| litwol | oh ... | 15:56 |
| beuno | vila, so we're releasing 1.0? :) | 15:57 |
| mok0 | litwol: there are ways of working with stacked branches but I've not tried that | 15:57 |
| J-m-D | rubbs: oki. interesting. thnx | 15:57 |
| vila | beuno: hehe, not yet, but that doesn't forbid using the milestone :) | 15:57 |
| mok0 | litwol: in it's basic form, no bzr branch would know about other branches... only the parent | 15:57 |
| litwol | i c | 15:58 |
| litwol | ty | 15:58 |
| J-m-D | thanks for now. See you later guys. | 15:58 |
| mok0 | litwol: however, if you use Launchpad, it's different | 15:58 |
| beuno | vila, we should figure out what we want for 1.0, and target it! | 15:58 |
| rubbs | J-m-D: np. see you later | 15:58 |
| vila | beuno: I agree, I think the list we did at UDS is a good target, I'm fighting for free time to work on it though :-/ | 15:59 |
| vila | beuno: may be we should just go for time-based release... | 15:59 |
| beuno | vila, we'll pull through, even if it's me hacking up code you you cleaning it up ;) | 15:59 |
| beuno | well, it is stable enough | 16:00 |
| beuno | I'll go through the list of bugs and features | 16:00 |
| jam | morning vila and beuno | 16:13 |
| vila | morning jam | 16:14 |
| beuno | hiya jam | 16:19 |
| * vila EODing, already late for school meeting :-. | 16:33 | |
| === beuno is now known as beuno-lunch | ||
| chx | i just committed with the wrong commit message can i change it? | 17:00 |
| === deryck is now known as deryck[lunch] | ||
| chx | ah bzr uncommit | 17:02 |
| chx | great. | 17:02 |
| maxb | Has anyone performed any sort of trade-off analysis of methods of converting from svn to bzr? There seem to be quite a few of them. | 17:06 |
| jelmer | maxb: What sort of tradeoffs do you mean? | 17:15 |
| maxb | Any discussion that would assist me in deciding which method I'm better off using | 17:16 |
| jelmer | maxb: Can you give some examples of tradeoffs though, I'm not sure exactly what you mean by that. | 17:18 |
| maxb | I have lots of projects in a svn repository which I'd like to convert to separate bzr repositories. I see that there are at least two mainstream methods of doing so - bzr-svn and bzr-fastimport - and a bunch of other ones too. I'm looking for any guidance that will help me choose which I should use. | 17:20 |
| jelmer | maxb: as far as I know both should be able to convert subprojects to separate bzr repositories | 17:23 |
| jelmer | bzr-fastimport doesn't do deterministic revision ids, so you can't pull from the original svn branch later on unless you have the mapping files | 17:25 |
| jelmer | but on the other hand, it might do rename detection, which bzr-svn doesn't do | 17:25 |
| maxb | OK, I guess I'll just need to explore the options | 17:42 |
| maxb | On another topic, is there any software to facilitate code review via bzr branches that companies can install for internal use - i.e. not Launchpad. | 17:43 |
| maxb | I was going to look at BundleBuggy, but the project doesn't seem too healthy now bzr has left it | 17:43 |
| awilkins | maxb, Launchpad can be installed locally... it's rather large though... I've just never had the time to finish configuring it | 17:47 |
| maxb | awilkins: Yes, but not legally, unless you find a graphics designer to make you a new set of icons | 17:48 |
| awilkins | What license are the icons under? | 17:48 |
| maxb | Canonical Proprietary | 17:49 |
| awilkins | Does "internal code review" count as development or production... but yes, that's slightly troublesome | 17:51 |
| === tchan1 is now known as tchan | ||
| === Supertan1er is now known as Supertanker | ||
| jelmer | maxb: reviewboard has bnasupport | 17:56 |
| jelmer | maxb: reviewboard has basic support for bzr bundles | 17:57 |
| maxb | I will have to investigate that | 17:57 |
| === deryck[lunch] is now known as deryck | ||
| jam | maxb: BundleBuggy is probably not actively maintained by abentley anymore, but it is probably a decent starting point. | 18:15 |
| jam | I've heard good things about ReviewBoard, though. | 18:15 |
| maxb | The most dispiriting thing about BundleBuggy was that it has quickstart documentation that doesn't work :-) | 18:16 |
| === beuno-lunch is now known as beuno | ||
| rindolf | Hi all! I just blogged about how much bzr sucks - http://community.livejournal.com/shlomif_tech/41922.html | 18:24 |
| nailuj24 | rindolf: well done my dear... | 18:25 |
| === chx is now known as chx_food | ||
| jpds | rindolf: Which version of bzr are you using? | 18:26 |
| rindolf | jpds: 2.0.3 | 18:26 |
| jpds | Format <RepositoryFormatKnit4> for lp-64863440:///~inkscape.dev/inkscape/trunk/.bzr is deprecated - please use 'bzr upgrade' to get better performance | 18:27 |
| jpds | rindolf: Tell the Inkscape guys to do that. | 18:27 |
| rindolf | jpds: it's in my bug report. | 18:28 |
| rindolf | If it's hosted on LP , why isn't it upgrade automatically? | 18:28 |
| rindolf | It takes a second for bzr --version to run. | 18:29 |
| * fullermd gets very unhappy with hosting providers screwing with his data... | 18:29 | |
| maxb | rindolf: Because it would be very stupid for Launchpad to silently force new formats on people when their local bzr versions might not be new enough | 18:29 |
| jpds | rindolf: Backwards compatibility with what the developer is using I guess. | 18:29 |
| maxb | rindolf: Whilst I agree that bzr's speed is not great, I don't think the attitude of your blog or bug report is anything other than unproductive | 18:32 |
| * fullermd notes that the branch of postr takes 26 seconds, and the diff 0.16 from here.. | 18:32 | |
| fullermd | Of course, going over a dumb protocol (http) means that latency is going to kill you flat dead. And you may be rather farther away from it than I am. | 18:33 |
| maxb | rindolf: In fact, why on earth do you comment on the time taken for the error to occur, when it's clearly a network problem | 18:34 |
| Tak | originality: 4% accuracy: 6% grammar: 20% emotionality: 30% overall troll: 10% | 18:40 |
| pturcotte | Is there a way to prune (remove) a part of the history? Let's say from revision 1 to X while the actual version is at X+50 ? | 18:41 |
| james_w | pturcotte: no, that's not really possible | 18:41 |
| rindolf | maxb: if it stops in the middle, I should be able to resume it later. | 18:41 |
| === chx_food is now known as chx | ||
| Flydoire|Taktik | hi everyone | 19:16 |
| Flydoire|Taktik | I just tried to install bzr on snow leopard from the pkg. bzr command does not work : bzr: ERROR: Couldn't import bzrlib and dependencies | 19:17 |
| Flydoire|Taktik | anyone has an answer ? | 19:17 |
| pturcotte | james_w: thanks. | 19:28 |
| pturcotte | Then, is there a way to reduce the disk usage of the branch. My branches are around 420Mb, mostly binary files that are not in use anymore. | 19:29 |
| james_w | not really, bzr is designed to have immutable history, and it's tough to get around that | 19:33 |
| Kinnison | Do we have history horizon yet? | 19:36 |
| mwhudson | jelmer: ok, i guess we should file a bug in the mean time? | 19:36 |
| awmcclain | Hi all -- I've been looking through help commands but can't find it -- How do I get the last revision that a particular file was changed? | 19:45 |
| luks | something scriptable? if not, I'd use bzr qbrowse | 19:48 |
| luks | (`bzr qbrowser -r -1` to be more specific) | 19:50 |
| luks | otherwise you probably have to mess with bzr log | 19:50 |
| luks | which is not going to be very fast | 19:51 |
| luks | I don't know of any built-in command that exposes the information, even though bzr has it easily available | 19:51 |
| awmcclain | luks: Ok. Sounds great. Thanks! | 19:52 |
| Flydoire|Taktik | familiar with this error ? : bzr: ERROR: exceptions.TypeError: Auth providers should be list ? | 20:17 |
| lifeless | Flydoire|Taktik: no, but I'd guess at a old plugin or something like that. | 20:28 |
| Flydoire|Taktik | hum | 20:28 |
| Flydoire|Taktik | what about bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium 'SmartSSHClientMedium(connected=True, username=u'fl-taktik', host='bazaar.launchpad.net', port=None)' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. | 20:29 |
| Flydoire|Taktik | . | 20:29 |
| Flydoire|Taktik | ? | 20:29 |
| fullermd | That's usually a secondary symptom. Perhaps of the error you mentioned before. | 20:31 |
| Flydoire|Taktik | will the bazaar.launchpad.net server kill my concurent requests so that it will work in a few hours ? | 20:32 |
| fullermd | There probably AREN'T any concurrent requests. It just looks like it when the connection fails. | 20:32 |
| fullermd | (that error is from your local bzr, not from LP) | 20:33 |
| Flydoire|Taktik | how to I fix it ? Do I have to get the latest trunk version ? | 20:33 |
| fullermd | Are you sure there's something to fix? | 20:34 |
| fullermd | That's an error that pops up in a single bzr invocation, and usually is just fallout from an earlier error. | 20:34 |
| Flydoire|Taktik | I just got the bzr: ERROR: Could not acquire lock "(remote lock)": | 20:35 |
| fullermd | It doesn't in itself leave anything hanging around for later runs. | 20:35 |
| Flydoire|Taktik | so I break-lock | 20:35 |
| Flydoire|Taktik | and I bzr pull again | 20:35 |
| Flydoire|Taktik | and boom : bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests | 20:35 |
| Flydoire|Taktik | what shoul I do ? | 20:36 |
| fullermd | Yes, that's not from the break-lock. That's from some failure in that specific invocation, probably having to do with the connection either breaking or not being properly established. | 20:36 |
| fullermd | Is there any output other than that? | 20:37 |
| Flydoire|Taktik | yep | 20:37 |
| Flydoire|Taktik | http://pastebin.com/d38355f11 | 20:38 |
| fullermd | What the error generally boils down to is a generic sort of "Hey, I can't seem to talk across this connection I expect to be there" | 20:40 |
| fullermd | So you need to figure out why the connection isn't working out. | 20:41 |
| fullermd | There may be something in .bzr.log about it, or you may need some debug flag... -Dhpss maybe, to get it to tell you more. | 20:41 |
| fullermd | (I don't know what would show you useful output) | 20:41 |
| fullermd | Start off simple; can you connect to LP with sftp? | 20:42 |
| Flydoire|Taktik | trying | 20:42 |
| Flydoire|Taktik | yes | 20:43 |
| fullermd | 'k... try pulling over sftp instead of bzr+ssh (just change the protocol on the URL). 'll be a lot slower, but... | 20:44 |
| Flydoire|Taktik | where do I change the protocol ? in .bazaar/authetication.conf ? | 20:45 |
| fullermd | No, just do it manually. | 20:45 |
| fullermd | bzr pull sftp://...... | 20:45 |
| Flydoire|Taktik | worked :D | 20:46 |
| Flydoire|Taktik | thanks fullermd | 20:46 |
| fullermd | 'k, so it's just something with bzr+ssh. | 20:47 |
| fullermd | Try it with that regular URL again; maybe it was just a transient problem somewhere. | 20:47 |
| Flydoire|Taktik | ...trying... | 20:47 |
| fullermd | (you definitely don't want to use sftp instead of bzr+ssh in general; lot slower and more resource-consuming on both ends. Useful diagnostic though, since it tests most of the same infrastructure) | 20:47 |
| Flydoire|Taktik | worked fine | 20:48 |
| fullermd | If it consistently works with sftp, and consistently fails with bzr+ssh... well, we've localized it at least. I don't know where do go from there, if something like -Dhpss doesn't tell any more. | 20:48 |
| Flydoire|Taktik | maybe a pb in my repository ? | 20:48 |
| fullermd | Hm. OK. We'll just chalk it up to Random Internet Schizo Crap 8-} | 20:48 |
| Flydoire|Taktik | works : bzr pull bzr+ssh://fl-taktik@bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/ | 20:49 |
| Flydoire|Taktik | does not work : bzr pull | 20:49 |
| fullermd | Well, that's a very different URL from what you've got there as the parent... | 20:50 |
| Flydoire|Taktik | with | 20:50 |
| Flydoire|Taktik | $ bzr info | 20:50 |
| Flydoire|Taktik | Checkout (format: unnamed) | 20:50 |
| Flydoire|Taktik | Location: | 20:50 |
| Flydoire|Taktik | checkout root: . | 20:50 |
| Flydoire|Taktik | checkout of branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/ | 20:50 |
| Flydoire|Taktik | Related branches: | 20:50 |
| Flydoire|Taktik | push branch: bzr+ssh://bazaar.launchpad.net/~openerp-community/openobject-addons/taktik/ | 20:50 |
| Flydoire|Taktik | parent branch: bzr+ssh://bazaar.launchpad.net/~openerp/openobject-addons/5.0/ | 20:50 |
| * fullermd blinks. | 20:50 | |
| lifeless | ok, you shouldn't be pulling here | 20:51 |
| fullermd | OK, well... I'm not sure what you're asking for makes much sense. | 20:51 |
| lifeless | use update instead | 20:51 |
| fullermd | pull'ing the branch you're a checkout of is nugatory. | 20:51 |
| Flydoire|Taktik | ok : sorry, I'm new to bzr, and it's quite confusing | 20:51 |
| fullermd | Now, it may make sense to pull that parent. I can see how that might legitimately give that error, if bzr is being too dumb or too smart about its connection, though. | 20:52 |
| fullermd | So, that might actually be a legitimate case of that error message. | 20:53 |
| Flydoire|Taktik | pull is to get changes from other branches, update just updates the current branch, right ? | 20:54 |
| fullermd | Update roughly means "update my working tree to match the branch". Pull roughly means "update my branch to match this other branch". | 20:54 |
| fullermd | So when you run 'bzr update', you're saying "Get this working tree at . up to match the branch at bzr+ssh://[...]/taktik/" | 20:55 |
| fullermd | 'bzr pull' is saying "Update my branch at bzr+ssh://[...]/taktik/ to match the branch at bzr+ssh://[...]/5.0/" | 20:55 |
| fullermd | It's believable that bzr is doing something overly {smart,stupid} about trying to reuse a single connection to LP to do both sides of that. | 20:56 |
| fullermd | Which would bring up that error. | 20:56 |
| * fullermd passes that one to lifeless. | 20:56 | |
| jelmer | mwhudson, please do | 20:57 |
| Flydoire|Taktik | ok, thank you for your time fullermd | 20:58 |
| jelmer | mwhudson: does that branch have any round-tripped revisions? | 20:58 |
| mwhudson | jelmer: your guess is as good as mine | 20:58 |
| jelmer | mwhudson: svn proplist on the branch root should tell you | 20:58 |
| mwhudson | jelmer: it has a svk:merge property, is that enough? | 20:59 |
| jelmer | mwhudson: that would suggest at least that the problem is not in the roundtripping | 20:59 |
| jelmer | mwhudson: although svk does often create very strange situations | 21:00 |
| poolie | hi jam? | 21:09 |
| poolie | hi all | 21:09 |
| jam | hi poolie | 21:09 |
| jam | good morning | 21:09 |
| poolie | shall we talk? | 21:13 |
| awmcclain | luks: What if I used bzrlib? I'm scripting the rev stuff, but it's from a python script | 21:22 |
| awmcclain | luks: Would that be faster? | 21:22 |
| luks | awmcclain: should be easy enough to write a plugin that does that | 21:23 |
| luks | oh, it's actually a python script | 21:24 |
| luks | yes, that should be easy | 21:24 |
| luks | not sure if I'm the best person to help though. my bzrlib knowledge is probably mostly obsolete by now :) | 21:25 |
| luks | I'd use something like wt.inventory[wt.path2id(filename)].revision | 21:28 |
| luks | but there is probably a better way now | 21:28 |
| awmcclain | thanks! | 21:29 |
| lifeless | awmcclain: bzr ls would be a good place to put that query | 21:35 |
| lifeless | awmcclain: in order to make it more easily scriptable | 21:35 |
| awmcclain | lifeless: Ah, smart. | 21:35 |
| awmcclain | What, you don't like bzr log settings.py | sed -n 2p | sed "s/revno: \([0-9]*\).*/\1/"? ;) | 21:36 |
| lifeless | awmcclain: not really, no. | 21:36 |
| lifeless | awmcclain: :) | 21:36 |
| === Noldorin is now known as Leto | ||
| === Leto is now known as LetoAtreidesII | ||
| === LetoAtreidesII is now known as LetoAtreidesI | ||
| === LetoAtreidesI is now known as Noldorin | ||
| jam | awmcclain: besides, grepping .bzr/checkout/dirstate would be a lot faster :) | 22:16 |
| igc | morning | 22:40 |
| mr-russ | in bazaar, can I merge a number of commits and push them as a single changeset to a parent tree? I can't find if you can in the documentation. | 22:43 |
| lifeless | mr-russ: bzr branch parent foo; cd foo; bzr merge source_branch; bzr commit; bzr push :parent | 22:45 |
| mr-russ | okay, so you merge from a branch which appears then as a single changset and push that. | 22:46 |
| mr-russ | so in bugfix lifecycle you branch for bugfix, make 10 commits to get it all fixed propertly. merge to you parent tree, then commit and push. | 22:46 |
| m3ga | hi all, i'm looking for a pre-commit hook that would check all the files in the current commit, check if they have a copyright notice and if they do check if the current year is included in the (c) notice. if its not it would barf. | 22:49 |
| mr-russ | okay, now conversely, how would you keep the entire commit history when pushing? push the child tree directly? | 22:51 |
| lifeless | mr-russ: yes | 22:53 |
| lifeless | mr-russ: no data is lost either way; its just what is presented | 22:53 |
| mr-russ | lifeless: thanks. I've been unable to find anything on that from google. | 22:56 |
| === nailuj24_ is now known as testuj5 | ||
| * igc bbl | 23:36 | |
| poolie | hi igc | 23:50 |
| poolie | hi m3ga | 23:50 |
| poolie | m3ga, i don't know if there is one like that | 23:50 |
| poolie | i think there is a plugin that enforces whitespace rules and similar things at commit time | 23:50 |
| poolie | and jml has one that checks for todo comments | 23:50 |
| poolie | so you could adapt one of them | 23:51 |
| jml | lp:bzr-todo | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!