bob2 | aedan: only make framework changes on the framework branch. or at least put the changes you want to send the other way in self contained commtis. | 00:00 |
---|---|---|
bob2 | I dunno how smart bzr is about cherrypicking these days | 00:00 |
aedan | bob2: Ooh, so you're saying, if possible, commit only the changed framework files, then I can pull from that revision? | 00:01 |
lifeless | spiv: ugh | 00:04 |
lifeless | mwhudson: its rsyunc | 00:20 |
marianom | lifeless: thanks for the suggestions you provided me earlier today. already migrated and all issues fixed. | 00:31 |
lifeless | marianom: excellent | 00:32 |
bob2 | heh, bzr.dev is too old to work with bzrtools.dev | 00:37 |
mwhudson | spiv, lifeless: did my no-LockableFiles.__del__ patch fail tests? | 00:52 |
lifeless | mwhudson: no it was pending a prior patch, one sec | 00:54 |
mwhudson | k | 00:54 |
mwhudson | lifeless: i still get | 00:57 |
mwhudson | error: Error -5 while decompressing data | 00:57 |
mwhudson | on the bzr.dev.chk | 00:57 |
mwhudson | i have a 64 bit install, could that be related? | 00:57 |
jelmer | lifeless, did you see my reply about default-rich-root ? | 00:58 |
lifeless | mwhudson: from what? (I have a 64-bit install too) | 00:59 |
lifeless | jelmer: no | 00:59 |
jelmer | lifeless, http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/53957 | 00:59 |
mwhudson | lifeless: bzr log --short -l 10 | 00:59 |
mwhudson | lifeless: brisbane-core @ 3875 | 00:59 |
mwhudson | bzr-groupcompress @ 47 | 00:59 |
lifeless | rollback to 43 | 01:01 |
mwhudson | lifeless: ah, now we're go | 01:01 |
lifeless | jelmer: you want a new format, default-rich-root, which should be an alias for another format right? | 01:01 |
jelmer | lifeless, Yes, but what format it is an alias for will change in the future | 01:03 |
jelmer | just like --default does | 01:03 |
lifeless | jelmer: right, which is what aliases are all about | 01:03 |
jelmer | lifeless, right | 01:03 |
lifeless | jelmer: so just register an alias | 01:03 |
jelmer | lifeless, that's what I'm doing afaik | 01:04 |
lifeless | no, you're adding a new method | 01:04 |
jelmer | well, a new method to maintain the alias | 01:04 |
lifeless | you just need to register a new format that is an alias | 01:04 |
jelmer | lifeless, so you basically want me to move the contents of set_default_rich_root() to the top-level of bzrlib/bzrdir.py ? | 01:06 |
jelmer | lifeless, imho it's cleaner having that stuff in a separate method | 01:07 |
lifeless | uhh | 01:07 |
mwhudson | lifeless, jam, etc: bzrlib/_chk_map_pyx.pyx seems to have an error in brisbane-core | 01:08 |
mwhudson | /home/mwh/canonical/repos/bzr/brisbane-core/bzrlib/_chk_map_pyx.pyx:232:25: Expected an identifier or literal | 01:08 |
lifeless | jelmer: no; I'm suggesting you do what the other alias formats do | 01:09 |
lifeless | jelmer: which would be consistent :) | 01:09 |
mwhudson | oh | 01:09 |
mwhudson | my pyrex does' | 01:09 |
jelmer | lifeless, which means duplicating the branch format / repo format in a couple of places | 01:09 |
mwhudson | n't support ++ | 01:09 |
mwhudson | += | 01:09 |
jelmer | lifeless: anyway, if it's consistent I'll fix my patch but the way the aliases work seems suboptimal to me | 01:11 |
lifeless | jelmer: one place only. You could also put in a patch to make alias formats easier to manage; I object to the patch you have put in because it widens the registry interface specially rather than generally | 01:11 |
lifeless | when the thing that is needed is already in general use. | 01:11 |
* mwhudson is thinking that delta computation must be a little tiny bit faster in chk repos: http://pastebin.ubuntu.com/130001/ | 01:14 | |
mwhudson | strangely though log --short -l 10 still takes 3 seconds | 01:14 |
mwhudson | and heck | 01:15 |
mwhudson | *-l 1* takes 3s | 01:15 |
lifeless | spiv: (Pdb) ll = bzrlib.registry._LazyObjectGetter('bzrlib.branch', 'Branch.hooks') | 01:17 |
lifeless | (Pdb) ll.get_obj() | 01:17 |
lifeless | *** AttributeError: 'module' object has no attribute 'Branch.hooks' | 01:17 |
mwhudson | something is killing "start up" time on chk branches | 01:17 |
lifeless | spiv: I am not liking this :( | 01:17 |
lifeless | spiv: I would like a hand, otherwise I will feel that the code I have that works is better | 01:27 |
jam | mwhudson, lifeless: the startup time could easily be the time to unpack the one large group for all of the revision texts. | 01:39 |
jam | we have a couple ideas of how to make that better | 01:39 |
jam | and I'll go ahead and work out a fix for broken old pyrex versions :) | 01:40 |
lifeless | jam: we might want to do something about that | 01:40 |
glyph | 'bzr visualize' is a completely awesome thing | 01:41 |
glyph | thank you all | 01:41 |
lifeless | mwhudson: --lsprof on log --short -l 10 might be useful | 01:41 |
glyph | for making it possible | 01:41 |
lifeless | glyph: you're welcome | 01:41 |
glyph | suggestion though: "bzr glog" might be a good alias for it | 01:42 |
mwhudson | jam: http://pastebin.ubuntu.com/130009/ | 01:42 |
glyph | is 'dvc' the generally preferred emacs integration mechanism for bzr? | 01:43 |
mwhudson | lifeless: http://pastebin.ubuntu.com/130010/ | 01:43 |
* mwhudson not feeling so good, biab | 01:43 | |
lifeless | glyph: glog would be an awesome alias | 01:44 |
jam | mwhudson: what is the 'iter_inventory_xml_keys' change? | 01:45 |
lifeless | glyph: vila: will know | 01:45 |
jam | otherwise, I understand the += => = a + change | 01:45 |
mwhudson | jam: something lifeless gave me yesterday, i didn't mean to give that to you :) | 01:45 |
jam | and it is committed to brisbane-core 3876 | 01:45 |
mwhudson | jam: the .pyx fix is all i needed to make it compile | 01:45 |
mwhudson | cool :) | 01:45 |
jam | mwhudson: try setting _NO_LABELS = True | 01:47 |
jam | in groupcompress.py | 01:47 |
jam | and see how that changes "bzr log --short" time | 01:48 |
=== mneptok_ is now known as mneptok | ||
jam | mwhudson: ah, that won't actually make a difference, as it parses the labels if they are there | 01:50 |
jam | I can give you a one-line change to the parser, though, just a sec | 01:51 |
jam | mwhudson: you can cherrypick revno 48, or use: http://pastebin.ubuntu.com/130013/ | 01:56 |
jam | (sorry it isn't 1 line, but it was cleaner this way) | 01:57 |
=== timchen1` is now known as nasloc__ | ||
jam | mwhudson: that patch has some typos, this one is better: http://pastebin.ubuntu.com/130019/ | 02:20 |
jam | it drops off about 300ms for me on 'bzr log --short -r -10..-1' | 02:20 |
jfroy | vila: quick fyi: new patch is up | 02:32 |
mwhudson | jam: it gets me back to "error: Error -5 while decompressing data" | 02:43 |
mwhudson | jam: oh no, pebkac; it just doesn't apply cleanly to r43 of groupcompress | 02:45 |
mwhudson | so my branch of loggerhead is less of a dos attack on servers, i hope | 03:02 |
mwhudson | it still does a pretty good job on firefox if you ask for it... | 03:02 |
lifeless | mwhudson: cool | 03:27 |
mwhudson | oh and the code is horrible beyond all belief | 03:28 |
lifeless | :*( | 03:28 |
lifeless | why | 03:28 |
mwhudson | because i've been hacking | 03:28 |
mwhudson | now i know it works and feels ok, it's time to do it right | 03:29 |
lifeless | wat have you done | 03:29 |
mwhudson | some ajaxy loading | 03:30 |
mwhudson | play, if you like: bzr+ssh://bazaar.launchpad.net/~mwhudson/loggerhead/finite-revision-pages | 03:30 |
lifeless | what does it do though | 03:33 |
lifeless | mwhudson: like, is it just skipping html rendering on the server? | 03:41 |
mwhudson | lifeless: it's more about not including stuff in the initial page sent to the browser | 03:44 |
mwhudson | lifeless: so for example, in the changelog view, not sending the list of changed files until the disclosure triangle is clicked | 03:44 |
lifeless | mwhudson: cool | 03:51 |
gotgenes | I'm having difficulty figuring out when one branch originated from another. I thought bzr viz would show it but I don't see anything obvious. Is there some other way? | 04:01 |
SamB | glyph: I have no idea if it's preferred, but if you find any bugs please report them on launchpad ;-) | 04:14 |
SamB | re: dvc | 04:14 |
poolie | jml, http://imgs.xkcd.com/comics/not_enough_work.png | 04:16 |
spiv | mwhudson: your patch landed | 04:20 |
jml | poolie: yeah, I've seen it. | 04:27 |
jml | glyph: welcome to #bzr :) | 04:27 |
* SamB wonders why *bzr-status* is in dvc-diff-mode | 04:38 | |
poolie | lifeless: thanks for the hooks registry :) | 04:39 |
SamB | is there a way to get structured information out of bzr status ? | 04:39 |
poolie | SamB from another process? you can try the bzr-xmloutput plugin | 04:43 |
SamB | but then I'd have to parse the XML ... no json? | 04:44 |
SamB | (just because it's a heck of a lot simpler to parse than XML, not that I'm writing AJAX or anything) | 04:44 |
james_w | not currently I believe | 04:45 |
james_w | extending bzr-xmloutput could be extended to provide json I guess | 04:45 |
abentley | LarstiQ: Hi there, I've started work on nested trees, starting with merging bzr.dev into your latest. | 05:11 |
poolie | spiv, not to interrupt you too much, but did you already fix something like bug 341535? | 05:28 |
ubottu | Launchpad bug 341535 in bzr "hpss SmartMedium doesn't handle eintr" [Undecided,New] https://launchpad.net/bugs/341535 | 05:28 |
spiv | poolie: I did, for the TCP client medium | 05:31 |
spiv | poolie: there's a osutils.until_no_eintr helper | 05:31 |
poolie | thanks | 05:32 |
poolie | i don't think i care quite enough to do it right now | 05:32 |
poolie | maybe when fetch progress is a bit more cooked | 05:32 |
SamB | is there a way to cancel a bzr rm ? | 05:37 |
jml | SamB: if you mean undo, then 'bzr revert filename' works | 05:39 |
=== abentley1 is now known as abentley | ||
SamB | jml: well ... I have files still | 05:42 |
jml | SamB: I don't follow. | 05:43 |
SamB | they had gotten moved away from where they should have been, is all | 05:44 |
SamB | and then I foolishly ran "bzr rm" with no arguments | 05:45 |
spiv | SamB: so you have a change in your working copy you want to revert, the change being that some files were unversioned; "bzr revert filenameA filenameB ..." as jml says is the way to undo that. | 05:48 |
bob2 | hm, should upgrading a bzr.dev mirror to --development take like hours and spin at "checking repository format 1/1" for 2 or so? | 05:49 |
lifeless | bob2: possibly :P you'reusing bzr.dev? | 05:54 |
bob2 | lifeless: yeah | 05:55 |
poolie | rfc: there should also be a 'connecting' activity indicator to show that's what we're waiting for | 05:58 |
poolie | activity as opposed to a progress thing | 05:58 |
SamB | i.e. a spinner | 05:59 |
spiv | poolie: it would be nice, although a little bit hard to implement accurately perhaps? I'm thinking of when bzr+ssh delegates the connecting to an openssh subprocess... | 06:03 |
poolie | spiv, i'm basically saying it should do | 06:04 |
SamB | spiv: what would it mean for it to be accurate in that situation? | 06:05 |
poolie | > report_activity(self, 'connecting') | 06:05 |
poolie | before running openssh | 06:05 |
poolie | so it won't spin but at least it'll show that rather than just '0kB' | 06:06 |
SamB | oh | 06:08 |
SamB | you just want a message | 06:08 |
SamB | "hey this is what's I'm about to do, just hold on, I'll be right back!" | 06:08 |
spiv | poolie: ah, right. +1 | 06:09 |
poolie | SamB, exactly | 06:09 |
spiv | SamB: Well, there's arguably a significant difference between "waiting for SSH to connect" and "waiting for remote bzr to reply to my first request" | 06:10 |
spiv | I'm not sure it really matter too much in practice. At least at the moment our first requests don't require much processing time on the server. | 06:11 |
SamB | spiv: well, it would at least tell you that bzr wasn't ransacking your local storage ... | 06:11 |
SamB | though I guess if you're actually sitting at your computer you'd know anyway ... | 06:12 |
poolie | spiv, doing something for the hello would be good too | 06:19 |
spiv | poolie: when probing for bzr+http? | 06:25 |
=== abentley1 is now known as abentley | ||
poolie | or on the first request to the smart server | 06:28 |
poolie | just an idea | 06:28 |
poolie | it might take a while to get going | 06:28 |
=== abentley1 is now known as abentley | ||
=== abentley1 is now known as abentley | ||
poolie | spiv, remote.py has | 07:34 |
poolie | 1509 if not resume_tokens: | 07:34 |
poolie | 1510 # XXX: Ugly but important for correctness, *will* be fixed during | 07:34 |
poolie | 1511 # 1.13 cycle. Pushing a stream that is interrupted results in a | 07:34 |
poolie | 1512 # fallback to the _real_repositories sink *with a partial stream*. | 07:34 |
poolie | 1513 # Thats bad because we insert less data than bzr expected. To avoid | 07:34 |
poolie | 1514 # this we do a trial push to make sure the verb is accessible, and | 07:34 |
poolie | 1515 # do not fallback when actually pushing the stream. A cleanup patch | 07:34 |
poolie | 1516 # is going to look at rewinding/restarting the stream/partial | 07:34 |
poolie | 1517 # buffering etc. | 07:34 |
poolie | is that true? | 07:34 |
=== kiko is now known as kiko-afk | ||
stefanlsd | Can i push a branch i was working on to another server? I did a push and i just get the .bzr directory on the other side (no files) | 09:30 |
beuno | stefanlsd, right, remote pushes don't create working trees | 09:31 |
beuno | so you have the branch, but not the actual files | 09:32 |
beuno | if you want the files, you need to run: bzr co . | 09:32 |
beuno | but subsequent pushes won't update them | 09:32 |
beuno | you need the push-and-update plugin for that | 09:32 |
beuno | unless you *only* care about the actual files remotely, then you can use bzr-upload | 09:32 |
stefanlsd | beuno: mm. im trying to setup that another guy in my office can work on some of the projects with me. So i made a place on a remote server. I wanted to take my local bzr stuff and get it there. Would it be better to just scp it to the central server now? | 09:33 |
beuno | stefanlsd, no, he can just branch from that | 09:34 |
stefanlsd | beuno: its not there yet. I have it all locally. i wanted to get it there first by pushing.. should I rather go central and branch it from me? | 09:34 |
beuno | stefanlsd, it *is* there | 09:35 |
beuno | if you pushed it, and there's a .bzr directory | 09:35 |
beuno | that's the branch | 09:35 |
beuno | you don't need the working tree (actual files) | 09:35 |
stefanlsd | beuno: oh. interesting. wasnt aware of that | 09:36 |
stefanlsd | beuno: thanks. so my understanding now is, if i want the working tree there also i need the push and update plugin. will look into that. thx! | 09:40 |
beuno | stefanlsd, you're welcome | 09:40 |
cristi_an | what is the diff between bzr push and bzr up | 09:41 |
cristi_an | ? | 09:41 |
beuno | cristi_an, one is used for checkouts, and one is used for branches | 09:42 |
beuno | (there's more to it, but let's start with that) | 09:42 |
cristi_an | beuno: thx...i did not find this in the 5 min tut :) | 09:42 |
cristi_an | which one i sfor checkouts | 09:43 |
beuno | cristi_an, how did that question pop into your head? | 09:43 |
cristi_an | well...i explain | 09:43 |
cristi_an | i get a project called openerp from launchpad | 09:43 |
hmeland | The help for up probably ought to mention the term "checkout" somewhere. | 09:43 |
cristi_an | but after a few day since i was i cvs user before | 09:44 |
cristi_an | i did bzr up | 09:44 |
cristi_an | but it did not bring any of the changes done by others | 09:44 |
beuno | cristi_an, did you branch it, or did you make a checkout? | 09:44 |
cristi_an | beuno: i run a script that get all those projects for me... | 09:46 |
cristi_an | http://paste.pocoo.org/show/107535/ | 09:46 |
beuno | cristi_an, ok, so you branch them | 09:47 |
beuno | 'bzr update' won't come into play at all for now | 09:47 |
cristi_an | in terms of using cvs | 09:47 |
cristi_an | i checkout them... | 09:47 |
cristi_an | :) | 09:47 |
beuno | well, you can do a checkout with bzr as well | 09:48 |
beuno | and then it's basically the same | 09:48 |
beuno | when you commit, it will commit directly to the online branch | 09:48 |
beuno | "update" brings in new changes, etc | 09:48 |
beuno | a checkout is bound to it's parent | 09:48 |
cristi_an | but can you tell me what that script does | 09:48 |
beuno | branches, on the other hand, are independant | 09:48 |
cristi_an | i seee | 09:48 |
beuno | yes, it creates branches | 09:48 |
cristi_an | so i have c copy locally | 09:49 |
cristi_an | and i work local | 09:49 |
cristi_an | then i can merge with some server branch | 09:49 |
cristi_an | ? | 09:49 |
cristi_an | somthing like commit will commit on my local branch | 09:49 |
cristi_an | not on server ? | 09:49 |
hmeland | cristi_an: Your script takes a --checkout option. Supply that option with your launchpad username to make the script do "bzr checkout" and "bzr update" instead of "bzr branch" and "bzr pull". | 09:50 |
cristi_an | i have to read about this more.... | 09:51 |
cristi_an | :) | 09:51 |
cristi_an | but i got the picture.... | 09:51 |
cristi_an | thx | 09:52 |
=== abentley1 is now known as abentley | ||
=== bac` is now known as bac | ||
nick_ | Can anyone help me with setting up a bug tracker within Bazaar? The documentation I've found tells me about it, but not how to do it | 13:00 |
=== `6og is now known as Kamping_Kaiser | ||
hmeland | nick_: What kind of bug tracker are you talking about? | 13:25 |
nick_ | hmeland: a custom made one - I basically want to know what things I need to put in the bazaar.conf file in order to get it working with --fixes | 13:25 |
hmeland | You've seen http://doc.bazaar-vcs.org/latest/en/user-reference/bzr_man.html#bug-tracker-settings already? | 13:30 |
nick_ | hmeland: yes, but it seems to be lacking explanation | 13:37 |
nick_ | hmeland: for example, I don't know what parameters Bazaar passes my bug tracker when I mark a commit as --fixed | 13:37 |
nick_ | I'm assuming it HTTP POSTs by default? | 13:37 |
beuno | nick_, no, it's metadata on the branch | 13:38 |
beuno | no http communication at all | 13:38 |
nick_ | beuno: ahhh, so how does the tracker get this information, through a post commit hook? | 13:40 |
beuno | nick_, well, it's up to the tracker | 13:40 |
beuno | tip-change | 13:40 |
beuno | cronjob | 13:40 |
beuno | whatever | 13:40 |
nick_ | beuno: I see | 13:40 |
nick_ | beuno: are you familiar with the shell_hooks plugin at all? | 13:40 |
beuno | nick_, not really, no | 13:41 |
nick_ | beuno: ah, just I can't get it to work :) | 13:41 |
nick_ | beuno: I'm not well versed with Python | 13:41 |
nick_ | does anyone know of a post commit hook that can HTTP POST to a URL? | 13:43 |
* SamB wishes bzr-gtk didn't have that unintended seahorse dependancy :-( | 13:54 | |
kfogel | When I bring in changes from someone else's branch via 'bzr merge', I have to write a new log message when I then do 'bzr commit', even though the other person already wrote a log message. I can even see the original log message when I do 'bzr status' ("pending merge tips: ...", or with -v, "pending merges: ..."). Is there some way to commit the merged change(s) locally such that they automatically get the same author and commit message as | 13:58 |
kfogel | the originals? | 13:58 |
beuno | kfogel, not atomatically, no | 13:58 |
kfogel | beuno: hmrm. Okay, thanks. So it sounds like there isn't really a way to say (in a non-mirror branch) "Just bring in these changes, I don't want to have to specify anything more about them, I just want them incorporated into my local branch." | 13:59 |
kfogel | ? | 13:59 |
beuno | kfogel, right, the merge is always explicit | 13:59 |
kfogel | *nod* | 14:00 |
kfogel | beuno: thx | 14:00 |
beuno | :) | 14:00 |
kfogel | beuno: is there at least some way (immediately after 'bzr merge') to get the full information about all merged-but-not-committed changes? Specifically, I want to list their source branch and revision number, in my commit message. | 14:01 |
kfogel | beuno: or is that pointless, because bzr will already record those when I commit? | 14:01 |
beuno | other than bzr status? | 14:02 |
kfogel | (in which case, great, but I'd still want to *see* the pending revs before committing) | 14:02 |
kfogel | beuno: bzr status -v shows committer, date, and msg, but not source branch or rev num | 14:02 |
beuno | right, so there's not way that I know of to see those | 14:02 |
beuno | that may be useful | 14:02 |
beuno | so it sounds like you're cooking a bug there | 14:03 |
kfogel | :-) | 14:03 |
kfogel | Yeah, it would be nice to be able to see the exact identity of what I'm about to commit. For an especially paranoid developer, that might be part of a sanity check. | 14:03 |
SamB | high in protein! | 14:03 |
kfogel | SamB: breakfast of champions! | 14:03 |
SamB | but at least you know their descriptions -- darcs isn't even capable of telling me what revisions have conflicted | 14:04 |
* kfogel looks at bzrlib/status.py:show_pending_merges() | 14:05 | |
SamB | (apparantly it's not even easy in theory!) | 14:05 |
* awilkins is totally awesomed out by how awesome uploading things to a PPA is | 14:09 | |
awilkins | Why the hell does it build fricking Atom builds of things though..... | 14:10 |
kfogel | beuno: crimminy, don't even have the information available in bzrlib/revision.py:Revision, as far as I can tell. | 14:15 |
SamB | Atom ? | 14:17 |
SamB | you mean it converts them to RSS feeds? | 14:18 |
SamB | (Yeah, I know Atom isn't actually named RSS -- but then basically no two versions of RSS expand to the same name either) | 14:19 |
* SamB wonders how glyph found out about dvc | 14:20 | |
rocky | jelmer: bzr svn-import is currently failing for me (after a few mins of running) on htps://dev.serverzen.com/svn/cluemapper | 14:21 |
rocky | jelmer: that's with bzr 1.13rc1 and bzr-svn 0.5.3 | 14:21 |
kfogel | policy question: when bzr can receive a setting from either an environment variable or the bazaar.conf file, which overrides which? Does the env var dominate the config setting if both exist, or the other way around? | 14:23 |
kfogel | (this is for implementing a new thing -- if it were an existing feature, I'd just test) | 14:31 |
SamB | kfogel: well, usually the env var, I hope | 14:54 |
kfogel | SamB: that's what I picked | 14:54 |
SamB | might depend on the setting a bit, but for instance if I have an emacs package that wants to turn off the progress bar ... | 14:55 |
SamB | ... then I'm going to be annoyed by https://bugs.launchpad.net/bzr/+bug/339385 | 14:56 |
ubottu | Ubuntu bug 339385 in bzr "bzr: BZR_PROGRESS_BAR is ignored" [Medium,Confirmed] | 14:56 |
* SamB wishes ubottu would get it right and say "Launchpad bug" | 14:57 | |
kfogel | SamB: well, that's just because of the bug, right? It doesn't change the correct ordering. | 14:58 |
SamB | yeah | 14:58 |
SamB | I was just being silly with that last message | 14:59 |
SamB | going to a conclusion unrelated to the premise | 14:59 |
SamB | (the premise that the env var should override the conf file, that is) | 15:00 |
SamB | (I don't think there is a conf setting for this?) | 15:00 |
SamB | I certainly don't see a progress bar setting in my bazaar.conf | 15:01 |
* SamB wonders if there's some sort of script to manually convert an svn:ignore property to .bzrignore | 15:02 | |
SamB | jelmer: is there a way to query SVN revision properties from bzr-svn ? | 15:03 |
SamB | no, wait, this would be a file property | 15:03 |
SamB | well, both things would be good anyway | 15:03 |
SamB | and the way should be mentioned in "bzr help svn", of course | 15:04 |
* SamB wonders if there's a way to get launchpad to build and serve docs | 15:06 | |
* SamB re-opens https://bugs.launchpad.net/bzr-svn/+bug/174947 | 15:16 | |
ubottu | Ubuntu bug 174947 in bzr-svn "Commands for changing/viewing file properties" [Wishlist,In progress] | 15:16 |
SamB | does anyone know how to get word-wrap in emacs (without altering the buffer data)? | 15:19 |
SamB | i.e. yes, I know how to use M-q, that's not what I want ;-P | 15:19 |
SamB | oh, emacswiki says LongLines | 15:25 |
jelmer | SamB, I think we did have them at some point but they got removed, since they were just aliases for "svn propset / svn propget" | 15:25 |
SamB | jelmer: how's that going to work in a bzr-native format checkout/branch/etc? | 15:25 |
jelmer | SamB: there's no way that can work in a bzr native format | 15:26 |
SamB | oh | 15:26 |
jelmer | SamB, but with a bzr-specific command it can't work in a bzr native format either | 15:26 |
jelmer | since the bzr native format can't store custom file properties | 15:26 |
SamB | wait, I din't need an answer to how is "svn foo" going to work in a bzr-native directory ;-P | 15:26 |
SamB | that was rhetorical | 15:26 |
Leon_Nardella | leon@bespin:~/Documents$ bzr update scrip/ | 15:27 |
Leon_Nardella | Permission denied (publickey). | 15:27 |
Leon_Nardella | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) <-- What does this usually mean? I know it's something to do with my messing around backing up the branch to Dropbox and changing keys, but I'm not sure what I can do to make it work now. This branch is hosted on Launchpad and I can check it out without problems. | 15:27 |
SamB | I thought you were giving the second (bzr format can't handle that) answer already ;-) | 15:27 |
jelmer | SamB, I also mean "bzr svn-propset" can't work in a bzr-native directory | 15:27 |
* Leon_Nardella sorry for the multiple lines | 15:27 | |
jelmer | SamB, since there's no place it can store the properties | 15:27 |
SamB | jelmer: oh | 15:27 |
jelmer | SamB, the way you've changed the bug report right now indicates I'm working on it.. that's not the case :-) | 15:28 |
SamB | jelmer: well, you can change it to something more appropriate | 15:29 |
SamB | I thought maybe you'd somehow hidden it where I couldn't see it :-) | 15:29 |
SamB | given it a funny name or something | 15:29 |
jelmer | SamB, are you still interested in it if it's just going to be an alias for "svn propset" / "svn propget" ? | 15:29 |
SamB | not if it requires a .svn dir, no. but some documentation about the uselessness of such a thing would be good. | 15:30 |
jelmer | SamB, I'll comment in the bug report | 15:31 |
SamB | and I would be interested in extensions to bzr to allow it to be useful, as well | 15:31 |
SamB | jelmer: how about adding it to the FAQ? | 15:31 |
jelmer | SamB, that's the sort of documentation you meant, right? | 15:31 |
SamB | in addition, I mean | 15:31 |
SamB | like: "Q: How can I look at my file properties?" "A: If you're in an svn checkout, the usual way. If in a bzr native tree, there aren't any to see." | 15:33 |
jelmer | SamB, Care to send a patch ? :-) | 15:35 |
sohail | how can I take the difference of two branches? | 15:40 |
sohail | one has a bug, one doesn't :-) | 15:40 |
sohail | ah --old | 15:41 |
sohail | hmm... well that is lying | 15:42 |
jelmer | SamB, just curious, what sort of properties would you want to set ? | 15:42 |
Odd_Bloke | sohail: How so? | 15:44 |
sohail | Odd_Bloke, bzr switch buggy-branch; bzr diff --old non-buggy-branch -> no diff which is not true | 15:45 |
sohail | oh do I have to give the full path to the old branch? | 15:46 |
sohail | that's annoying but ok | 15:46 |
Odd_Bloke | sohail: Yeah, that'll be it. | 15:46 |
Odd_Bloke | sohail: Though there should probably be an error message if there isn't a branch at non-buggy-branch... | 15:47 |
sohail | Odd_Bloke, I'd agree with that | 15:50 |
sohail | ok I need to binary search where this bug was introduced... how do I do that with bzr? is there an equivalent to svn up -r $FOO ? | 15:56 |
sohail | sorry if my question is ignorant :-) | 15:56 |
Kinnison | you can either make new checkouts at given revisions, or bzr revert might help you since you can pass that -r $FOO | 16:00 |
Kinnison | but I'm not a power-user, so I could be wrong | 16:00 |
sohail | I just found the bzr bisect plugin | 16:01 |
sohail | lets hope it doesn't screw up my repo :-) | 16:01 |
glyph | how does one unbind a bound branch | 16:03 |
jelmer | glyph, bzr unbind :-) | 16:04 |
glyph | jelmer: I figured that out a split second before you said it, and felt appropriately foolish :) | 16:04 |
jelmer | glyph, :-) | 16:06 |
=== gorozco is now known as p4tux | ||
sohail | haha... bzr bisect: 1115 no, 1118 yes, 1116 yes, 1116, 1116, 1116, 1116, explode | 16:10 |
sohail | lol! | 16:10 |
sohail | screw this, I'm going ot exercise | 16:10 |
Kinnison | heh | 16:12 |
ripps | Does anybody here know how to mirror a git repository into a launchpad branch? | 16:22 |
SamB | ripps: jelmer might? | 16:35 |
SamB | then again maybe you can't | 16:35 |
SamB | I think it will involve a cron job on a system you have a shell on, though | 16:36 |
jelmer | ripps, small repositories should be convertable with git-import from bzr-git, alternatively you can use git fast-export/ bzr fast-import | 16:36 |
jelmer | ripps, there's nothing in launchpad to have it mirror for you automatically (yet) | 16:36 |
ripps | jelmer: so, back to manually uploading it | 16:36 |
SamB | or if you control the git server you could use some kind of post-hook | 16:36 |
SamB | ripps: cron! | 16:37 |
SamB | hmm, how come you can't just give launchpad svn:// URLs to mirror the bzr way, anyway? | 16:37 |
SamB | why does it have a special vc-import thing for that? | 16:38 |
jelmer | SamB, hysterical raisins | 16:38 |
jelmer | SamB, vcs-imports predate bzr-svn | 16:38 |
SamB | I suppose it's good for the users anyway | 16:38 |
SamB | jelmer: oh. how does it work then? | 16:38 |
jelmer | SamB, there has been talk about using bzr-svn on lp | 16:38 |
jelmer | SamB, but the problem is it will cause disruption for users of the existing mirrors | 16:38 |
SamB | I mean, it would be kind of confusing to expect users to just enter an SVN url as if it was a BZR url | 16:39 |
jelmer | SamB, it use cscvs | 16:39 |
jelmer | SamB, what would be confusing about that? | 16:39 |
SamB | jelmer: well, for new users anyway | 16:39 |
jelmer | SamB, there are mirrors of "regular" bzr branches too | 16:39 |
jelmer | SamB, In general the format of a branch shouldn't matter, whether it's Subversion or native Bazaar | 16:40 |
SamB | anyway ... the obvious way to go to bzr-svn would be to allow people to start entering those SVN urls in the field, then tell them about it after a while ... | 16:40 |
SamB | and just keep doing vcs-import the same way as before | 16:40 |
jelmer | SamB, yeah | 16:41 |
jelmer | SamB, unfortunately there's no shared history between stuff imported with vcs-imports and bzr-svn | 16:41 |
jelmer | SamB, so users can't really migrate from vcs-imports to bzr-svn | 16:41 |
SamB | yeah | 16:41 |
SamB | but giving new users the option is good | 16:42 |
SamB | does bzr-rebase share git-rebase's "no revision 0" flaw? | 16:42 |
jelmer | SamB: well, it means that if somebody you work together with happens to do a commit based on a bzr-svn branch and your branch is a vcs-improts branch it breaks | 16:42 |
SamB | jelmer: oh | 16:42 |
SamB | it breaks? | 16:42 |
jelmer | SamB, "breaks" in the sense that it doesn't have any shared history | 16:43 |
SamB | it doesn't just ... not show up nicely? | 16:43 |
SamB | vcs-imports doesn't grok SVK attributes? | 16:43 |
SamB | anyway, that doesn't sound much worse than using SVN in the first place ... | 16:43 |
jelmer | SamB, and will attempt to merge from rev 0 as it doesn't see common revisions | 16:43 |
SamB | jelmer: huh? | 16:43 |
jelmer | SamB, I'm not sure I understand what SVK has to do with it | 16:43 |
SamB | what do you mean? | 16:43 |
jelmer | SamB, it will attempt to merge *all* revisions from the bzr-svn branch as none are present in the vcs-imports branch | 16:44 |
SamB | oh | 16:44 |
jelmer | SamB, bzr-rebase doesn't have any "no revision 0" flaws | 16:44 |
SamB | you mean if you try to pull a commit across via bzr! | 16:44 |
SamB | apparantly git-rebase can't really rebase between branches with different roots :-( | 16:45 |
SamB | I read somewhere a proposal for a special 00000... commit | 16:45 |
jelmer | SamB, bzr already has such a thing | 16:46 |
SamB | I thought probably | 16:46 |
SamB | sounds better than git-svn, anyway ;-) | 16:46 |
jelmer | SamB, so the main reason bzr-svn isn't supported at the moment yet is because it would cause confusion for existing vcs-imports users and problems merging | 16:47 |
SamB | git-svn users are encouraged not to share git commits! | 16:47 |
jelmer | SamB, whoa, wasn't aware of that | 16:47 |
SamB | since it doesn't roundtrip too well | 16:48 |
Odd_Bloke | Yeah, bzr-svn is just a ridiculous amount better than git-svn. | 16:48 |
SamB | so having two incompatible tools doesn't sound nearly as bad | 16:49 |
Odd_Bloke | In terms of actual functionality. | 16:49 |
SamB | yeah | 16:49 |
SamB | now if only it didn't spend so much time apparantly doing nothing ... | 16:49 |
jelmer | SamB, are you running 0.5.3 yet? | 16:49 |
Odd_Bloke | Maybe not so much in terms of speed, but <insert tired argument about features > speed here> | 16:49 |
SamB | svn 0.5.4dev | 16:50 |
jelmer | SamB, and what in particular is slow? | 16:50 |
SamB | hmm. | 16:51 |
SamB | it's stopped doing it. | 16:51 |
SamB | typical! | 16:51 |
SamB | hmm, maybe that's because that branch was bound to the SVN repository ... | 16:54 |
SamB | bzr-svn just seems to spend an inordinate amount of time looking at svn revisions it's already seen | 16:55 |
SamB | even when there are no revisions to pull | 16:55 |
SamB | but apparantly not when your working directory is a heavyweight bzr-native SVN checkout | 16:56 |
SamB | is there a way to dump the progress output? | 16:57 |
jelmer | SamB, Not really | 17:02 |
jelmer | SamB, you can run with -Dtransport and see what sort of protocol requests it's doing | 17:02 |
jelmer | SamB, what progress bar phase is it spending the most time in during pull ? | 17:02 |
SamB | it skips back and forth | 17:02 |
SamB | there ought to be a way to dump either a trace or at least a sampling of the progress bar phases ... | 17:04 |
jelmer | SamB, skips back and forward between what? | 17:04 |
jelmer | SamB, what texts in the progress bar I mean | 17:04 |
SamB | I know, that's what I'm saying should be traceable | 17:05 |
SamB | discovering revisions and determining changes | 17:05 |
SamB | Pull phase | 17:05 |
SamB | and the SVN revnums are all over the place as it does that | 17:06 |
SamB | hmm, gotta go to school now | 17:06 |
jelmer | SamB, might be looking at tags | 17:07 |
jelmer | SamB, That should hopefully be fixed in the next version | 17:07 |
SamB | why does bzr not being able to delete a non-empty directory count as a conflict? | 17:08 |
jelmer | SamB, because upstream has removed a directory and locally that directory can't be removed | 17:10 |
SamB | I know what it means | 17:10 |
SamB | but why's that a conflict? | 17:10 |
SamB | it should be something more like a sticky warning or ... | 17:10 |
SamB | I mean it's just object files, probably ... | 17:10 |
jelmer | SamB: Well, I was stating it like that to hopefully clarify that the operation that happened remotely can't happen locally | 17:11 |
SamB | I know but conflict seems a bit harsh a status for it | 17:11 |
jelmer | and that's basically what a conflict is about | 17:12 |
SamB | in that case | 17:12 |
SamB | the directory can just be removed from version control, can't it? | 17:12 |
jelmer | SamB, if there's only ignored files in it, sure | 17:12 |
jelmer | SamB, but in that case the user probably won't be aware of it | 17:12 |
SamB | oh. is ignoring that important? | 17:12 |
SamB | well, it still seems slightly less urgent than a warning | 17:13 |
SamB | er. s/warning/conflict/ | 17:13 |
jelmer | SamB, so you think a directory should become "unknown" at that point? | 17:14 |
jelmer | SamB, in that case you risk that a user runs "bzr add" to add their other unknown files and ends up re-versioning the directory | 17:15 |
SamB | hmm. | 17:15 |
SamB | maybe I'd just like it to be easier to say "okay, go ahead and unversion that" | 17:15 |
jelmer | SamB, right | 17:15 |
SamB | could be something to add to dvc | 17:15 |
jelmer | SamB, I think it would be reasonable to automatically mark a conflict as resolved if the remote removed a file/directory but it was changed locally | 17:16 |
jelmer | SamB, and the user then removed the local files | 17:16 |
SamB | hmm. | 17:16 |
SamB | well, I didn't remove it yet actually | 17:17 |
SamB | I'm so lazy | 17:17 |
jelmer | join the club :-) | 17:17 |
SamB | I still don't get why bzr-status and bzr-conflicts use dvc-diff-mode ... | 17:18 |
=== serg_ is now known as serg | ||
mwhudson | jelmer: hello | 19:57 |
BasicOSX | We still on track for 1.13final on 03/13 or should I push a 1.1.3rc2? I've posted to bazaar general about it. | 19:59 |
=== thumper_laptop is now known as thumper | ||
ovnicraft | hi, i see in lauchpad trac-bzr is part of bzr if anyone can help me here? | 20:07 |
mwhudson | BasicOSX: how many changes have hit bzr.1.13 since rc1 ? | 20:07 |
mwhudson | BasicOSX: i was going to nag you about sneaking some patches in, but i don't think it's worth it any more | 20:08 |
BasicOSX | mwhudson: do not know the number of changes, don't have ability to check right now, and I don't control the freeze, I just do the work of pushing the release :-) | 20:10 |
mwhudson | BasicOSX: do you know what revno 1.13rc1 was? | 20:11 |
BasicOSX | bzr log, look for 'Release 1.13rc1' | 20:12 |
LarstiQ | bzr log -m Release\ 1.13rc1 | 20:13 |
mwhudson | hm, there have been two landings | 20:13 |
LarstiQ | ovnicraft: do you have an actual question? | 20:13 |
mwhudson | (vila) Fix non ascii symlink handling | 20:13 |
mwhudson | (spiv) Fix bogus 'Source format does not support stacking' warning | 20:13 |
mwhudson | when pushing to smart server | 20:13 |
BasicOSX | revno: 4104.1.1, should be PQM submission | 20:13 |
LarstiQ | abentley: ok, how is that going? | 20:14 |
mwhudson | both look reasonably minor | 20:15 |
mwhudson | though i guess the non-ascii one could potentially cause problems | 20:15 |
ovnicraft | LarstiQ, i have problems with trac-bzr i get the output | 20:16 |
ovnicraft | can you help me about that? | 20:16 |
lucypher | Hi , I can't branch a project from launchpad , here the result: http://pastebin.com/m41156b8b | 20:17 |
lucypher | I'm on Ubuntu jaunty | 20:17 |
LarstiQ | ovnicraft: I can try, but so far I don't know what problem you are experiencing | 20:17 |
LarstiQ | lucypher: Permission denied (publickey) is the important part | 20:18 |
mwhudson | hmmm | 20:19 |
awilkins | Ah, he's defined launchpad-login but either hasn't uploaded a key or doesn't have it available to the local bzr process | 20:19 |
mwhudson | why isn't the non-ascii symlink fix in bzr.dev | 20:19 |
mwhudson | vila: hi :) | 20:20 |
lucypher | LarstiQ : I did... bzr lp-login | 20:20 |
awilkins | lucypher: Did you upload a public key, and is it available in your local ssh-agent | 20:21 |
awilkins | Or even in ~/.ssh/id_rsa | 20:21 |
awilkins | (the private key to go with that public key) | 20:21 |
LarstiQ | lucypher: have you followed a process like https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair ? | 20:22 |
LarstiQ | lucypher: the ssh server on launchpad is complaining it doesn't know the key you are trying to log in with | 20:22 |
lucypher | I've moved my Home partition recently and did some cleanup... ;-) | 20:23 |
LarstiQ | lucypher: that might explain it ;) | 20:23 |
ovnicraft | LarstiQ, any pastebin to this channel? | 20:23 |
ovnicraft | LarstiQ, http://pastebin.com/m35bd5f39 | 20:24 |
ovnicraft | my error | 20:24 |
lucypher | LarstiQ , awilkins : thanks | 20:24 |
jelmer | mwhudson, hi | 20:25 |
mwhudson | jelmer: so, bzr-svn vs codespeak currently breaks because of that svn bug | 20:25 |
mwhudson | jelmer: i can probably remove the problem revprops | 20:26 |
mwhudson | jelmer: if you explain how :) | 20:26 |
mwhudson | (i can probably figure it out myself, but my brain is on go-slow today) | 20:26 |
awilkins | AFAICR if you set them to an empty value they will be removed | 20:27 |
awilkins | Ah, or propdel | 20:27 |
awilkins | svn propdel PROPNAME --revprop -r REV | 20:28 |
jelmer | mwhudson, the problem is it isn't not the revprops | 20:28 |
jelmer | mwhudson, it's fileprops | 20:28 |
mwhudson | jelmer: grunk | 20:28 |
mwhudson | jelmer: i guess committing a change that deleted the file props wouldn't help? | 20:29 |
mwhudson | i mean, i have root on the box, all things are possible :) | 20:29 |
mwhudson | but i'd rather not knacker the repo | 20:29 |
jelmer | mwhudson: fixing it will require a svndump + edit of the svn dump + reload | 20:29 |
mwhudson | jelmer: if i manage to do an import over svn+ssh:// or even file:/// will updating it over http: work? | 20:30 |
jelmer | mwhudson, I think so | 20:30 |
vila | mwhudson: hi (still syncing my clock so unsure if *your* was minutes or hours ago :-) | 20:32 |
mwhudson | vila: minutes :) | 20:32 |
mwhudson | vila: you landed a change to bzr.1.13 wrt unicode symlinks | 20:32 |
mwhudson | vila: it doesn't seem to be in bzr.dev | 20:32 |
mwhudson | vila: any deep reason for that? | 20:32 |
jelmer | mwhudson, alternatively, you could add a hack to bzr-svn to assume an empty set of properties if it can't retrieve them | 20:34 |
mwhudson | jelmer: hm, that sounds interesting | 20:35 |
jelmer | mwhudson, there should only be one place where it's called | 20:35 |
vila | mwhudson: check again, it should have been merged back | 20:36 |
jelmer | mwhudson, I'd rather not have it in mainline bzr-svn though, since the error that is raised is a generic "RA request failed" | 20:36 |
mwhudson | vila: oh right. r4124 | 20:37 |
jelmer | LarstiQ, perhaps in changelog | 20:46 |
awilkins | Have we gone gpl2 ? | 20:48 |
LarstiQ | awilkins: bzr-svn | 20:48 |
LarstiQ | jelmer: I'm mimicing debian unstable now | 20:48 |
jelmer | awilkins, GPLv2 or later specifically, it was GPLv3 or later | 20:52 |
awilkins | Righto | 20:53 |
jelmer | LarstiQ: Yeah, in hindsight I probably should've mentioned it | 20:58 |
ovnicraft | LarstiQ, did you check my error with trac-bzr? | 20:58 |
LarstiQ | ovnicraft: ah yes, it wasn't familiar, I then went to look if there was a bug filed for it but trailed off | 20:59 |
LarstiQ | ovnicraft: what version of trac integration are you using? | 20:59 |
ovnicraft | trac 0.11.2.1 - plugin from branch | 21:01 |
LarstiQ | ovnicraft: which version of trac bzr? | 21:02 |
ovnicraft | 0.2 | 21:02 |
LarstiQ | ovnicraft: https://bugs.launchpad.net/trac-bzr/+bug/318839 and https://bugs.launchpad.net/trac-bzr/+bug/341916 look similar | 21:03 |
ubottu | Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/318839/+text) | 21:03 |
LarstiQ | ovnicraft: oh, that latter one is by you :) | 21:03 |
* LarstiQ wonders how to track his ppa upload status | 21:06 | |
=== Jc2k_ is now known as Jc2k | ||
LarstiQ | aha! A view build records link, sneakily hiding out of view. | 21:17 |
abentley | LarstiQ: Well, I've got the physical merge done, but I haven't got it logically updated so that all the tests pass. | 21:23 |
abentley | LarstiQ: It's at http://code.aaronbentley.com/bzr/bzrrepo/nested-trees | 21:23 |
LarstiQ | abentley: thanks for the heads up btw | 21:28 |
abentley | LarstiQ: np | 21:29 |
LarstiQ | gah, even in a short time the diff ratchets up :/ | 21:35 |
EnCuKou | Hello. Does anybody know about a bzrlib transport that simulates network failures, for testing? | 21:47 |
EnCuKou | It shouldn't be too hard to write a simple one, I'd just like to reuse if one's floating around somewhere. | 21:47 |
Peng_ | EnCuKou: There might be stuff in the test suite. | 21:50 |
EnCuKou | Peng_: Thanks. I didn't find much there though. | 21:53 |
vila | EnCuKou: Hi ! | 21:57 |
vila | EnCuKou: There is no such thing as transport simulating failures, you want test servers simulating failures instead | 21:57 |
EnCuKou | vila: Hello! | 21:57 |
EnCuKou | vila: Okay, I'll look for that. | 21:58 |
vila | EnCuKou: As a starting point you can have a look at bzrlib.tests.http_utils.py I think or http_server.py | 21:59 |
loffe | Is there a way to ignore files when using "bzr upload"? (For example I don't wan't to upload my test cases but I want them in my repo) | 21:59 |
vila | loffe: not yet, but we're thinking about it | 21:59 |
EnCuKou | vila: Okay, thanks | 21:59 |
vila | loffe: filtered views may also be a way to address that, but again nothing works out of the box right now | 22:00 |
loffe | vila, "thinking" as in "has not written it yet" or "not sure if it's needed" ? | 22:00 |
vila | loffe: "thinking" as in "beuno kicked my ass enough that it will be written" :) | 22:00 |
loffe | hehe | 22:01 |
vila | EnCuKou: the closest server for what you're after may be test_http.TestWallServer | 22:01 |
loffe | Is there any "smart" way of adding my testcases now? | 22:02 |
vila | loffe: adding testscases *is* smart ;) | 22:03 |
loffe | yeah, that was my idea, but I don't want to upload them (and then delete from webserver) | 22:04 |
vila | loffe: seriously, if you want to use bzr-upload yet have test cases, write them in a different branch | 22:04 |
vila | as in separate branches | 22:04 |
EnCuKou | vila: Okay. I'll need some time to grok how it works, but I think I'll manage with your hints ^^ | 22:04 |
loffe | ok. So how do I create a "sub"-branch within my working tree? | 22:07 |
loffe | bzr: ERROR: No repository present: "file:///media/windows/Users/Eloff/Documents/src/jobb/www/timjack.se/trunk/tests/" | 22:07 |
loffe | when doing "bzr init tests/" | 22:08 |
vila | EnCuKou: you may also want to have a look at lp:~vila/bzr/local-test-server, search for and install pyftpdlib (code.google.com/p/pyftpdlib/ ) and start a test server with failure from there | 22:09 |
vila | loffe: better create your branch *outside* of the initial one for now, later on, there will be better ways to manage that setup, but for now, that's the best I can think of | 22:10 |
vila | loffe: I understand it sub optimal as you will need to commit in both though.... | 22:11 |
EnCuKou | vila: OK | 22:12 |
loffe | vila, yea, how long till upload ignore is working? weeks, months? | 22:12 |
vila | loffe: not years :-) But patches welcome ! | 22:15 |
loffe | vila, Maybe I'll look into it. Have just fallen in love with python :) | 22:16 |
vila | loffe: The main blocking point is the lack of a good and easy to modify ftp test server, and that will be available RSN | 22:17 |
cyberix | I received a patch that was created with bzr send, but for some reason that persons commit did not appear in my bzr log | 22:27 |
cyberix | Only my own commit, which I did after merging the patch in, is shown on the log | 22:28 |
james_w | cyberix: how did you merge the patch? | 22:36 |
bob2 | lifeless: still upgrading to --development after 20 hours - should I ctrl-c and file a bug w/backtrace? | 22:36 |
cyberix | bzr merge ../foo.patch | 22:36 |
james_w | cyberix: that should work, does "bzr --no-aliases log" show it? | 22:37 |
bob2 | did you commit right after merging? | 22:37 |
cyberix | james_w: no | 22:38 |
cyberix | bob2: yes | 22:38 |
james_w | odd | 22:40 |
cyberix | http://www.cs.helsinki.fi/u/froblom/Kunquat/kunquat-photos.patch | 22:41 |
cyberix | This is the patch | 22:41 |
cyberix | It is huge | 22:41 |
cyberix | It cointains a few jpgs | 22:41 |
cyberix | Is there something wrong with it? | 22:44 |
cyberix | You could try merging it yourself | 22:44 |
cyberix | how this actually work | 22:45 |
cyberix | she did her send against the lp trunk branch | 22:46 |
cyberix | should I still be able to merge it in? | 22:46 |
cyberix | to my own branch | 22:46 |
cyberix | or can it only be merged to lp trunk? | 22:46 |
cyberix | i.e. Is it at all possible to send a patch to someone, without having access to his branch? | 22:50 |
cyberix | or | 22:52 |
cyberix | Should anyone be able to apply that patch after doing "bzr branch lp:kunquat"? | 22:52 |
lifeless | bob2: is strace showing activity? | 22:58 |
AirBender | Hello | 23:00 |
bob2 | lifeless: yes, and it's eating 95% of a cpu | 23:01 |
AirBender | I'm looking for a simple way of tracking the current version of my source code inside my code, and also with autotools, in order to show the current version automatically | 23:01 |
AirBender | may be a header file generated by bzr like config.h of autotools? | 23:02 |
Peng_ | AirBender: bzr help version-info | 23:06 |
lifeless | bob2: hit ctrl-\ and get a backtrace :) | 23:08 |
bob2 | lol debuggerry | 23:09 |
SamB | Peng: but doesn't that vary branch-to-branch? | 23:09 |
bob2 | SamB: isn't that the point? | 23:09 |
bob2 | (you want the revid not the revno) | 23:10 |
SamB | ah | 23:10 |
AirBender | thanks Peng_ that's what i'm looking for, but still don't know how to integrate it with my configure.ac file in order to keep the version at make dist time | 23:14 |
AirBender | but I think this is more likely an autotools question | 23:15 |
lifeless | spiv: I've audited bzr.dev for missing patches | 23:25 |
igc | morning | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!