| lifeless | spiv: seen poolie | 00:11 |
|---|---|---|
| lifeless | spiv: I think its because the command finding hooks have been cleared inappropriately | 00:12 |
| lifeless | spiv: and/or a chdir has been done inappropriately. | 00:12 |
| spiv | lifeless: hmm, quite likely. | 00:13 |
| spiv | lifeless: regarding poolie, I haven't seen/heard anything. | 00:14 |
| Noldorin | jelmer, hello? | 00:20 |
| jelmer | Noldorin, hi | 00:20 |
| Noldorin | hey | 00:21 |
| Noldorin | jelmer, any idea about that strack trace for bzr-svn? | 00:21 |
| jelmer | Noldorin, which stack trace? | 00:21 |
| Noldorin | jelmer, http://pastebin.com/m122b7c64 | 00:22 |
| Noldorin | did you catch any of the convo with spiv ? | 00:22 |
| jelmer | no, I haven't | 00:22 |
| Noldorin | that describes it all anyway...trying to push to an svn repo with bzr-svn | 00:22 |
| Noldorin | always worked until recently :S | 00:22 |
| jelmer | Noldorin: have you pushed to this codeplex repository before? | 00:23 |
| Noldorin | jelmer, yep, worked many times | 00:23 |
| Noldorin | and haven't really changed the bzr repo | 00:23 |
| Noldorin | it might have happened when i cancelled a push to svn one time :S | 00:23 |
| jelmer | Noldorin: remove the 'layout = None' bit in ~/.bazaar/subversion.conf | 00:23 |
| Noldorin | jelmer, it has guessed-layout = None | 00:24 |
| Noldorin | do i want to remove that? | 00:24 |
| jelmer | Noldorin: can you remove that ? | 00:25 |
| Noldorin | (or comment it out?) | 00:25 |
| Noldorin | ok | 00:25 |
| Noldorin | jelmer, ok, it's doing better now... | 00:26 |
| Noldorin | [- ] 208KB 3KB/s | analyzing repository layout:fetchi | 00:26 |
| poolie | hi spiv, lifeless? | 00:33 |
| Noldorin | jelmer, 1900KB now...seems to be going a bit long :/ | 00:33 |
| jelmer | Noldorin, it'll do the full repository analysis again now | 00:34 |
| Noldorin | fair enough | 00:34 |
| Noldorin | jelmer, so what's thie about layout...? why do i have to remove that line from the conf file? | 00:35 |
| jelmer | Noldorin: it contains the guess repository layout | 00:36 |
| jelmer | you had to remove it because it contained an invalid value (None) | 00:36 |
| Noldorin | ah | 00:36 |
| jelmer | not sure how that got in there though | 00:36 |
| Noldorin | so by default there shouldn't any there...? | 00:36 |
| spiv | poolie: good morning | 00:40 |
| jelmer | Noldorin: it should be there, it should just have the right value :-) | 00:40 |
| jelmer | Noldorin, does it work now? | 00:41 |
| Noldorin | jelmer, ah fair enough...still going | 00:41 |
| Noldorin | 3500KB now | 00:41 |
| Noldorin | what should be the right value? | 00:41 |
| jelmer | Noldorin: it'll be determined by bzr-svn automatically | 00:42 |
| Noldorin | ok | 00:42 |
| jelmer | or you can specify one - see "bzr help svn-layout" | 00:42 |
| Noldorin | fair enough. | 00:42 |
| Noldorin | heh, just waiting still. 4MB seems like an awful lot, and it's still going ... | 00:42 |
| lifeless | abentley: the fix for you has landed | 00:45 |
| lifeless | poolie: hi | 00:45 |
| Noldorin | jelmer, does this make sense that so much is being downloaded? 5.5MB now and 0/36100 | 00:50 |
| Noldorin | it looks like it's downloading the entire revision history of codeplex, hah :P | 00:56 |
| jelmer | Noldorin: No idea, sorry | 00:59 |
| jelmer | Noldorin: it might be a codeplex issue, I've seen issues with it before | 00:59 |
| Noldorin | ah right | 00:59 |
| Noldorin | hrm | 00:59 |
| Noldorin | no worries then. thanks anyway | 00:59 |
| jelmer | Noldorin: I | 01:12 |
| jelmer | 'm happy to help debug though | 01:13 |
| jelmer | Noldorin: If it keeps going, you might want to try again with -Dtransport | 01:13 |
| Noldorin | jelmer, ok i think i'll try that then | 01:14 |
| Noldorin | hmmm | 01:14 |
| Noldorin | it shows [####################/] now | 01:14 |
| Noldorin | does that mean it's almsot done? | 01:14 |
| Noldorin | jelmer, hmm? | 01:17 |
| spiv | Noldorin: it means we probably made the right decision to remove the progress bar in 2.1 ;) | 01:18 |
| Noldorin | spiv, hehe, fair enough | 01:18 |
| * Noldorin cancels it | 01:18 | |
| spiv | Noldorin: chances are it's making progress, but I couldn't say how long it would take | 01:19 |
| Noldorin | spiv, yeah. so i've run it with Dtransport now | 01:21 |
| Noldorin | what should i check? | 01:21 |
| spiv | Noldorin: that'll add a lot of debug output to ~/.bzr.log | 01:25 |
| Noldorin | ok | 01:25 |
| spiv | Noldorin: so you can monitor that and hopefully get an idea of what it's doing | 01:25 |
| Noldorin | "hopefully" | 01:25 |
| Noldorin | mm | 01:25 |
| Noldorin | spiv, http://pastebin.com/m67c3cc57 | 02:01 |
| Noldorin | that's what .bzr.log gives | 02:01 |
| Noldorin | spiv, any ideas? | 02:20 |
| jelmer_ | Noldorin, hi | 02:24 |
| jelmer_ | Noldorin, this is indeed a codeplex issue | 02:24 |
| jelmer_ | Noldorin, it's not behaving as a svn server should | 02:24 |
| Noldorin | hi jelmer_ | 02:24 |
| Noldorin | you read the pastebin eh? | 02:24 |
| Noldorin | hrmm | 02:24 |
| jelmer_ | yeah | 02:24 |
| Noldorin | yay for MS again | 02:24 |
| jelmer_ | any chance you can file a bug with them? | 02:24 |
| Noldorin | jelmer_, sure, if you tell me what to put in it :) | 02:24 |
| Noldorin | since i don't fully understand the source of the problem | 02:24 |
| jelmer_ | all I can say based on that pastebin is that it doesn't actually provide all data that is requested by the client when you do a log request | 02:25 |
| jelmer_ | If you specify the line that's being repeated in .bzr.log and your repository URL I should be able to help narrow that down | 02:26 |
| jelmer_ | I'm off again, back later | 02:27 |
| Noldorin | jelmer_, ok, thanks... | 02:27 |
| Noldorin | i'll try to submit that tomorrow | 02:27 |
| Noldorin | (late here, so i'm off to bed) | 02:27 |
| Noldorin | night | 02:27 |
| spiv | poolie: going to fetch mary, brb | 03:51 |
| poolie | k | 03:51 |
| lifeless | poolie: what version of subunit were you using when you had the problem stream on friday? | 03:56 |
| poolie | um | 04:01 |
| jelmer | uhm! | 04:02 |
| poolie | hello :) | 04:02 |
| poolie | are you at lca? | 04:02 |
| jelmer | hi :-) | 04:02 |
| jelmer | yep | 04:02 |
| jelmer | james_w: ping | 04:02 |
| poolie | lifeless: i think 0.0.4-4 | 04:02 |
| poolie | btw it has no __version__ | 04:02 |
| lifeless | poolie: yeah I should add one | 04:15 |
| lifeless | poolie: ok, well I still have no explanation then; its missing the xfail outcomes | 04:15 |
| lifeless | poolie: and I can't trigger the fault myself so far | 04:15 |
| xnox | Now when I run bzr I always get the pre-commit hook running | 04:33 |
| xnox | I don't believe I created any myself | 04:33 |
| xnox | how do I find out which out of my ~10 plugins is missbehaving? | 04:33 |
| * xnox wants to know what's it's doing | 04:33 | |
| lifeless | xnox: do you mean that qwhen you commit you see 'running pre commit hooks' | 04:34 |
| xnox | yeap | 04:34 |
| xnox | and sometimes it takes a while (on big binary blob commits) | 04:35 |
| xnox | lifeless: it wasn't there before... | 04:35 |
| lifeless | thats bzr telling you its at that point in the commit. It doesn't really mean anything in and of itself. Each prec ommit hook run will have its label printed out separately. | 04:35 |
| lifeless | xnox: you can however get a list of the installed hooks. | 04:35 |
| lifeless | uhm | 04:35 |
| xnox | oh my I do have quite a few hooks | 04:38 |
| lifeless | ok in python | 04:38 |
| lifeless | import bzrlib.plugins | 04:38 |
| xnox | I think I know what it is. I've enabled bzr search / index on this repo and it's activated on tip change | 04:39 |
| xnox | $bzr hooks | 04:39 |
| lifeless | import bzrlib.plugin | 04:39 |
| xnox | showed me =) | 04:39 |
| lifeless | bzrlib.plugin.load_plugins() | 04:39 |
| lifeless | bzrlib.branch.Branch.hooks['pre_commit'] | 04:39 |
| lifeless | yeah, that will too :) | 04:39 |
| === abentley1 is now known as abentley | ||
| * xnox says everyone on #bzr just love to do everything with bzrlib =) | 04:40 | |
| lifeless | however index is post_change_branch_tip | 04:40 |
| xnox | true | 04:41 |
| xnox | then I'm clueless | 04:42 |
| xnox | cause there are no post_commit hooks installed yet it stops there for while | 04:43 |
| xnox | bzrlib.branch.Branch.hooks['pre_commit'] is just a pointer and not callable | 04:43 |
| * xnox whatever is the real name for pointers in python "object in memory"? | 04:43 | |
| lifeless | reference | 04:44 |
| igc | hi all | 04:45 |
| xnox | aha! =) thank you | 04:45 |
| lifeless | whats the callbacks list though? | 04:45 |
| lifeless | I have to go, perhaps igc can help you :) | 04:45 |
| lifeless | ciao | 04:45 |
| === abentley1 is now known as abentley | ||
| xnox | lifeless: it's empty via bzrlib method also | 04:51 |
| xnox | callback=[] | 04:51 |
| xnox | =(((( | 04:51 |
| xnox | maybe another day | 04:51 |
| james_w | hi jelmer | 05:27 |
| jelmer | hey James | 05:30 |
| jelmer | james_w: can I upload current bzr-bd to sid? | 05:30 |
| james_w | sure | 05:30 |
| jelmer | james_w: would you be ok with 2.2 as version number for that, or would you rather see a 2.2~ ? | 05:52 |
| james_w | 2.2 is fine | 05:59 |
| james_w | jelmer^ | 05:59 |
| jelmer | james_w: thanks | 06:00 |
| james_w | no, thank you | 06:01 |
| jelmer | james_w: Is there still a debian branch somewhere with the Maintainer: etc set properly? | 06:06 |
| james_w | there may be one on bzr.debian.org | 06:07 |
| james_w | it's probably a fair way behind if it is | 06:07 |
| vila | hi all ! | 07:02 |
| james_w | salut | 07:03 |
| thumper | james_w: hey | 07:03 |
| james_w | hey thumper | 07:03 |
| thumper | james_w: you coming around? | 07:05 |
| james_w | yeah, I'm still writing | 07:05 |
| thumper | james_w: so is everyone here :) | 07:06 |
| james_w | you need me soon? | 07:06 |
| thumper | if you are getting more done there, feel free to finish first | 07:06 |
| james_w | thumper: we're just ordering some pizza, I'll come over post-prandially | 07:11 |
| vila | prandially: ENOTFOUND | 07:12 |
| james_w | vila: after eating | 07:13 |
| mwhudson | isn't "prandially" basically a frenchism? | 07:14 |
| vila | james_w: thanks :) I mostly deduced it from the context but my online dictionary raised the error above and I was wondering where the word was coming from.. | 07:14 |
| vila | mwhudson: It doesn't ring any bell.... | 07:15 |
| james_w | from the latin apparently | 07:16 |
| vila | oh, prandial, got it | 07:16 |
| vila | mwhudson: so the English jumped over the French for this one :) | 07:17 |
| mwhudson | ah | 07:17 |
| poolie | hello vila, mwhudson, james_w | 07:26 |
| vila | hey | 07:26 |
| james_w | hi poolie | 07:26 |
| mwhudson | hello poolie | 07:26 |
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://bazaar.canonical.com/ | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0b4 and 2.0.3 released | ||
| spiv | vila: hello patch pilot :) | 08:05 |
| vila | spiv: ;) | 08:05 |
| spiv | vila: I'm about to go on leave (I'll send mail about this shortly), so you may need to take care of https://code.edge.launchpad.net/~spiv/bzr/per-file-merge-hook-491711/+merge/17279 ;) | 08:06 |
| vila | spiv: before you left, I haven't yet look at your merge hook ... hehe good | 08:06 |
| vila | spiv: roughly, are you confident enough to land for 2.1.0rc1 or is it something for 2.2 ? | 08:07 |
| spiv | vila: I think it may actually be ready to land now | 08:07 |
| spiv | And I think it'd be good for 2.1.0rc1 | 08:07 |
| vila | ok | 08:07 |
| spiv | It's fairly low risk, I think. The bits that are likely to break are probably shallow. | 08:07 |
| vila | spiv: so you can fix them in your part-time ? ;-) | 08:08 |
| spiv | e.g. maybe the news_merge plugin might accidentally cause tracebacks on some corner case, and will need to be made a little more resilient to just giving up when that case happens. | 08:08 |
| spiv | vila: right ;) | 08:08 |
| spiv | The sooner it lands, the sooner any bugs will get shaken out, of course ;) | 08:09 |
| spiv | But it would be a useful feature to land for udd | 08:09 |
| spiv | Especially if someone at the sprint can write a debian/changelog merger (see my mail to the udd list) | 08:09 |
| vila | spiv: Yes I read that, I'll look into it asap | 08:09 |
| spiv | Having glanced at it again, I think it might actually be really easy... | 08:10 |
| spiv | I had been thinking it'd be good to do at the sprint, but maybe you'll just do it today ;) | 08:10 |
| spiv | (for someone other than me to do at the sprint, of course) | 08:10 |
| vila | spiv: I think it's a really good target for the sprint and will spread the knowledge better. | 08:12 |
| spiv | vila: *nod* | 08:12 |
| vila | spiv: but I'll note to land it | 08:12 |
| spiv | vila: thanks :) | 08:12 |
| mwhudson | james_w: hi | 08:14 |
| poolie | spiv/vila, what is? | 08:14 |
| mtaylor | spiv, vila: debian/changelog merger ++ | 08:14 |
| vila | poolie: per-file-merge-hook | 08:14 |
| poolie | that sounds good | 08:15 |
| poolie | vila, thanks for being patch pilot this week | 08:16 |
| * igc dinner | 08:17 | |
| * beuno waves at vila | 08:24 | |
| * vila waves at beuno | 08:24 | |
| * jelmer waves | 08:24 | |
| vila | beuno: you're abroad again right ? | 08:25 |
| vila | jelmer: You're never up that early so you're definitely abroad too :) | 08:25 |
| jelmer | vila: I'm in NZ :_) | 08:25 |
| spiv | mtaylor: Hopefully quite soon! :) | 08:25 |
| vila | bingo :) | 08:25 |
| spiv | mtaylor: I already have a bzr NEWS file merger :) | 08:26 |
| mtaylor | spiv: yippee!!! | 08:26 |
| mtaylor | spiv: as someone who does a lot of merging between packaging backport branches, I will welcome this new feature | 08:26 |
| spiv | But someone else will get to write the debian/changelog one I think, I'm about to become a parent :) | 08:26 |
| beuno | vila, no, I'm startiong early so I can finish early. I'm signing the contract to move into a new apartment | 08:27 |
| mtaylor | spiv: congratulations! | 08:27 |
| beuno | heya jelmer | 08:27 |
| vila | beuno: wow, *that's* early ! | 08:27 |
| vila | beuno: Congrats for the new apartment ! I'm happy to hear that ! | 08:28 |
| beuno | mwhudson, if you're around, I'm curious about LH's performance since the latest patch | 08:28 |
| spiv | mtaylor: thanks! | 08:28 |
| poolie | hello beuno | 08:28 |
| poolie | how nice to see you | 08:28 |
| mwhudson | beuno: it's been ok | 08:28 |
| beuno | hey hey poolie | 08:29 |
| beuno | mwhudson, significantly more stable? or "meh"? | 08:29 |
| mwhudson | beuno: hard to say at this stage | 08:30 |
| mwhudson | beuno: perhaps a little better | 08:30 |
| poolie | spiv, I am asked to approve or disapprove of your paternity | 08:38 |
| poolie | that's kind of a big question :) | 08:38 |
| jelmer | beuno: Yes, congrats! | 08:40 |
| beuno | jelmer, how's LCA? | 08:41 |
| jelmer | beuno: Nice :-) Preparing our talks for tomorrow's miniconf at the moment. | 08:41 |
| vila | spiv: so regarding per-file-merge-hook, I think you addressed jam's remarks but I'd wait for his comments/approval before landing | 08:55 |
| poolie | vila, tanks for the progress review | 08:56 |
| vila | ta | 08:58 |
| === gerard_1 is now known as gerard_ | ||
| mwhudson | james_w: i'm trying to use bzr-builder and failing | 09:01 |
| mwhudson | james_w: it would be good to fix this before tomorrow :-) | 09:01 |
| === abentley1 is now known as abentley | ||
| spiv | vila: great, thanks :) | 10:21 |
| vila | spiv: I'm reviewing right now, a couple of tweaks so far, nothing serious. | 10:22 |
| vila | spiv: I really like your refactorings... | 10:23 |
| spiv | vila: phew :) | 10:27 |
| vila | spiv: done. | 10:35 |
| lifeeth | Hello folks.. I was wondering if there was a bzr utils suite that can be used without installation on windows? | 11:09 |
| spiv | lifeeth: what do you mean by "utils suite"? | 11:10 |
| lifeeth | I mean just the bzr.exe | 11:10 |
| spiv | lifeeth: there are a fair few plugins available that don't need speicial installation. | 11:10 |
| spiv | Oh, hmm. | 11:11 |
| spiv | Not sure, sorry :/ | 11:11 |
| lifeeth | Ok.. | 11:11 |
| lifeeth | Need to package it with a portable app -- so was wondering if there was just one executable that can be used | 11:11 |
| flavour | Cool, there is a channel :) | 11:35 |
| flavour | Apply change? [yNfq?] | 11:35 |
| flavour | on bzr merge -i | 11:35 |
| flavour | What is the 'f' for? | 11:35 |
| flavour | Please tell me it's 'forget' | 11:35 |
| flavour | As in 'don't commit this change & then don't bug me about it again' | 11:35 |
| flavour | I have a criss-cross merge | 11:36 |
| maxb | I suggest you press '?' | 11:37 |
| flavour | maxb thanks | 11:46 |
| flavour | What does 'finish' mean then? Same as my hoped-fr 'forget'? | 11:47 |
| flavour | Or just 'stop processing more files, but process the ones already 'y''d? | 11:47 |
| === Peng___ is now known as Peng_ | ||
| spiv | flavour: the latter, IIRC, but I can never remember... | 11:48 |
| flavour | So is there any way of telling Bzr to 'never hassle me about this change again'? | 11:48 |
| flavour | Any other way of cleanign a criss-cross merge other than one side dleeting & repulling afresh? | 11:48 |
| tumbleweed | flavour: bzr revert, bzr revert --forget-merges ? | 11:49 |
| flavour | Well, I want to keep 2 LP branches in sync | 11:49 |
| spiv | flavour: never in which sense? If you do regular (non-cherrypick) merge, and resolve it and then commit it, then the next time you merge those changes will not be reconsidered. | 11:49 |
| flavour | Syncing often (coding for Haiti) | 11:49 |
| flavour | If I do a normal merge then I will lose a whole bunch of changes | 11:50 |
| flavour | Which I'll have to reapply manually | 11:50 |
| spiv | Lose in what sense? | 11:50 |
| flavour | Well, the incoming merge wants to revert a whole bunch of changes I just made | 11:50 |
| spiv | Well, you can revert those files before committing. | 11:50 |
| flavour | So I'd have to reapply the change again to each of the files | 11:50 |
| spiv | i.e. "bzr merge ../other-branch; bzr revert file1 file2; bzr commit" | 11:51 |
| flavour | Then it'll hassle me about merging again next time I think | 11:51 |
| spiv | No, it won't. | 11:51 |
| flavour | I'll try it, thanks :) | 11:51 |
| spiv | So long as "bzr st" shows a pending merge. | 11:51 |
| spiv | Then bzr will remember that you've merged in that revision (and thus all the parent revisions of that, too). | 11:52 |
| spiv | And it won't try to remerge them. | 11:52 |
| spiv | criss-crosses can make it hard to determine which changes are already merged, but even then "bzr merge --lca" tends to do a pretty good job. | 11:53 |
| tumbleweed | question I asked on the weekend (when the channel was dead). We are doing a big code-reorganisation. Some files can be "bzr mv"ed. But there's a lot of movement of things from one file to another. No way to carry history, right? | 11:54 |
| Peng | tumbleweed: Right. | 11:56 |
| spiv | tumbleweed: right, unfortunately. | 11:56 |
| tumbleweed | thanks | 11:56 |
| Peng | tumbleweed: If you're moving the majority of a file, it may make sense to "bzr mv" it then create a new file. (You can do that in the same revision. I think.) | 11:56 |
| tumbleweed | yeah, unfortunatly that only goes so far | 11:57 |
| spiv | (Although someone might in the future write a fancy tool to analyze the history later and use heuristics to track code moves across files, that doesn't exist yet.) | 11:57 |
| flavour | http://paste.pocoo.org/show/166677/ | 11:57 |
| flavour | -lca made no difference to me unfortuantely...I tried it | 12:00 |
| flavour | I know clearly which files should 'win' | 12:00 |
| flavour | with only minor tweak | 12:00 |
| flavour | But a lot of files | 12:00 |
| flavour | Rest of the files reverted ok, but not this one | 12:00 |
| spiv | flavour: that "input line too long" is a weird error, I assume there's something wacky happening with your shell of environment. | 12:00 |
| spiv | s/of/or/ | 12:00 |
| flavour | Win32, so what do I expect? ;) | 12:01 |
| spiv | flavour: I expect weird voodoo that I can't diagnose for you :) | 12:01 |
| flavour | now getting it with just bzr ver | 12:01 |
| flavour | Let me cycle the shell | 12:01 |
| spiv | flavour: I'd suspect you have something that's growing an environment variable or alias every time you run 'bzr' | 12:02 |
| flavour | yeah, that fixed it | 12:02 |
| flavour | cmd window exhausted | 12:02 |
| flavour | Looks good...am going to docuemnt this for future & try it on some other branches I have probs with - many thanks! | 12:33 |
| michaelis | Hi. I could use some help organizing my project. Does anyone have some time to spare? | 12:53 |
| michaelis | I only have a couple of questions and it will probably not take more than 5-10 minutes. | 12:55 |
| Peng | michaelis: Someone might, but you'd have to ask your questions to find out. :P | 12:58 |
| michaelis | I was thinking a private chat session but I can post my questions here. | 12:59 |
| === mrevell is now known as mrevell-lunch | ||
| Peng | I, for one, don't know enough to want to talk one-on-one, but I might be able to contribute a little bit of you ask in the channel. | 13:05 |
| rubbs | Peng: is correct... usually it's best to ask the group. that way different people can weigh in and help out with your problems | 13:06 |
| rubbs | if you're worried about hogging the channel... don't worry, it's usually not that busy. | 13:06 |
| Peng | Besides, that's what the channel is for. | 13:07 |
| vila | spiv: I'm not sure I understand the meaning of "That's very much for the extra review.", is it "you're asking too much" or "you reviewed a lot" ? | 13:08 |
| vila | spiv: or yet another meaning ? ;) | 13:08 |
| michaelis | I work in a municipality with water distribution/cleaning and we have many files that we would like to version control. It's everything from simple text documents, pdf's to PLC programs. Since there are many facilities and every facility has its own set of documents, every facility, according to me, is organized as a shared repository. Thereafter every specific set of directory, such as e.g.... | 13:10 |
| michaelis | ...PLC programs, are organized as a shared repository beneath the previous one. Finally, every PLC program in the facility is a branch with a working tree. Could this work? | 13:10 |
| michaelis | The most simple thing would be if you could checkout only part of a working tree but since this isn't possible I have to come up with something else. | 13:12 |
| * rubbs goes and gets some pen an paper. | 13:13 | |
| rubbs | I am too visuall of a person... I have to draw that out. | 13:13 |
| rubbs | just a sec. | 13:13 |
| bialix | michaelis: what is the question? | 13:17 |
| bialix | many nested repos with branches? | 13:17 |
| bialix | yes, this will works | 13:17 |
| bialix | but what your intent? | 13:17 |
| michaelis | How should I organize it in the most convenient way. | 13:17 |
| bialix | it depends | 13:17 |
| bialix | convenient for what? | 13:18 |
| rubbs | michaelis: is this what you are thinking? | 13:18 |
| rubbs | http://paste.ubuntu.com/358487/ | 13:18 |
| bialix | do you want to combine several branches as the complex project? | 13:18 |
| rubbs | michaelis: I think that's what he means... each Facility is a project of several branches | 13:18 |
| rubbs | er | 13:18 |
| rubbs | bialix: ^ | 13:19 |
| michaelis | Thats right. | 13:19 |
| bialix | makes sense for me, rubbs | 13:19 |
| rubbs | ok, so you may be looking for the SCM plugin. | 13:19 |
| bialix | michaelis: where is your branches there? | 13:19 |
| michaelis | Since I can't checkout parts of wokring tree I have to make every specific part of the facility a branch. | 13:19 |
| bialix | scmproj plugin | 13:19 |
| rubbs | michaelis: that's correct. you'd have to made each part a branch. | 13:20 |
| bialix | michaelis: that's right, dvcs require you to think in the term of entire tree, not subdirectories | 13:20 |
| michaelis | Another thing, I run bzr in a windows environment with the gui explorer. | 13:20 |
| bialix | michaelis: TortoiseBzr or bzr-explorer? | 13:20 |
| michaelis | Bzr-explorer. | 13:21 |
| bialix | both are ok | 13:21 |
| rubbs | mmm... bialix you run the scmproj right? I'm not sure how that works with guis | 13:21 |
| rubbs | ah... cool | 13:21 |
| bialix | if you will want to use scmproj you need to make some operations via console or qrun dialog | 13:22 |
| bialix | rubbs: there is no GUI for scmproj yet | 13:22 |
| michaelis | I myself am not afraid of running the shell version but it has to manageable by others. | 13:22 |
| bialix | michaelis: bzr-explorer has feature of open the directory with nested branches as some sort of the project | 13:22 |
| michaelis | But the others will mostly checkout and commit. Can I the use scmproj? | 13:23 |
| bialix | so if you open fac1 or fac2 you should see all nested branches | 13:23 |
| bialix | if others will work only in separate branches then scmproj will be mostly transparent for you | 13:24 |
| michaelis | bialix: Exactly. Now when they open fac1 they see yet another shared rep with e.g. blue prints and below that there are a set of branches for every device in that fac. | 13:25 |
| bialix | scmproj may help you to define directory structure for your branches (I calling them components in scmproj) and easily get entire project from the server for local work | 13:26 |
| bialix | also you can commit several branches at once, or push changes of the project back to the server | 13:26 |
| bialix | so only 1st step (get project for local work) is important. After that your colleges may work in separate branches | 13:27 |
| michaelis | My colleges main interest is to checkout one branch at a time, make modifications to it, and then commit the changes. | 13:28 |
| michaelis | There hardly will be any multibranching work going on. | 13:29 |
| bialix | if so then do you need a requirement to recreate the structure from http://paste.ubuntu.com/358487/ somewhere locally? | 13:30 |
| bialix | or you just need to select the way how to keep your branches on the server? | 13:31 |
| michaelis | The structure must be on the server. How my colleges organize it locally is not my problem. | 13:32 |
| bialix | then you can keep all related branches (PLC programs, text, pdf) in the separate shared repositories with branches for each facility | 13:33 |
| bialix | is it enough for you? | 13:33 |
| michaelis | Yes. | 13:33 |
| bialix | then you don't scmproj at all | 13:34 |
| bialix | don't need | 13:34 |
| michaelis | But if you look in http://paste.ubuntu.com/358487/ then fac1 and PLC are shared rep according to me. PLC_prog1 and PLC_prog2 are branches. | 13:36 |
| michaelis | They have to be able to checkout PLC_prog1 and PLC_prog2 seperatly. | 13:37 |
| bialix | you said you don't need this structure on the server | 13:38 |
| michaelis | seperatly = separately | 13:38 |
| michaelis | I obviously misunderstood you. | 13:38 |
| bialix | you don't need fac1 and fac2 | 13:38 |
| bialix | You need only PLC - shared repo, PLC_prog1 and prog2 as branches | 13:39 |
| bialix | docs -shared repo, and nested branches | 13:39 |
| bialix | and so on | 13:39 |
| bialix | remove from the picture work and fac1 | 13:39 |
| bialix | remove them as levels | 13:39 |
| bialix | and you'll see both fac1 and fac2 are the same | 13:39 |
| michaelis | I misunderstood you. Since there are more than 200 fac here I need them to be represented as shared rep. | 13:40 |
| bialix | you're on the road to troubles | 13:40 |
| bialix | does your fac have something in the common? | 13:40 |
| michaelis | Otherwise every branch will be called fac1 - plc_prog1, fac2 - plc_prog1 and so on. There will be more than a thousand branches in the explorer window. | 13:40 |
| michaelis | They all lie in the same country... ;D | 13:41 |
| bialix | I suggest you keep fac1 as one unite branch then | 13:41 |
| rubbs | michaelis: you could still do this... but nesting shared repos isn't going to help you much (I think) | 13:41 |
| michaelis | That was the idea from the beginning and my question was if there was any other way than having fac1 as a shared rep. | 13:42 |
| bialix | no | 13:42 |
| bialix | fac1 should be a branch | 13:42 |
| rubbs | you could do a shared repo at the PLC/docs/txt levels, but adding another at the fac level isn't going to help you much | 13:42 |
| michaelis | Indeed. | 13:43 |
| bialix | you won't checkout the subdir of that branch, but that's better than thousands of branches | 13:43 |
| rubbs | but if he has lots of stuff within each fac# then a big branch isn't really helpful either | 13:43 |
| michaelis | I have to take a 15 min tea break and talk to my colleges. I'll be back in 15. | 13:43 |
| michaelis | Thanks for the help so far. | 13:44 |
| rubbs | k... I'll brainstorm a little | 13:44 |
| bialix | the views maybe help? | 13:44 |
| rubbs | mmm... maybe. I"m wondering if pulling all that history down is going to be a problem. | 13:45 |
| bialix | if there is local network it won;t be a main problem | 13:47 |
| rubbs | does bzr know if a shared repo is a few dirs up? I guess I'm asking because if he creates a shared repo at /work and has folders for each facility, then he could have branches | 13:47 |
| rubbs | bialix: I think he said it was all over the country. | 13:47 |
| Peng | rubbs: Bazaar looks all the way up to the root for shared repos, and uses the first it finds. | 13:47 |
| rubbs | cool... so what if he put just one shared repo at the top of his dir structure and divided his branches out the way he wanted | 13:48 |
| rubbs | the fac# level directories don't have to be branches themselves, they are just there for organization right? | 13:48 |
| * rubbs forgot that michaelis is on break. | 13:48 | |
| rubbs | My guess is that nesting a shared repos isn't going to save you room. i.e. a shared repo doesn't look to see if there is a shared repo above it. | 13:49 |
| michaelis | I'm back. | 14:31 |
| michaelis | That was a long 15 minutes. | 14:31 |
| rubbs | ha... it happens | 14:33 |
| rubbs | so my question is (since nesting shared-repo's isn't going to help) is there something wrong with having a shared repo at the top, and having the fac1 and PLC directories as just directories? That way you could have the projects in their own branches and use the dir structure to organize them | 14:34 |
| michaelis | The problem is that when a college want's to check out blue prints for a specific object and and I want to check out a PLC-program we both end up checking out the same branch even tough this shouldn't be necessary. | 14:38 |
| michaelis | Or maybe I didn't understand you. | 14:39 |
| michaelis | The way I see it it will have to be: fac1 - shared rep, blueprints in fac1 - shared repo, an object specific blueprint in blueprints in fac1 - branch, so that there's only the possibility of checking out blueprints concerning one object at a time. | 14:41 |
| rubbs | right... | 14:41 |
| rubbs | let me illustrate what I mean... | 14:42 |
| * rubbs goes to pastebin again... just a sec. | 14:42 | |
| === salgado is now known as salgado-lunch | ||
| rubbs | http://paste.ubuntu.com/358522/ | 14:43 |
| rubbs | a little messy, but I think that should show what I meant.. | 14:44 |
| rubbs | if you wanted to check out a txt doc from fac1 and a college wanted to checkout plc_2 from fac1 those would be separate branches | 14:44 |
| rubbs | but to you, they would be organized by fac | 14:44 |
| rubbs | there is no need to have a shared repo at each dir level. that wouldn't save you any space. | 14:45 |
| michaelis | That is a good idea. | 14:45 |
| rubbs | bzr also keeps all individual information that is different in it's own branch, so you would get all the space saving of the shared repo but the flexibility of differing projects | 14:45 |
| michaelis | How would this look like in bzr-explorer. | 14:45 |
| rubbs | bzr-explorer would not know the dir structure intelligently. It would only know about each individual branch at a time. | 14:46 |
| rubbs | but each branch could be kept in it's own tab. | 14:47 |
| rubbs | so bzr-explorer would only know about /work/fac1/PLC/plc1 but won't know anything about /work/fac1/PLC/plc2 unless you opened a tab to that location. | 14:49 |
| michaelis | I don't see how I can omit the "thousand branches in explorer" problem. | 14:49 |
| rubbs | do you need to have them all open all the time? | 14:49 |
| michaelis | First I create a shared repo "work". | 14:49 |
| rubbs | right | 14:49 |
| michaelis | Then I create a branch at location work/fac1/blueprints/object_blueprint | 14:50 |
| rubbs | right | 14:51 |
| michaelis | So that object_blueprint has it's own work tree. | 14:51 |
| rubbs | correct. | 14:51 |
| rubbs | the idea of the shared repo isn't like a repo in svn. It's just a place that common revisions can be stored to save space... | 14:52 |
| michaelis | But if I have 200 fac and 5 subdirs in each fac then I will have 1000 branches in a non hierarchical structure, or have I misunderstood something here? | 14:53 |
| rubbs | You would have have some sort of heirarchy, but it would be via the system's directories. | 14:54 |
| michaelis | I understand. | 14:54 |
| rubbs | so to check out any branch, I would just have to know the dir structure. | 14:54 |
| michaelis | That was my main concern. How to present the branches in a well structured order. | 14:55 |
| rubbs | as far as bzr is concerned, it doesn't care where the branch is, so you can organize your branches in any dir structure you want. You just have to point bzr to the branches location, and it will work | 14:56 |
| michaelis | I could create a shared repo for every fac and by doing so my colleges would, naturally, work with one fac at a time. | 14:56 |
| rubbs | are you looking at a centralized workflow then? like having only checkouts and not branches? | 14:56 |
| michaelis | Yes I had figured that out but I was hoping to not have thousands of branches in the bzr-explorer. | 14:57 |
| michaelis | Explain the concept of centralized workflow to me. | 14:57 |
| michaelis | The files on the server should be the latest ones and if you want to make any changes you check them out, modify them, and then commit them to the server again. That is the workflow I had in mind. | 14:58 |
| michaelis | So yes, some sort of centralized workflow is needed. | 14:58 |
| rubbs | so like svn, centralized workflows usually mean that I'm only working with one revision on the tree. I "checkout" code and work on it and when I commit, it gets sent to that central location. It's sometimes called lock-step development. De-centralized -hybrid approach would be that there is a central branch, but I have my own branch. I do my work in my branch and when I'm ready to I merge in my changes (I can do several commits before merging) | 14:59 |
| rubbs | you were looking at a central -lock-step development workflow then. | 15:00 |
| michaelis | Yes it seems so. | 15:00 |
| rubbs | bzr is really designed for branching (whole history, not just one revision) and working on the branch. Then when you want, you merge your changes back into the central location. | 15:00 |
| rubbs | if I have a branc, and you have a branch, and we both work on the same project we can merge our changes... | 15:01 |
| rubbs | it allows for more concurrent development | 15:01 |
| rubbs | I can work on fac1 and you can too | 15:01 |
| rubbs | I merge my changes in.. | 15:01 |
| rubbs | then when you are ready you can merge yours in. | 15:02 |
| michaelis | I see. But what happens if we work on the same dwg file? | 15:02 |
| rubbs | the beauty of it is that with the merge, we both can work on it, and not have to worry about being "out of date" every time we commit | 15:02 |
| rubbs | that is where some intelligent merging is needed. | 15:02 |
| rubbs | so bzr will look and see that you and I worked on the same file | 15:02 |
| rubbs | it will then tell you that there was a conflict and ask you to resolve them. | 15:03 |
| rubbs | (this assumes I merged first) | 15:03 |
| rubbs | you then look at the dwg file and see what the differences were. | 15:03 |
| michaelis | Naturally. Then we would have to solve the conflict "manually". | 15:03 |
| rubbs | right | 15:03 |
| rubbs | this is the same with just about any VCS thought | 15:03 |
| rubbs | though* | 15:03 |
| rubbs | All of this stuff is possible with SVN or others, but bzr, git, and mercurial are best at merging. | 15:04 |
| rubbs | It's the merging that allows for people to work at the same time on the same project. | 15:04 |
| rubbs | if you have your 1000's of branches organized it shouldn't matter who is using what | 15:05 |
| michaelis | No of course not. | 15:05 |
| rubbs | just merge in and manually take care of conflicts as they come up | 15:05 |
| rubbs | To present your branch structure (organization) to your colleages, you would just have to let them know the dir structur | 15:05 |
| rubbs | structure* | 15:06 |
| michaelis | I get the point. But it would be much easier if we could check out parts of a working tree instead of having to check out a whole branch. | 15:06 |
| rubbs | then I would look at something like SVN. bzr won't be able to do that for you :( | 15:06 |
| michaelis | But that isn't posibble. | 15:06 |
| michaelis | I understand. | 15:06 |
| rubbs | I'm not sure if this helps, but bzr also uses views | 15:07 |
| rubbs | so you would have all of your branch there, but with views it masks away things you don't care about. | 15:07 |
| michaelis | That sounds interesting. | 15:07 |
| rubbs | so if you had the branches at the fac level, then you could create a view that hides everything except the PLC directory or something to that effect | 15:08 |
| michaelis | I wonder if it is possible to set views up in the bzr-explorer. | 15:08 |
| rubbs | I'm almost certain you can. I'd have to check. | 15:08 |
| rubbs | just a sec. | 15:08 |
| rubbs | also if igc is on, he's the main dev on bzr-explorer | 15:08 |
| rubbs | ping igc | 15:08 |
| michaelis | He is away. | 15:09 |
| rubbs | ah... thanks | 15:09 |
| rubbs | mmm... doesn't seem to have a gui button for doing it, but I could be wrong. | 15:12 |
| rubbs | I'm not giving up on that yet though. | 15:12 |
| michaelis | You keep on fighting! ;D | 15:12 |
| === stefanlsd_ is now known as stefanlsd | ||
| rubbs | ha | 15:13 |
| rubbs | well, I know that if you created the view, that bzr-explorer would support it. So if you masked off everything except PLC dir it would only show PLC in explorer, but I'm unsure of how to set it. | 15:16 |
| rubbs | it might have to be in a command line argument... but I think you can even do those within bzr-explorer | 15:17 |
| michaelis | I see. | 15:18 |
| michaelis | I have learned a lot and I will take this newly achieved knowledge and make the best of it. Thanks for the help. | 15:21 |
| rubbs | np. | 15:21 |
| michaelis | I'll come back for more talk about views. | 15:21 |
| rubbs | i don't know if youw ant, but you could email igc he could help much more with bz-rexplorer | 15:21 |
| rubbs | great! | 15:21 |
| michaelis | Maybe I'll do so. | 15:22 |
| rubbs | do you know igc's email? | 15:22 |
| michaelis | I thought I would get it from a simple whois but that was not the case. | 15:22 |
| rubbs | ian.clatworthy@canonical.com | 15:22 |
| michaelis | Do you have it? | 15:22 |
| rubbs | he should be able to help ^ | 15:22 |
| michaelis | Thank you. | 15:23 |
| michaelis | Thanks again and bye for now. | 15:24 |
| rubbs | bye, good luck! | 15:24 |
| michaelis | Thank you. | 15:24 |
| aquarius | I have a branch of the trunk of a project. At some point in the past, a change was introduced that broke another project that uses this one. What I want to do is: run the main project test suite; if the tests fail, step back one bzr revision in the subproject, repeat. | 15:44 |
| aquarius | how do I do the "step back one revision" bit? :) | 15:44 |
| tumbleweed | bzr uncommit? | 15:44 |
| tumbleweed | (you'll have to follow it with a bzr revert) | 15:45 |
| rubbs | you could also branch at a revision | 15:45 |
| aquarius | ooh, so just "bzr uncommit; bzr revert",repeatedly. That's ideal. | 15:45 |
| rubbs | also you could look at the bzr-bisect plugin | 15:45 |
| rubbs | it's built to do just exactly what you are looking for | 15:45 |
| aquarius | rubbs, I could do, yeah, but I don't know which revision has the problem, and looking up all the revnos is fiddly | 15:46 |
| rubbs | bzr bisect is supposed to emulate the git bisect functionatility | 15:46 |
| rubbs | aquarius: it's automatic | 15:46 |
| aquarius | I assumed it was. I don't really understand git bisect :) | 15:46 |
| Peng | You don't have to uncommit if you only want to revert the working tree... | 15:46 |
| aquarius | rubbs, how is it automatic? | 15:46 |
| Peng | Even without a bisect plugin, it's easy to do a binary search yourself. | 15:47 |
| aquarius | rubbs, I just do bzr branch lp:project the-revision-that-broke-it and it works? :) | 15:47 |
| rubbs | at least I think it's automatic... the git version is. | 15:47 |
| rubbs | you write a short script to run your test... have it return 0 if works and 1 if doesn't | 15:47 |
| aquarius | peng, hang on, not sure I understood that | 15:47 |
| rubbs | it will go through your history in a binary search and find the revision in which it changed | 15:48 |
| rubbs | admittely I didn't do it auto matically with bzr. just manually (I didn't have a lot of history) | 15:48 |
| rubbs | aquarius: he means find any revision that is working (liek the first one) and find one that isn't (like the last one) | 15:48 |
| aquarius | man, I'm prepared to do it the stupid drone way rather than anything clever ;) | 15:48 |
| rubbs | then pick the revision that is in the middle of the two, and do the test | 15:49 |
| tumbleweed | aquarius: http://doc.bazaar.canonical.com/plugins/en/bisect-plugin.html | 15:49 |
| rubbs | if it doesn't work, it's in between the first and the middleone. | 15:49 |
| aquarius | yeah, I get roughly how a bisect works | 15:49 |
| aquarius | but there are only, like, nine revisions I need to check. This is not the kernel we're talking about here ;) | 15:50 |
| tumbleweed | heh | 15:50 |
| rubbs | even then. a bisect is still faster. | 15:50 |
| aquarius | I shall bzr uncommit && bzr revert my way backwards until I work it out | 15:50 |
| rubbs | you can say.. revision 12 is good, revision 19 is bad | 15:50 |
| aquarius | not when you take into account that I have to work out how to do it :) | 15:50 |
| rubbs | it can help you find it quicly | 15:50 |
| Peng | You don't need to uncommit. Just "bzr revert -r 123". | 15:50 |
| rubbs | aquarius: fair enough. Peng is correct, you can just revert your tree, no need to uncommit | 15:51 |
| Peng | Doing a manual binary search is really easy. If you know it's between revisions 10 and 20, revert to 15, run the test. If it succeeds, revert to 17 and try again, ... | 15:51 |
| aquarius | yep, and that's now precisely what I'm doing :) | 15:59 |
| aquarius | thanks! | 15:59 |
| rubbs | np. | 15:59 |
| === salgado-lunch is now known as salgado | ||
| lornajane | can someone help me? I'm just starting to use bzr and I'm confused! I have changed a few files, but I don't want to commit all of them | 16:01 |
| lornajane | how can I tell bzr which files should be in this commit? | 16:01 |
| rubbs | lornajane: you can do a few things. You can do a commit and list the files. | 16:02 |
| rubbs | so like if you have file1 file2 and file3 and you only want to commit the first two you can do this | 16:03 |
| rubbs | bzr commit file1 file2 | 16:03 |
| lornajane | rubbs: that's how I would do it with svn - but it complained that I also have files that aren't added | 16:03 |
| lornajane | surely that's my problem, not bzr's problem? :) | 16:03 |
| rubbs | have you created new files in this revision? | 16:04 |
| rubbs | or possibly moved one of the files? | 16:07 |
| lornajane | rubbs: I have created new files in my working copy and not added them yet, I don't need to include them in this commit | 16:12 |
| lornajane | I guess I can just add them though | 16:12 |
| rubbs | lornajane: no | 16:13 |
| rubbs | do'nt add them | 16:13 |
| rubbs | you can shelve them | 16:13 |
| rubbs | so do this: bzr shelve name_of_files | 16:13 |
| rubbs | that will "stash them away" then do your commit... then do a bzr unshelve and they come back | 16:13 |
| lornajane | oh, that's cool! | 16:13 |
| lornajane | I should do that with my config files | 16:14 |
| rubbs | I love it... use it more than I care to admit | 16:14 |
| lornajane | stuff like this is why I need to get out of my svn rut :) | 16:14 |
| rubbs | alternatively, if you know you're never going to want to commit them, you can add them to your ignore config (bzr ignore name_of_file) | 16:14 |
| rubbs | also to learn more about shelve (really cool feature IMO) just run bzr help shelve and that will tell you everything you need to know! | 16:15 |
| lornajane | yes, I have bonded with bzr help - using bzr-svn because I travel so much with dodgy connection (on the train, for example) and the help has been surprisingly helpful | 16:16 |
| lornajane | and the command naming is close enough to subversion that I can find things | 16:16 |
| rubbs | yeah... when I don't know what to search on, I just do bzr help topics and I usually find what I need | 16:18 |
| gerard_ | anyone working on bug #395514 ? ( https://bugs.launchpad.net/bzr/+bug/395514 ) | 16:24 |
| ubottu | Ubuntu bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed] | 16:24 |
| ubottu | Launchpad bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed] https://launchpad.net/bugs/395514 | 16:24 |
| gerard_ | ah, good bot | 16:24 |
| alamati | Hi all | 16:50 |
| alamati | my native lang is not english, sorry | 16:51 |
| alamati | I have problem with bzr | 16:51 |
| rubbs | what is your problem? | 16:51 |
| alamati | when I enter: bzr pull | 16:51 |
| alamati | alamati@ThinkPad:~/Desktop/transmission$ bzr pull | 16:52 |
| alamati | Using saved parent location: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/ | 16:52 |
| alamati | No revisions to pull. | 16:52 |
| alamati | I got that message | 16:52 |
| alamati | but I sure that there are new codes | 16:52 |
| Peng | What's the problem? | 16:52 |
| Peng | Oh. :D | 16:52 |
| rubbs | can you tell me what the output of bzr revno is? | 16:53 |
| Peng | alamati: How do you know there are new revisions? | 16:53 |
| alamati | alamati@ThinkPad:~/Projects/transmission$ bzr revno | 16:54 |
| alamati | 8457 | 16:54 |
| alamati | bzr missing | 16:54 |
| rubbs | he's right, his tree is out of date | 16:54 |
| alamati | how I can update? | 16:54 |
| rubbs | trunk is at 8465 | 16:54 |
| alamati | yes yes | 16:54 |
| Peng | alamati: Try running "bzr update" | 16:54 |
| Peng | It *probably* won't do any damage. :D | 16:55 |
| alamati | alamati@ThinkPad:~/Projects/transmission$ bzr update | 16:55 |
| alamati | Tree is up to date at revision 8457. | 16:55 |
| alamati | I trust you :D | 16:55 |
| alamati | humm | 16:56 |
| rubbs | does bzr status say anything? | 16:56 |
| alamati | no | 16:56 |
| idnar | alamati: I notice you changed from ~/Desktop/transmission to ~/Projects/transmission there | 16:56 |
| idnar | did you move the directory, or do you have two of them? | 16:57 |
| alamati | exactly right | 16:57 |
| * rubbs will be right back. | 16:57 | |
| alamati | I move the directory | 16:57 |
| idnar | okay | 16:57 |
| alamati | what do I do? | 16:59 |
| idnar | I'm not sure what the problem is, hopefully somebody else will have an idea | 17:00 |
| alamati | thanks | 17:00 |
| Peng | alamati: Just to be sure, does "bzr info" say it's a standalone or repository branch? | 17:01 |
| rubbs | alamati: did you just want to make this branch be *exactly* like the one at bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/? | 17:01 |
| rubbs | oh, do what Peng says first | 17:02 |
| alamati | I did | 17:02 |
| alamati | alamati@ThinkPad:~/Projects/transmission$ bzr update | 17:02 |
| alamati | Tree is up to date at revision 8457. | 17:02 |
| rubbs | no do bzr info | 17:03 |
| alamati | yes I want to make this branch similar at official repo | 17:03 |
| rubbs | that tells us things about the branch you have, not if it's up to date | 17:03 |
| alamati | alamati@ThinkPad:~/Projects/transmission$ bzr info | 17:03 |
| alamati | Standalone tree (format: unnamed) | 17:03 |
| rubbs | if we can't find out what is wrong from bzr info, then I can tell you how to make it work. | 17:03 |
| alamati | Location: | 17:03 |
| alamati | branch root: . | 17:03 |
| alamati | Related branches: | 17:03 |
| alamati | push branch: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/ | 17:03 |
| alamati | parent branch: bzr+ssh://bazaar.launchpad.net/~vcs-imports/transmission/trunk/ | 17:03 |
| alamati | alamati@ThinkPad:~/Projects/transmission$ | 17:03 |
| rubbs | alamati: I can't seem to find out what is wrong with it, so we are going to try to overwrite the branch and pull the lastest from bzr... so do this: bzr pull --overwrite | 17:04 |
| rubbs | this will make it *exactly* like it is on launchpad. | 17:05 |
| Peng | Worst case, you can at least make a new temporary branch to work in: cd ~/Projects; bzr branch transmission transmission2; cd transmission2; bzr pull --remember lp:transmission | 17:05 |
| alamati | Oh woow | 17:07 |
| rubbs | but then his tree still wouldn't reflect the trunk | 17:07 |
| alamati | I can upgrade to latest revision | 17:07 |
| rubbs | so you figured it out? you solved your problem? | 17:08 |
| alamati | you solved my problem | 17:09 |
| alamati | really thanks | 17:09 |
| alamati | ;) | 17:09 |
| Peng | We did? | 17:09 |
| alamati | bzr pull --overwrite | 17:09 |
| rubbs | Peng: I think the overwrite worked | 17:09 |
| rubbs | alamati: I'm glad something worked out for you! | 17:10 |
| alamati | this command solve | 17:10 |
| Peng | Oh, interesting. Well, I'm glad it worked. :) | 17:10 |
| rubbs | I still don't know why that was necessary, but we got him to where he needed to be | 17:10 |
| rubbs | alamati: glad to hear everything worked out | 17:10 |
| alamati | thanks rubbs & Peng | 17:10 |
| alamati | I think that bzr is more complicated that svn | 17:11 |
| rubbs | alamati: it can be for a while, but once you get the hang of it, it gets better | 17:12 |
| alamati | and I don't understand why we first commit and then push | 17:12 |
| rubbs | just keep practicing ;) | 17:12 |
| maxb | I'd replace "more complicated" with "different underlying paradigm" | 17:12 |
| rubbs | alamati: that is because you can then do multiple commits before you push. | 17:12 |
| alamati | of course | 17:12 |
| rubbs | alamati: it takes a little while to understand it. It took me a while. | 17:13 |
| Peng | It's also so you don't have to be online to commit. | 17:14 |
| Peng | Which doesn't sound important until your Internet connection goes down or you're on a plane. :D | 17:14 |
| alamati | yes, this is nice situation | 17:14 |
| intellectronica | jml: around? know anything about bzr builder recipes? | 17:16 |
| === gerard_1 is now known as gerard_ | ||
| bialix | hi GaryvdM | 18:53 |
| GaryvdM | Hi bialix | 18:53 |
| bialix | how are you? | 18:53 |
| bialix | do you have any plans re qbzr 0.18? | 18:53 |
| GaryvdM | Good, you? | 18:53 |
| bialix | more or less | 18:53 |
| GaryvdM | I | 18:54 |
| bialix | I can wait with release till morning | 18:54 |
| bialix | please, don't disconnect | 18:55 |
| GaryvdM | My typing slow | 18:56 |
| * bialix fears your internet | 18:56 | |
| GaryvdM | I working on major features (find in annotate and diff, diff refactoring.) But I have shelved those. | 18:57 |
| GaryvdM | *I was | 18:57 |
| bialix | ok, I understand | 18:57 |
| bialix | we need to decide what will be our policy re Lucid | 18:58 |
| bialix | we made very good with 0.14 and Karmic | 18:58 |
| bialix | I'd like us to continue our success | 18:58 |
| GaryvdM | I'm now just trying to fix bugs | 18:58 |
| bialix | I've stumbled with code layout refactoring | 18:59 |
| bialix | it affects explorer | 18:59 |
| bialix | and I'm not sure about TBZR | 18:59 |
| GaryvdM | Yes - I think that 0.18 should become a stable branch, like 0.14 | 18:59 |
| GaryvdM | I want to look at: | 19:01 |
| GaryvdM | bug 487115 | 19:01 |
| ubottu | Launchpad bug 487115 in qbzr "qcommit: qt warning message in the console when files grouped into directory" [High,Confirmed] https://launchpad.net/bugs/487115 | 19:01 |
| bialix | oh, yes | 19:01 |
| bialix | this is very nasty | 19:01 |
| bialix | did you read my comments? | 19:01 |
| GaryvdM | yes | 19:02 |
| bialix | it's 100% repeatable, I just don't know where to start | 19:02 |
| GaryvdM | bug 505987 | 19:02 |
| ubottu | Launchpad bug 505987 in qbzr "show_file_differences in Annotate history pane crashes" [Undecided,New] https://launchpad.net/bugs/505987 | 19:02 |
| GaryvdM | Ok - going to reboot into windows to look at 487115 | 19:04 |
| GaryvdM | bialix: cool - I can reproduce it. | 19:16 |
| === NotADJ is now known as TheDJACR | ||
| === luks_ is now known as luks | ||
| gerard_ | guys, how about this test for bug #395514? http://pastebin.ca/1756446 | 19:33 |
| ubottu | Launchpad bug 395514 in bzr "bzr update with local updates and commits does an unexpected merge" [High,Confirmed] https://launchpad.net/bugs/395514 | 19:33 |
| lifeless | mtaylor: yo | 20:06 |
| mtaylor | lifeless: yo. just uploaded | 20:07 |
| mtaylor | lifeless: and... tested the install and stuff :) | 20:07 |
| gerard_ | how do I check if local commits are present? | 20:08 |
| gerard_ | also, please look at my patch: http://pastebin.ca/1756446 | 20:08 |
| lifeless | mtaylor: 0.9.8 ? | 20:09 |
| lifeless | ? | 20:10 |
| mtaylor | lifeless: yup | 20:10 |
| mtaylor | lifeless: well, 0.98 | 20:10 |
| mtaylor | lifeless: but yeah | 20:10 |
| === GaryvdM_ is now known as GaryvdM | ||
| === salgado is now known as salgado-afk | ||
| lifeless | gerard_: sorry, I'm at a conference, can't really look at the patch for you. hopefully someone else will do so today sometime | 20:14 |
| gerard_ | that's allright | 20:15 |
| gerard_ | I'll attach it to the bug report if nobody does ;) | 20:15 |
| lifeless | mtaylor: looks a it better. seems wasteful for the pandora configure to do c compiler checks etc | 20:15 |
| mwhudson | james_w: ping | 20:16 |
| bialix | GaryvdM: gnight | 20:16 |
| lifeless | james_w: bug 509325 | 20:38 |
| ubottu | Launchpad bug 509325 in bzr "merge & tree shape alteration hook for packaging" [Undecided,New] https://launchpad.net/bugs/509325 | 20:38 |
| james_w | hi mwhudson | 20:48 |
| MTecknology | I made a change to some code, the code was changed in that time but there's shouldn't be any issues with that | 20:48 |
| MTecknology | how can I resolve this? | 20:48 |
| mwhudson | james_w: can i get your help to come up with a good example of a bzr builder recipe? | 20:48 |
| james_w | sure | 20:48 |
| mwhudson | i can't find any packaging branches that just have the contents of the debian directory in them | 20:49 |
| mwhudson | lots of branches that just contain a debian directory, but i don't think they work with builder :/ | 20:49 |
| mwhudson | james_w: btw "nest foo lp:bar ." fails in a surprising way | 20:49 |
| mwhudson | (i didn't expect it to work, really, but it tries to lock . twice) | 20:50 |
| james_w | look under lp:~ubuntu-desktop | 20:50 |
| mwhudson | james_w: for example, http://bazaar.launchpad.net/~ubuntu-desktop/notify-osd/ubuntu/files looks like a branch to use with merge, not nest | 20:53 |
| mwhudson | james_w: also http://bazaar.launchpad.net/~ubuntu-desktop/gedit/ubuntu/files etc | 20:54 |
| james_w | ah yeah, those won't work | 20:56 |
| james_w | sorry, I mis-remembered | 20:56 |
| james_w | do you have to show nest for packaging? | 20:56 |
| mwhudson | i guess not | 20:56 |
| james_w | I can find one that would work, but they are rare | 20:58 |
| mwhudson | i guess i'll use merge then | 20:58 |
| james_w | note that you can't merge e.g. gedit either, as they don't share revision history | 20:58 |
| mwhudson | right :/ | 20:58 |
| mwhudson | i can do bzr-git maybe | 20:59 |
| mwhudson | james_w: so, for this recipe: http://pastebin.ubuntu.com/358692/ | 21:04 |
| mwhudson | james_w: to build the tree, it seems i want to do something like "bzr dailydeb --no-build example.recipe ." | 21:04 |
| james_w | yes | 21:04 |
| mwhudson | then cd into the built tree and run "bzr builddeb -S --native" | 21:05 |
| mwhudson | then cd ../build-area and say "see, look! a source package" | 21:05 |
| james_w | yes | 21:05 |
| mwhudson | cool | 21:05 |
| mwhudson | sigh, time to think about buying a new laptop battery | 21:05 |
| james_w | note that your deb-version should have 0.4.2+ or something at the start | 21:06 |
| lifeless-droid | Buy with the laptop:) | 21:06 |
| james_w | otherwise the version number will be 239 or something, and it will take a long while for bzr-git to reach that version number | 21:06 |
| mwhudson | james_w: ah yes, the one i'm actually using has been fixed like that | 21:07 |
| james_w | cool | 21:07 |
| mwhudson | (it references local paths) | 21:07 |
| lifeless-droid | use the deb version macro? | 21:07 |
| mwhudson | lifeless-droid: ah right | 21:10 |
| mwhudson | james_w: "{debupstream}-{revno}+{revno:packaging}" ? | 21:10 |
| mwhudson | i get confused about the rules wrt '-' | 21:11 |
| james_w | that would work | 21:11 |
| mwhudson | james_w: good enoguh | 21:12 |
| mwhudson | 1~1 < 1 < 1+1 in debian version numbers? | 21:13 |
| james_w | correct | 21:13 |
| james_w | 1 < 1-1 < 1+1 | 21:13 |
| mwhudson | cool | 21:13 |
| mwhudson | and the first (or is it last) '-' is special? | 21:14 |
| mwhudson | but i guess for a native package like this "who cares" | 21:14 |
| mwhudson | time for drinks | 21:14 |
| RumblePure | How to write a new log-format that only prints commit-message? | 21:18 |
| lifeless | RumblePure: have a look at one of the existing ones | 21:47 |
| RumblePure | lifeless: None of them print _only the commit-message of a given revision. | 21:48 |
| RumblePure | *_only_ | 21:48 |
| RumblePure | lifeless: I want to print the commit-message only, nothing else. This is for the purpose of a makefile. | 21:48 |
| lifeless | RumblePure: sure, you can do that, you'll need to look at the existing ones code to see how to do it itis all | 21:50 |
| RumblePure | lifeless: I've installed binary, you think the source code is there for log-formats? *non rethorical question* _) | 21:51 |
| RumblePure | * :) | 21:51 |
| lifeless | if you are on einwdows there is a zip file with all the source. Or you can look at plugins whic provide log formatters. | 21:52 |
| RumblePure | lifeless: I'm on ubuntu, I looked for plugins for log formats but no success. | 21:52 |
| rubbs | RumblePure: try this -> http://wiki.bazaar.canonical.com/BzrPlugins | 21:53 |
| lifeless | 0http://wiki.bazaar.canonical.com/BzrPlugins | 21:54 |
| lifeless | look for history exploration | 21:54 |
| rubbs | you can install those plugins by putting them in your ~/.bazaar/plugins directory (you can create that dir if it doesn't exist) | 21:54 |
| RumblePure | Haum, this might help: "Shows most recent commit messages " | 21:54 |
| rubbs | try it, if it doesn't work, you may be able to hack it to your needs. | 21:56 |
| NfNitLoop | Hrmm, odd bzr-svn issue. I've committed a change locally. Pushed it to my branch in svn. and done a 'pull' from there. But 'bzr log' still doesn't show the 'svn revno' like things below it. | 21:56 |
| NfNitLoop | I've seen this before, but I thought doing a 'bzr pull' had fixed it. | 21:56 |
| RumblePure | Thx guys, I'll try it. | 21:59 |
| lifeless | mtaylor: please upgrade t o 2a for pandora-bild.kthnx | 22:15 |
| mtaylor | lifeless: mordred@camelot:~/src/pandora-build$ bzr upgrade . | 22:16 |
| mtaylor | bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format. | 22:16 |
| lifeless | mtaylor: ok cool | 22:16 |
| mtaylor | :) | 22:16 |
| lifeless | mtaylor: you don't need the . | 22:16 |
| lifeless | like 'ls' we default to the current working directory | 22:16 |
| mtaylor | cool | 22:17 |
| lifeless | for everything except init-repo | 22:17 |
| lifeless | james_w: ping | 22:21 |
| lifeless | james_w: It would be nice if debrelease did mark-uploaded | 22:21 |
| james_w | I'm not sure what the difference is between that and dch -r | 22:23 |
| lifeless | debrelease uploads | 22:24 |
| lifeless | e.g. | 22:24 |
| lifeless | debrelease --dput ftp-master uploads the built package in .. with the current changelog version to ft-master | 22:25 |
| james_w | well, dch -r does the tagging, so maybe that's the correct place for the d* tools | 22:26 |
| lifeless | does dch -r do 'bzr mark-uploaded' at the moment ? | 22:26 |
| james_w | yes | 22:26 |
| lifeless | ok cool | 22:27 |
| james_w | indirectly | 22:27 |
| maxb | indirectly? | 22:42 |
| doctormo | Odd problem with caling cmd_push from bzrlib's builtins... when it's being called from a process that's been run from a command line, it works, when it's called from a detached gui, it stalls, no response. | 22:56 |
| doctormo | Any ideas? | 22:56 |
| maxb | What's a detached gui? | 22:57 |
| doctormo | maxb: Not being run from a command line | 22:57 |
| maxb | Can you reproduce the problem in a simple script that imports bzrlib? | 22:58 |
| doctormo | maxb: No | 23:00 |
| doctormo | Perhaps it's some weird threading issue, I know that this code running through nautilus-python isn't just simple threads. | 23:09 |
| Noldorin | hi | 23:22 |
| Noldorin | i'm wondering: when i branch the main branch for a release (say, 0.1.0)... | 23:23 |
| doctormo | It's the only command from bzrlib that I'm calling through builtins, everything else I'm calling direct calls because I'm doing custom things. So perhaps I shouldn't use the cmd_push command in this way? | 23:23 |
| Noldorin | and i find bug fixes i want to make | 23:23 |
| Noldorin | is it wise to merge across branches? | 23:23 |
| Noldorin | i so, should it be from 0.1.0 to main or vice versa? | 23:23 |
| NfNitLoop | Noldorin: merging across branches will work, but your history gets hard for a human to make much sense of. :p | 23:31 |
| NfNitLoop | If you just want to merge into 0.1 and main, you can make your fix on 0.1 and merge into main. | 23:31 |
| maxb | Noldorin: Because of the way DVCSes track history (all ancestry or none of it), it is best practice to make bugfixes in the earliest branch they apply to and merge them forwards | 23:31 |
| NfNitLoop | if you have several branches ... yeah, do what maxb says. | 23:31 |
| NfNitLoop | so you'd make a new "bugfix branch" at a "least common denominator" location that all of your destinations have in common... make your fix, then merge it into the 3 locations. | 23:32 |
| maxb | You certainly can cherrypick from trunk to a release branch, but bzr won't give you any help in tracking what has been merged that way. You'll be at the mercy of reading commit messages. | 23:32 |
| Noldorin | hmm | 23:32 |
| NfNitLoop | s/3/N/ :p | 23:32 |
| Noldorin | i see | 23:32 |
| Noldorin | maxb, so merging bug fixes from a release branch to trunk is just about all i should do? | 23:33 |
| Noldorin | (or even need to do) | 23:33 |
| NfNitLoop | in this case, yep. | 23:33 |
| Noldorin | NfNitLoop, bug fix branch...never heard of that | 23:33 |
| Noldorin | ok | 23:33 |
| NfNitLoop | Noldorin: It's a branch that contains [code from source X] plus a bugfix. | 23:34 |
| NfNitLoop | makes it easy to merge in *just* The bugfix to several locations. | 23:34 |
| NfNitLoop | but, if you're only fixing bugs on 1.0, then it's your bugfix branch. ;) | 23:35 |
| NfNitLoop | er, 0.10 | 23:35 |
| Noldorin | NfNitLoop, that's a good point | 23:35 |
| Noldorin | yeah, i feel any bugs that get fixed in trunk, should *never* be merged into existing branches | 23:35 |
| Noldorin | only future releases | 23:35 |
| maxb | Noldorin: Why do you feel that? What about a bug which is fixed on trunk and then discovered to affect an earlier series? | 23:36 |
| Noldorin | maxb, if the early release is flawed, then so be it. it's the natuer of development | 23:36 |
| Noldorin | if there's a newer release, why bother anyway? | 23:37 |
| maxb | What if there isn't a newer release yet, and won't be for a couple of months? | 23:37 |
| maxb | What if the old release series is one you've committed to long term support for? | 23:37 |
| NfNitLoop | What if you have clients who refuse to upgrade a major revision because it involves data migrations? | 23:37 |
| NfNitLoop | :p | 23:37 |
| NfNitLoop | *cough* Not that I've EVER seen that. | 23:37 |
| maxb | heh. There's still some MySQL 4.0 running here | 23:38 |
| fullermd | Then you pretend you're MySQL and just stick incompatible changes in the middle of a minor revision. Duh. | 23:38 |
| maxb | lol | 23:38 |
| NfNitLoop | hehe. | 23:38 |
| NfNitLoop | whoops. /wc is window close, not /window change. | 23:39 |
| NfNitLoop | IRCFAIL. | 23:39 |
| maxb | yay irssi | 23:39 |
| fullermd | Yeah, /wc's are for flushing. | 23:40 |
| * kfogel is away: afk for some hours; see you antipodal people later probably | 23:58 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!