jelmer | thumper: I'm not sure why it isn't there for the working tree, it's strange indeed. I could imagine it being None for files that have changed (since their current state is not in any revision yet) but not for unchanged files. | 00:00 |
---|---|---|
thumper | I guess I could file a bug, it can always be marked invalid :) | 00:03 |
poolie | thumper: it's not a bug | 00:13 |
poolie | files in the wt don't have a revision | 00:13 |
thumper | poolie: even when they are versioned? | 00:13 |
thumper | poolie: it has a parent_id | 00:13 |
thumper | poolie: hence my confusion | 00:14 |
spiv | thumper: a working tree is a revision-under-construction, conceptually. | 00:15 |
thumper | spiv: it'd make sense to me then to not have a parent_id for the InventoryFile from a working tree | 00:16 |
spiv | Well, it knows the parent. | 00:16 |
thumper | at least then it would be internally consistent from my point of view | 00:16 |
poolie | thumper: nb the parent is the parent directory | 00:16 |
thumper | spiv: so why doesn't it know the revision? | 00:16 |
poolie | thumper: what revision do you want it to be? | 00:16 |
poolie | the one where it was last modified? | 00:16 |
thumper | poolie: that is what I would expect, yes | 00:16 |
poolie | but then what if it's been modified on disk? | 00:16 |
spiv | Or the one it is about to be when you type "bzr ci" ;) | 00:16 |
poolie | if we leave it the same, there is a big risk of bugs | 00:17 |
poolie | if we perhaps set it to None in that case, that requires reading the whole file to determine this property | 00:17 |
poolie | which would tend to make things slow | 00:17 |
thumper | I'm not sure, I'm just starting to play with bzrlib internals | 00:17 |
poolie | so | 00:18 |
poolie | if you want to find out "for the unmodified files, tell me which revision they came from" | 00:18 |
poolie | this necessitates doing a diff type operation | 00:18 |
poolie | so you have to do iter_changes | 00:18 |
thumper | poolie: so what is the parent_id of an InventoryFile? | 00:18 |
thumper | poolie: all I want to find out is the last revision a particular file was modified in | 00:18 |
spiv | thumper: the file_id of its containing directory | 00:18 |
thumper | poolie: which I get from wt.basis_tree().inventory[file_id].revision | 00:19 |
thumper | poolie: which is what jelmer said | 00:19 |
poolie | or something equivalent to that | 00:19 |
poolie | we should document that more | 00:19 |
poolie | thumper: yes that's the best way to get it | 00:19 |
thumper | cool | 00:19 |
poolie | assuming you don't care about uncommitted changes | 00:19 |
thumper | poolie: for what I'm doing, there aren't any uncommitted changes | 00:20 |
poolie | k | 00:20 |
poolie | you don't even have to use a wt if you don't need one | 00:20 |
thumper | poolie: it makes for fast file access | 00:20 |
thumper | poolie: for the tip revision | 00:20 |
thumper | that is my current reasoning | 00:21 |
thumper | I may change later to just using in memory trees | 00:21 |
thumper | but getting something working first | 00:21 |
poolie | please file bugs tagged 'doc api' if something is not sufficiently explained, or perhaps just send one email describing everything | 00:22 |
poolie | and i will try to make it better | 00:22 |
thumper | poolie: where are the existing docs on the api? | 00:22 |
thumper | poolie: I'm just working from mwhudson's pydoctor files right now | 00:22 |
thumper | poolie: if there are some conceptual overviews that'd probably help | 00:22 |
spiv | thumper: In addition to the pydoctor docs there is http://doc.bazaar.canonical.com/bzr.dev/developers/ | 00:23 |
thumper | spiv: thanks, I'll take a look | 00:23 |
spiv | Primarily the "Developing using bzrlib" section, I guess. | 00:24 |
spiv | But there might be some relevant info in the other sections, e.g. if you want to use bzrlib's testing facilities in your test suite. | 00:24 |
thumper | yeah, I'm using TestCaseWithTransport | 00:25 |
thumper | I'm actually quite keen to learn more of the bzr internals | 00:25 |
thumper | I may even submit some patches :) | 00:25 |
poolie | cool | 00:26 |
thumper | one day... | 00:26 |
poolie | this really is a good chance to improve the api docs | 00:26 |
thumper | I'll try to make notes of my pain points | 00:26 |
poolie | lucid needs to reboot now, biab | 00:26 |
mwhudson | i guess i could try to put my editable version of the apidocs online again | 00:26 |
poolie | mm | 00:27 |
poolie | you're welcome too, but i think it will become a dead end | 00:27 |
poolie | i think what we need is not a gloss written onto the api docs, but rather people asking questions that actually drive improvements in the docs instead | 00:28 |
mwhudson | probably | 00:28 |
poolie | like a footer on all of them saying "if this is unclear ask in #bzr and we will improve it" | 00:28 |
dvheumen | hi poolie. about the contributor agreement. I forwarded your reply to me with the agreement and my text, but maybe that's what killed the process?!? | 00:31 |
dvheumen | :P | 00:31 |
dvheumen | In that case, I could send a clean version again | 00:31 |
dvheumen | ... and I didn't CC you, only sent it to contributor-agreement@canonical.com | 00:32 |
poolie | would you please forward that mail to me? | 00:33 |
dvheumen | ah, whoops, I missed the second part of that sentence saying I should CC you :P | 00:33 |
dvheumen | forwarding ... | 00:33 |
spiv | dvheumen: ah good, I'm looking forward to your patch landing :) | 00:34 |
dvheumen | spiv, well, it's not that spectacular :), but thanks for saying that ;) | 00:35 |
dvheumen | poolie, mail should arrive shortly | 00:35 |
=== BasicPRO is now known as BasicOSX | ||
poolie | k thanks | 00:41 |
dvheumen | okay, since you've got the Agreement, everything should be alright. I'm gonna call it a night. | 00:42 |
igc | morning | 00:51 |
moldy | hi | 00:58 |
moldy | can i easily merge a single directory of another branch into my branch while keeping history? | 00:59 |
bob2 | no | 01:00 |
moldy | hm, ok :-/ | 01:00 |
moldy | bob2: how would you approach this? | 01:00 |
spiv | moldy: the two basic options are "lose the history" and "merge the whole other branch in but then undo the changes from outside the directory you want." | 01:02 |
moldy | spiv: hm, ok, thanks. | 01:02 |
moldy | if i deleted a directory, how can i view the log for that directory? "Path unknown at end or start of revision range" | 01:11 |
Peng | moldy: If you can remember when you deleted it, 'bzr log -r <some rev where it existed>' | 01:14 |
moldy | Peng: hm, ok, thx | 01:15 |
poolie | hi igc | 01:23 |
=== gnomefreak76 is now known as gnomefreak | ||
thumper | poolie: any way to tag an individual file? | 02:19 |
poolie | thumper: i just answered the question about it | 02:19 |
poolie | no | 02:19 |
thumper | poolie: thanks | 02:20 |
vila | hi all | 07:19 |
gour | hello | 07:20 |
gour | jelmer is the author of bzr-svn? | 07:20 |
vila | gour: yes he is | 07:20 |
gour | vila: i had some crash in bzr explorer while fetching from svn repo, but would like to send paste before opening ticket (http://dpaste.com/173190/) - maybe it's just network problem | 07:21 |
vila | gour: well, 'could not connect' indicates either a network problem or an authentication problem | 07:23 |
vila | gour: try connecting with the svn client itself and, except if the problem is transient) file a bug | 07:24 |
gour | vila: thanks. it may be network problem then...it fetched quite a lot from the repo before crashing | 07:24 |
gour | ok | 07:24 |
gour | vila: svn did the job | 07:28 |
vila | gour: bug filing time it is then | 07:29 |
gour | vila: ok | 07:29 |
igc | bbiab | 08:06 |
echo-area | spiv: ping | 08:11 |
knielsen | bzr has per-file changeset comments (implemented for MySQL I think). They can be added with `bzr gcommit`. But is there any way to view them? I couldn't find any ... | 09:03 |
vila | oh boy, how I hate linux when it starts thrashing... | 09:08 |
GaryvdM | knielsen: I believe with bzr glog | 09:13 |
vila | knielsen: bzr viz (GaryvdM you insensitive clod !) | 09:14 |
knielsen | ok, thanks! (glog is a plugin I guess?) | 09:15 |
vila | GaryvdM: may be we should just add glog as an alias for viz in bzr-gtk ;-) | 09:15 |
vila | knielsen: it's part of bzr-gtk | 09:15 |
GaryvdM | vila: Oh. I thought that was allready the case. | 09:16 |
knielsen | vila: hm, strange, I have bzr-gtk but don't seem to have glog ... anyway, I'll check it out | 09:16 |
GaryvdM | knielsen: I thought it was glog, but it is bzr viz | 09:17 |
vila | knielsen: GaryvdM thought about qlog in qbzr plugin but it's called viz in the bzr-gtk plugin | 09:17 |
knielsen | hehe, ok :) | 09:17 |
vila | knielsen: sorry for the confusion | 09:17 |
spiv | echo-area: pong | 09:18 |
spiv | echo-area: I'm only half around... | 09:18 |
vila | knielsen, GaryvdM, jelmer : I've just pushed to lp:bzr-gtk the alias addition, so there | 09:21 |
GaryvdM | :-) | 09:21 |
knielsen | ok, I see, that works, thanks! I guess there is no command-line way to see the comments? | 09:22 |
vila | GaryvdM: Wow, just tried 'bzr qlog' in a directory (below a shared repo) without branchs in it (but still branches in sub dirs) | 09:22 |
vila | GaryvdM: I got a message on the console but a blank (well grey) screen.... | 09:23 |
knielsen | (probably `bzr log --verbose` should show them, if anyone cared enough to add that) | 09:23 |
knielsen | I guess MySQL is probably the only project to use per-file comments anyway ... | 09:25 |
vila | knielsen: it's implemented as a revision property, which are quite arbitrary (and in that case encoded in a non-trivial way), so bzr itself can't just display it properly | 09:28 |
vila | knielsen: a specific log formatter can, you may want to file a bug asking for one | 09:28 |
knielsen | vila: ok, I see, thanks for info | 09:28 |
echo-area | spiv: Okay, so let's talk tomorrow. I just checked our last dialogue, and you are off the day by now :) | 09:29 |
GaryvdM | vila: my 3g went wonkey, so I may have missed messages. The last thing I saw was: "GaryvdM: I got a message on the console but a blank (well grey) screen..." | 09:30 |
vila | GaryvdM: that was it | 09:30 |
GaryvdM | vila: what was the message? | 09:31 |
vila | GaryvdM: not a branch | 09:31 |
GaryvdM | Vila: ok. I'll log a bug. It should be able to handel that. | 09:32 |
vila | GaryvdM: sure, that's the first time I encounter it and I was a bit surprised that I needed to *kill* the window, clicking the close button seemed unresponsive | 09:33 |
GaryvdM | vila: Can you reproduce the hang? | 09:34 |
vila | just a sec | 09:34 |
vila | WOW | 09:35 |
vila | I can't | 09:35 |
vila | I just get the error message and the qlog just quit | 09:36 |
balor | So I've merged something onto my mainline. I've now got a BASE OTHER and THIS file for one file. What's the best way to merge all this? Do I meld OTHER and THIS onto BASE or some other permutation? | 09:36 |
vila | amazing, ok, forget it, I can't reproduce | 09:36 |
vila | balor: 'file' itself already contains all the merged stuff and the conflicted regions enclosed with markers | 09:38 |
balor | vila: I can see that. But is there a tool that lets me choose between chunks, rather than simply editing the file in emacs? | 09:38 |
vila | balor: man, if you use emacs try smerge ! | 09:39 |
* vila checks how smerge is configured here | 09:39 | |
vila | balor: hmm, just opending a conflicted file is enough to trigger smerge here | 09:40 |
balor | And if I wasn't an emacs user, is there another tool? | 09:40 |
vila | Ha, that maybe because I use dvc | 09:40 |
vila | yes meld certainly, but I don't use it (I've just installed it, gimme a sec) | 09:40 |
* vila thought meld could be triggered automatically frombzr | 09:42 | |
balor | ah! bzr-gconflicts | 09:42 |
balor | It'll set up meld correctly to do the merge | 09:42 |
vila | balor: starts meld automatically ? | 09:42 |
vila | good | 09:42 |
vila | balor: try pinging GaryvdM when he come back, I'm pretty sure qconflicts (from qbzr) can do that too | 09:43 |
balor | Hmm....I still have to copy foo.c.BASE over foo.c after the merge | 09:51 |
vila | balor: you still need to to 'bzr resolve file' | 10:49 |
vila | s/to to/to do/ | 10:54 |
alf_ | Hi all, I have been using bzr explorer to read the history/logs of specific files and directories. | 11:45 |
alf_ | Due to the depth of the history (>40000) this takes a while. Is there a way to speed things up? Would indexing using "bzr index" help here? | 11:46 |
jelmer | alf_: Hi | 11:50 |
jelmer | alf_: No, bzr index is just used by "bzr search" - it won't speed anything up | 11:50 |
jelmer | alf_: Do you have the Bazaar C extensions compiled? | 11:50 |
jelmer | alf_: And are you using a recent version of Bazaar? | 11:51 |
alf_ | jelmer: I am using bzr 2.1.0 from debian testing | 11:51 |
alf_ | jelmer: The good thing is that bzr explorer incrementally displays the matching commits as it finds them. It still takes a lot of time to process them all, however. | 11:55 |
alf_ | I am guessing it is just searching all commits and just displays ones that match? | 11:57 |
jelmer | alf_: You're just browsing aren't you? | 12:03 |
jelmer | alf_: Or are you doing something more complex than that? | 12:04 |
igc | night all | 12:05 |
alf_ | jelmer: in the file browser I am selecting a file/directory and clicking show log in the context menu | 12:05 |
jelmer | g'night Ian! | 12:07 |
dcoles | jelmer: Would you believe I'm having trouble with bazaar and urlsplit again... | 12:35 |
dcoles | This time with bzr-git... | 12:36 |
jelmer | dcoles: You're running Lucid I bet? | 12:36 |
dcoles | Yes. Someone changed the behaviour of urlsplit? | 12:37 |
jelmer | dcoles, Yep, upstream python did | 12:37 |
jelmer | there's a fix for it in bzr-git trunk | 12:37 |
dcoles | (Since I can no longer reproduce the behavour that was breaking bzr-svn) | 12:37 |
jelmer | the behaviour in bzr-svn was unrelated to Python | 12:38 |
dcoles | Ah. Cool. I had just started to monkey-patch and then noticed that bzr-git already "did the right thing" | 12:39 |
bialix | jelmer: hi | 12:56 |
bialix | jelmer: can we chat about Bug 540363 | 12:57 |
ubottu | Launchpad bug 540363 in qbzr "SVN Commit throws 'SvnBranch' object has no attribute 'control_files'" [High,Fix released] https://launchpad.net/bugs/540363 | 12:57 |
jelmer | bialix, hi | 12:58 |
jelmer | bialix, sure | 12:58 |
bialix | in qcommit we're trying to store some data in branch.conf | 12:58 |
bialix | IIUC SvnBranch has no branch.conf? | 12:58 |
bialix | so my fix to use Branch.get_physical_status instead of bzranch.control_files might be incorrect at all? | 12:59 |
jelmer | bialix: To access branch.conf you should use Branch.get_config() | 12:59 |
bialix | jelmer: maybe I should skip work with branch.conf at all for SvnBranch? Or even for all non-BzrBranches? | 13:00 |
bialix | jelmer: we're using Branch.get_config() | 13:01 |
jelmer | bialix: bzr-svn will return a config object if you call get_config() on a SvnBranch | 13:01 |
jelmer | bialix: but will store/retrieve in branch.conf but elsewhere | 13:02 |
bialix | jelmer: here is the code: http://pastebin.com/kTCkCkic | 13:02 |
bialix | self._get_branch_config() == Branch.get_branch_config() | 13:03 |
jelmer | Branch.get_config() you mean? | 13:03 |
jelmer | Anyway, that should work | 13:03 |
bialix | yes, get_config, sorry | 13:03 |
* jelmer gets dragged to lunch | 13:04 | |
bialix | bon appetit | 13:04 |
bialix | thanks, jelmer | 13:04 |
smoser | Hey all, I know this isn't bzr specific, but expect someone would know an answer here. | 14:35 |
smoser | I'm looking at http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/files/head%3A/user-data/ , and want to include a download link to the 'head' version of one of the files there | 14:36 |
smoser | include-compressed-script-01.txt.gz specifically | 14:36 |
smoser | the 'download file' link seems to be a premenant link to the head at the time i grab it. | 14:37 |
james_w | smoser: you can probably mangle the link | 14:39 |
smoser | i would have thought so. but it seems to have some data in it. | 14:40 |
smoser | http://bazaar.launchpad.net/%7Esmoser/%2Bjunk/ec2-test/download/head%3A/includecompressedscr-20100318141221-ewki6l3sasp5rmny-1/include-compressed-script-01.txt.gz | 14:40 |
smoser | and its missing the path (user-data/), so i wasn't sure | 14:40 |
james_w | interesting | 14:40 |
james_w | beuno: around? ^ | 14:41 |
james_w | smoser: it still seems to be pointing to head: though, so should work | 14:41 |
james_w | it will break if you bzr rm and then bzr add that file | 14:42 |
smoser | well, it doesn't. i upated the file and the old link didn't work. | 14:42 |
smoser | well, it worked, but got the old version | 14:42 |
james_w | very odd | 14:46 |
smoser | yeah, i suspect user error. | 14:49 |
smoser | maybe i checked before new version had updated | 14:49 |
james_w | ah, there is probably a lag of a minute or two after you push | 14:52 |
beuno | james_w, hi | 14:53 |
beuno | yeah | 14:53 |
beuno | so loggerhead is on the public area | 14:53 |
james_w | hi beuno | 14:53 |
beuno | which has to wait for the puller to bring it in | 14:53 |
beuno | so there is a delay | 14:53 |
=== salgado is now known as salgado-lunch | ||
=== IslandUsurper is now known as IslandUsurperAFK | ||
NfNitLoop | Hrmm. I'm helping a coworker learn/use bzr and bzr-svn. He's used git before, and I think he's familiar with hg as well. But he seems to be having a hard time with some of the concepts. I may not be the best teacher. :/ | 16:25 |
NfNitLoop | Like, it's confusing to him that each branch is a separate directory since in bzr & hg that's handled in SCM metadata w/o the need for another directory. | 16:26 |
NfNitLoop | and he's not quite understanding the difference between a "parent" branch and a "bound" branch. | 16:28 |
NfNitLoop | OTOH, the problem could just be that he hasn't read any bzr docs and is relying on me to tell him everything. heh. | 16:28 |
fullermd | I'm of the belief the former is easier to grasp by thinking strictly about the 3 components, and which are present in a given location. | 16:28 |
fullermd | For the latter, _I_ like solving it by killing "bound". With fire. :) | 16:29 |
NfNitLoop | hehe. | 16:29 |
fullermd | But that's more like a troll than a solution... | 16:29 |
NfNitLoop | Well, we have a rather large tree, so it's handy to bind it to branches, do some work, bind to a different branch, do some other work... | 16:29 |
NfNitLoop | instead of creating N working copies, or doing 'bzr checkout .' 'bzr remove-tree' all the time. | 16:30 |
NfNitLoop | but yeah, he tried to rebase in a bound branch and... things did not go well. :p | 16:30 |
fullermd | What's the advantage of bounding, rather than using a light checkout and switch? | 16:30 |
NfNitLoop | eh, it's in a shared repo, bind and switch, light checkout and switch. Not much difference in that case, right? | 16:33 |
fullermd | Clarity about what's going on. | 16:33 |
fullermd | It would be better modelling it as a heavy checkout and switch, than as a bound branch. But with it all being local, light checkout is conceptually a step closer. | 16:34 |
NfNitLoop | does the behavior differ? | 16:35 |
* fullermd covertly looks around for anybody who'll call him on trolling like this... | 16:35 | |
NfNitLoop | I thought the only difference is that a lightweight checkout doesn't have local history. | 16:35 |
NfNitLoop | but otherwise all operations between a light/heavy checkout should be the same? | 16:36 |
NfNitLoop | (and a bound branch == a heavy checkout.) | 16:36 |
fullermd | Well, see, that's the thing... | 16:36 |
fullermd | In implementation, they are, which is the root of confusions. In concept, they're not. | 16:36 |
fullermd | And in concept, what you're using here is a checkout, because what you want is just a working tree on a branch (in a serial-monogamy sort of sense). | 16:37 |
fullermd | And (IMAO) that's a lot easier to explain and grasp if explained as a checkout (working tree) moved among branches via 'switch', than as another branch with a special bound property that causes certain automatic interations with this other branch. | 16:38 |
NfNitLoop | Oh. Yeah. | 16:39 |
NfNitLoop | Only at this point, changing his workflow more would be counterproductive. | 16:39 |
fullermd | Oh, just reboot 'im. The POST will wipe out the old habits. | 16:39 |
NfNitLoop | heh. | 16:39 |
NfNitLoop | I think he'd be a lot less confused if he'd started with the bzr tutorial and learned the concepts first. | 16:40 |
NfNitLoop | instead, he looked at a wiki page I wrote about the workflow I use to interact with our SVN repo. | 16:40 |
NfNitLoop | thought "Git's close enough" and started using my workflow. | 16:40 |
* fullermd really should write up his model docs sometime :| | 16:40 | |
NfNitLoop | without quite understanding it. | 16:40 |
fullermd | Well, look at the bright side; if the version control usage doesn't pan out, he's still got a good future in politics 8-} | 16:42 |
=== salgado-lunch is now known as salgado | ||
=== IslandUsurperAFK is now known as IslandUsurper | ||
=== radoe_ is now known as radoe | ||
=== salgado is now known as salgado-brb | ||
MTecknology | What would cause this? bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/~ubuntu-drupal-devs/ubuntu-drupal-theme/6.x-orange/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 20:50 |
fullermd | Trying to write across http. | 20:52 |
MTecknology | fullermd: that happened when I just rant bzr commit -m "..." | 20:54 |
fullermd | Which suggest that somewhere prior to that you did "bzr checkout http://...." | 20:54 |
MTecknology | I grabbed it with bzr branch lp:.. | 20:54 |
MTecknology | I even tried on a fresh branch | 20:55 |
fullermd | If you're not logged in (bzr lp-login), lp: resolves to a read-only http:// URL. | 20:55 |
MTecknology | oh.. | 20:55 |
=== salgado-brb is now known as salgado | ||
fullermd | If you lp-login, it'll resolve to a writable (assuming you're in the right group anyway) bzr+ssh:// url, so you could lp-login, and then "bzr switch lp:..." to swap over to the writable protocol. | 20:56 |
MTecknology | why does it need to use the web if I'm only doing a commit on a branch grabbed using bzr branch? I thought that usually meant everything happens local until a push | 20:56 |
fullermd | It doesn't, if you made a _branch_ with "bzr branch". But in this case, you made a _checkout_ with "bzr co" (or possibly altered the branch later with 'reconfig' or 'bind') | 20:57 |
fullermd | Check "info". | 20:58 |
MTecknology | oh.... i get it now | 20:58 |
fullermd | (if you expect and _want_ a separate branch, definitely check before you switch and commit and maybe push it upstream before you intend to) | 20:58 |
MTecknology | I ran bzr branch lp:.. but because I didn't do lp-login, that's why it did http | 20:59 |
MTecknology | I thought you meant that had to do with the commit | 21:00 |
MTecknology | fullermd: thanks | 21:00 |
fullermd | Well, commit wouldn't try to write to the upstream if it were just an indepdendent branch. | 21:00 |
fullermd | It would only do that if you somehow ended up with a checkout/bound branch. | 21:01 |
=== salgado is now known as salgado-afk | ||
poolie | hi igc, lifeless, spiv, jelmer, | 21:58 |
lifeless | poolie: the robert has landed | 22:12 |
poolie | ah, you're in the other Commonwealth? | 22:17 |
lifeless | poolie: yup | 22:27 |
lifeless | about to go to the pre conf dinner I think | 22:27 |
poolie | enjoy | 22:29 |
lifeless | I got some good stuff done on the plane; I took lynnes new eeepc - huge battery life | 22:31 |
fullermd | Wait... if there's an "other", they're no longer common wealths anymore. | 22:34 |
igc | morning | 23:06 |
igc | hi poolie | 23:06 |
=== Meths_ is now known as Meths |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!