| Leefmc | Question: How do you check to see if your local branch copy of a project is current? | 01:03 |
|---|---|---|
| jml | so, I wrote a couple of Bazaar commands over the weekend. I'd like it if someone could look over the code and tell me if I'm doing anything gratuitously stupid: lp:~jml/+junk/bzr-establish | 01:03 |
| Leefmc | Without actually merging | 01:03 |
| jml | Leefmc: bzr missing, I think. | 01:04 |
| Leefmc | nice, thanks | 01:04 |
| jml | Leefmc: or you could do 'bzr merge --preview' | 01:04 |
| Leefmc | gotcha | 01:04 |
| Leefmc | Now if i have a /trunk and a lightcheckout of /trunk at /wrk, and im _in_ wrk, will merge commands and whatnot mess up my light checkout? In otherwords, do i need to do all merge previews and merges in /trunk and not /wrk? (ie, merge in trunk, and update my light checkout.. or something.) | 01:08 |
| bob2 | they'll modify the checkout | 01:08 |
| bob2 | and if you commit, modify /trunk | 01:09 |
| Leefmc | bob2: Ok i think i understand, but is that a good thing or bad thing? Is merging from the server to the working branch (lightcheckout) /wrk a bad thing? Should that server/client transactions be done in the real branch (/trunk)? | 01:24 |
| bob2 | no, it is fine | 01:24 |
| fullermd | You can't merge into a branch per se; only into a working tree. The working tree colocated with the branch isn't any more "real" than any other. | 01:28 |
| markh | Does 'UserWarning: lock on <open file u'.../.bzr/checkout/dirstate', mode 'rb' at 0x0301BF50> not released' imply I've taken a lock on a tree object and not explicitly unlocked it? Or maybe a branch object? Any other clues? | 02:00 |
| spiv | markh: that you've taken a lock on a tree and not released it, yes. | 02:01 |
| markh | spiv: thanks | 02:01 |
| markh | are there any bzrlib api functions that implicitly take a lock for you and expect you to release it? | 02:06 |
| * markh wouldn't have thought so... | 02:07 | |
| fullermd | lifeless: Can you elaborate a little on what that means re manually zeroing errno? | 02:07 |
| spiv | markh: not that I can think of | 02:07 |
| lifeless | fullermd: errno = 0; retvalue = readdir(handle); if (!retvalue) { if errno == XXX ()... | 02:09 |
| jam | markh: I think DirState.initialize and maybe a couple others, but generally, no | 02:10 |
| spiv | markh: not sure if you're already considering this, but it could be a lock_read rather than a lock_write. | 02:11 |
| LeoNerd | .oO( Why did I read that as DireStraits ?) | 02:11 |
| spiv | LeoNerd: because you're dreaming about getting Money for Nothing? :) | 02:11 |
| lifeless | spiv: its the chicks; its always the chicks | 02:11 |
| markh | jam: thanks. All the locks I can see correctly use finally, so its something subtle. I think I'm getting closer via 'print' debugging :S | 02:11 |
| fullermd | lifeless: Mmm. Does readdir() even set errno? | 02:12 |
| lifeless | fullermd: is that rhetorical? | 02:12 |
| fullermd | Mmph. Blah, need to fix that manpage :| | 02:14 |
| fullermd | I hate functions like that :| | 02:14 |
| lifeless | fullermd: apue recommends this for all C library functions - set errno before calling if you want to consult it after for any reason other than 'I already know an error has occured' | 02:15 |
| lifeless | fullermd: its the 'NULL -> EOF || ERROR' that makes readdir suck in this case | 02:15 |
| fullermd | Yah. There's a half dozen functions with those sorta stupid dual meanings. | 02:16 |
| fullermd | I don't recall that suggestion in the book, though. I don't think I've seen such a thing recommended elsewhere. | 02:17 |
| lifeless | it's not prhased quite like that | 02:17 |
| lifeless | quoting mwhudson quoting it | 02:17 |
| lifeless | "There are two rules to be aware of with respect to errno. First, its value is never cleared by a routine if an error does not occur." | 02:17 |
| LeoNerd | That's not quite always true. There are a few functions that will zero it first | 02:18 |
| lifeless | well, eratta -> the author :P | 02:19 |
| fullermd | Generally, because it internally calls one of those stupid ambiguous functions. | 02:19 |
| fullermd | Wow, I've got a receipt for a muffler I bought 10 years ago serving as a bookmark in it, too. | 02:20 |
| * fullermd sighs. | 02:26 | |
| fullermd | It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout :( | 02:26 |
| poolie | lifeless, why would you want to check errno if an error has not occurred? | 02:28 |
| poolie | i thought it's value was undefined then | 02:28 |
| fullermd | poolie: Because some functions (like readdir()) have ambiguous returns. | 02:28 |
| fullermd | It returns NULL for both "Done" and "Oops" | 02:28 |
| poolie | ah, i see | 02:29 |
| poolie | that's pretty crazy | 02:29 |
| poolie | istr there are other routines which tread on errno - changing the value from 0 even if an error did not occur | 02:30 |
| poolie | because one occurred at a lower level | 02:30 |
| fullermd | Lots of them do. | 02:30 |
| fullermd | You just have to know which of them have ambiguous returns. | 02:31 |
| jml | spiv: just email bugs to me. | 02:31 |
| spiv | jml: but how will I know what their Status and Importance are? ;) | 02:31 |
| jml | spiv: The planning committee will inform you in due course | 02:32 |
| === kiko is now known as kiko-zzz | ||
| lifeless | argh | 04:01 |
| lifeless | jelmer: please please please please please please please please | 04:01 |
| lifeless | jelmer: stop bzr-svn bitching about versions ? kthx | 04:01 |
| jelmer | lifeless, uhm | 04:06 |
| jelmer | lifeless, when does it do that? | 04:06 |
| lifeless | $ bzr info | 04:06 |
| lifeless | bzr-svn is not up to date with installed bzr version 1.8dev. | 04:06 |
| lifeless | There should be a newer version of bzr-svn available. | 04:06 |
| lifeless | bzr: ERROR: Version mismatch | 04:06 |
| jelmer | it already doesn't if you're running a development (e.g. not released) version | 04:06 |
| lifeless | jelmer: I run whatever branch you tell me to | 04:07 |
| lifeless | jelmer: till it breaks, then I generally remove it until I actually need it | 04:07 |
| jelmer | if (bzrlib_version in desired or | 04:08 |
| jelmer | ((bzrlib_version[0], bzrlib_version[1]-1) in desired and | 04:08 |
| jelmer | bzrlib.version_info[3] in ('dev', 'exp'))): | 04:08 |
| jelmer | return | 04:08 |
| jelmer | lifeless, what bzr-svn branch are you running? | 04:08 |
| lifeless | I don't know, I removed the symlink already | 04:09 |
| lifeless | sorry | 04:09 |
| lifeless | I have a trunk, 0.3, 0.4 | 04:10 |
| lifeless | trunk was most recently pulled into | 04:11 |
| jelmer | 0.3 is waay outdated (and would rightly warn about being incompatible), the other two are marked as being compatible with bzr 1.7 | 04:11 |
| lifeless | http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/ | 04:11 |
| jelmer | so shouldn't warn if you run bzr 1.8dev | 04:11 |
| lifeless | jelmer: I should note, I don't pull plugins routinely | 04:11 |
| lifeless | jelmer: I bet if I pull and build it will get your update to say 1.7 is ok | 04:12 |
| lifeless | 2008-09-24 10:44 | 04:12 |
| lifeless | is the last date on the trunk dir | 04:12 |
| jelmer | the latest revision should be from about 10 hours ago | 04:13 |
| lifeless | sure | 04:13 |
| lifeless | I'm not saying you haven't updated it to say 1.7 is ok | 04:13 |
| poolie | that's interesting, you can using sigaction to say that system calls should be automatically restarted after particular signals | 04:13 |
| jelmer | ah, sorry | 04:13 |
| lifeless | I'm saying that *I haven't updated* and I wish it would not force me to to shut it up | 04:13 |
| poolie | it seems like this would fix bug 173007 for instance | 04:13 |
| ubottu | Launchpad bug 173007 in bzr "SIGQUIT debugging breaks networking" [Medium,Triaged] https://launchpad.net/bugs/173007 | 04:13 |
| jelmer | lifeless, so it sounds like you should update :-) | 04:13 |
| jelmer | lifeless: There's no easy way to warn lazily | 04:14 |
| lifeless | jelmer: uhm, thats the point, it interrupts workflow to force that, for instance on a train its hard | 04:14 |
| lifeless | jelmer: sure, check the api minimum version rather than the bzrlib version | 04:15 |
| lifeless | jelmer: and ask for module specific versions for more precise api's that you depend on | 04:15 |
| lifeless | thats what we wrote that stuff for, to stop bzr-svn and bzrtools having to be so whingy | 04:15 |
| jelmer | lifeless, what APIs have a separate version though? | 04:17 |
| lifeless | there is no evolution at the moment because you're checking the bzr command version not the library api compatibility version; and we're not being granular about the library because noone is using it | 04:17 |
| lifeless | start using granular apis and tell me what you're using and we'll start being explicit about those modules | 04:17 |
| lifeless | but please don't claim a better way isn't possible - we discussed this, came up with a solution, I wrote the bzr end, and nothing has happened since | 04:18 |
| jelmer | I'm claiming bzr-svn can't do better than this at the moment | 04:18 |
| jelmer | I'll happily use other APIs that are available when they're there | 04:18 |
| jelmer | and matter | 04:19 |
| lifeless | import bzrlib.api | 04:19 |
| lifeless | api.require_api(bzrlib.repository, (1, 6)) | 04:19 |
| lifeless | the api is available | 04:20 |
| jelmer | ok, fair enough | 04:20 |
| jelmer | please file a bug | 04:21 |
| lifeless | done | 04:22 |
| poolie | lifeless, i fixed 279381, and found quite a nice other bug right next to it | 04:24 |
| jelmer | lifeless, just tried it out | 04:29 |
| jelmer | lifeless, require_api() doesn't allow multiple versions | 04:29 |
| jelmer | lifeless, which makes it impossible for bzr-svn to claim support for bzr 1.6 and 1.7 | 04:29 |
| jelmer | bug 279447 | 04:30 |
| ubottu | Launchpad bug 279447 in bzr "bzrlib.api.require_api() doesn't allow multiple versions" [Undecided,New] https://launchpad.net/bugs/279447 | 04:30 |
| jelmer | lifeless, it also doesn't allow bzr-svn to provide any information about which API versions it itself provides, e.g. new arguments to functions can break code that calls out to bzr-svn | 04:33 |
| lifeless | jelmer: so for the former | 04:37 |
| lifeless | jelmer: are you doing conditional stuff in bzr-svn? | 04:37 |
| lifeless | jelmer: or is it just that the bzrlib api update wasn't granular enough? | 04:38 |
| jelmer | lifeless: both | 04:38 |
| lifeless | for the latter I'm not all that concerned, once we know what you're using and have api versions in place it should stop being an issue | 04:38 |
| lifeless | erm | 04:38 |
| jelmer | yes, but that will still hurt people in the mean time | 04:38 |
| lifeless | for 'wasn't granular enough' ^ | 04:38 |
| jelmer | I run both bzr.dev and bzr 1.7 with the same bzr-svn | 04:39 |
| lifeless | jelmer: secondly, it raises incompatible version - you can probe twice | 04:39 |
| lifeless | try: | 04:39 |
| lifeless | api.require_version() | 04:39 |
| lifeless | except IncompatibleApi: | 04:39 |
| jelmer | using bzrlib.api.require_api() will break | 04:39 |
| lifeless | api.require_version() | 04:39 |
| lifeless | we can add a require_any_version(object, version_list) if you like | 04:40 |
| jelmer | that would be nice, otherwise I have to add utility functions that myself | 04:41 |
| lifeless | jelmer: as for "doesn't allow bzr-svn to provide any information about which API versions it itself provides" - I'm not sure what you mean there | 04:41 |
| jelmer | lifeless, If a new argument is added for e.g. Branch.update_revisions(), does that mean the minimum_api_version and api_version are both updated? | 04:42 |
| jelmer | even if a default value is set for that argument? | 04:42 |
| lifeless | jelmer: yes | 04:42 |
| jelmer | ok, that addresses my concern | 04:42 |
| lifeless | jelmer: we can also look at being more precise | 04:42 |
| lifeless | jelmer: e.g. we could have bzrlib.branch.client_api and bzrlib.branch.provider_api | 04:43 |
| lifeless | jelmer: the big problem is that noone is using this stuff | 04:43 |
| jelmer | another thing is that the error message from require_api() is not shown to the user - bug 279451 | 04:43 |
| ubottu | Launchpad bug 279451 in bzr "IncompatibleAPI error should not be masked by "could not load plugin error"" [Undecided,New] https://launchpad.net/bugs/279451 | 04:43 |
| lifeless | jelmer: so I can write tweaks to it and it still won't fit what you need: you have to tell us, and I will fix the things you tell me, and we'll iterate | 04:44 |
| lifeless | jelmer: I'll add a multi-version require | 04:44 |
| lifeless | I'm not sure about the second, it sounds like the could not load plugin error hack is broken | 04:44 |
| lifeless | or perhaps 'import foo' is translating the error to ImportError | 04:45 |
| jelmer | I just get "Unable to load plugin 'svn' from '/home/jelmer/.bazaar/dev-plugins'" if IncompatibleAPI is raised by bzr-svn | 04:45 |
| jelmer | lifeless: Thanks - I'll happily migrate once it's at the same level as it is atm | 04:46 |
| lifeless | jelmer: try python -c 'import bzrlib.plugins.svn' | 04:46 |
| jelmer | bzrlib.errors.IncompatibleAPI: The API for "<module 'bzrlib.repository' from '/usr/lib/python2.5/site-packages/bzrlib/repository.pyc'>" is not compatible with "(1, 7)". It supports versions "(1, 7, 0)" to "(1, 7, 0)". | 04:46 |
| lifeless | jelmer: ok, so its the bzrlib wrapper that needs tuning | 04:46 |
| lifeless | poolie: whats the standard for bazaar plugin maintainers now? | 04:57 |
| poolie | a high standard :) | 04:57 |
| lifeless | I mean | 04:57 |
| poolie | more specifically? | 04:58 |
| lifeless | what group | 04:58 |
| poolie | should they join on launchpad? | 04:58 |
| lifeless | no | 04:58 |
| lifeless | what group should be the maintainer for a new plugin | 04:58 |
| lifeless | whats the meta group, is it still 'bzr' ? | 04:58 |
| lifeless | or is it different | 04:58 |
| poolie | launchpad.net/~bzr explains that ~bzr is the overall thing, ~bzr-core is for just bzr itself | 04:59 |
| poolie | therefore, plugins can either get their own group of which ~bzr is a member, or just be owned by ~bzr | 04:59 |
| poolie | lifeless, speaking of (vaguely) this kind of thing, you have an approved patch "make dist includes plugins" | 05:01 |
| poolie | should we just do it, or withdraw the patch? | 05:01 |
| lifeless | http://bazaar-vcs.org/BzrMigration doesn't mention lp's code import service; hmm | 05:01 |
| lifeless | poolie: there is a note in the comments/thread/etc about that patch, it doesn't run setup.py for plugins, so e.g. bzr-svn will fail | 05:02 |
| poolie | ok | 05:02 |
| lifeless | I said in the thread that I might get back to it 'eventually' but that we probably need that to go forward | 05:02 |
| poolie | does that mean we can use it but just not include bzr-svn? | 05:02 |
| lifeless | and if someone else wanted to that would be loverly | 05:02 |
| lifeless | poolie: yah, anything trivial will just work | 05:02 |
| lifeless | poolie: 'trivial' -> bzrtools, bzr-loom, etc | 05:03 |
| lifeless | mwhudson: oh lol; when will launchpad support --development2 ? :> | 05:04 |
| mwhudson | lifeless: i sent you an email about that | 05:05 |
| lifeless | mwhudson: did you? cool | 05:05 |
| lifeless | I have lots of mail | 05:06 |
| poolie | could i beg a review from someone for the bug 279381 fix so it can go in 1.8rc1 | 05:06 |
| ubottu | Launchpad bug 279381 in bzr "_readdir_pyx.pyx in python 2.5 causes errors with bzr" [High,In progress] https://launchpad.net/bugs/279381 | 05:06 |
| lifeless | mwhudson: any hint on finding it? | 05:07 |
| mwhudson | lifeless: well, not really, but i sent a mail saying that something like bazaar.edge.launchpad.net would make it a lot easier | 05:08 |
| lifeless | fullermd: https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk | 05:09 |
| lifeless | fullermd: I'm just about to 'upgrade' it to pack-0.92 | 05:09 |
| lifeless | fullermd: but if you're in the bzr group you can read it direct from the writable area | 05:09 |
| fullermd | Huh? | 05:11 |
| lifeless | fullermd: ? | 05:11 |
| fullermd | In reference to what? | 05:11 |
| lifeless | 12:25 < fullermd> It should take me less than 30 seconds to figure out why 'bzr diff' isn't working right in a CVS checkout :( | 05:12 |
| lifeless | fullermd: ^ | 05:14 |
| fullermd | Oh :p | 05:15 |
| fullermd | Yeah, I'm still short a month and a hundred gigs of space to do the conversion... | 05:15 |
| lifeless | fullermd: you don't need to | 05:15 |
| lifeless | fullermd: install that plugin | 05:15 |
| fullermd | Yah, but it offers me conversion options, is my point :p | 05:16 |
| lifeless | fullermd: thats to be helpful | 05:16 |
| lifeless | fullermd: it will stop the confusion though | 05:16 |
| fullermd | Well, ending the use of CVS will do that too :) | 05:16 |
| fullermd | It's the VCS version of bug 1 after all. | 05:17 |
| ubottu | https://bugs.launchpad.net/ubuntu/+bug/1 (Won't display info) | 05:17 |
| lifeless | lol | 05:17 |
| lifeless | anyhow, quick hack done, install it or not :P | 05:18 |
| lifeless | but don't complain about taking 30 seconds to realise its CVS in future :> | 05:18 |
| lifeless | mwhudson: is there some way to trigger mirrors yet ? | 05:22 |
| poolie | spiv, still here? | 05:22 |
| mwhudson | lifeless: the api might work at last, i haven't tried for a while | 05:23 |
| lifeless | https://code.edge.launchpad.net/~bzr/bzr-cvs/trunk | 05:23 |
| lifeless | its hosted, pack-0.92 *now* | 05:23 |
| spiv | poolie: yeah | 05:23 |
| lifeless | been > 5 minutes, no change | 05:23 |
| poolie | could you read http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ce01316480810062029v75a37f54qb79c168f3b81cab2%40mail.gmail.com%3E for me quickly? | 05:23 |
| lifeless | poolie: looks wrong to me: | 05:25 |
| lifeless | poolie: EINTR is ctrl-C yes? | 05:25 |
| poolie | no, that's sigint | 05:25 |
| lifeless | I thought it was one of those dual-arrival-path things | 05:25 |
| lifeless | like SIGPIPE/EPIPE | 05:25 |
| poolie | http://www.wlug.org.nz/EINTR | 05:26 |
| poolie | it will happen if for example somebody suspends the process or resizes the window while you're in that system call | 05:26 |
| lifeless | it looks like you have altered ENOENT's behaviour | 05:27 |
| poolie | i don't think i did, but i do notice that it's inconsistent with the comment | 05:28 |
| poolie | i think that in both the before and after versions, we terminate the loop successfully on getting enoent | 05:29 |
| spiv | lifeless: the ENOENT behaviour looks the same to my eyes | 05:29 |
| spiv | i.e. ENOENT -> continue | 05:29 |
| lifeless | bb:approve | 05:30 |
| poolie | i inverted the sense of that test for (subjective) clarity | 05:30 |
| lifeless | spiv: continue will exit the loop, I think poolie is right it was inconsistent with the comment | 05:30 |
| lifeless | mvo: hi1 | 05:30 |
| poolie | so the comment should be s/swallow this and continue/treat this as the end of the directory | 05:30 |
| spiv | poolie: I also voted bb:approve, but technically it should bb:tweak because I pointed out an unnecessary semi-colon ;) | 05:31 |
| lifeless | poolie: actually I suspect all those special cases were due to the missing errno=0 | 05:31 |
| poolie | linux doesn't document that it can happen and http://www.opengroup.org/onlinepubs/009695399/functions/readdir.html is unclear about how it should be handled | 05:31 |
| poolie | the eintr thing is definitely wrong and potentially quite scary | 05:31 |
| poolie | as i said | 05:31 |
| poolie | anyhow thanks | 05:31 |
| mvo | hey lifeless | 05:32 |
| lifeless | I don't know that EINTR can happen here; it backs onto getdents - Id need to read through | 05:32 |
| lifeless | but its not a bad condom to have | 05:32 |
| lifeless | hi mvo | 05:32 |
| lifeless | I saw your mail, I don't have any handy suggestions, that looks like storm complaining about something | 05:33 |
| mvo | lifeless: thanks, I had hoped you had some sort of magic bullet. I look into it again then (squeeze it in between the ubuntu beta bug squashing) | 05:34 |
| poolie | i wonder if i should just delete the enoent case | 05:34 |
| poolie | neither treating it as eof (and potentially missing things) or retrying (and spinning) is very desirable | 05:34 |
| lifeless | poolie: I suggest not at this point, rather get this change in | 05:36 |
| lifeless | poolie: and do a test branch people can test with other changes; pqm is not a good assessor for this | 05:37 |
| lifeless | is 1.8 still open ? | 05:43 |
| lifeless | poolie: ^ | 05:47 |
| poolie | yes | 05:47 |
| poolie | but i'm planning to start making it soon | 05:47 |
| lifeless | I'm asking because I've got a little api patch for jelmer | 05:47 |
| lifeless | I don't care if it goes in 1.8/1.9, but the docstring needs a version :P | 05:48 |
| lifeless | I love bzr-search sometimes :) | 05:52 |
| lifeless | :!bzr search -d ../bzr.dev Unable to load plugin | 05:52 |
| lifeless | jelmer: | 06:01 |
| lifeless | :!./bzr st | 06:01 |
| lifeless | Unable to load plugin 'cvs'. It requested API version (1, 0, 0) of module <module 'bzrlib' from '/home/robertc/source/baz/api/bzrlib/__init__.pyc'> but the minimum exported version is (1, 7, 0), and the maximum is (1, 8, 0) | 06:01 |
| lifeless | jelmer: better? | 06:01 |
| persia | Good day. I'm trying to solve a particular problem in arranging a branch history, and wondered if anyone could help me with a recipe. | 06:31 |
| poolie | hey | 06:31 |
| poolie | maybe | 06:31 |
| persia | Specifically, I want to revert about 20 commits from trunk to get back to an older version, add some patches that were applied back then in some new revisions, and then reapply the changes to trunk as a base for a new revision. | 06:32 |
| persia | (this is a workaround for a package only partially managed in VCS in Ubuntu) | 06:32 |
| poolie | ok | 06:33 |
| poolie | so if i were in this situation i'd think about just being lazy and applying the old changes on top of your current tip | 06:34 |
| poolie | otherwise, you should look at launchpad.net/bzr-rebase to rewrite the revisions | 06:34 |
| persia | bzr-rebase looks like what I want, but it seems to assume I have a clean starting point. Is there perhaps a means by which I can start a branch from an earlier revision? | 06:36 |
| poolie | sure | 06:36 |
| poolie | bzr branch -r 123 . ../rewritten-trunk | 06:36 |
| poolie | for instance | 06:36 |
| poolie | then work over there, and when you're sure you're happy, bzr push --overwrite into your publishing location | 06:37 |
| persia | Thanks! That's precisely what I want. That way I can pull the old version, apply the patches, and bzr merge will do the right thing. Thanks! | 06:37 |
| poolie | you're very welcome | 06:37 |
| * persia deletes everything | 06:37 | |
| poolie | !! | 06:38 |
| persia | I work with patchsets. quilt is very comfortable for me. replaying the set of changes I made is trivial, but I need to rebranch to get clean history. | 06:38 |
| lifeless | I'm pretty sure rebase can do what you want from an older base | 06:39 |
| persia | lifeless, Hrm? There's only one extant branch, which has more in it than I want. My first attempt included reverting stuff that I then wanted to unrevert. bzr branch -r makes it trivial to get it right. | 06:40 |
| lifeless | persia: I may be wrong; you have a something that works now though, so cool - use that | 06:41 |
| vila | hi all | 06:48 |
| poolie | hm, our extern decl of errno doesn't quite work for it to be assigned | 06:49 |
| poolie | this may be tricky | 06:49 |
| poolie | as it's not a real variable... | 06:49 |
| poolie | not necessarily a real variable anyhow... | 06:51 |
| lifeless | usually isn't | 06:52 |
| poolie | ah, "global errno" | 06:55 |
| poolie | python scoping yay | 06:56 |
| vila | regarding bug #277537, I found a problem exhibited here: http://paste.ubuntu.com/54894/ | 07:09 |
| ubottu | Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New] https://launchpad.net/bugs/277537 | 07:09 |
| lifeless | ubottu: thats due to merges, its not a bug | 07:09 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 07:09 |
| vila | And I just came across a comment saying: '# we hope there are no repositories with inconsistent parentage anymore.' in knit.py | 07:10 |
| vila | Did I found such a repo ? | 07:10 |
| lifeless | vila: well, I'll have to look I guess | 07:10 |
| lifeless | vila: but I suspect its linear-expectations confusing people | 07:10 |
| vila | seen my paste ? | 07:11 |
| vila | annotate is provided with parent in wrong order, which is the cause of the wrong annotation | 07:11 |
| vila | s/parent/&s/ | 07:11 |
| vila | lifeless: here is the script I used: http://paste.ubuntu.com/54897/ | 07:13 |
| vila | branches built as explained in https://bugs.edge.launchpad.net/bzr/+bug/277537/comments/3 | 07:13 |
| ubottu | Launchpad bug 277537 in bzr "annotate says revision modified file, "bzr diff -c" widly contradicts" [Undecided,New] | 07:13 |
| vila | ubottu: you just said that, pay attention please :) | 07:14 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 07:14 |
| poolie | hey vila | 07:15 |
| vila | hey :) | 07:15 |
| poolie | i have to say that's really not one of python's nicest features, that adding an assignment statement changes the meaning of references to that variable occuring earlier in the text | 07:17 |
| poolie | i understand what's happening but it's still gross | 07:17 |
| === gour_ is now known as gour | ||
| chandlerc | jelmer: pong | 07:20 |
| vila | lifeless: Tell me where you end up before leaving and if you think I can continue from there (sounds a bit hairy to me, but yet, I didn't think I could go that deep before trying either) | 07:42 |
| lifeless | vila: I probably won't look at it this week | 07:43 |
| lifeless | vila: I was simply commenting | 07:43 |
| vila | oh :-/ | 07:44 |
| vila | lifeless: may be you can give some hints about that comment then ? A way to find if parentage *is* inconsistent in that repo ? | 07:46 |
| lifeless | 'bzr check' | 07:47 |
| vila | ouch, I can go fix some coffee then :) | 07:49 |
| poolie | lifeless, if you're still here, what was it that you wanted to merge into 1.8? | 08:57 |
| poolie | oh the api thing | 08:57 |
| lifeless | poolie: I put 1.9 in the docstring | 08:58 |
| poolie | so you did | 08:58 |
| poolie | i was just looking at it | 08:58 |
| lifeless | poolie: as it sounds like 1.8 is basically baked | 08:58 |
| poolie | i'm just seeing if a knife comes out cleanly | 08:58 |
| lifeless | ?! | 08:59 |
| jml | lifeless: were you using 'baked' in a more colloquial sense? | 09:00 |
| Odd_Bloke | The old murder/cake confusion. | 09:01 |
| jml | First you will be baked, then there will be cake. | 09:03 |
| lifeless | jml: no, I'm just sufficiently tired that following my sentence and poolies reply stumped me | 09:04 |
| jml | lifeless: :) | 09:04 |
| jml | Rest assured that there is absolutely no chance of a dangerous equipment malfunction prior to your victory candescence. | 09:05 |
| lifeless | you want me to DE before VC ? | 09:10 |
| Odd_Bloke | abentley: In the 'merged' messages Bundle Buggy sends, would it be possible to show the revision number in which the change was merged, or would that cause considerable extra grief? | 09:11 |
| * Odd_Bloke is trying to mark a bug as Fix Released, and likes to mention when it was merged to bzr.dev so people can be sure they have the fix. | 09:12 | |
| jml | Odd_Bloke: Launchpad should so do that for you. | 09:13 |
| * jml waves his hands a bit | 09:13 | |
| Odd_Bloke | jml: Less waving, more coding! :p | 09:14 |
| jml | Odd_Bloke: I'm waiting for some tests to run :) | 09:15 |
| Odd_Bloke | Oh. Carry on.</xkcd> | 09:15 |
| Odd_Bloke | One thing that would be nice to do in LP is to link a bug report to an arbitrary URL, which Launchpad then goes and mirrors for you, unlinking it if the URL isn't mirrorable. | 09:17 |
| poolie | jml/lifeless, i was referring to cookbook instructions as to when a cake is cooked | 09:28 |
| jml | poolie: yeah, I guessed. | 09:30 |
| poolie | but thanks for the Portal reference | 09:30 |
| poolie | > "1953 - Aperture Science begins operations as a manufacturer of shower curtains. Early product line provides a very low-tech portal between the inside and outside of your shower. Very little science is actually involved. The name is chosen to make the curtains appear more hygienic. | 09:31 |
| jml | poolie: heh | 10:21 |
| jml | poolie: where's that from? | 10:21 |
| === mneptok_ is now known as mneptok | ||
| stefanlsd | Could someone have a look at this for me please - http://pastebin.ubuntu.com/54943/ - i have a problem pushing with http. Giving me you have a valid .bzr control directory, but not a branch or repository. This is an unsupported configuration. I am using --use-existing-dir | 10:57 |
| spiv | stefanlsd: try pushing to bzr+ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel | 11:10 |
| spiv | stefanlsd: what led you to try pushing to http://code.edge.launchpad.net/...? | 11:12 |
| spiv | stefanlsd: Actually, you probably need "bzr push bzr+ssh://stefanlsd@ssh://bazaar.launchpad.net/~stefanlsd/mplayer/devel" | 11:14 |
| spiv | stefanlsd: Or more simply, "bzr push lp:~stefanlsd/mplayer/devel" (do "bzr launchpad-login stefanlsd" first if you've never run "bzr launchpad-login" before). | 11:15 |
| stefanlsd | spiv: mm. i wanted to do http as im going thru a proxy... | 11:20 |
| spiv | stefanlsd: Launchpad doesn't offer any way to push to a branch via HTTP at the moment. | 11:21 |
| spiv | Only via sftp/bzr+ssh. | 11:21 |
| stefanlsd | spiv: aah. that sucks :) - so you can only branch from http currently? | 11:22 |
| spiv | That's right. | 11:22 |
| stefanlsd | spiv: kk. thanks for that. | 11:22 |
| === Freeky is now known as Freaky | ||
| abentley | Odd_Bloke: It would be a bunch of extra work, because Bundle Buggy doesn't currently determine which new revision merged the change. | 13:31 |
| Odd_Bloke | abentley: OK, don't worry about it. | 13:46 |
| Odd_Bloke | abentley: If I were to look into it sometime, would you be open to a patch to do it? | 13:46 |
| abentley | Odd_Bloke: certainly. | 13:47 |
| === doko_ is now known as doko | ||
| === Guest448` is now known as Leonidas | ||
| === Mathilda is now known as uws | ||
| maysam | hi, does anybody know if there is any Bazaar plug-in for visual studio 2008? | 14:51 |
| === kiko-zzz is now known as kiko | ||
| sabdfl | how do i see the version of bzr on a remote server, like bazaar.launchpad.net? | 15:01 |
| sabdfl | other than the web interface :-) | 15:01 |
| abentley | sabdfl: I'm not sure whether we can do that. | 15:04 |
| abentley | I can grovel the code... | 15:04 |
| ericvw | So I have a varchar() column in my database, when I try to save something like P4_testCases, I get the following message:/mysql/base.py:83: Warning: Data truncated for column 'project_id' at row 1 | 15:05 |
| ericvw | any ideas? | 15:05 |
| ericvw | wrong channel :D | 15:05 |
| __lucio__ | hi. bzr question: im trying to merge my branch into trunk, but bzr merge thinks trunk is newer, so its removing my changes. same thing if i merge trunk into my branch. what can i do? | 15:07 |
| Odd_Bloke | __lucio__: How do you mean 'removing your changes'? | 15:09 |
| __lucio__ | Odd_Bloke: i have more lines in the new branch, but when i merge with trunk, the lines are gone. | 15:10 |
| Odd_Bloke | __lucio__: Have you committed them? | 15:10 |
| __lucio__ | its trying to make my branch look like trunk, not trunk look like my branch | 15:10 |
| sabdfl | thanks abentley. would be a nice little hpss patch if we can't already do it | 15:10 |
| sabdfl | bzr version URL | 15:10 |
| __lucio__ | Odd_Bloke: yessir | 15:10 |
| Odd_Bloke | __lucio__: And you're just running 'bzr merge <BRANCH>'? | 15:11 |
| __lucio__ | Odd_Bloke: trunk$ bzr merge $MY_BRANCH and mybranch$ bzr merge $TRUNK | 15:11 |
| abentley | sabdfl: Yes, grovelling the code suggests we can't do it yet. | 15:12 |
| Odd_Bloke | __lucio__: Can you make these branches publically available? | 15:12 |
| sabdfl | thanks abentley for checking it out | 15:12 |
| __lucio__ | Odd_Bloke: not really. are you in canonical? | 15:12 |
| Odd_Bloke | __lucio__: Nope. | 15:12 |
| abentley | sabdfl: np. I'm taking Community Help Rotation to new levels :-) | 15:13 |
| Odd_Bloke | abentley: Speaking of which, can you help __lucio__? I'm at something of a loss (and meant to be working :p). | 15:14 |
| james_w | __lucio__: when you split the branch did you use "revert" at all? | 15:15 |
| __lucio__ | one clue: i may have branched the full branch and removed some of the code there. that branch is in trunk now. | 15:15 |
| __lucio__ | james_w: i dont remember. | 15:16 |
| james_w | yeah, I've you've reverted the bits left in your branch in something that has ended up in trunk then I think bzr will consider them unwanted and not merge them,. | 15:17 |
| james_w | I'm not sure what debugging flags we have for merge | 15:17 |
| abentley | Odd_Bloke, __lucio__: bbs | 15:19 |
| abentley | james_w: -Dmerge is it. | 15:19 |
| james_w | thanks abentley | 15:21 |
| james_w | __lucio__: could you run again with "bzr merge -Dmerge $MY_BRANCH" please? | 15:21 |
| __lucio__ | james_w sure | 15:21 |
| james_w | __lucio__: if there is no extra output then it means it goes in to ~/.bzr.log | 15:22 |
| beuno | james_w, what's happening is actually expected | 15:22 |
| beuno | he had 1 big branch | 15:22 |
| james_w | hey beuno | 15:22 |
| beuno | branched from that | 15:22 |
| beuno | and deleted all the branched lines from the second and first one | 15:22 |
| beuno | merged the first one | 15:22 |
| beuno | and is now merging the second one, which is the parent of the first, and deletes it's lines | 15:23 |
| beuno | hi :) | 15:23 |
| james_w | ah, rubbish | 15:23 |
| james_w | do you know of a way to get the result he wants? | 15:23 |
| beuno | my guess would be that he may be able to, either merge, commit, and merge from the old revision again | 15:24 |
| abentley | james_w: merge, revert text changes, commit. | 15:24 |
| beuno | that's it | 15:24 |
| beuno | what abentley seaid | 15:24 |
| beuno | *said | 15:24 |
| __lucio__ | revert text changes: this is by hand or some other way? bzr revert file by file? | 15:25 |
| james_w | "bzr revert ." | 15:25 |
| __lucio__ | then bzr ci --unchanged? | 15:26 |
| james_w | umm, dunno | 15:27 |
| __lucio__ | beuno: ? | 15:30 |
| abentley | __lucio__: You shouldn't need --unchanged, because it will still show pending merges if you do "revert ." | 15:31 |
| abentley | It only clears pending merges on "revert" (no dot). | 15:31 |
| __lucio__ | abentley: ahh.. thanks. i thought that revert and revert . where the same. | 15:32 |
| __lucio__ | now.. did i just kill all the changes that where in trunk? (not done by me) | 15:33 |
| abentley | __lucio__: Yes. You should merge an older revision of trunk that has no changes. | 15:34 |
| abentley | __lucio__: (instead of what you just did, so uncommit) | 15:35 |
| abentley | Then after you've redone the merge;revert .;commit, merge should work properly. | 15:35 |
| __lucio__ | thanks a lot abentley, Odd_Bloke, beuno. got it. | 15:36 |
| beuno | __lucio__, :) | 15:36 |
| abentley | __lucio__: np | 15:36 |
| psusi | I'm trying to follow the revision history of a project ( https://code.launchpad.net/~scott/upstart/0.5 ) and am a bit confused... I can see a merge done from another branch, but I can not figure out where that branch is | 16:20 |
| psusi | what exactly is the meaning of branch nick:? | 16:20 |
| abentley | psusi: It is a hint about the purpose of the branch. | 16:22 |
| psusi | abentley: so how do I figure out where the branch actually is? I would like to view the history of, or check out, just that branch that was merged into the trunk | 16:22 |
| abentley | psusi: We don't really track merges by branch, we track them by the code that was merged. | 16:23 |
| abentley | psusi: So you can just checkout the revision that was merged into trunk. | 16:23 |
| abentley | That will have the full history of that set of changes. | 16:23 |
| abentley | There are other way of looking at it, like "bzr viz" from the "bzr-gtk" plugin. | 16:24 |
| psusi | well, it says in revision 1045 that 1024.1.3 was merged to this branch.... what I can't figure out is what branch IS 1024.1 | 16:24 |
| abentley | psusi: And you don't need to. bzr checkout -r 1024.1.3 will give you a checkout with that history. | 16:24 |
| psusi | hrm.... | 16:25 |
| psusi | it doesn't seem to want to checkout from an existing checkout | 16:25 |
| abentley | psusi: Well, no, that's usually a bad idea. You can branch instead. | 16:26 |
| psusi | so why is it identified as 1024.1? going by the branch nick and looking at the history, i tlooks like I started with a side branch and 1024.1 is the trunk that was merged in again, rather than being split off from 1024 | 16:30 |
| psusi | I thought the 1024 part was supposed to indiciate that the other branch split off from this one in 1024? | 16:30 |
| abentley | psusi: All a dotted revno means to me is that it's not a mainline revision. | 16:31 |
| abentley | 1024.1 is not a meaningful revno, AIUI. | 16:32 |
| psusi | so how does it choose the first number? I thought the docs said it picked it based on the common ancestor | 16:32 |
| abentley | psusi: beats me. | 16:32 |
| psusi | I see.... | 16:32 |
| abentley | 1024.1.3 is a meaningful revno, because it refers to a revision. | 16:32 |
| psusi | right, but in what branch? ;) | 16:33 |
| abentley | psusi: Locations aren't meaningful. they may have changed. The domains may have gone away. We have the changes that were made in that branch. We don't need a physical location. | 16:33 |
| abentley | Actually, a more literal response would be that 1024.1.3 refers to a revision in https://code.launchpad.net/~scott/upstart/0.5 | 16:34 |
| psusi | hrm.... ok, so 1024 DOES appear to be a common ancestor | 16:36 |
| psusi | bzr log -r 1024 in both branches shows the same entry | 16:36 |
| psusi | hrm.... so when the first branch shows it merged in 1024.1.1 to 1024.1.3, it is saying there were 3 changes made on the other branch since it split off in 1024 that were pulled back in, right? | 16:37 |
| abentley | psusi: Yes, the log entries will show which revisions were merged. | 16:38 |
| psusi | but when you look at the history of the other branch, its history shows all the way back to 1... but it shows 1025, 1026, and 1027, which the first branch calls 1024.1, 1024.2, 1024.3 | 16:38 |
| abentley | psusi: That's right. Revnos are relative to the branch. | 16:38 |
| psusi | hrm... but the log does not record when a branch was made does it? | 16:39 |
| abentley | Another way to see the differences between branches is with "bzr missing" | 16:39 |
| abentley | psusi: No, branch creation is not versioned data. It will record the first commit to the branch, the same as it records all other commits. | 16:40 |
| psusi | hrm.... so when looking through the log and I see the branch nick changed... it was upstart-tooling, and now it is upstart-0.5... so he was working on all this in the upstart-tooling branch first, then branched it to upstart-0.5 right? | 16:41 |
| psusi | hrm... the pieces are starting to come together I think.... | 16:42 |
| abentley | psusi: That's how it looks. | 16:43 |
| psusi | seems pretty similar to git... just tries to hide the details and apply human friendly identifiers | 16:43 |
| psusi | I think my brain just is having a hard time wrapping around that since the human friendly identifiers are a poorly fit synthetic | 16:44 |
| abentley | psusi: There are certainly similarities and differences. | 16:44 |
| abentley | psusi: If you like opaque identifiers, you can always use --show-ids. | 16:45 |
| psusi | hrm.... | 16:45 |
| === mthaddon_ is now known as mthaddon | ||
| === abentley is now known as abentley-lunch | ||
| === Ng_ is now known as Ng | ||
| james_w | jam: hi, do you think it would be a good idea to backport http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/46310 for the Ubuntu packages? | 18:14 |
| james_w | perhaps even release 1.6.2 | 18:14 |
| james_w | (it's GraphIndex and _buffer_all) | 18:15 |
| jam | james_w: I'm not a big fan of backporting. And while those help, they also hurt sometimes as well (hopefully not as often as they help). Is there something that is specifically being hit ? | 18:32 |
| jam | I guess 1/2 of that is strictly good | 18:32 |
| jam | (as in, always better than what we have now) | 18:32 |
| james_w | no, just trying to make sure we have a solid release in Intrepid | 18:32 |
| jam | james_w: backport 1.7.1 then :) | 18:32 |
| jam | Intrepid isn't a LTS, right? | 18:32 |
| james_w | heh, not that solid :-) | 18:33 |
| james_w | no, it's not | 18:33 |
| === abentley-lunch is now known as abentley | ||
| === bac is now known as bac_afk | ||
| === bac_afk is now known as bac | ||
| === fta_ is now known as fta | ||
| jpe | is it possible to update or merge a subdirectory or file in a branch? | 19:37 |
| mtaylor | is the owner of bzr-builddeb aroud? jelmer is that you? | 19:46 |
| * mtaylor is wondering if there's a feature he's missing before filing a feature request... bzr bd -S works great for making source packages, but there isn't an _easy_ way to also do the equiv of bzr bd --builder='debuild -S -sd' | 19:47 | |
| mtaylor | so that if I'm making the same package for 4 different release series, I don't upload the tarball to launchpad 4 times... :) | 19:48 |
| jam | mtaylor: I believe you can configure the default builder either by project or overall | 19:48 |
| abentley | jpe: You can specify a path to a file/directory with merge. | 19:48 |
| jam | in ~/.bazaar/builddeb.conf for global | 19:48 |
| jam | or in .bzr-builddeb/default.conf | 19:48 |
| mtaylor | jam: yeah... I can do the default builder - but what I _really_ want is two different builders :) | 19:48 |
| jam | for a specific project | 19:48 |
| jam | one style for the first | 19:48 |
| jpe | abentley, is this the -d flag? | 19:49 |
| jam | and a different for the rest? | 19:49 |
| james_w | mtaylor: it's me | 19:49 |
| james_w | mtaylor: and yeah, it sucks, you're not missing anything | 19:49 |
| abentley | jpe: No, it's the first parameter to merge. | 19:49 |
| mtaylor | james_w: ok. well, thanks | 19:49 |
| mtaylor | james_w: and double thanks for writing it in the first place - can't tell you how much better it makes my life in general :) | 19:49 |
| james_w | mtaylor: I haven't thought up a good way to do this yet, but I'm going to try and crack it fairly soon. | 19:49 |
| jpe | abentley, isn't that the branch to merge from? | 19:49 |
| mtaylor | james_w: awesome. | 19:49 |
| mtaylor | james_w: I have no good suggestions | 19:50 |
| james_w | mtaylor: if you do please send them my way :-) | 19:50 |
| mtaylor | james_w: will do! | 19:50 |
| abentley | jpe: It is the branch and path to merge from. | 19:50 |
| jpe | abentley, an example would be to merge changes in the doc subdirectory of the bzr source and nothing outside that directory | 19:51 |
| mtaylor | james_w: I'm still trying to figure out a sensible way to automatically manage a set of packaging and a branch for each of (dapper,edgy,feisty,gutsy,hardy,intrepid) so that I don't have to manually build 6 source packages | 19:51 |
| mtaylor | james_w: for which I also have no good ideas as of yet | 19:52 |
| abentley | jpe: e.g. bzr merge http://bazaar-vcs.org/bzr/bzr.dev/doc | 19:52 |
| jam | james_w: wasn't there a program written on top of builddeb which at least did basic templating in order to build multiple versions from the same branch? | 19:54 |
| jam | I don't remember the name | 19:54 |
| jam | I do remember that it wasn't working for jelmer at one point | 19:54 |
| mtaylor | that would make me happy | 19:55 |
| jpe | abentley, so the rough equivalent of svn update doc is bzr merge <upstream-branch>/doc ? | 19:55 |
| mtaylor | of course, I've also been tempted to write a custom merge algorithm for debian/changelog files... but that sure hasn't happened | 19:55 |
| mtaylor | Format <RepositoryFormatKnit3> for file:///home/mtaylor/package/pkg-mysql/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance | 19:55 |
| mtaylor | I tried --rich-root-pack, and got a message about no subtree support | 19:55 |
| abentley | jpe: sounds plausible. I've never really used svn. | 19:56 |
| jpe | abentley, I think it is; thanks | 19:57 |
| === gotgenes is now known as gotgenes_away | ||
| james_w | mtaylor, jam: you may be after autoppa | 20:17 |
| james_w | mtaylor: it's another problem I'm going to look at in the next couple of months | 20:17 |
| mtaylor | james_w: mmm. autoppa sounds good | 20:21 |
| mtaylor | anybody: ? Format <RepositoryFormatKnit3> for file:///home/mtaylor/package/pkg-mysql/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance | 20:40 |
| beuno | mtaylor, sounds like you need to upgrade that branch to packs | 20:40 |
| mtaylor | beuno: I tried upgrading to --rich-root-pack - it whined about subtrees | 20:40 |
| beuno | ah, that's out of my league then | 20:41 |
| mtaylor | I don't think I'm actually _using_ subtrees... is there a way to tell and/or remove them if I'm using them accidentally? | 20:44 |
| mtaylor | aha! --pack-0.92-subtree seems to have helped | 20:45 |
| beuno | ugh | 20:47 |
| beuno | wouldn't it be nice if we could recommend what upgrade should do? | 20:47 |
| === bac is now known as bac_afk | ||
| === bac_afk is now known as bac | ||
| fullermd | mtaylor: If you're not actually using subtrees, you can 'pull' it into a rich-root-pack format branch (and theoretically "should"). | 21:07 |
| fullermd | It's kinda going around behind the tool's back, to do something it "should" do directly. Two wrongs make a right ;) | 21:08 |
| mtaylor | yay! | 21:08 |
| thrope_ | hi - I have a truck bzr-svn checkout and hten I've been working in branches | 21:24 |
| thrope_ | I made some changes is one branch - pulled them back into trunk and successfully updated other unmodified branches | 21:24 |
| thrope_ | but one branch I've been working on gives and error: | 21:24 |
| thrope_ | bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. | 21:24 |
| thrope_ | but I'm confused because they do have a common ancestor up to revision 11 or so | 21:25 |
| thrope_ | I had this error before actually as well so it must be something wrong with my workflow | 21:25 |
| thrope_ | ah found it - it had rememberred an old merge location | 21:26 |
| mtaylor | james_w: what about a flag to turn on a feature where it looks in build-area for a source package already built with a tarball included, and if it finds one, it turns on -sd by default? | 21:45 |
| bpierre | hi | 21:47 |
| bpierre | I've made some modification to bzrtools, how do I submit it? Do I register a new branch in launchpad? | 21:49 |
| lifeless | bpierre: you can, or you can just send a patch by doing 'bzr send' | 22:04 |
| bpierre | lifeless: ok | 22:05 |
| psusi | how do you see what branches are contained in a shared repository? | 22:05 |
| Jc2k | lifeless: bzr-playground has all gone a bit wrong. looks like loggerhead is down, new bzr-p users cant create a /bzr/$username folder because of permission problems and someone said the mirror was out of date too | 22:06 |
| Jc2k | lifeless: but regardless, one of the tomboy maintainers was hugely impressed already | 22:06 |
| Jc2k | (with merging and speed of branching and such) | 22:06 |
| lifeless | Jc2k: the mirror has just been restarted | 22:07 |
| lifeless | didn't know about loggerhead | 22:07 |
| lifeless | following up with sysadmins | 22:07 |
| Jc2k | ty | 22:07 |
| Jc2k | some soundbites: | 22:08 |
| Jc2k | 21:06 < sandy> god this is so fucking awesome | 22:08 |
| bpierre | lifeless: and if I register a branch on launchpad, I can then request a merge when I feel it's ready to be included in the mainline? | 22:08 |
| Jc2k | 21:37 <@sandy> Jc2k: btw, that merge worked beautifully, as you predicted | 22:08 |
| Jc2k | 21:38 < Jc2k> :) | 22:08 |
| Jc2k | 21:38 <@sandy> so fucking awesome is bzr | 22:08 |
| lifeless | bpierre: yes | 22:08 |
| lifeless | psusi: bzr branches <repo root> | 22:09 |
| bpierre | does launchpad use things like bundlebuggy? | 22:09 |
| lifeless | psusi: or 'ls' | 22:09 |
| lifeless | bpierre: the BB main author is working on the review system for launchpad | 22:09 |
| bpierre | ok | 22:09 |
| psusi | lifeless: ls doesn't work though if you don't have the working trees checked out... branches will though right? | 22:09 |
| lifeless | bpierre: so its growing up to become like BB :) | 22:09 |
| lifeless | psusi: ls will still work, because a branch has a dir - even without a tree | 22:10 |
| bpierre | but the review system right know support mail? | 22:10 |
| psusi | that's what I was looking for... was wondering why bzr info -v just says it's a shared repo but not what's IN the shared repo ;) | 22:10 |
| lifeless | bpierre: yes | 22:10 |
| bpierre | and it's the same when requesting a merge? | 22:10 |
| bpierre | same system? | 22:10 |
| lifeless | bpierre: I don't understand the question | 22:10 |
| psusi | lifeless: it does? can't I remove the entire directory, or have several branches in one tree that is a shared repo and bzr switch between branches instead of cd? | 22:11 |
| lifeless | psusi: if you remove the entire dir then your branch is gone, though the head will remain in the repository | 22:11 |
| psusi | ( the entire directory meaning the subdir of the branch, while leaving the repository in the main direcotory intact ) | 22:11 |
| lifeless | psusi: you can have several branches and switch using 'bzr switch' | 22:11 |
| lifeless | psusi: switch switches a tree between branches | 22:12 |
| bpierre | you can either send a bundle by mail to a specific address, or request a merge for a registered branch, and then have something that works kinda like bundlebuggy: people can comment, and one (or more) appointed integrators can accept the merge? | 22:12 |
| psusi | right... well wouldn't the point of switch be to avoid having each branch in its own direcotory? instead switching one directory between them as needed? | 22:12 |
| lifeless | psusi: directories are really quite cheap; its what you put in them :P. | 22:12 |
| psusi | well, yea... I just don't like clutter ;) | 22:13 |
| lifeless | psusi: the point of switch is to avoid having many copies of your source code expanded on disk | 22:13 |
| psusi | right... so if you have a dozen branches and only really want to check out and work on the trunk... you don't want all of the branches expanded on disk | 22:13 |
| psusi | but you are saying you at least have to have subdirecories cluttering things up for each branch, even if they don't have an expanded tree in them? | 22:13 |
| lifeless | psusi: err | 22:14 |
| lifeless | if you have a branch at /repo/A and another at /repo/B | 22:14 |
| lifeless | you don't need any of the subdirectories of your code under those | 22:14 |
| psusi | can't you safely rm -fr /repo/B and later bzr checkout it if you need it? | 22:15 |
| lifeless | check it out from what? | 22:15 |
| psusi | from /repo | 22:15 |
| lifeless | have you used git? | 22:15 |
| psusi | yes | 22:15 |
| lifeless | ok | 22:15 |
| lifeless | git has 'refs' right? | 22:15 |
| psusi | yea | 22:15 |
| lifeless | each branch is a ref | 22:16 |
| === gotgenes_away is now known as gotgenes | ||
| psusi | are the refs not stored in the shared repo? | 22:16 |
| lifeless | (more or less) | 22:16 |
| psusi | ohh... so if you delete the branch, you loose the ref? | 22:16 |
| lifeless | the refs that make up your branches are stored in /repo/A/.bzr/branch/last-revision | 22:16 |
| psusi | and thus, can't find the head for that branch any more? | 22:16 |
| lifeless | right | 22:16 |
| lifeless | you can recover a head from 'bzr heads --dead' | 22:16 |
| psusi | I see... | 22:16 |
| lifeless | and pull that into a fresh branch | 22:16 |
| jam | lifeless: provided it wasn't merged | 22:16 |
| lifeless | jam: well, then its in your history anyhow and pull . -r XX will do it | 22:17 |
| jam | The *named* ref is gone if you delete the branch | 22:17 |
| jam | lifeless: right, but you don't know the *name* anymore | 22:17 |
| lifeless | jam: of course | 22:17 |
| lifeless | jam: did I sound confused ? :P | 22:17 |
| jam | I was mostly trying a different tack on explaining the situation | 22:17 |
| fullermd | I smelled confusion. And a little egg salad. | 22:18 |
| jam | and "bzr heads --dead" doesn't work if the branch has been merged | 22:18 |
| lifeless | ah yes I see | 22:18 |
| lifeless | psusi: so there are a few reasons for why we do it this way | 22:18 |
| psusi | bzr branches does not appear to be a valid command... | 22:18 |
| lifeless | psusi: the primary user visible concept people work with are 'branches' | 22:18 |
| psusi | so there is no way to have the refs stored in the shared repo too, like git? | 22:18 |
| lifeless | so we wanted to make those as visible as possible | 22:19 |
| lifeless | psusi: not in any of the repository formats shipped in bzr core | 22:19 |
| jam | psusi: well you could create your own text file with "name revision-id" | 22:19 |
| lifeless | psusi: bzr-svn and bzr-git obviously support that :P | 22:19 |
| jam | and then refer to them by revision-id later | 22:19 |
| psusi | ok... seems nice as a default... I'd just like the option to be able to tidy up old obsolete branches from the directory tree, yet still have them in the repo | 22:20 |
| jam | psusi: you could always "mv branch old/branch" | 22:20 |
| jam | either a file or a directory is going to get cluttered | 22:20 |
| jam | s/either/either way/ | 22:20 |
| lifeless | psusi: If I want to keep the old branch (e.g. a failed experiment that might be useful), I would: | 22:22 |
| lifeless | mkdir obsolete | 22:22 |
| lifeless | mv failed-branch obsolete/ | 22:22 |
| psusi | so if you don't want to keep it.. just rm -fr, then run some sort of packing/cleaning operation on the repo? | 22:22 |
| lifeless | yah | 22:23 |
| lifeless | bzr branches is in the bzrtools plugin | 22:23 |
| psusi | hrm... now to figure out if it is possible to get buildd to build a personal branch from launchpad... | 22:24 |
| lifeless | james_w: does bzr-builddeb know about the buildd service yet ? | 22:24 |
| lifeless | james_w: ppa's I mean | 22:24 |
| psusi | hrm... why would you want to bzr split? | 22:29 |
| psusi | and would that remove that subdirecotory from the original branch when you commit it, or are they just shadowed by the new branch? | 22:29 |
| lifeless | psusi: it turns a versioned subdirectory into a tree object | 22:30 |
| lifeless | psusi: its a bit raw, I'd ignore split for now. | 22:30 |
| psusi | k... so why would you want to switch if you have the other branch in its own directory anyhow? like with svn you switch so yuo only have to checkout project/A branch into the project direcory... then you switch the project directory so it is now project/B | 22:32 |
| psusi | but it sounds like with bzr, you have to have project/A and project/B | 22:32 |
| psusi | all the time... so if you want to switch, you just cd | 22:32 |
| bpierre | a branch can only contains bzr metadata | 22:32 |
| bpierre | and not it's associated tree | 22:32 |
| psusi | ??!@ | 22:32 |
| bpierre | only project/A/.bzr and project/B/.bzr | 22:33 |
| psusi | I got two branches with their trees in a shared repo right now | 22:33 |
| bpierre | you can remove the tree with remove-tree | 22:33 |
| psusi | ohh, you mean it MAY only contain the metadata, i.e. not hve the tree | 22:33 |
| bpierre | and only keep the metadata | 22:33 |
| bpierre | yes | 22:33 |
| psusi | I read it as it can ONLY have the metadata, and can NOT have the tree ;) | 22:34 |
| bpierre | and then you can use a lightweight checkout witch switch | 22:34 |
| bpierre | *with switch | 22:34 |
| lifeless | psusi: sorry did you mean 'split' or 'switch' they are very different things | 22:35 |
| psusi | switch | 22:39 |
| psusi | so if you are in /proj/A and you bzr switch ../B, then /proj/A becomes /proj/B? then how do you get back to A? | 22:40 |
| lifeless | Jc2k: loggerhead should be restored to sanity | 22:41 |
| bpierre | psusi: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#reusing-a-checkout | 22:41 |
| psusi | ohh... I think I see... it wouldn't make sense to do that... only makes sense when you're using a central repo model | 22:41 |
| lifeless | psusi: it makes sense without a central repo | 22:42 |
| bpierre | but you can work like that locally! | 22:42 |
| lifeless | psusi: consider this: | 22:42 |
| psusi | it does? | 22:42 |
| lifeless | /repo/A and /repo/B, are bare branches | 22:42 |
| lifeless | no working tree, just the ref & configuration data | 22:42 |
| lifeless | cd /repo | 22:42 |
| lifeless | bzr checkout --lightweight A working | 22:42 |
| lifeless | cd working | 22:42 |
| lifeless | bzr switch B | 22:42 |
| lifeless | bzr switch A | 22:42 |
| lifeless | bzr switch B | 22:42 |
| lifeless | etc | 22:42 |
| psusi | ohh, well yea... I suppose you could make another working directory to switch back and forth in | 22:43 |
| psusi | but why bother when you can just cd between the two? ;) | 22:43 |
| bpierre | less space? | 22:43 |
| lifeless | because A and B don't have any source code to edit ? | 22:43 |
| bpierre | plus you can have uncommited changes | 22:43 |
| jam | psusi: wel, I've switched to it because I have 200ish feature branches | 22:43 |
| jam | and I didn't really want a WT in each | 22:43 |
| psusi | well, it would be equivalent then to remove-tree + cd + checkout | 22:43 |
| lifeless | psusi: thats a lot more work for the system to do | 22:43 |
| bpierre | not if you have uncommited changes | 22:43 |
| psusi | though I guess it would probably be a bit less work | 22:43 |
| psusi | hrm... I see... | 22:44 |
| lifeless | psusi: also some people find it useful to only have one copy, so they can be sure that their editor window is looking at the right code | 22:44 |
| jam | psusi: on the other hand, I generally have 3-4 WTs that I have checked out | 22:44 |
| jam | as i work on more than one thing at a time | 22:44 |
| lifeless | psusi: basically the point is - you *can* choose to use a single working tree and switch | 22:44 |
| jam | so I have a checkout for "Trunk", Work1, Work2 | 22:44 |
| jam | and work1 and work2 switch often | 22:44 |
| lifeless | psusi: *or* you can just have a bunch of branches with colocated trees that you can edit on | 22:45 |
| psusi | yea... I guess that's why I was looking for a model of refs without having each branch directory... | 22:45 |
| lifeless | or some combination, bzr doesn't care, and supports you doing this | 22:45 |
| jam | lifeless: side question. Any thought on how to make Repository._generate_text_index not be glacially slow for something like the mysql repository? (65k revisions, 256k text revisions) | 22:45 |
| jam | I tried just bumping up the cache size and batch size, in case it was cache thrashing | 22:45 |
| jam | but at inventory cache of 100, it is using 600MB and still taking a long time | 22:45 |
| lifeless | psusi: if you have bare branches and a single wt you edit in you'll have no problems with your editor getting confused :P | 22:45 |
| lifeless | jam: less inventory snapshots | 22:46 |
| psusi | lifeless: yea... I just have to get used to having a working tree in one directory and the other directories just being branch heads with no tree... just seems odd at first | 22:46 |
| jam | lifeless: do you think that is really it? AFAICT the time is spent during "revision_tree(id).inventory" | 22:46 |
| psusi | compared to git | 22:46 |
| jam | find_text_key_references() finishes in about 20s | 22:47 |
| jam | psusi: well, git branch heads have no tree | 22:47 |
| lifeless | psusi: I appreciate its different; all the modern vcs's have similar differences, and in different areas to add to the disconnect when you first play with one | 22:47 |
| jam | they are just listed in a text file | 22:47 |
| psusi | jam: right, but unless you look in the direcotrory, youc an't tell that... they all look like directories, be they branches with no tree, or a working tree | 22:48 |
| jam | psusi: if it is an issue, put them all in a directory called "branches" and have the rest in "working_trees" | 22:49 |
| jam | but sure, I understand it is *different* | 22:49 |
| lifeless | jam: tbh, I'm not really interested in further tweaks on sngle document inventories | 22:51 |
| jam | lifeless: well, I'm trying to justify "reconcile" as it takes.... I don't really know, but it has been 2hrs so far | 22:52 |
| lifeless | jam: we're so close to pinning down the performance envelope of split ones that I'd rather see your time and mine going into that than optimising something we know can't ever possibly scale | 22:52 |
| bpierre | jam: https://bugs.launchpad.net/bzr/+bug/269456 has been marked as 'Fix commited', is the fix available somewhere? | 22:53 |
| ubottu | Launchpad bug 269456 in bzr "checkout operation consume too much resources" [High,Fix committed] | 22:53 |
| jam | bpierre: http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C48E64F01.1000106%40arbash-meinel.com%3E | 22:54 |
| bpierre | jam: thanks | 22:56 |
| psusi | bzr missing... it shows revisions that are in the other branch, and not this one? and the revision numbers are relative to the other branch? so if you want to see what is in this branch, that is not in the other one, you have to cd to the other branch and missing this one from there? | 23:03 |
| radix | psusi: no, bzr missing shows both | 23:04 |
| radix | psusi: i.e., it shows revisions that the current branch has and the other branch doesn't, and vice versa | 23:04 |
| Spaz | 9 | 23:06 |
| Spaz | oops | 23:06 |
| psusi | radix: how do you differentiate? | 23:12 |
| radix | psusi: it prints a header | 23:13 |
| psusi | ohh... I see... missing/extra... and then the revision numbers are relative to this branch for extra, and that branch for missing | 23:14 |
| fullermd | Alternately phrased, the revision numbers are for the branch where they are (after all, by virtue of being 'missing', they can't have a number in the other ;) | 23:16 |
| spiv | jam: oh, I remember why unlock can't reraise; it's impossible to tell at that point if there is a live exception or a previously handled one that just happens to still be in sys.exc_info() | 23:24 |
| spiv | e.g. "try: foo(); except: pass" will tend to leave a real-looking exception in sys.exc_info(). The only way to distinguish an active exception from stale is by controlling the try/except around the function call and observing if an exception was actually raised. | 23:27 |
| spiv | So the best you can do is have a helper function that does the call-function, observe-exception, unconditionally-unlock, reraise-if-appropriate sequence for you. | 23:29 |
| spiv | With python 2.5 we could at least spell that helper as "with write_locked(foo): ..." | 23:29 |
| spiv | But 2.4 doesn't have that syntax. | 23:29 |
| spiv | So you need something more like "foo.write_lock(); call_and_unlock_safely(foo, foo.method)" | 23:31 |
| spiv | (Hmm, maybe you couldn't do better in 2.5. It doesn't matter anyway, as we support 2.4...) | 23:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!