jeremywI have a revision id for a file that was merged into the branch.  I try to get the revno of that revision id and I'm told there is no such revision.  How can you get the revno without looping through all revisions and checking the inventory?00:20
mmclarkgot a question about pushing a shared repo to a server00:32
mmclarkif i setup a shared repo locally: (e.g. bzr init-repo website ; bzr init website/trunk)00:33
maxbpoolie: ping?00:34
mmclark... hack on the trunk, and then am ready to push the trunk to a server so others can access it, according to the docs I can do something like....00:34
mmclarkbzr push --create-prefix bzr+ssh://host/path/to/repos/website/trunk00:35
mmclarkto create the branch on the remote server.  so far so good...00:35
mmclarkwhat I don't get is that locally, in the top-level repo, there's a .bzr folder where (if I understand correctly), files will be shared amongst branches00:36
mmclarkthere's no similar .bzr folder on the server, so it appears there's no sharing.00:37
dashmmclark: the repo is for sharing _revisions_ between multiple branches00:37
mmclarkis that correct?  is the approach above the best way to go?00:37
dashmmclark: you have to do init-repo on the server side to get the same thing there.00:37
mmclarkok, so if i start by doing a bzr init-repo bzr+ssh://host/path/to/repos/website ...00:38
dashhaven't tried that, but it might work :)00:38
mmclarkand then push the branch as I did, then we've got the same scenario both locally and remotely00:38
mmclarkok - i'll give that a try.  thanks00:39
pooliehi maxb00:59
maxbpoolie: hi01:03
maxbYou mentioned that pitti said 2.2.1 needed to be a SRU - I was wondering if you had a link to that, as I got a verdict that a post-RC release pocket upload was still reasonable, said about 24 hours ago01:03
maxbeither way, I've subscribed ~ubuntu-release and requested an official verdict01:04
pooliemaxb, he said that in #ubuntu-devel about 16h ago01:04
pooliei think it will be in the irclogs.ubuntu.com scrollback01:04
poolieif we can do better that's brilliant01:05
maxbI think we're hearing a slightly different position from different ~ubuntu-release members, so I guess we'll see what they say in response to me subscribing them to the bug01:07
pooliefrom my experience you'll have to actually poll them not just subscribe them01:08
maxbMeanwhile, I think we should try to get some bzr selftest analysis of 2.2.0-1 vs. 2.2.1-0~bazaar1~maverick1 in the bug, in the spirit of the MicroReleaseException01:08
poolieit could be good to check the failures are a subset01:10
pooliemaxb i'll try to do that soon01:23
jeremywAnyone have a minute to help me out with the bzrlib API?  I'm completley stumped.01:44
* maxb is no expert, but perhaps...01:45
pooliejeremyw: sure, just ask01:45
jeremywI have a revision_id and when I try to get its revno, I'm told there is no such revision.  I guess that revision_id corresponds to another repository.01:46
jeremywIs there any way to get the revno without iterating over the whole history and seraching each revision's inventory?01:46
jeremywI asked this earlier but got no response.  Pardon the asking to ask thing...didn't want to waste my time again.01:46
maxbWhat API? Branch.revision_id_to_dotted_revno ?01:47
jeremywI got the revision_id using b.repository.get_inventory(youngest_revision)[file_id].revision01:47
jeremywAnd I later use b.revision_id_to_revno()01:48
jeremywb is a branch.Branch01:48
maxbrevision_id_to_revno only consults the mainline01:49
maxbUse revision_id_to_dotted_revno01:49
jeremywThat helps.  :)  The numbers don't match what 'bzr log' would output but I'm sure I can figure out why.01:51
jeremywHow easy was that...ugh.01:51
maxbuh, they don't match?!01:51
jeremywWell, basically I'm trying to find the last revision (local) a file was modified.  If I use log.find_touching_revisions(), I get some revisions that I'm comparing this other work to.01:52
jeremywMaybe find_touching_revisions() isn't right?  I'll consult the log.01:52
jeremywOkay...so 'bzr log setup.py' shows 425 as the last modified version while the revision_id_to_dotted_revno returns 424.01:53
james_wrevision_id_to_dotted_revno returns a tuple doesn't it?01:55
jeremywMaybe my approach is wrong.  What I've done is I use branch.list_files(recursive=False) to get the file_id.  I then use the file_id to get a revision_id it was last modified.  I then am using this API you told me about.01:55
james_wthat's certainly the approach that I would use01:56
jeremywIt returns a tuple...going to see what the pieces mean...maybe there is something I can do to get the exact same number that 'bzr log -l1 PATH' gives me.01:57
fullermdThe tuple woudl be the components of the [dotted] revno.01:58
fullermdSo it's 424.something.something; you see it listed on log in 425 because that's the rev that merged those changes.01:59
jeremywIf I use log.find_touching_revisions(file_id) and I get the last entry, I get a number that matches the same output as 'bzr log -l1 PATH'.01:59
* jeremyw reads01:59
jeremywfullermd: So how might I get 425 instead of 424?01:59
fullermdWell, 425 is sorta a lie.  Depending on semantics.02:00
jeremywBut I don't understand the semantics enough to figure out if my code/approach is borked or I've got it right and the CLI is giving you the lie.02:00
fullermd425 just copied in the changes from 424.whatever.whatever.  Collapsed log shows it because otherwise it couldn't show anything, which is flat wrong.  Expanded log shows it because it's too confusing to have a right-side path without showing where it walked off the left side.02:01
fullermdDefining changes is a little tricky with branched history.  In this case, 425 has different contents in that file from 424, so in one sense, it changed.  But it's the same contents as 424.whatever.whatever, which is ALSO a parent of 425.  So in another sense, it didn't change.02:02
fullermdWhat bzrlib is telling you is that 424.something.something is the rev where that was actually changed.02:02
fullermdlog actually does a fair amount of work beyond that to try and make pretty-understandable output on top of the low-level facts.02:03
jeremywSo let's pretend you had a repository browser and I showed you 424 but the cli showed you 425.  You'd be confused right?02:04
jeremywAny thought on how I might be able to remedy this?02:04
fullermd424 isn't the answer.  The answer is 424.something.something.  It's a dotted revno, not on the mainline.02:05
fullermdI believe you just glue the tuple bits together to get the full thing.02:05
jeremywOkay.  I see what you mean.  But if I wanted to only track mainline, how could I get 425 without doing it the same way log does, which is really expensive?02:06
jeremywI want to lie.  ;)02:06
fullermdWell, I'd suspect if there were a cheaper way to lie, we wouldn't have made log expensive for no reason   :)02:06
jeremywI guess not.02:06
fullermdAt a high level, you'd need to take that rev you found, and walk forward until you first hit the left path.  That's probably not going to be especially cheap.02:07
mkanatI think that it's possible to do some things more cheaply if you only care about mainline.02:08
jeremywHere's what I'm talking about: http://dpaste.com/250788/02:08
mwhudsonif you build the merge sorted revision graph it's easy enough02:08
mkanatjeremyw: Yeah, you might just want to try using bzr-history-db?02:08
mkanatIf it works outside of loggerhead, that is.02:08
mwhudsonjeremyw: 3.5 s seems awfully slow, are you read locking the branch?02:09
mwhudsonand it's a 2a format branch?02:09
jeremywNow you see why I'm trying to do this quicker.02:10
fullermdI presume that's 3.5 seconds to do log __init.py ; log docs ; log loggerhead ; [...].  That doesn't sound all that slow to me.02:10
james_wthere might be a Graph call to get first merged point of A in to B, which is what you want here02:10
mkanatmwhudson: I've seen that sort of operation take 3.5s before, many times. Although usually on heavily-loaded systems when working with a large history.02:11
jeremywThis is the loggerhead sources...only 428 revisions.02:11
jeremywNot really a large history.02:11
jeremywI mean, I'm reporting against the loggerhead sources, the root of the branch only.02:12
mkanatjeremyw: The loggerhead sources are deceptive.02:12
mkanatjeremyw: They have lots of large merges.02:12
mkanatSo the mainline history is short, yeah, but the full history is pretty complex.02:13
jeremywI guess I could save some time by only using the find_touching_revisions() for revision_id that aren't on the mainline.  In the case here, it's roughly 60% of the files listed so maybe I could shave off 1.5 seconds from the 3.5 seconds.02:15
jeremywNot a huge gain but, well, if it's the only way to do it...02:15
fullermdWell, the most expensive part is probably building the graph.  And once you do that once (in a single process), reusing it should be pretty cheap.02:16
jeremywI can test this by running the same thing twice?02:16
jeremywThat wasn't really a question.02:17
jeremywShaved off .11s.02:17
jeremywWell, sounds like I'm stuck for now.  Using the log, I get cli/mainline accurate results but suffer a performance hit.  I can dig that since it works and wouldn't prompt confusion.02:19
jeremywOne of the biggest hits for log.find_touching_revisions() is that it starts from oldest to newest to create the graph and since I want the last changed revision, I'd need to go backwards.02:21
jeremywI'll try that and see if I can speed things up.02:21
pooliejeremyw: i thought there was a way to go backwards?02:27
pooliei'm pretty sure log from newest to oldest doesn't buffer the whole thing02:27
mkanatjeremyw: I think you want bzr-history-db.02:27
mkanatjeremyw: Its purpose is to speed up that operation, IIRC.02:27
mkanatjeremyw: It's jam1's baby.02:28
pooliemaxb, there is bug 651706, does that sound familiar to you?02:47
ubot5`Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/65170602:47
jeremywYou guys are going to laugh...writing my own version of find_touching_revisions() that goes backwards, does it in .79s instead of 3.5s and returns the same results.  :)02:54
jeremywmkanat | fullermd | mwhudson: ^^^02:56
jeremywPretty fricking slick.02:56
jeremywI see that the loggerhead directory entry is missing...I bet I can fix that.  Other than that, it's identical and much faster.02:56
mkanatjeremyw: Sounds like find_touching_revisions itself should be fixed?02:57
mwhudsonthat seems more like it02:57
jeremywWell, my approach doesn't care about creating a log output for each revision where it's logged, only the last.02:57
jeremywSo I don't think find_touching_revisions is the problem.02:57
mkanatjeremyw: In that case, isn't there a better way to do it already, iter_...something?02:58
jeremywTo do it backwards or to get the last without the rest?02:58
jeremywI wonder why loggerhead is missing from the output in the third list...02:59
jeremywIt was my fault...bad range usage.03:02
jeremywMy last paste: http://dpaste.com/250802/03:07
jeremywThat shows the final results.03:07
jeremywThat isn't fricking bad if you ask me.  :)03:09
mkanatjeremyw: Nice.03:11
jam1jeremyw: just to mention, find_touching_revisions looks to be a pretty terrible function in general, it grabs the full inventory of every revision in the mainline... going in reverse is an option, but it isn't exactly a great option, anyway yes, for your use case going in 'reverse' makes sense, but just loading "revision_history()" is pretty expensive (think emacs)03:13
jam1jeremyw: note that "find_touching_revisions" isn't actually used by log, there is only one user, a hidden command "cmd_touching_revisions"03:14
jam1definitely not what I would pick as my starting material03:14
jam1as reference, try doing the same thing for bzr's source tree03:16
jam1jeremyw: one option is to use "for rev_id in repo.iter_reverse_revision_history(branch.last_revision()):03:18
jam1possibly batch them, and then call deltas = repo.get_deltas_for_revisions(revison_ids, file_ids)03:19
peitschiehi everyone03:33
peitschieis there anyone here that might have a shoulder for crying on?03:34
fullermdWill there be cake?  'cuz I'll take a lot of crying for good cake.03:34
peitschiedepends on whether i can get it out of bzr lol03:35
peitschieso not likely :(03:35
fullermd...   OK, I'll take crying for bad cake too.  I'm not particular.03:35
peitschie$: make cake03:36
peitschiemake: *** No rule to make target `cake'.  Stop.03:36
peitschiei dont have the source03:36
jeremywjam1: I'll look into that.  Would repo.iter_reverse_revision_history(branch.last_revision()) be any lighter than just doing what find_touching_revisions() in reverse would do?03:37
fullermdThat sounds like a bug in make.  Something that important should be built-in.03:37
peitschiei agree... i need to go raise a report i reckon03:37
jeremywjam1: I'll probably spend some time with cmd_log.run() to make sure I'm not doing things completely wrong using any version of find_touching_revisions().03:37
mkanatjeremyw: I think that's the method I was thinking of.03:38
jam1jeremyw: there are a few things03:38
jeremywjam1: If you know of any way to find the last revision a file was changed that is what you'd use, let me know.03:38
jam11) just doing it in reverse is a good start for you03:38
jam12) switching to iter_reverse_revision_history() will help *a lot* for large histories like emacs03:38
jam1(think 100k mainline revs, vs 400)03:38
jeremywThat's the end result here...based on a path, and potentially a revision, find out when it was last changed.03:39
jam13) Switching the api to do multiple file-ids at once will be a big win for your use case03:39
jam1since otherwise you iterate the same history multiple times03:39
jam14) If you just want the last modified revision tree.inventory[file_id].revision is that value, but it is the 'actually changed' value, not the last revision which merged the last change03:39
jam15) lp:bzr-history-db makes it fast to find the mainline revision that merged a given revision by writing out some cached info into a sqlite database03:40
jam1(as in, low ms not seconds)03:40
jam1I don't remember if I have that specific function encoded, but it would be pretty cheap in the datastructure03:41
jam1jeremyw: The loggerhead trunk branch has incorporated bzr-history-db into the main process now03:41
jeremywjam1: Cool.03:42
jeremywjam1: That's the next enhancement I was goign to make to my version of find_touching_revisions_in_reverse, to handle multiple file_ids at once.03:43
jeremywWhat I'll probably do to finish this learning process is to enhance my version to do multiple file_ids at once and another version doing the iter_reverse_...03:44
jam1jeremyw: so if it was me, and I was really concerned about performance, I would grab bzr-history-db, use for file_id in file_ids: revision_id = inv[file_id].revision03:45
jam1and then look up the mainline revs for all of those in one go03:45
jbowtiepeitschie: You don't have the source, because the cake is a lie.03:45
jam1def get_mainline_where_merged(self, revision_ids):03:45
jam1in history_db.py03:45
jeremywjam1: Pretend that isn't an option right now, bzr-history-db.  I'm trying to learn and add a feature at the same time.  I'd deal with a little loss of performance at this state for a solid understanding by doing it myself.03:46
jam1jbowtie: the cake being a lie is the lie. If you play through the whole thing, there is a cake in the closing scene03:46
jbowtiefullermd: I'm sure you meant to say "baked in"03:46
jbowtiejam1: Yes, a plastic cake. It's a double-bluff.03:47
jbowtieOn topic, I'm wondering how bzr-history-db interacts with foreign branches.03:48
jam1jbowtie: its a cache, it will read the whole history one time, and then incremental in the future03:48
jam1but some like bzr-git don't really like incremental for some things. Mostly require you to convert first03:49
jeremywDamn...all attemps are horribly slow on larger repositories, like bzr itself.03:49
jeremywdotted_revno was the fastest.  Too bad there isn't some quick way to get from dotted to merged when there are changes off mainline.03:50
jeremywMaybe that's where bzr-history-db comes in.03:50
jam1jeremyw: bzr-history-db03:50
jbowtieI'm just wondering if I could use it to speed up some of the bzr-tfs operations, particularly those that require mapping back and forth between repositories.03:50
jam1Basically, bzr stores a map from child => parent, and you need parent => children03:50
jam1so you need a new index03:50
jeremywTrust me, I'm hearing what you're saying.  I just wish I understood enough to avoid it.03:51
jam1jeremyw: the problem is the only way to invert child => parent is to walk all revisions, which is expensive03:51
jam1there are some bits you can make cheaper, but a lot of things are "it may also be a child but you just don't know it yet"03:52
jam1jeremyw: I'd be happy to chat with you to increase your knowledge :)03:52
fullermdOh, it's easy; first you stick the history in a relational database...03:52
jeremywAre there any shortcuts that could be made if it was a hosted, no real changes being made to the branch itself, repository?03:52
jam1if you were to say do "branch.repository.revisions.get_known_graph_ancestry([(branch.last_revision,)])" you'd end up with a Graph object that can be traversed bidirectionally very quickly03:53
jam1with the pain that it has to always load the whole ancestry03:53
jam1fullermd: oh wait, that's already been done :)03:53
thumperjam1: sorry for not calling before03:53
jam1thumper: np03:54
thumperjam1: got dragged out to get a new vacuum cleaner03:54
thumperI have a problem with some stacked branches03:54
fullermdThat sucks   :p03:54
thumperwhere one branch is stacked on another but they share no history03:54
thumperparticularly when I go reconfigure --unstacked03:55
thumperah poo03:57
thumperit is worse03:57
thumperlp:ubuntu/language-pack-gnome-yo is stacked on lp:ubuntu/lucid/language-pack-gnome-tg03:58
thumperrev 1 of lp:ubuntu/language-pack-gnome-yo is dated after rev 203:58
thumperand rev 2 is a merge of  lp:ubuntu/lucid/language-pack-gnome-tg03:58
thumpertrying to reconfigure lp:ubuntu/language-pack-gnome-yo unstacked fails03:59
thumperpoolie: any idea ^^?04:00
thumperhttp://pastebin.ubuntu.com/502991/ is the error04:00
peitschiehi everyone... I am wondering if anyone could give me a hand trying to get out debug data for: https://bugs.launchpad.net/bzr/+bug/48560104:03
ubot5`Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete]04:03
smoseranyone know what the issue is here:04:09
smoser$ bzr branch lp:ubuntu/maverick/ssh04:09
smoserbzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <DistroSeries u\'maverick\'> cannot have linked branches.">')04:09
thumpersmoser: yes04:18
thumpersmoser: poor error message mostly04:19
thumpersmoser: ssh isn't a package name04:20
thumpersmoser: try openssh04:20
smoserluser error04:21
smosersorry. thanks.04:21
=== jamesh_ is now known as jamesh
pooliethumper: hi there04:47
thumperhi poolie04:47
pooliethumper: not immediately obvious to me04:48
=== jam1 is now known as jam
=== Ursinha-bbl is now known as Ursinha-afk
jeremywAnyone having issues with the bzr branch on launchpad?  I get to 14440k and it stops, every time.06:16
sladenprobably being stupid, but what's the equivalent to  git am?  (There are lots of ways to /export/ patches as emails, but no obvious way I can see to import them with dates/headers automatically)06:42
jeremywIs there a way to use the bzr source tree as a bzr installation without installing?06:50
jeremywMy first thought was to symlink bzrlib into site-packages like I do with mercurial.06:51
jelmerjeremyw: that should work06:51
dashjeremyw: if you're going to do that, why not do the regular install step?06:51
jelmersladen: "bzr send" can generate bundles that you can "bzr pull" or "bzr merge" like a branch.06:52
jeremywdash: Well, I'm trying to just use the bleeding edge so that when my app is done, I can just say that I support the newest version instead of having to stay up to date.06:52
jeremywjelmer: I was running into trouble with it previously...I'll try again.06:52
jelmerjeremyw: what sort of trouble?06:53
jeremywFailing to load compiled libs that would halt branching lp:bzr.06:53
jeremywHard stop every time at the same point.06:54
jelmerjeremyw: none of the compiled modules are required to run bzr06:56
jeremywI know but until I did a real install "./setup.py install --home PATH", it would stop at the same place everytime.06:57
jeremywI can't explain it but I've been troubled by it for 3 hours.  Only when I tried the full install on a whim did things work.06:57
jeremywBut that was after my machine crashed the first time because of it, losing about 3-4 hours of work.  :-/06:57
jeremywMy fault, I know...06:57
jeremywI lost my work on making find_touching_revisions() 77% faster.  Eff me.07:14
jeremywThat was bad math on my part.  It's 3x faster.07:16
sladenjelmer: thanks.  The "bundles" were coming from git, after git-bzr bzr-git, fast-export/fast-import all failed07:26
sladenjelmer: however, 'git format-patches -k' was working07:26
jelmersladen: hmm - I'd be interested in hearing why bzr-git didn't work07:28
vilahi all !07:34
jelmer'morning Vincent!07:34
vilajelmer: welcome back in civilized TZ ;-)07:35
jelmervila: I don't think there is anything civilized about waking up at 7AM ;-)07:37
* jelmer is still slightly jetlagged07:37
pooliehi there vila, jelmer07:50
vilapoolie: one word: http://pypi.python.org/pypi/bzr :)07:50
mtaylorhey all...08:00
mtaylor$ bzr push --remember lp:~haildb-core/ubuntu/maverick/haildb/trunk08:00
mtaylorThis transport does not update the working tree of: bzr+ssh://bazaar.launchpad.net/~haildb-core/ubuntu/maverick/haildb/trunk/. See 'bzr help working-trees' for more information.08:00
mtaylorum - I know that - why is it carping about that?08:01
vilapoolie: can you reproduce bug #651706 or is it sporadic ?08:05
ubot5`Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,Confirmed] https://launchpad.net/bugs/65170608:05
pooliemtaylor: good question08:05
pooliei wonder if it thinks that branch has a working tree for some reason08:05
poolievila, i don't know yet, i've only tried once, will try again soon08:05
mtaylorpoolie: yeah - it's weird. it doesn't recur, but I had it on one push yesterday too08:06
vilamtaylor, poolie : Isn't it something that occur when a .bzr dir is left on the server in some corrupted state ?08:07
vilalike while a push is interrupted or aborted ?08:07
mtaylorvila: ah - that would make sense - I did interrupt a push earlier08:08
vilamtaylor: IIRC the next push won't complain, but come back if they do08:08
mtaylorvila: they don't. just wanted to report in case that was something you guys didn't know about08:09
vilamtaylor: thanks for that !08:09
vilamtaylor: really appreciated08:10
poolievila, do you think this issue with svn should block 2.2.1 into maverick?08:10
vilapoolie: the one involving people with 2.2.1 and 2.1.1 ?08:11
maxbHave we figured out why 2.2.0 is behaving differently to 2.2.1?08:12
vilaSince the bug has been fixed in 2.1.3... there is little we can do if people don't upgrade, so the question is what upgrade paths they can use.08:12
vilapoolie: so my answer to your initial question is: no, this shouldn't block 2.2.1 for maverick08:13
peitschiepoolie: i'm originator of the 2.2.0 => 2.2.1 svn email warning today if thats what you're discussing :)08:14
vilapeitschie: excellent !08:14
vilapeitschie: so, about 2.1.1, what OS is this ?08:15
peitschievila: we're running windows boxes with clients at 2.1.1, 2.1.2 & 2.2.0... with a smart server (bzr+ssh) at 2.1.108:15
peitschievila: oh.. the server is debian lenny08:16
peitschievila: i'm working with server guys to get that updated to something more recent... potentially bzr 2.2.0... and all the devs will be jumping onto 2.2.1 tonight08:16
vilapeitschie: I'd kindly suggest upgrading your windows boxes to the same 2.2.1...you're typing and acting faster than I type ;)08:17
peitschievila: if it's related to https://bugs.launchpad.net/bzr/+bug/485601 or https://bugs.launchpad.net/bzr/+bug/522637  like we suspect, in "theory", reconciling the shared repo and getting all the devs to start clean again should fix it08:17
ubot5`Launchpad bug 485601 in Bazaar "missing chk node(s) for id_to_entry maps (affected: 2, heat: 5)" [Medium,Incomplete]08:17
vilapeitschie: that's the idea yes08:17
vilapeitschie: I think spiv would have the definite answer here about which versions are compatible with which, but in this particular case, trying to ensure compatibility between all micro versions....08:18
vilasounds like a nightmare and a waste of time08:18
peitschievila: are there likely to be issues running 2.2.0 on the server and 2.2.1 on the clients?08:18
peitschievila: I agree... it's one of those things I should have been more attenative to at the time... unfortunateyl we are just getting people creeping into bzr at the moment.  I was being a little too cautious about changing things that hadn't yet broken :)08:19
vilaAIUI the problem was ghosts coming from bzr-svn no ?08:19
vilaso if you're now using bzr only they shouldn't come back haunting you08:20
peitschiethat'd be nice... we've had a few discussions about that, but unfortunately we have several dev tools (TeamCity, JIRA to name a few) that don't play terribly well with bzr at this point08:20
peitschiethe discussions continue, but this project is a little late already and quite entrenched so I suspect moving to pure bzr may end up impractical... I am trying though :)08:21
vilaha, so you're still using bzr-svn somewhere ?08:21
peitschiesvn is our main commit point actually :S08:22
vilain this case, I think only the clients matter anyway08:22
peitschieto stop the haunting i have a rather strange design setup here08:22
peitschiebasically, devs commit to a shared repository on a network server, and then merge these changes into svntrunk08:22
peitschieso locally most devs have ghosts all over the place08:22
vilabut if you upgrade the server, stick to our stable releases, that would avoid this kind of weird interactions08:23
peitschiebut the shared repo on the server at least has a complete view08:23
peitschievila: is the stable the 2.1.X series?08:23
vilaso 2.2.108:23
peitschieahh... awesome08:23
peitschieI'm getting the server upgraded to 2.2.0 I believe... all clients will be 2.2.X series on fear of me distributing their parts for them :P08:24
vilapoolie: I can reproduce #651706 with 2.2.*0*08:25
peitschievila: would there be a significant downside to using 2.2.0 rather than 2.2.1?08:26
vilapeitschie: well, the bug we're talking about has been fixed in 2.2.1 no ? :D08:26
peitschievila: assuming we both mean https://bugs.launchpad.net/bzr/+bug/522637 :)... it was in 2.2.008:27
ubot5`Launchpad bug 522637 in Launchpad Bazaar Integration "BzrCheckError: Cannot add revision(s) to repository: missing referenced chk root keys (affected: 16, heat: 66)" [Low,Triaged]08:27
vilaha no ! 2.2.0 already for #52263708:27
vilapeitschie: could type a little bit slower to stop making me look like a monkey ? :D08:27
vilajoke aside, also check the bzr-svn plugin version, but for windows 2.2.1 should be good too08:28
vilahmm, jelmer wasn't able to reproduce it so I think this means this was a bzr only issue08:29
poolievila, that's actually really good you can reproduce it there08:30
pooliethat was going to be my next step08:30
poolieso we can just say that on 63693008:30
peitschievila: heheh... if I type faster doesnt that make me *more* of the code monkey?08:31
vilapeitschie: :D08:31
peitschievila: so basically, 2.2.0 should have this fix, and as far as your aware, 2.2.0 in the server should be sufficient (i won't sue you if your wrong btw... just looking for a gut-feeling/opinion :) )08:32
vilapeitschie: exactly08:32
peitschievila: much awesomeness! thanks :)08:33
vilapeitschie: thanks for helping sorting this out quickly ;)08:33
peitschievila: is it worth me sending around another email with the summary of our discussion here? i.e., the difficulty was caused by inconsistent clients... therefore probably a good idea to either bulk upgrade, or tread carefully?08:34
vilapeitschie: that would be awesome08:34
vilamaxb: this may sounds strange but can a ppa be used for lenny or any debian if we provide the right packages ?08:35
jelmervila: no, this isn't possible08:36
vilajelmer: can you elaborate a bit ? A on-line explanation would be enough :)08:37
jelmervila: https://bugs.edge.launchpad.net/soyuz/+bug/18856408:38
ubot5`Launchpad bug 188564 in Soyuz "Build also packages for Debian in PPA's (affected: 38, heat: 274)" [Low,Triaged]08:38
jelmervila: it might be more useful to get newer bzr releases into the Debian backports though, as that would be the first place where debian stable users look08:40
* vila reading the bug comments08:40
vilaHa, right, build infra08:41
vilaok, so this is a WIP08:43
vilamgz: FYI, I'm going to revert from py27 on the babune's maverick slave08:47
peitschievila: oh... the bug (#522637) is fixed in the 2.2.0 series... but the 2.2.1 release... so it hasta be 2.2.1 I guess08:52
maxbvila: Well, I suggested that peitschie use the hardy packages on lenny. As I said in the email, it's a hacky kludge, but in the specific instance of the bzr package for hardy onto lenny, it seems to work08:54
maxbIt's absolutely not something to recommend as a general procedure, though08:55
vilamax, peitschie : sounds like the cheapest alternative for the server admins no08:56
maxbjelmer: Question for you - how would you feel about uploaded 2.2.1 to sid, as a feeder for backports?08:56
peitschiesounds like our only option atm really08:56
maxbvila: cheapest alternative? It's an option which peitschie can use *right* now, if that's what you mean08:56
peitschiemax: are there likely to be issues updating to the official backport when that eventually makes it out?08:57
peitschiei'm assuming no.. but it doesn't hurt to ask :)08:57
maxbpeitschie: Well, you do have other options: you could install from source, or rebuild the packaged source on debian yourself :-)08:57
maxbupgrading... let me remind myself of backports versioning scheme.....08:57
peitschiemaxb: i'm assuming that isn't going to be much prettier from the ppa...?08:57
peitschieworse comes to worse we can purge bzr and install the official one when it hits08:58
vilapeitschie: you're right and lp is wrong: http://paste.ubuntu.com/503077/08:58
peitschievila: should I update the bug report at all or just leave things?08:59
maxbpeitschie: ok, so: 1) I expect what hits backports will be an indentical source package, just rebadged with the appropriate version number, so the only difference will be the build environment, and 2) yes the version number should be greater, so apt should just do the right thing08:59
vilapeitschie: you mean marking it as fix released in 2.2.1 ? Refresh the page :)08:59
peitschievila: :O... you guys are so speedy here!09:00
peitschiemaxb: that sounds good.  thanks for checking that for me :)09:00
* vila try to type faster :)09:00
jelmermaxb: That doesn't work, backports have to be created from packages in testing and we won't be able to do a new upload that will end up in testing.09:01
jelmermaxb: see the backports FAQ09:02
vilapoolie: can't reproduce bug #651706 on maverick 8-)09:02
ubot5`Launchpad bug 651706 in Bazaar ""problem with the SSL CA cert" when running tests from installed 2.2.1 (affected: 1, heat: 6)" [High,In progress] https://launchpad.net/bugs/65170609:02
* vila tries harder09:02
poolievila, i thought you just said you could?09:02
poolieor you can't reproduce it in a source tree?09:02
vilaI can reproduce with 2.2.0 system install, I can't with 2.2.1 from sources, but both mention leaking tests...09:03
vila... which I could very easily be persuaded that they are the cause of the transient failure09:04
vilaI'll try again with the stable ppa installed09:05
maxbjelmer: There was mention of it being occasionally acceptable to backport from unstable, I was hoping we could convince people that it was a sensible thing to do09:05
jelmermaxb: afaik that only applies to things like security uploads09:06
=== spike_ is now known as spikeWRK
vilapoolie: wow, reproduced when running from the ppa version 8-/ That would make the debugging interesting...09:12
vilahmm, could that be the test ssl certs not installed correctly...09:13
pooliei suspect it's something like that09:15
pooliemaybe ownership or permissions?09:16
poolieor not shipped at all?09:16
vilashipped, permissions look correct09:16
pooliestrace time?09:19
vilagood idea09:19
pooliemaxb: still here?09:21
vilapoolie: bingo, we don't install ca.crt...09:31
vilapoolie: the fix is a one-liner in setup.py, should I target 2.0 or 2.2 ?09:34
poolie2.2, i would say09:35
pooliebut, hang on, do we really need to install a certificate?09:35
pooliethis is a made-up one just for running the tests?09:35
vilafor the test sever yes09:36
poolielet's make sure it's not installed anywhere someone could mistake it for a real one09:37
vilaWe had a fix long ago for this, I don't understand why this file wasn't spotted earlier, I guess the fix itself wasn't properly tested or... unexpectedly succeeded :)09:37
vilalook at /usr/lib/python2.5/dist-packages/bzrlib/tests/ssl_certs09:38
vilathere is a create_ssls.py there that should make it clear enough09:38
vilaand the script defines... a rather fictional locality and country code, etc09:39
vilaeven if someone pick it up I strongly doubt it will be able to certify anything dangerous09:40
vilapoolie: https://code.edge.launchpad.net/~vila/bzr/651706-test-ca-crt/+merge/3710909:55
vilago lp go, update this diff ;)09:55
bialixGaryvdM: it seems we should made release of qbzr 0.20b1 for bzr 2.3b1, shouldn't we?09:59
vilabialix: as long as you release 0.20 for 2.3.010:00
vilabialix: I don't think you strictly *need* to release it, but that will be good10:00
bialixvila: qbzr has switched to the 1 major release per 1 major bzr release10:01
bialixwe did 0.14 exclusively for 2.210:01
bialixwe did 0.18 exlusively for 2.110:01
bialixwe did 0.14 exclusively for 2.010:01
bialixwe did 0.19 exclusively for 2.210:01
bialixand 0.20 will be exclusive for 2.310:01
vilayou just *rock* :)10:01
bialixvila: this is not the first time you asking this10:02
vilablame Alzheimer :)10:02
vilabialix: who are you ?10:02
bialixman with a headache?10:03
bialixI said something bad/wrong/weird again?10:03
vilabialix: ideally qbzr, like all plugins that are shipped with stable bzr releases should also define stable series, no ?10:03
* poolie looks10:04
bialixwhat it means: should also define stable series10:04
vilabialix: exactly what you listed above :)10:04
bialixwhere I should list them?10:04
bialixwiki will be OK?10:04
vilalp:qbzr home page even10:05
bialixit makes sense10:05
bialixshould do10:05
poolievila, your patch looks good to me10:14
vilapoolie: thks, already sent to pqm ;)10:14
vilapoolie: sry, I should have said it earlier10:15
GaryvdMHi all10:21
* GaryvdM was afk, reading back10:21
* bialix waves at Gary10:22
* bialix wait a minute and waves again10:22
GaryvdMHi bialix10:22
vilaGaryvdM: \o_ _o_ _o/ \o/10:23
bialixround dance10:24
bialixdance vila dance10:24
pooliehi gary, bialix10:24
* vila pumps the volume.... oh wait, no music here ;)10:25
GaryvdMSo for 2.3b1, I included tip versions of most plugins10:25
vilapumps *up* grr10:25
GaryvdMincluding qbzr10:25
bialixhi poolie!10:25
* GaryvdM -> afk10:26
vilaGaryvdM: which is a good way to make people release official versions :) I fully agree with the idea, but will it work ?10:26
bialixGaryvdM: the last bug report about QBzrGlobalConfig said user has 0.1910:26
pooliethat's all for me, good night10:32
vilapoolie: g'night !10:33
vilapoolie: try to give the orphans some love tomorrow ;)10:35
peitschiewow... it is that time... i'm off too10:35
peitschiethanks for all ur help vila... was very much appreciated10:35
peitschiehope ur day/night/afternoon/thing goes well :)10:35
GaryvdMbialix: so the have bzr.dev/2.3b1 with qbzr 0.19 - they should just upgrade qbzr10:35
vilapeitschie: np, your clear reports were also much appreciated !10:36
GaryvdMbialix: and i think that we should mark the next releases of qbzr 0.18 and 0.19 as incompatible with bzr 2.310:38
bialixGaryvdM: fine with me10:40
GaryvdMbialix: the fix was quite a big change, so I'm in 2 minds about backporting.10:40
bialixGaryvdM: backporting what?10:41
GaryvdMbialix: the config fix10:41
bialixis it only required for 2.2?10:42
GaryvdMbialix: It is required for bzr 2.310:43
bialixyep, sorry10:43
bialixI don't mind to leve it unfixed in 0.1910:44
GaryvdMwe were using a _method which got removed10:44
bialixso that's our problem10:46
=== bialix_ is now known as bialix
vilabialix, GaryvdM: Excuse my Alzheimer but which python version is used in the 2.2 and 2.3 installers ?10:53
bialixhate it10:53
GaryvdMbialix: I'm hoping to land lp:~garyvdm/qbzr/log_refactor/ soon11:07
GaryvdMI'm dogfooding, need to fix some last bugs.11:08
GaryvdMIt's allready in the threads branch, and working well there.11:09
* GaryvdM -> lunch11:10
GlenjaminI don't suppose anyone's ever deployed the http bazaar smart server wsgi app on gunicorn and proxied through to it?15:09
* jeremyw goes back to finding the last changed revision of a file...15:52
=== Ursinha is now known as Ursinha-lunch
=== Ursinha-lunch is now known as Ursinha
awilkinsOoooh. Bazaar job.17:22
awilkinsAnyone have an idea what the payscale is :-)17:22
cody-somervilleawilkins, if its a Canonical gig, you normally negotiate your salary17:26
awilkinsWould be sweet to work on something useful though :-)17:27
tsmithHi. I have suffered a tremendous security breach due to BZR and would like to know how to prevent it in the future.17:38
rubbsmay I ask what the breach was?17:38
tsmithWell, it could be *really* bad. Fortunately, only a low-grade site was compromised.17:39
tsmithI run (among many other things) a PHP course and detected a security breach on the URL for the third session's final exam.17:40
tsmithBasically, someone bzr branch http://mywebsite/final_exam, and it worked, and they ended up with all the (supposed to be secret!) source code.17:40
tsmithSince this is basically *impossible* w/ SVN and CVS, I didn't realize BZR allowed this, and I have to know how to stop this for every one of my sites.17:40
KinnisonSo the security breach was that you published the branch on a public website?17:40
vilatsmith: lp:bzr-upload17:41
tsmithwell my deployment practices have not changed from svn to bzr, so obviously I accept responsibility.  I just want to know what is the proper way to deploy to production?17:41
KinnisonPersonally I use bzr export17:41
Kinnisonand then rsync17:41
Kinnisonbut as vila suggests, there's a bzr-upload plugin too17:42
vilaKinnison: which is what bzr-upload aims to reproduce ;)17:42
Kinnisonaah, handy-dandy17:42
* Kinnison shall add that to his list of things to think about when he has time17:42
Kinnisontsmith: another good idea is to put a .htaccess in place which denies access to .bzr17:43
vilarelying on bzr to calculate which files should be uploaded/deleted/renamed17:43
Kinnisonthat way even if you forget, it will keep you safe17:43
tsmithvilla: what is the difference between upload and export?17:43
vilatsmith: export is one-short, upload is incremental (well, it won't patch your files, it needs to upload them again)17:44
vilaone-shot :)17:44
tsmithSo export uploads *everything* but upload is more like rsync17:44
tsmithok that's exactly what i need17:44
tsmiththank you very much kind sir17:44
vilayou're very welcome17:45
KinnisonOh, tsmith, welcome to bzr.  It may confuse you at first, but you'll never want to go back in the end :-)17:45
tsmithKinnison, thanks, but I've been using it since the 0.5 days ;-)17:45
vilatsmith: wow, you beat me ! I think I started in the 0.7 days ;)17:46
awilkinstsmith, And take comfort from the fact that I've clipped that IRC log for an internal training course :-)17:46
tsmithan internal training course on how to avoid loss of source? :)17:46
awilkinsI'm talking about general VCS and specific issues migrating to DVCS17:47
tsmithawilkins, ok, cuz I had no idea this **could** happen.17:47
tsmithi use bzr+ssh:// for everything17:48
tsmithi am pretty sure i'm not the only one, too17:48
tsmithbzr: ERROR: Invalid http response for http://repo.phpexperts.pro/driving_app/.bzr/branch-format: Unable to handle http code 500: Internal Server Error17:48
vilatsmith: yup, that was one of the reasons to write bzr-upload in the first place17:48
tsmith<-- success17:48
vilageez, that was fast !17:48
=== beuno is now known as beuno-lunch
vilatsmith: 7 minutes between answer and tested deployment 8-)17:49
tsmithwell i already implemented upload on incendiary.ws17:50
tsmithbzr branch http://www.incendiary.ws/ if you want to help me QA17:50
tsmithand the site still seems to live17:50
tsmithok cheers, guys17:50
mgzvila: thanks for the heads up on babune maverick change18:34
mgzright thing as we're approaching 10-10-10, and I think I have a handle on the remaining python 2.7 issues18:34
mgz(though I need to file bugs on a few still)18:34
=== beuno-lunch is now known as beuno
exarkunWhat are my options if I have a branch with private stuff in it that I want to make public?18:40
mgzprobably the import/export thing to make a new history18:41
exarkunBy "new history" you mean a history beginning after all the current history?18:45
mgzwell, presuming the private stuff you don't want to make public was there to start with, I mean a completely recreated history with that ommitted18:46
dashexarkun: it's pretty hard to publish a branch without publishing all the revisions in it, AFAIK.18:46
mgzsee the bzr-fastimport plugin and using that to filter out certain things.18:47
exarkunmgz: I don't see how export/import would recreate the history.  It looks like it just bundles up a particular revision into an archive.18:47
mgz'export' was confusing, forget I used that word.18:47
exarkunah, ok18:47
exarkunThe other half of the question, I guess, is where people keep their private stuff.  In a separate branch that's not published?18:49
mgzdepends what you mean by private I guess, if it's code, then yeah. config stuff is often just in the tree but unversioned18:50
exarkunin this case it's python source, but it's really configuration.18:51
exarkunHm, maybe I should make someone implement X509 based authentication18:51
exarkunThen it wouldn't actually need to be private, I think18:52
mgzyeah, making it not need to be private would be the best thing, if it's practival18:57
vilamgz: exactly (about maverick). python-2.7 seems to have survived to the operation though, I don't where I got the idea that it was installed by default, in fact I had a symlink in ~/bin, so it's still possible to use python2.7 explicitly for focused tests19:28
mgzvila: do you know if Gary or Alexander are working on bug 632465 or should I fix it tonight?19:29
ubot5`Launchpad bug 632465 in Bazaar Windows Installers "bzr.exe tried to use the system msvcrt90.dll from system32, not the bundled one (affected: 2, heat: 16)" [Critical,Confirmed] https://launchpad.net/bugs/63246519:29
vilamgz: no idea, sry :-/19:29
vilamgz: but bialix mentioned a workaround right ?19:30
vilaThere is something more... but I don't remember what19:30
mtaylorhey lovely people...20:46
mtaylorValueError: We are missing inventories for revisions: [StaticTuple('jaypipes@gmail.com-20100924204917-evjhm0hc7s5t25ol',)]20:46
mtaylorI'm getting a fail when I'm trying to commit to a lightweight checkout ^^20:46
rockstarjam, mtaylor is having issues with a lightweight checkout and the remote repository, but I don't know how to help him debug.21:31
GaryvdMmtaylor: Please could you pastebin the traceback. I don't think I can help, I'd like to learn more, and having the traceback will tell me what to read.21:40
mgzargh, buildout is massive bullshit21:40
mgzGaryvdM, are you looking at the manifest thing? because I've not even got as far as getting buildout past the "download stuff" stage yet21:41
jeremywjam: I don't care what everyone else says about you.  You're a gentleman and a scholar.21:43
GaryvdMmgz: I'm not, cause I don't know where to start.21:43
mgzokay, well, I'm pretty sure I can fix it easily, but I hate build stuff and am failing to actually get to step 0: get installer built21:43
mtaylorGaryvdM: yes! .. one sec21:43
mgzbuildout is currently managing to break my bzr installation by somehow intruding it's bullshit isolation across to the subprocess21:45
GaryvdMmgz: please pastebin buildout error. I may be able to help.21:45
mgzand actually debuging anything is a pain because everything's in zips that always get redownloaded21:45
mgzthe error is trivial, gf.recipe.bzr tries to run `bzr get ...` and buildout has screwed with the environment so that it can't find bzrlib21:47
mtaylorGaryvdM: http://paste.openstack.org/show/36/21:47
mtaylorjam: ^^^21:47
mgzI could work around by sticking an installered bzr.exe on the path, but this is dumbness I want fixed21:47
GaryvdMmgz: That's the setup on the build host.21:49
GaryvdMmtaylor: Thanks.21:49
mgzright, there are probably a selection of things that happen to work with how the build host is setup but not on my machine21:49
mgzI've avoided a few already.21:49
mgzand the buildout docs suck, of course.21:51
mgzwhen is this ever not true.21:51
GaryvdMmtaylor: That is happening in autopack. I wonder if the same happens on a manual bzr pack ?21:54
mtaylorGaryvdM: can I run that?21:59
mtaylorGaryvdM: trying21:59
GaryvdMmtaylor: yes22:01
=== r0bby is now known as robbyoconnor
mtaylorGaryvdM: bzr pack seems to have fixed the tree22:08
mtaylorrockstar: ^^22:08
rockstarmtaylor, hooray!22:08
jeremywAnyone that was following my work yesterday to get the last changed revisions for a directory of files: http://paste.ubuntu.com/503509/22:10
jeremywCheck those numbers out.22:10
jeremywThanks to jam I was able to identify the approach that yielded the best results.  :)22:10
GaryvdMmtaylor:  hmm - If autopack failed, and pack passed, that's a bug in autopack then.22:11
rockstarjeremiah, nice.22:11
mtaylorGaryvdM: w00t! I'm helpful22:11
rockstarEr, jeremyw... ^^22:11
jeremywGoing from 115s to 0.8s...wow.22:11
jeremywAnd that's without bzr-history-db.  ;)22:12
GaryvdMmtaylor: I think we should try log a bug.22:13
jeremywUsing find_touching_revisions() going backwards, insted of 1...N, would produce a time ~30s.  I don't have that metric in here.22:14
mtaylorGaryvdM: agree22:15
GaryvdMmtaylor: I think it's bug 43700322:15
ubot5`Launchpad bug 437003 in Bazaar 2.0 "Failure to autopack because of 'missing inventories' (affected: 4, heat: 15)" [High,Confirmed] https://launchpad.net/bugs/43700322:15
GaryvdMjeremyw: May I ask what are you building?22:18
jeremywA rocketship powered by the heat generated by producing a rev_id to mainline_rev_id map.22:19
jeremywThis code is for a repository browser.22:19
mtaylorGaryvdM: yes. I agree with you22:19
GaryvdMjeremyw: Ah.  For web, gui, or cli?22:22
jeremywWeb UI22:23
GaryvdMjeremyw: Ah cool.22:24
GaryvdMjeremyw: KnownGraph rocks...22:26
GaryvdMso dose jam!22:26
jeremywThe KnownGraph is great but when merge_sorted(), it's a freak of nature.22:28
* jeremyw feels his bzrlib kung fu getting stronger...22:46
mgzis this really true? bzr-windows-installers requires gnu make... just to build windows html help... and there are batch scripts in the bzr tree it could be using anyway22:51
jeremywHow's the Bazaar installer for OS X?22:54
mgzthat's handled somewhere else entirely I think, you'd need to ask Gordon Tyler22:56
=== Ursinha is now known as Ursinha-afk
jeremywJust figured I'd ask while we were on the subject of installers.22:58
=== Ursinha-afk is now known as Ursinha
pooliehi all23:55
FryGuy_is there any way to do a reverse merge? currently i'm in a checkout of a branch, but I want to switch to another branch, and merge the first branch into the branch I'm going to. If I do a switch then merge it's going to complain about having to delete folders that have temporary files in it, when they're just going to be created again23:55
poolieFryGuy_: not quite23:57
thumperpoolie: hi23:57
poolieyou could delete the temporary files with clean-tree23:57
poolieor make another checkout23:57
FryGuy_ya, i was figuring that's the case23:57
thumperpoolie: I have a local example of the unstacking failure23:57
thumperpoolie: but it is about 10 meg23:57
FryGuy_i don't want to have to rebuild the source though, which is why i didn't do it that way23:57
thumperpoolie: where do you want it?23:57
FryGuy_and checkout takes like 5 minutes to get all the source :(23:58
pooliethumper: make a bug and attach a url23:58
pooliemaybe you should branch locally?23:58
FryGuy_it is local23:58
thumperpoolie: do you want the branches tarred up and put in the librarian or people.c.c23:58
FryGuy_it's like 500 megs23:58
FryGuy_and my hard drive is slow23:58
poolieit would be nice to add an option to merge in reverse order23:59
FryGuy_a merge --switch option?23:59
pooliehi jam?23:59
pooliesomething like that23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!