| spiv | Peng_: Apparently! | 00:03 |
|---|---|---|
| jfroy|work | The link to reverse cherrypicking in http://doc.bazaar-vcs.org/latest/en/user-guide/undoing_mistakes.html is broken | 00:07 |
| Peng_ | mwhudson: wb | 00:12 |
| * Peng_ pushes | 00:13 | |
| mathepic | How can I accept a list as an argument for a command? | 00:16 |
| spiv | mathepic: in a bzrlib.commands.Command subclass? | 00:17 |
| mathepic | spiv: Yes, I'm trying to make remove-tree accept multiple trees as arguments | 00:18 |
| spiv | mathepic: something like takes_args = ['file*'] | 00:18 |
| spiv | see e.g. cmd_dd | 00:18 |
| spiv | er, | 00:18 |
| spiv | cmd_add | 00:18 |
| mathepic | Thanks | 00:18 |
| spiv | (my 'a' key is becoming a bit dodgy) | 00:18 |
| mathepic | And add a ? after the * if I want it to be optional, right? | 00:19 |
| mathepic | It doesn't seem to work with optional... | 00:23 |
| spiv | No, just * | 00:24 |
| spiv | If you don't pass any, then the list will be empty :) | 00:24 |
| mathepic | In my parameters for run, I have location_list=['.'] | 00:31 |
| mathepic | But it still gives an error if I don't specify a directory | 00:31 |
| mathepic | bzr: ERROR: exceptions.TypeError: 'NoneType' object is not iterable | 00:31 |
| mathepic | Oh wait, it passes an empty list | 00:32 |
| mathepic | So I need to check if its empty, and if its empty, assign ['. | 00:32 |
| spiv | Right. | 00:33 |
| mathepic | Okay, got it. It works now. | 00:34 |
| Peng_ | Revision graphs contain lots of ints and bools, no? | 00:40 |
| spiv | Bools? Not off the top of my head, but ICBW | 00:41 |
| Peng_ | Eh. I don't know if Loggerhead's graph structure is the same as bzr's. | 00:42 |
| Peng_ | Anyway, it would be a great case for StaticTuple, but it has ints and bools. :( | 00:43 |
| Peng_ | There's are a bunch of diff-related tuples that include ints, too. | 00:52 |
| Peng_ | jam: It'd be awesome for Loggerhead if StaticTuples could include Python ints and bools. | 00:54 |
| * Peng_ /away! | 01:02 | |
| Peng_ | LH doesn't have any interesting str-only tuples. :\ | 01:06 |
| Peng_ | Graph.iter_ancestry could use StaticTuples. | 01:09 |
| spiv | Peng_: patches welcome! | 01:10 |
| spiv | I think jam is choosing where to introduce it by profiling rather than inspection. | 01:11 |
| spiv | But if it fits, there's no reason not to use it. | 01:11 |
| spiv | lifeless: good morning | 01:26 |
| === norly is now known as ejat | ||
| lifeless | spiv: hai; internode outage ;) | 01:36 |
| spiv | :) | 01:36 |
| Peng_ | spiv: Yeah, that makes sense. I'm doing simple profiling ("scroll through Dozer output") and skimming through the code. Still, LH has a lot of tuples from iter_ancestry. | 01:43 |
| === davidstrauss_ is now known as davidstrauss | ||
| lifeless | spiv: bug 449923; I think its wishlist more than invalid - just a thought | 05:15 |
| ubottu | Launchpad bug 449923 in bzr "bzr send should offer the --diff-options option" [Undecided,Invalid] https://launchpad.net/bugs/449923 | 05:15 |
| spiv | lifeless: yeah, good point | 05:17 |
| === Adys_ is now known as Adys | ||
| bialix | hello all | 06:39 |
| bialix | spiv: thanks | 06:39 |
| === Adys_ is now known as Adys | ||
| spiv | bialix: no worries, thanks for bringing it to my attention | 06:48 |
| bialix | I suspect the bug traffic is too high to see every sepearte bug report | 06:49 |
| bialix | *separate | 06:49 |
| bialix | spiv: I'm not sure I'll be able to work on fixing this bug in bzrlib until december or january... So I'll try to invent some workaround | 06:52 |
| spiv | bialix: I expect I'll get to it before December :) | 06:54 |
| bialix | spiv: I'll respect this | 06:54 |
| bialix | though the bug triggered by QBzr non-trivial usage | 06:55 |
| spiv | Yeah. | 06:55 |
| bialix | though abentley suggest using dicts, but anyway today it's our (qbzr) problem | 06:56 |
| igc | hi bialix, spiv | 06:58 |
| bialix | hi igc | 06:58 |
| bialix | igc: re http://doc.bazaar-vcs.org/migration/en/foreign/bzr-on-svn-projects.html | 06:58 |
| bialix | is it now official? | 06:58 |
| igc | in which sense? | 06:58 |
| igc | bzr-migration-docs is a separate project to bzr core fwiw | 06:59 |
| igc | but the core docs link to the latest copy of the migration docs | 06:59 |
| bialix | oh, I saw http://doc.bazaar-vcs.org/... URL and thought it's part of official documentation | 07:01 |
| bialix | it seems there is too much different branches with different docs, site etc. I've lost the track | 07:02 |
| igc | bialix: it's meant to look like one set of doc :-) | 07:04 |
| igc | bialix: behind the scenes though, I need to build different bits on different timelines | 07:04 |
| igc | with different dependencies | 07:04 |
| igc | migration is migration - it's not really tied to 2.0.1 vs 2.1.0b1 say | 07:05 |
| bialix | I'd like to link to your document in bzr-day blog. May I cal it semi-official tutorial/guide then? | 07:05 |
| igc | it's more tied to bzr-fastexport patches | 07:05 |
| bialix | *call | 07:05 |
| igc | yes | 07:05 |
| igc | bialix: like the plugin guide, it is official documentation, just not "core" documentation | 07:06 |
| * igc off for some medical stuff - bbl | 07:07 | |
| treeform | hey guys i did not have internet for a while, so i used bzr commit --local, now i got internet and repo has moved. I tried to commit to the new reposatry (via bind to it first) but it made such a mess | 07:18 |
| treeform | whats the best way to deal with --local? | 07:18 |
| treeform | i have now over 18 conflicts | 07:18 |
| dash | 'bzr push' | 07:18 |
| dash | oh | 07:18 |
| treeform | thats odd being the only developer | 07:18 |
| dash | what did you do? | 07:19 |
| treeform | i used commit --local couple of times | 07:19 |
| dash | right | 07:19 |
| dash | and then what did you do, later? | 07:19 |
| treeform | then i did bzr commit ( when i got internet setup) | 07:19 |
| treeform | it said | 07:20 |
| treeform | no address | 07:20 |
| treeform | so i did bzr bind to new address | 07:20 |
| treeform | then i did bzr commit ( then i got message that i need torun bzr up) | 07:20 |
| treeform | i run bzr up | 07:20 |
| treeform | now every thing is confused | 07:20 |
| treeform | and i have 18 conflicts | 07:21 |
| treeform | and conflicts are crazy too: | 07:21 |
| MTecknology | conflicts in any vcs blow :( | 07:22 |
| MTecknology | bzr isn't too bad though | 07:22 |
| treeform | http://dpaste.com/107979/ | 07:22 |
| dash | MTecknology: it's better than not having them | 07:22 |
| MTecknology | yup | 07:22 |
| treeform | the problem is that i am conflicting with myself | 07:22 |
| === Kamping_Kaiser is now known as `6og | ||
| spiv | treeform: yeah, bzr up when you have local commits *and* uncommitted changes tends to give nasty double conflicts. | 07:23 |
| treeform | spiv: is there a way to undo | 07:23 |
| treeform | and do some thing better? | 07:23 |
| MTecknology | So.. I want to have a group of users that can access a bzr branch - what's the best way to handle that? | 07:23 |
| mzz | I tend to make sure "bzr st" is clean before doing pretty much anything important | 07:23 |
| mzz | well, before doing pretty much anything that might involve a merge | 07:24 |
| treeform | howly fuck bzr st is even crazier | 07:24 |
| spiv | treeform: so a good thing to do if you have local commits is make sure you have no uncommitted changes (i.e. shelve or commit your changes) before doing bzr up | 07:24 |
| treeform | i have hunders of moded, unkown, delted, undelete ... files | 07:24 |
| mzz | yeah, if you're already in weird merge territory "bzr st" is going to be pretty confusing too | 07:24 |
| mzz | err | 07:24 |
| mzz | that sounds excessive. Any idea what happened? | 07:25 |
| mzz | sometimes certain large tree reorganizations cause this | 07:25 |
| treeform | yes | 07:25 |
| treeform | how can i roll back that update? | 07:25 |
| treeform | without causing even more strife? | 07:25 |
| mzz | you can just revert, but that'll kill your existing local changes | 07:25 |
| treeform | yeah | 07:25 |
| mzz | I'm not sure if there's a sane way to preserve those at this point :( | 07:25 |
| spiv | You can do "bzr revert", but as mzz says that'll forget your uncommitted changes. | 07:26 |
| treeform | ill copy the folder first? | 07:26 |
| treeform | and copy it back? | 07:26 |
| mzz | that won't necessarily give helpful results, although I guess it's better than nothing | 07:26 |
| treeform | well i use all local changes? | 07:26 |
| treeform | lose* | 07:26 |
| mzz | I know this doesn't help at all with your problem now, but if "bzr st" was originally clean being able to just revert a merge that went wrong is extremely useful | 07:27 |
| spiv | Yeah, so copying the current mess, doing a revert, then doing an update into a clean tree is probably simplest. And then manually copy across any local changes from the copy. | 07:27 |
| mzz | yeah | 07:27 |
| mzz | I don't think you actually have better options, since your local changes are tangled into this confused merge now and bzr doesn't store enough information to untangle them | 07:27 |
| treeform | man thats sound like what reversion controll made to avoid | 07:27 |
| mzz | yes, and you can just revert *if* your original status was clean | 07:28 |
| mzz | so I tend to either commit or shelve local changes before doing something that'll involve a merge | 07:28 |
| spiv | I think https://bugs.launchpad.net/bzr/+bug/120970 is the relevant bug report, they may be others. | 07:28 |
| ubottu | Launchpad bug 120970 in bzr ""bzr update" reports spurious conflicts when local commits added a directory." [Medium,Confirmed] | 07:28 |
| MTecknology | I need to learn how to shelf something | 07:28 |
| spiv | MTecknology: bzr help shelve :) | 07:28 |
| treeform | yeah me too | 07:29 |
| treeform | never sued shelve | 07:29 |
| spiv | It's pretty easy | 07:29 |
| treeform | used* | 07:29 |
| mzz | although I don't think I've dealt with unshelving onto a very different tree than what I shelved from using the new shelve yet | 07:29 |
| mzz | the old shelve stored changes as plain diffs, so I was always sure I'd be able to manually apply them if I confused shelve | 07:29 |
| treeform | i think fixing the conflicts might be eser then redoing everything | 07:29 |
| treeform | i did lots of stuff | 07:30 |
| spiv | (And also see http://doc.bazaar-vcs.org/latest/en/user-guide/shelving_changes.html) | 07:30 |
| treeform | if i fix all the conflicts i shoudl be good riht? | 07:30 |
| mzz | treeform: downside of that is that you're going to end up with your local changes and the merge being in the same commit | 07:30 |
| vila | hi all | 07:30 |
| dash | treeform: well | 07:30 |
| dash | treeform: what i'd do first is revert the changes | 07:30 |
| mzz | treeform: the resulting history will be cleaner if you manage to revert, commit just the merge, then commit the local changes on top of that | 07:30 |
| mzz | but at this point it'll be painful no matter what you end up doing | 07:30 |
| vila | Sorry to begin the day with bad news, but babune is fully *red*: as of revno 4750, not a single successful selftest, with default locale and extensions compiled, pass | 07:31 |
| vila | the most disturbing is that this is the run that pqm is supposed to run, any info I may have missed that occurred during my night ? | 07:31 |
| vila | the failures (6) are related to: TypeError: can only concatenate tuple (not "StaticTuple") to tuple | 07:32 |
| vila | occurring in _commit_write_group | 07:32 |
| treeform | mzz, dash: so you say revert, and then copy all the files from the safe folder i just did? | 07:32 |
| treeform | but that does not take care all the files that i removed | 07:33 |
| dash | treeform: no, don't copy | 07:33 |
| dash | merge | 07:33 |
| vila | jam, spiv, lifeless, igc: ^ | 07:33 |
| treeform | dash: resolve conflicts? | 07:33 |
| mzz | treeform: I'd back up the current tangled state somewhere, just in case, then revert, redo the merge (the one "bzr up" triggered), then reapply the local changes from the backup of the mess | 07:33 |
| treeform | i am merging v n-1 with version n .. its utter crap | 07:33 |
| fullermd | vila: See what happens when you wake up early? :p | 07:33 |
| mzz | treeform: but that's just me, and I don't know exactly what state your tree is in | 07:33 |
| spiv | vila: huh | 07:34 |
| dash | treeform: 'bzr vis' might help, maybe :) | 07:34 |
| MTecknology | so - handling groups with bzr? | 07:34 |
| dash | what's a group | 07:34 |
| fullermd | MTecknology: Well, I use... y'know. Groups :) | 07:34 |
| spiv | vila: that is weird | 07:34 |
| treeform | dash: i dont have it instaled | 07:34 |
| fullermd | viz probably wouldn't help when you're in a twisted up state. | 07:35 |
| mzz | MTecknology: err, I haven't done this in ages, but I think the last time I did we used a separate user account on the server with the keys of the developers supposed to be able to push to it in authorized_keys | 07:35 |
| vila | spiv: I haven't investigated yet, but yes that's very very weird | 07:35 |
| mzz | MTecknology: which gave those users access to quite a bit more than just bzr, but that wasn't an issue for us | 07:35 |
| fullermd | treeform: Are you still sitting with the giant pile of conflicts? | 07:35 |
| treeform | yeah | 07:35 |
| treeform | and lost histry | 07:35 |
| fullermd | OK. So you've got two sets of changes here. | 07:35 |
| MTecknology | mzz: sounds interesting | 07:36 |
| mzz | treeform: you really shouldn't be losing any history, but it's hard to reliably preserve uncommitted changes across something like this. That's why they're uncommitted, I guess | 07:36 |
| fullermd | The ones you commit'd (--local), and the ones that were sitting uncommitted in the tree. | 07:36 |
| MTecknology | mzz: last time I used actual group accounts but I needed to miss with sticky bits | 07:36 |
| fullermd | treeform: The former are still in your repo, so that's all recoverable. The later, unless you can puzzle them out of the mess you have, are gone. | 07:36 |
| spiv | vila: btw, it would be neat if babune used --subunit | 07:36 |
| mzz | MTecknology: yeah, if you rely on groups it'd take a bit of effort to keep permissions consistent (everything group-writable). This was easier for us. | 07:36 |
| * fullermd marks up another tick in the "get rid of fscking ci --local already" column... | 07:37 | |
| MTecknology | mzz: thanks | 07:37 |
| treeform | fullermd: i dont want to loose stuff | 07:37 |
| treeform | but i think revert will cause even more pain | 07:37 |
| vila | spiv: full agreement, I want to switch to hudson first though... or to anything that allow a better tracking of runs | 07:37 |
| treeform | then resolving 18 conflicts | 07:37 |
| mzz | MTecknology: but in this case everyone being able to do a full ssh login as that project user was a feature, allowing them to update the website and the like | 07:37 |
| mzz | ymmv and all that. | 07:37 |
| spiv | vila: so, I see that failure locally, and it disappears if I delete _static_tuple_c.so | 07:38 |
| spiv | vila: which suggests that PQM isn't building that extension :( | 07:38 |
| fullermd | treeform: Well, unless you can sort out the big mess there, you're not going to get a hold of your uncommitted changes. And even sorted out, it's a big ugly knothole in history because of all the unrelated changes mixed in. | 07:38 |
| mzz | MTecknology: I'd expect the groups approach to also work, I just don't know the best approach to forcing bzr to use the right umask so everything stays group-writable | 07:38 |
| MTecknology | mzz: that's what the sticky bit was for | 07:39 |
| MTecknology | I wonder how LP handles it | 07:39 |
| mzz | yeah | 07:39 |
| fullermd | treeform: The changes you _committed_ are fine, we can recover those easy. Presumably, you're committing often enough that the uncommitted bits are easy to redo, right? ;) | 07:39 |
| treeform | yes | 07:39 |
| mzz | treeform: I'd be pretty surprised if the revert loses any *committed* changes. It'll eat the uncommitted ones. | 07:39 |
| spiv | mzz: right | 07:39 |
| treeform | ok will resolve | 07:39 |
| treeform | o will revert* | 07:40 |
| treeform | its reverting... | 07:40 |
| MTecknology | spiv: how does LP handle teams? | 07:40 |
| spiv | MTecknology: LP doesn't use filesystem permissions at all, it handles all that internally | 07:40 |
| fullermd | treeform: 'k. Do you have bzrtools installed? | 07:40 |
| MTecknology | oh | 07:40 |
| mzz | treeform: after the revert I'd manually delete any cruft left behind ("bzr st" is your friend here) | 07:40 |
| treeform | ok i reverted | 07:40 |
| mzz | ah, nvm, I'll stop interfering with the others helping out | 07:40 |
| spiv | MTecknology: you can take a look at the source these days :) | 07:41 |
| treeform | what do i do? | 07:41 |
| MTecknology | spiv: I will when I start trying to do some dev on it - but I've been lacking time | 07:41 |
| MTecknology | I just realized I spaced on an assignment.. | 07:41 |
| fullermd | treeform: Have bzrtools so you have the 'heads' command, and run a 'bzr heads --dead-only'. | 07:41 |
| fullermd | treeform: That'll list the head revs in the repo that aren't on the branch; one of them will be the head of your local changes. | 07:41 |
| fullermd | (you'll have to look at timestamps and log messages to figure which one; should be easy to tell) | 07:42 |
| spiv | MTecknology: but briefly it implements a custom bzrlib.transport.Transport that a) translates paths from the user to how things are actually stored on disk, and b) does acceses control checks based on team membership | 07:42 |
| mzz | fullermd: isn't he already on that head if he reverted? | 07:43 |
| vila | spiv: thanks, good to know | 07:43 |
| MTecknology | spiv: Sounds tricky | 07:43 |
| fullermd | mzz: No, he's on the head of the 'remote' branch. | 07:43 |
| mzz | fullermd: I haven't commit --local'd anything recently, but I'd expect this to just do the right thing | 07:43 |
| mzz | urgh? | 07:43 |
| fullermd | mzz: The update pivots over to that branch and stuffs your local commits as a pending merge. | 07:43 |
| mzz | that sounds like a misfeature | 07:43 |
| treeform | fullermd: getting bzr tools | 07:43 |
| fullermd | treeform: Once you find it, grab the revid and run "bzr merge -rrevid:$WHATEVER ." | 07:44 |
| spiv | MTecknology: it's not too hard, actually. | 07:44 |
| spiv | MTecknology: you can basically do it all as a bzr plugin | 07:44 |
| mzz | heh | 07:44 |
| fullermd | treeform: That'll set up a pending merge with those local changes; then you can check and commit it, and you'll be where you want to be, minus the uncommitted stuff. | 07:44 |
| fullermd | mzz: You're too kind. | 07:44 |
| mzz | spiv: you can do tons of stuff as a bzr plugin, doesn't necessarily mean they're easy :P | 07:44 |
| spiv | mzz: :) | 07:44 |
| spiv | mzz: well, you can look at the code an judge for yourself ;) | 07:45 |
| fullermd | Yeah. I mean, theoretically you write write a svn gateway as a bzr plugin, but who would... oh. | 07:45 |
| treeform | fullermd: where do i install bzrtools on windows? | 07:45 |
| spiv | Actually, the bzrlib.transport.pathfilter module in recent bzr would make this even easier. | 07:45 |
| fullermd | treeform: Mmm. Dunno. Doesn't the windows installer come with bzrtools? | 07:45 |
| fullermd | treeform: (try 'bzr help heads') | 07:45 |
| mzz | treeform: which installer did you use? | 07:45 |
| mzz | treeform: (for bzr itself, that is) | 07:45 |
| treeform | oh its there | 07:45 |
| treeform | but not bzr vis | 07:45 |
| mzz | ah, nvm then | 07:45 |
| MTecknology | chmod +s = :) ;; when used correctly | 07:46 |
| treeform | bzr merge --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc | 07:48 |
| treeform | bzr: ERROR: no such option: --rrevid:me@centurion-20091012170842-puyjiezcx4dw6noc | 07:48 |
| fullermd | One dash | 07:48 |
| fullermd | (and don't forget the " ." at the end; that's important) | 07:48 |
| treeform | same thing | 07:49 |
| treeform | dot or not | 07:49 |
| mzz | treeform: single - | 07:49 |
| treeform | oh ok | 07:49 |
| mzz | treeform: (it's the option -r, taking an argument of revid:... | 07:49 |
| treeform | its spinning | 07:50 |
| mzz | treeform: ("-r revid:..." also works. It's not the option --rrevid) | 07:50 |
| spiv | vila: | 07:50 |
| spiv | - all_missing.update([(prefix,) + key for key in missing]) | 07:50 |
| spiv | + all_missing.update([(prefix,) + tuple(key) for key in missing]) | 07:50 |
| spiv | vila: that seems to be an effective band-aid | 07:50 |
| MTecknology | Is it possible to have something like lp: instead of a site name? | 07:50 |
| treeform | fullermd: its done | 07:51 |
| treeform | bzr st is soo confused | 07:51 |
| mzz | MTecknology: lp: already works (it's builtin). You might want the "bookmarks" plugin for other sites. | 07:51 |
| fullermd | treeform: Confused how? Just "a lot of stuff"? It should just be the changes from your local commits. | 07:51 |
| treeform | yes i guess it is | 07:52 |
| treeform | i was just not ready for 25 page report ;) | 07:52 |
| treeform | what is this > pending merge tips: (use -v to see all merge revisions) me 2009-10-12 fixed the errors from major renaming spree | 07:52 |
| MTecknology | mzz: yup - that plugin is what I was asking for :) | 07:52 |
| fullermd | treeform: That's the head of the revs you're merging. | 07:53 |
| treeform | what do i do next | 07:53 |
| fullermd | Check that everything looks right (no conflicts etc), then commit 'em. | 07:53 |
| spiv | treeform: basically local commits makes a temporary branch, and when you do "bzr update" it's bascially the same as "bzr merge" of the main branch with that temporary branch. | 07:53 |
| treeform | i see | 07:54 |
| spiv | treeform: so, your local commits show up as a pending merge. | 07:54 |
| treeform | but why did the uncommited stuff cause so much problem? | 07:55 |
| MTecknology | I need to install bzr on the server first.. huh.. | 07:55 |
| mzz | MTecknology: depends on what you're pushing over | 07:56 |
| mzz | MTecknology: you can do sftp pushes, for example. But installing bzr on the server may be preferable performance-wise. | 07:56 |
| MTecknology | ya | 07:57 |
| MTecknology | anyway - I'm getting permission errors but I'm in the group that has access for it | 07:57 |
| MTecknology | chmod 770 /bzr/test bzr push bzr+ssh://192.168.1.6/bzr/test | 07:59 |
| MTecknology | anything wrong with that? | 07:59 |
| vila | spiv: +1, please land :-) | 08:00 |
| mzz | MTecknology: not offhand, no. ~/.bzr.log? | 08:01 |
| vila | spiv: or tell me to land it, I really don't like having the test suite failing that way, so let's fix that first and then fix it best (with jam input) and let's address the root cause (not building extensions if that's it) | 08:01 |
| MTecknology | woah.. http://dpaste.com/107985/ | 08:02 |
| spiv | vila: go ahead and land it for me, I'm playing with making tuple + StaticTuple work | 08:03 |
| vila | spiv: ok | 08:03 |
| spiv | vila: but I agree, the root bug is that PQM should not pass if that extension doesn't build | 08:03 |
| vila | spiv: just running a full test suite to make sure | 08:04 |
| spiv | vila: ta | 08:04 |
| MTecknology | bzr: ERROR: Server sent an unexpected error: ('error', "'Bazaar repository format 2a (needs bzr 1.16 or later)\\n'") | 08:04 |
| MTecknology | so - I need to update my server? | 08:05 |
| spiv | MTecknology: that error is probably because you're trying to push a 2a format branch to a server that can't read 2a | 08:05 |
| spiv | so, yes | 08:05 |
| MTecknology | both client and server are Ubuntu 9.10 | 08:06 |
| vila | MTecknology: what does 'bzr version' says ? | 08:06 |
| MTecknology | ooh... the server's 9.10 | 08:06 |
| MTecknology | 9.04* | 08:06 |
| MTecknology | I should upgrade it to 9.10 | 08:07 |
| mzz | MTecknology: if you just need a newer bzr: bzr 2.0 is in the bazaar ppa | 08:07 |
| vila | MTecknology: I don't know by heart what bzr version are proposed by default to 9.04 and 9.10 so try 'bzr version' in both places | 08:07 |
| MTecknology | server - 1.13.1 | 08:07 |
| vila | MTecknology: you can then look at https://launchpad.net/~bzr/+archive and foolow the instructions to update your source lists | 08:08 |
| MTecknology | I guess I just need to either upgrade the entire server or use a pp | 08:08 |
| MTecknology | ppa* | 08:08 |
| MTecknology | I like the server idea | 08:08 |
| vila | MTecknology: you may be able to upgrade bzr only instead of the whole system, but you decide... | 08:08 |
| MTecknology | I thought the guy was installing 9.10 :P | 08:08 |
| MTecknology | thanks for all the help | 08:09 |
| MTecknology | I imagine that's what caused the other error too | 08:09 |
| MTecknology | "This session appears to be running under ssh. It is not recommended to perform a upgrade over ssh currently because in case of failure it is harder to recover." | 08:12 |
| MTecknology | :P | 08:12 |
| === gdmfsob is now known as mishok13 | ||
| MTecknology | shower and sleep time - I'll catch you all later | 08:13 |
| vila | spiv: sent to pqm | 08:15 |
| igc | vila: I'm fine with you landing that revdwim patch from fullermd | 09:03 |
| igc | vila: also, https://code.edge.launchpad.net/~vila/bzr/405745-http-hangs/+merge/13050 is approved. Can we land that one as well? | 09:04 |
| vila | igc: ok for the dwim patch | 09:04 |
| vila | igc: no, fixing bug #405745 makes the leaking tests more sensitive to a yet-to-fix other bug | 09:05 |
| ubottu | Launchpad bug 405745 in bzr "blackbox.test_check.ChrootedCheckTests.test_check_missing_branch hangs on AIX" [Medium,In progress] https://launchpad.net/bugs/405745 | 09:05 |
| vila | see my comment there | 09:05 |
| igc | vila: what's the buildbot url again? | 09:12 |
| vila | igc: can't remember, never use it myself :) | 09:13 |
| igc | vila: I some a url with pretty pictures/tables I can reference :-) | 09:13 |
| igc | showing our cross-platform testing | 09:13 |
| vila | http://babune.ladeuil.net:26862/ | 09:13 |
| vila | igc: the pretty pictures are planned after a switch to hudson so far... | 09:14 |
| vila | igc: especially because tracking the overall behavior across the revisions is not that easy with buildbot, but I get that feeling progressively by using it daily | 09:15 |
| awilkins | Been using Maven / Archiva / Hudson .... we've been having real headaches but I suspect that's because of the module graph we've been building | 09:19 |
| vila | babune progressively recovers some green color ;) Thanks for the quik help spiv :) | 09:19 |
| spiv | vila: cool | 09:27 |
| spiv | vila: I'm just finishing for the day | 09:27 |
| spiv | vila: I just sent a patch to John for making tuple + StaticTuple work though | 09:27 |
| vila | spiv: good, I wanted to give you some feedback before :) | 09:27 |
| vila | great, I'll track that later today ! | 09:27 |
| spiv | vila: I'll leave it to jam to polish and merge if thinks its a good idea | 09:28 |
| vila | sure | 09:28 |
| spiv | vila: (it's visible in a comment at https://code.edge.launchpad.net/~jameinel/bzr/2.1-static-tuple-btree-string-intern/+merge/13296 if you're curious) | 09:28 |
| spiv | vila: it makes the test pass without the bandaid though :) | 09:29 |
| spiv | Ok, have a good weekend everyone | 09:31 |
| vila | s | 09:31 |
| vila | spiv: sorry keyboard battery failure here, have a good weekend ! | 09:31 |
| spiv | :) | 09:32 |
| vila | spare batteries to the rescue ! | 09:33 |
| fullermd | igc: I seem to be outvoted on the 'keep going if it looks like a revno' thing; I was gonna wait a day or so for any more weigh-ins and then push up a change to stop searching there. | 09:35 |
| igc | fullermd: ok | 09:35 |
| fullermd | I still like it going ahead and keeping trying, but if the majority opinion is the other way, I won't kvetch too much about it. I don't use pure-numeric tags anyway ;) | 09:37 |
| vila | fullermd, igc: what did I miss here ? | 09:41 |
| fullermd | Oh, heck, you sided with me. Shucks, now it's even again. | 09:42 |
| * fullermd catches up on mail after writing stupidly long-winded PM posts... | 09:42 | |
| vila | I think the performance issue should be balanced by the time the user will spend understanding the error and typing the new command | 09:43 |
| vila | performance and DWIM doesn't have to be compatible as long as an explicit way exists to disable dwim to get performance, and I think your approach is sound for that | 09:44 |
| fullermd | Yeah, the only case where it (currently) adds a meaningful performance hit above the status quo, is if the user enters a revno that doesn't exist; it'll do more searching. If they keep using explicit revid:'s and such, they'll never need to hit those cases in the DWIM. | 09:45 |
| fullermd | (well, there's trivial overhead from instantiating another class and calling some functions, but that's negligable) | 09:46 |
| vila | fullermd: if you want to further improve your patch you can do so or let me land that one and build on top of it, your call, unless igc revert his "vila, go land it" message from some minutes ago | 09:46 |
| * vila nods to fullermd | 09:46 | |
| vila | igc: I suspect you missed some of the last messages right ? | 09:47 |
| vila | igc1: even | 09:47 |
| fullermd | Mod lifeless's larger concerns, the only thing is the whether to keep the fallback on "looked like a revno, but wasn't" or cut off the search then; votes seem about split on that. | 09:47 |
| * fullermd hopes his high school English teacher doesn't get a look at that 'sentence'... | 09:47 | |
| vila | yeah. if lifeless could shime in to say whether he strongly vetoed or is ok for a further submissions can clear that bit | 09:48 |
| vila | but if you plan to tweak some more you can also address that even if I think it will be a yagni, | 09:48 |
| vila | at least it would make it possible for someone else than you to try another DWIM approach | 09:49 |
| vila | and DEIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished tomorrow | 09:50 |
| vila | s/DEIM/DWIM/ | 09:50 |
| Tak | vila meant: and DWIM, by experience, tends to evolve incrementally so what sounds perfect today may be more polished tomorrow | 09:50 |
| vila | Tak: wow ! Hurrah ! Someone can fix muy tupos ! WOnderfulk 1 | 09:50 |
| vila | fullermd: all of that to say: you've been waiting with your proposal a bit too long to see it land, I think we can land the actual one and wait for improvements in another one OR, if you feel like it, you can address the concerns you feel like addressing and resubmit | 09:52 |
| * igc1 dinner | 09:53 | |
| vila | from babune, instant feedback, jaunty fully green, hardy and karmic coming along nicely | 09:53 |
| * fullermd polishes up another response to lifeless. | 09:59 | |
| fullermd | So, yeah, the only concern I have open is whether the bulk of opinion wants to stop the fallthru on revno-looking stuff. Opinion seems split, so either way. | 10:04 |
| lifeless | fullermd: attributes on the revspec classes would do it easily without needing another registry or lots of cruft.IMO | 10:35 |
| lifeless | fullermd: as for the exceptions; I hear standardising interfaces is useful :) | 10:35 |
| vila | lifeless: agreed on both point, I was about to say roughly the same (attributes and exceptions) | 10:35 |
| lifeless | :) | 10:36 |
| vila | lifeless: Do you agree to land it as is and to file a bug for that requirements or do you want them implemented before that is landed ? (Given that fullermd implied he will not do them soon, I'd rather land that now) | 10:36 |
| fullermd | Well, there's a limit to the standardizability... I mean, if RevisionSpec_date ever started raising errors.TagsNotSupported, I'd look a little squirrely at bzrlib... | 10:37 |
| fullermd | Ditto NotBranchError, etc. | 10:37 |
| vila | fullermd: they can inherit from a common exception | 10:37 |
| lifeless | so, (NoSuchRevision, UnsupportedFeature, RevisionNotPresent) | 10:38 |
| fullermd | I'm sure a lot could be achieved by rototilling how all the RevisionSpec_*'s work, but that's definitely in the "way more scope than I wanna get within 10 blocks of" area. | 10:38 |
| lifeless | NotBranchError should bubble up | 10:38 |
| vila | fullermd: or have an attribute list the raisable exceptions | 10:38 |
| lifeless | +1 on ^ | 10:38 |
| vila | lifeless: sorry, what are you referring to ? | 10:38 |
| fullermd | Well, NotBranchError is somewhat special since branch: is the last thing tried, but it doesn't necessarily HAVE to be, in which case we'd need to catch it. | 10:38 |
| lifeless | 20:36 < vila> fullermd: or have an attribute list the raisable exceptions | 10:39 |
| vila | ok | 10:39 |
| fullermd | Anyway, it's doable with more or less pain in various ways, probably. But it's not as simple as "slap it in, you're done", 's what I was aiming for. | 10:40 |
| fullermd | Holy crud, it's almost 0500?? | 10:43 |
| vila | wow, tiger slaves fails but leave a running selftest process that generates log in /tmp of ~3GB size.... triggering OSX warnings about boot disk almost full until I kill them 8-/ | 10:44 |
| fullermd | Well, bzr can use a lot of resources. Selftest has to try overloading the system to make sure it can handle it :p | 10:45 |
| vila | process leaks now... | 10:45 |
| vila | yeah, but I'd like to get better control on that kind of experiment :D | 10:45 |
| vila | I just freed 10GB on a 32GB partition... that should *never* occur or I will really become insane without any hope to cure that... | 10:47 |
| fullermd | Cure? Why waste a good insanity? :p | 10:48 |
| vila | Because it's good as long as I'm still enjoying it, if it goes too far, I may forget than I enjoy it, and *then* it would be wasted ! | 10:49 |
| vila | from babune: gentoo back in green, waiting for freebsd[78], OSX failed because of yet another hidden aspect of the leaking tests | 10:50 |
| SamB_XP_ | fullermd: well, there's insanity and there's insanity | 10:55 |
| SamB_XP_ | some of it's not so great :-( | 10:55 |
| fullermd | The way I see it, that's the world's problem, not mine... | 10:55 |
| SamB_XP_ | it *will* be yours if you get one of the not-so-great kinds! | 10:56 |
| SamB_XP_ | it's not fun to be paranoid-delusional, for instance! | 10:56 |
| fullermd | It's not delusional if they really ARE out to get me. The bastards. | 10:56 |
| SamB_XP_ | well, if they are out to get you, you aren't insane | 10:56 |
| SamB_XP_ | but it's still not that much fun | 10:57 |
| fullermd | That's what *I* keep telling people, but they still cross the street when I walk by... | 10:57 |
| SamB_XP_ | lol | 10:58 |
| SamB_XP_ | but, wouldn't you want someone to stop you if you started thinking PHP was a good idea? | 10:59 |
| fullermd | Well, true, it doesn't have the power and flexibility of VB... | 11:00 |
| SamB_XP_ | I hope you mean VB.NET | 11:00 |
| fullermd | Well, I'm holding out for VB.ORG, actually... | 11:01 |
| SamB_XP_ | because the other kind is pretty crappy, IMO | 11:01 |
| SamB_XP_ | hehehehe | 11:01 |
| SamB_XP_ | I always thought .net was the coolest suffix ;-P | 11:01 |
| oleavr | hi.. is there any way to merge from a 2a branch to one with knitpack-experimental? (which I cannot upgrade yet) | 11:02 |
| fullermd | No. Your best bet will be rich-root-pack, assuming everybody's on 1.0 or later. | 11:03 |
| fullermd | (and will jump over the flag day, natch) | 11:03 |
| fullermd | But you're already on the 0.92 format, so it's only one prettydurnoldversion higher. | 11:04 |
| oleavr | fullermd: so I can upgrade the knitpack-experimental one to rich-root-pack, pull in changes from the 2a one, then from the original knitpack-experimental pull in changes from the rich-root-pack one? | 11:04 |
| fullermd | No, once rich root, always rich root. | 11:05 |
| fullermd | Once one corner of a project crosses the Rubicon, everything's gotta. | 11:06 |
| asabil | oleavr: bzr has historically had 2 format families: rich root and non rich root | 11:06 |
| asabil | rich root can pull from non rich root, but not the other way around | 11:06 |
| oleavr | fullermd: ok.. guess I'm screwed then (cannot upgrade the knitpack-experimental branch yet because the whole continuous integration system uses such branches and won't be upgraded just yet) | 11:07 |
| oleavr | asabil: yep.. meaning I'm screwed :P | 11:07 |
| oleavr | so guess bzr diff | patch will have to do for now then :/ | 11:08 |
| fullermd | Why won't be upgraded yet? Just practical 'doing it all' issues? | 11:08 |
| asabil | oleavr: you can | 11:08 |
| asabil | rich root formats has been available since bzr 1.0 | 11:08 |
| fullermd | And with some kinda ugly hackish work, you can get rich root revs back into an 0.15 format, which predates any pack format by several versions. But you don't wanna do that. | 11:09 |
| oleavr | fullermd: I see.. they'll upgrade the continuous integration branches to 2a next week. hey, I just got an idea.. I can 'bzr replay' the commits on top of the crappy in-house branch which is knitpack-experimental, then uncommit all those commits in the public branch (which I control and no-one else pulls from anyway), and finally pull from the in-house branch | 11:16 |
| fullermd | Well, if they're going to upgrade next week, you could just take a long nap ;) | 11:17 |
| oleavr | shit.. replay won't work for the same reason. ah well, long nap it is ;) | 11:18 |
| SamB_XP_ | or, at least, you'll have to wait to have your branch(es) merged :-( | 11:19 |
| fullermd | I totally vote for nap. | 11:20 |
| fullermd | There may be things better than sleeping, but they're probably all illegal and fattening. | 11:20 |
| SamB_XP_ | a week seems a bit long | 11:23 |
| SamB_XP_ | ... and since when is using IDA Free to disassemble itself illegal or fattening? | 11:23 |
| fullermd | Are you kidding? Look at me; I haven't even done it yet, and already there are these extra inches around my waist... | 11:24 |
| fullermd | It's kinda depressing. BRB, gotta go eat some chocolate to ease the pain. | 11:24 |
| oleavr | lol | 11:24 |
| oleavr | hmm..screw replay, I'll write a shell script that uses bzr diff and bzr log to replay commits the dumb way | 11:25 |
| * oleavr is out of patience | 11:25 | |
| fullermd | "Ed Gruberman, you must learn patience." "Yeah, yeah, yeah, patience, how long will that take?" | 11:27 |
| oleavr | :D | 11:27 |
| === elmo_ is now known as elmo | ||
| === `6og is now known as Kamping_Kaiser | ||
| === mrevell is now known as mrevell-lunch | ||
| vila | from babune: back to green except for the known OSX leak related failures, pfew, sleep well spiv :) | 12:30 |
| johnf | are lp:bzr and pqm missing the 2.0.0 tag or is it just me? | 12:50 |
| === mrevell-lunch is now known as mrevell | ||
| wlawless | is there a download mirror for bzr2.0.0-setup.exe? the launchpad site is running VERY slow | 14:32 |
| === wlawless is now known as theLawless1 | ||
| igc1 | well done vila! | 14:35 |
| igc1 | night all - have a good weekend | 14:35 |
| === igc1 is now known as igc | ||
| vila | igc: thks :-) Have a nice week-end too and sleep well :D | 14:36 |
| theLawless1 | is there a non-launchpad.net hosted version of the windows bzr setup file? | 14:38 |
| mathepic | I have no idea, but the file isn't all that big, it shouldn't be much of a deal to download from Launchpad even if its a bit slower | 14:42 |
| theLawless1 | 4 hours currently.... | 14:42 |
| theLawless1 | 1.2k is the fastest I can get from launchpad | 14:42 |
| mathepic | Wow, only 1.2k? I guess Launchpad is being slow... | 14:42 |
| vila | theLawless1: this is really surprising | 14:42 |
| theLawless1 | that's why I was hunting for a mirror | 14:43 |
| vila | theLawless1: I can get 1.5MB/s from lp right now | 14:44 |
| vila | where are you ? | 14:44 |
| theLawless1 | Toronto, Canada | 14:44 |
| abentley | vila, jam: I've got three outstanding merge proposals. Could one of you please review them? | 14:45 |
| vila | theLawless1: you should ask about that in #launchpad, some devs are in canada | 14:45 |
| theLawless1 | awesome thanks, didn't know they had their own channel | 14:45 |
| vila | abentley: the most ugent seems to be the limbo one right ? The other two are targeted at 2.0 so I'd let jam at least says whether or not he want them in 2.0.1 or 2.0.2 | 14:50 |
| jam | vila, abentley: so 2.0.1 is cut, anything else will go to 2.0.2, that and I'm on vacation today | 14:51 |
| vila | jam: sorry, enjoy your vacations ! | 14:51 |
| abentley | vila: All of them are addressing oopses, so we will cherrypick them when a fix is ready. | 14:51 |
| vila | abentley: Do you have URLs for the bzr versions run on launchpad ? | 14:53 |
| abentley | vila: lp is currently running unpatched 2.0.0 | 14:53 |
| vila | abentley: oh, and why are most (if not all) recent submissions contain conflicts in the NEWS file ? | 14:53 |
| vila | abentley: ok, but you seem to suggest that you will run a customized version soon no ? | 14:54 |
| abentley | vila: Right. | 14:54 |
| abentley | vila: I guess the conflicts are because the 2.0 branch was updated after I branched from it. | 14:55 |
| abentley | vila: The diffs used in code reviews are now "merge --preview" diffs, so they reflect what would happen if you merged, not what changes were made. | 14:56 |
| vila | abentley: haaaaa | 14:56 |
| vila | so there was a change, thanks for confirming | 14:56 |
| vila | abentley: is limbo-renames a fix on top of ascii-preview ? | 14:58 |
| abentley | vila: limbo-renames is a bug affecting bzr, but once ascii-preview is applied, it will stop affecting launchpad. | 14:59 |
| gioele | What is the current status of nested trees? The wiki page has a (broken) link to a bundlebuggy merge proposal that I cannot see on launchpad | 15:06 |
| abentley | gioele: I have submitted a new spec, but has not been approved yet. | 15:07 |
| gioele | abentley: where is that available? | 15:11 |
| abentley | gioele: The spec is here: https://code.edge.launchpad.net/~abentley/bzr/devnotes | 15:12 |
| bialix | hello jam | 15:25 |
| bialix | jam: can I ask about your workflow described http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html | 15:26 |
| vila | bialix: he's in vacation today | 15:26 |
| bialix | rats | 15:26 |
| bialix | hi vila | 15:26 |
| bialix | vila: you're also expert in annotations, right? | 15:27 |
| vila | ask the next question and we'll see :D | 15:27 |
| bialix | I have feature branch nt ready to merge to trunk | 15:27 |
| vila | nt == not ? | 15:28 |
| bialix | but I want to peek some work from it to trunk | 15:28 |
| bialix | *not | 15:28 |
| bialix | I think about using jam approach to merge and selective revert | 15:28 |
| bialix | I'm not quite sure is it will work fine if I'll revert part of file | 15:29 |
| vila | you can't revert part of the file, you can shelve part of the changes and revert the whole file and unshelve | 15:29 |
| bialix | for example: https://code.launchpad.net/cfifo | 15:29 |
| bialix | well, I can just delete half of file | 15:30 |
| abentley | vila: Wouldn't it be easier to just do "merge -i" in the first place? | 15:30 |
| bialix | because this file will be added by merge, I can't shelve part of it | 15:30 |
| vila | abentley: I was about to mention that :) | 15:30 |
| bialix | abentley: what is merge -i? | 15:30 |
| vila | abentley: but this has landed ? | 15:31 |
| bialix | bzr merge --usage mention -i in 2.0 | 15:31 |
| abentley | bialix: It's a selective merge that uses the same code as shelve. | 15:31 |
| bialix | aha | 15:31 |
| bialix | but my problem is that I want to selectively merge half of newly added file | 15:31 |
| bialix | is it possible? | 15:32 |
| bialix | I suspect -- it's not | 15:32 |
| abentley | bialix: it's not something merge -i supports directly. | 15:32 |
| bialix | IIUC it's related to feature request about splitting hunks, right? | 15:32 |
| abentley | bialix: Sure. | 15:32 |
| abentley | bialix: Your whole newly-added file is a single hunk. | 15:33 |
| bialix | I understand | 15:33 |
| abentley | bialix: But it should be simple enough to remove the parts of the file that you don't want in your editor, right? | 15:33 |
| bialix | right | 15:34 |
| bialix | my initial question was: does it preserve annotations for me? | 15:34 |
| abentley | bialix: I don't know. The lines will be introduced in two different commits, and I don't know which one bzr will prefer. | 15:35 |
| bialix | I'd like to keep annotations if possible, though I won't worry too much if there is no direct way. I'm not quite understand jam approach, mostly because he don't have added files IIUC | 15:36 |
| abentley | bialix: All the options we've discussed have the same chance of preserving annotations. | 15:37 |
| bialix | OK, perhaps it's too much nosie for simple thing. I'll cherrypick and will see | 15:37 |
| vila | annotations depend on the per-file graph, depending on your *future* merges the annotations will reflect them, the question you ask, I think, is if two revisions seem to introduce the same lines which one will win ? | 15:37 |
| bialix | something like that, yes | 15:37 |
| bialix | jam approach is nice hack, though maybe I don't quite understand all tiny details how he did all these merges | 15:38 |
| vila | this apply to cherry-picks too, in that case, we chose the first revid in the lexicographic order, there are plans (and already a hook) for people who want (for example) chose the oldest one instead | 15:38 |
| bialix | ok | 15:39 |
| bialix | interesting, how hard to follow content moves between 2 files? | 15:40 |
| === davidstrauss_ is now known as davidstrauss | ||
| bialix | I mean to annotate | 15:40 |
| vila | bialix: we miss GUID for lines | 15:41 |
| bialix | :-) | 15:41 |
| abentley | vila, bialix: It seems like it would quickly fan out to performing annotate across the whole source tree. | 15:42 |
| vila | that's an important challenge yes | 15:43 |
| bialix | I've heard git do something similar | 15:43 |
| bialix | so at least it possible in theory | 15:43 |
| abentley | bialix: I've heard of git doing it with merge. Are you sure it does it with annotate? | 15:44 |
| bialix | some people talking about annotating functions | 15:44 |
| bialix | and they insist that git track moves of function body between files | 15:44 |
| bialix | but I don't use git so I can't insist I understand it right | 15:45 |
| abentley | bialix: It's an easier problem with merge than with annotate. | 15:45 |
| * bialix trying jam hack | 15:45 | |
| bialix | why? | 15:45 |
| abentley | bialix: Because typically you're only talking about three revisions. | 15:46 |
| bialix | ah, I see | 15:46 |
| abentley | bialix: So you only have to worry about the files modified in those revisions. | 15:46 |
| bialix | ok | 15:47 |
| abentley | (Actually, the files that *vary* among those revisions, not "are modified") | 15:47 |
| bialix | jam wrote: Create a new branch from it (bzr branch --switch ../dogpile ../feature1), and remove all of the changes but the 'first step'. I personally did that with "bzr revert -r submit: file1 file2 file3" but left "file4" alone. | 15:52 |
| bialix | what is -r submit: | 15:52 |
| bialix | ? | 15:52 |
| vila | bialix: =~= send --preview | 15:52 |
| bialix | mmm? | 15:53 |
| vila | err, what 'bzr send' outputs | 15:53 |
| vila | bialix: try bzr diff -rsubmit: | 15:54 |
| vila | in any feature branch it will show you your submission | 15:54 |
| bialix | C:\work\MyCode\APMoney\ChainedFifo\nodes-for-trunk>bzr diff -r submit: | 15:54 |
| bialix | Using parent branch file:///C:/work/MyCode/APMoney/ChainedFifo/nodes/ | 15:54 |
| bialix | <nothing more> | 15:54 |
| vila | your branch has been merged | 15:55 |
| bialix | nnope | 15:55 |
| bialix | nope | 15:55 |
| bialix | I did bzr branch nodes nodes-for-trunk | 15:55 |
| bialix | cd nodes-for-trunk | 15:55 |
| bialix | I'm trying to follow jam articla | 15:55 |
| bialix | article | 15:55 |
| vila | hmm, there should be some parent location to tweak | 15:56 |
| bialix | but it seems he wrote it from memory, there is something missing | 15:56 |
| vila | 'bzr info' should report nodes as parent when run in nodes-for-trunk | 15:56 |
| bialix | so -r submit: means the branch where I want to merge? it makes sense | 15:57 |
| vila | yes, and it fallback to parent | 15:57 |
| vila | abentley: reviews done | 15:57 |
| abentley | vila: Thank you very much. | 15:58 |
| vila | abentley: if you can make new releases for bzrtools.... some RM will rejoice :) | 16:04 |
| abentley | vila: Sure, I'll do that today. | 16:04 |
| vila | abentley: thank you very much :D | 16:04 |
| bialix | vila: IIUC you said half hour ago that latest revision used as annotation origin? | 16:05 |
| bialix | so if I'll remove half of file and later merge entire file then full annotation will be used? | 16:06 |
| vila | bialix: I don't remember that, annotations are built from the oldest revision and adding annotations for the newer revisions | 16:06 |
| bialix | hmm. perhaps I should stop here | 16:07 |
| vila | bialix: sounds correct | 16:07 |
| === vxnick is now known as vxnick-AFK | ||
| treeform | hi guys | 16:47 |
| treeform | the bzr says its Uploading data to master branch - Stage : Copying content | 16:48 |
| treeform | while i see 0 network trafic | 16:48 |
| treeform | how can i find out what is going on? | 16:48 |
| beuno | treeform, take a peak in ~/.bzr.log | 17:00 |
| === beuno is now known as beuno-lunch | ||
| djmitche | I'm maintainer for buildbot, and we have a problem of file descriptor consumption when buildbot interfaces with bzr -- http://buildbot.net/trac/ticket/621#comment:9 | 17:08 |
| treeform | beuno-lunch: i did but there is nothing conclusive there | 17:09 |
| djmitche | does the bug look familiar? | 17:10 |
| djmitche | the line -- bzrlib.trace.enable_default_logging() | 17:11 |
| jml | djmitche, looking | 17:12 |
| djmitche | tx | 17:12 |
| jml | djmitche, I'd guess that there's an equivalent disable_* method that's not being called... | 17:14 |
| djmitche | I think that it's being called within bzr library code, though -- I don't find that string in buildbot | 17:15 |
| jml | ahh ok. | 17:15 |
| djmitche | oh -- it's a really old version of bbot | 17:15 |
| djmitche | hang on | 17:15 |
| jml | well, I don't know much about buildbot's bzr integration | 17:15 |
| djmitche | neither do I :( | 17:15 |
| djmitche | ok, well, I'll ask the user where that line appears, and see if they can upgrade buildbot | 17:16 |
| djmitche | thanks for looking | 17:16 |
| djmitche | sorry I didn't spot the old version :) | 17:16 |
| MTecknology | What permissions should I have on a bzr branch that a few people will access? 770? | 17:48 |
| mathepic | Is it open source? | 17:49 |
| MTecknology | there we go, o+x | 17:50 |
| MTecknology | mathepic: is bzr open source? | 17:50 |
| mathepic | Yes. | 17:50 |
| MTecknology | ya | 17:51 |
| mathepic | Then I don't see anything wrong with giving others read-access | 17:52 |
| === beuno-lunch is now known as beuno | ||
| === amanica is now known as amanica_ | ||
| === amanica_ is now known as amanica | ||
| === flacoste_afk is now known as flacoste | ||
| flacoste | hello bzr! | 20:54 |
| flacoste | how do I fix the problem of things in ~/.bazaar/locations.conf overriding things in .bzr/branch.conf | 20:54 |
| flacoste | especially the push location | 20:54 |
| flacoste | i use puish --remember, but then get warning about stuff in locations.conf shadowing it | 20:55 |
| flacoste | shouldn't it work the other way around? (branch.conf always taking precedence over locations.conf) | 20:55 |
| mathepic | I would say thats a bug | 20:57 |
| mathepic | Checking out the source code, one second | 20:57 |
| jelmer | flacoste: I think locations.conf has precedence over branch.conf since you might not always have write access to the latter (i.e. in case of a remote read-only branch) | 21:12 |
| jelmer | flacoste: older versions of Bazaar used to write to locations.conf in "bzr push --remember", newer versions write to branch.conf | 21:12 |
| flacoste | right | 21:12 |
| flacoste | and since locaitons.conf is the place for global configuration (based on patterns), the fact that it takes precedence of branch.conf is unfortunate :-/ | 21:13 |
| mathepic | I do not have a locations.conf | 21:13 |
| jelmer | Perhaps "bzr push --remember" should update locations.conf if there is something set there already that matches the branch URL, rather than writing to branch.conf | 21:13 |
| jelmer | That might get complex in some situations though.. | 21:14 |
| flacoste | i prefer that --remember writes to the branch | 21:14 |
| flacoste | otherwise, locations.conf gets cluttered | 21:14 |
| flacoste | i like the fact that locations.conf makes it easy to have a set of rules/default for development | 21:14 |
| flacoste | that's especially useful for LP-based dev | 21:15 |
| flacoste | i basically have <launchpad>/<project>/<branches> directory | 21:15 |
| jelmer | ah, so you use branch.conf as a way to override the defaults set in locations.conf rather than the other way around. | 21:16 |
| flacoste | and I can set the defaults for all of these projects / branches in locations.conf using very few stanzas | 21:16 |
| flacoste | yes | 21:16 |
| flacoste | because i can set multiple branches in locations.conf | 21:17 |
| flacoste | and only one in branch.conf | 21:17 |
| jelmer | That seems like something that would be nice to support. Perhaps we could have something similar to '<variable>:policy = norecurse' that specified the precedence. | 21:25 |
| jelmer | The other alternative would be another configuration file similar to locations.conf that branch.conf would take precedence over. | 21:25 |
| jelmer | I guess this is a good topic for the bzr UI discussion :-) | 21:26 |
| * jelmer -> sleep | 21:26 | |
| kees | hi! I'm trying to convert a subversion dump into bzr with svn2bzr, but I'm hitting these bugs: 407256 343922 any chance I can help test/motivate their fixing? :) | 22:10 |
| jam | mwhudson: when you wake up, I went ahead and tried out using 'dot' to format my graphs. I gave it a 'small' dump, which had ~350k nodes. It has peaked at 1.4GB of memory used, and has been running for 6 hours now (after pruning nodes with lots of edges). | 22:20 |
| jam | Until that finishes 'dotviewer' won't work. Though I have my doubts about it working once I'm done... :) | 22:20 |
| jam | thanks for the pointer to the 'large heap' paper, though | 22:20 |
| jam | (when i tried with all edges, I just got an OOM error fairly early... :) | 22:20 |
| jam | bug #407256 | 22:22 |
| ubottu | Launchpad bug 407256 in svn2bzr "branchcreator.py:720: ValueError: list.remove(x): x not in list" [Undecided,Confirmed] https://launchpad.net/bugs/407256 | 22:22 |
| mwhudson | jam: the reftracker thingy doesn't go via dot, it allows you to navigate around the object graph | 22:22 |
| jam | bug #343922 | 22:22 |
| ubottu | Launchpad bug 343922 in svn2bzr "add svn:ignore to .bzrignore conversion" [Wishlist,Confirmed] https://launchpad.net/bugs/343922 | 22:22 |
| jam | kees: you might try an svn => git fast-import stream => bzr fast-import instead of svn2bzr. Just a thought | 22:22 |
| jam | I don't think it would handle the ignore stuff for you | 22:23 |
| jam | also, svn ignores are pretty crappy (non recursive), so I'm not sure that they translate well | 22:23 |
| kees | jam: will that retain all the branch and tag histories? | 22:29 |
| jam | kees: going through fast import should be able to retain branches and tags, though it depends more on the svn exporter | 22:30 |
| jam | the data stream can cope with ti | 22:30 |
| jam | it | 22:30 |
| kees | jam: I had to use rsvndump -- I'm a bit worried it might have created problems. | 22:30 |
| jam | mwhudson: 'reftracker' is for viewing live content, right? | 22:32 |
| jam | I guess I could customize the "get_referents" and "get_referrers" | 22:34 |
| jam | mwhudson: so I can do a 'live' reftracker, the only problem is that it all too often finds a node like '__builtins__' which is referenced by 100+ modules | 22:39 |
| jam | and then the graph goes unreadable... | 22:39 |
| jam | and that doesn't count the 500k StaticTuple references that will be in my intern structure... | 22:39 |
| jam | it does seem interesting though | 22:39 |
| jam | thanks for the pointer | 22:39 |
| lifeless | hmm, I may need reftracker for that failed netbeans import ;P | 22:44 |
| lifeless | I did get it into sqlite | 22:44 |
| jam | lifeless: :). Question2 is whether you could build the backwards mapping from node to referrers | 22:46 |
| jam | you probably could in sql at least | 22:46 |
| jam | as you can build the links one-by-one | 22:46 |
| Zand3r | Hi all... i'm new to bzr and playing with Explorer and qbzr-eclipse to evaluate for my purposes... I've noticed that neither Explorer not qbzr-eclipse report an error when you try to 'switch' branches whilst having uncommitted work. I'm looking for advice as to whether I should report this to each of those projects or is this something that should be reported to the core qbzr project? | 23:02 |
| jam | Zand3r: that is intentional so that you can create a new branch, switch to it, and commit the new work to the target branch | 23:04 |
| jam | anyway, I'm off for now, perhaps someone else can help explain | 23:04 |
| Zand3r | jam: Thanks, perhaps I have overlooked something but it appeared that switching did not work prior to committing as you are going perhaps someone else might know. | 23:05 |
| jam | Zand3r: I use "bzr branch ../bzr.dev ../new-bugfix --switch" all the time when I'm working on feature X and realize I should create a new branch for this bugfix | 23:06 |
| Zand3r | Maybe the issue is specific to light checkouts which I am using... I should maybe have noted that in my original enquiry but I'm new to bzr as I said so am still learning what is relevant. | 23:07 |
| jam | Zand3r: should still work | 23:07 |
| Zand3r | jam: ok... thanks.. I will go back and re-trace my steps now I know it 'should' work and see what is going on. | 23:08 |
| Zand3r | Thanks for the help | 23:08 |
| dash | o/` | 23:33 |
| dash | I am happy that bzr does reasonable things in cases where it would be very easy to do unreasonable things. | 23:33 |
| dash | in particular, cherry-picking from trunk into a maintenance branch Just Works, even when done out of order. | 23:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!