yebanwhat would be the bzr equivalent of 'git show'00:09
bob2bzr diff -c asdfasdf00:10
bob2for the common case00:10
yebanbob2: I want to see the state of one particular file for a revision00:13
yebani did not know about -c though, thanks :)00:13
bob2bzr cat -c asdfsd filename00:14
spivBugs like bug 745083 are why I wanted to have catch-all try/excepts around calls to hooks on plugins.00:17
ubot5Launchpad bug 745083 in Bazaar "UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'math range error') during commit" [Undecided,Incomplete] https://launchpad.net/bugs/74508300:17
yebanbob2: its bzr cat -r not -c, thanks :)00:18
spivYes, it would be a bit weird if 'bzr cat' took a revision range :)00:19
psusiI just had a stuck lock on lp.  bzr help break-lock makes it sound like it is not safe if you don't first kill the process, but I can't do that on lp.  Is it safe, or not?01:31
spivpsusi: the process that matters isn't the one on lp, but the client that took out the lock01:47
spivpsusi: so if it's a stale lock because e.g. your connection dropped out while pushing to launchpad, then it's your own lock for a (local) process that's already failed, and you can break it completely safely.01:48
spivpsusi: the lock info bzr shows you should help you see who took the lock out01:48
psusispiv, ohh... well I took it out, but on the lp server... I thought that meant that the bzr process running on the server is what was holding the lock, and it either is hung, or did not remove the lock when it died01:51
psusiit lists a pid, which I took to be a pid on the server, not a local one01:52
spivpsusi: in a sense the lock was created by the server process, but it's entirely on behalf of your local process01:56
spiv(The pid is a pid from the server)01:57
psusispiv, right, but it is the server process that creates and clears the lock, so don't I need to be sure that process is dead?01:57
psusiin fact, whether the process hung or somehow exited without clearing the lock is a bug isn't it?  even if I drop connection or ctrl-c my local bzr, the server side should clean up the lock before exiting shouldn't it?02:00
spivpsusi: the lock lifetime is controlled by the client02:04
spivpsusi: it can be legitimate for a client to lock and disconnect without unlocking02:05
spiv(although that would be very unusual)02:05
spivpsusi: the smart server protocol is stateless between requests, so the fact the connection went away doesn't imply that any locks that were taken should be dropped.02:06
psusihrm... that's weird02:16
psusiwhy is it stateless?  I would think the protocol should be transaction based02:16
spivPartly so it can be carried over HTTP smoothly.02:20
psusiwhy is http at all incompatible with a transaction based protocol?  send request, get reply is how http works... seems perfectly suited for a transaction02:23
spivAnd that's what we do.02:27
spiv"Take lock" is one of those requests.02:28
spivThe problem really is that we take multiple requests for things that in principle could be done in single requests.02:29
spivIf you're curious about the sort of requests being made, add -Dhpss to your command line and look at the extra logging that adds to ~/.bzr.log02:29
jbowtieSo, I occasionally have an issue where revisions being imported from my external(tfs) repository end up as dead heads in the repository.04:26
jbowtieI've tracked down and eliminated most of bugs in bzr-tfs that cause these.04:27
jbowtieHowever, I have a (very large) existing repository where I need to splice in a single revision where it belongs in the branch history.04:28
jbowtieI might be able to get away with merging it into the current branch, the plugin just follows the LHS currently as it only imports a single branch.04:33
jbowtieWhat's the preferred method for dealing with dead heads in a way that won't affect the LHS ancestry?04:34
lifelessignore them?04:35
jbowtieMost of the time I can get away with that, but not in this instance.04:36
jbowtieI was thinking about trying to actually insert it into the revision graph for the branch, but worried that might have evil side effects.04:37
jbowtieIf I actually corrupt the repository I'm looking at working the whole weekend to re-import the trunk. Don't want that.04:39
ScottKMake a backup copy first?04:40
jbowtieScottK: I can do that, I was just hoping someone had an informed opinion before I started doing open-heart repository surgery.  :)04:41
ScottKMy informed opinion is take a backup no matter what anyone says here about what your odds of success are.04:42
ScottKAbout the bzr part, no idea.04:42
spivI don't understand how or why "splice in a single revision where it belongs in the branch history" is related to having dead heads in your repository.04:51
spivOr why you can't just ignore the dead heads?  By definition they have no impact of the ancestry, LHS or otherwise, of a branch.04:52
spivI think I must be misunderstanding what you're asking.04:53
jbowtiespiv: so the actual revision graph is r1->r2->r3; the bug in the import process created the graph r1->r3 and r2 ends up as a dead head.04:54
jbowtiespiv: I'm in the position where I want to correct the revision graph by hand.04:55
jbowtieI could re-run the (now fixed) import process but that's a days-long affair.04:55
spivWell, all you can do there is generate a new r3', with a new revision ID, with the contents of r3 and a parent of r2.04:56
jbowtieIn other words, a merge, yes?04:57
spivNo, just a regular descendant.04:58
spivi.e. r3' would have a parent list of [r2] to match the graph you desire.04:59
spivMerges create revisions with more than one parent.04:59
* poolie is reconnected04:59
spivpoolie: hurrah!05:00
poolieonly over 3G, but usable 3G05:00
poolievodafone was atrocious05:00
jbowtieOh, I see the difference. That ends up rebuilding the whole branch after r3 as well, though. Still, it's at least viable.05:02
pooliei wonder if bzr push will be tolerable05:03
spivjbowtie: yes, it's rebasing05:03
jbowtieOh!  I never understood what rebasing was before! Now I get it!05:04
jbowtieSo maybe bzr-rewrite will solve my problem.  Thanks, this was extremely helpful.05:06
spivjbowtie: glad I could help :)05:08
pooliewow, even lp and bzr are quite usable05:08
pooliethat's a remarkable improvement05:08
poolieheh :)05:08
pooliespiv were you going to file a bug about, um06:13
poolieoh, explaining the likely hook or plugin for an error06:14
poolieand something else too?06:14
spivThe 'recent event' dict06:15
echo-area"bzr merge -r b..a branch" (a < b) may result in unresolvable conflict on changed files between revisions a and b.  Is this desired?06:33
spivecho-area: what do you mean by "unresolvable conflict"?06:40
echo-areaspiv: I tried many ways, all of them failed to resolve the conflicts.06:42
spivFrom bzr's perspective all conflicts are resolvable, in the extreme by discarding the conflicting changes entirely with e.g. "bzr revert ."06:42
spivecho-area: can you pastebin the output of the bzr merge, or of 'bzr conflicts'?06:42
echo-areaspiv: The only way to resolve is by reverting all changes, and avoiding use of bzr merge.  A moment please, I'll show you bzr conflicts06:49
echo-areaspiv: http://pastebin.com/4X4g2RSM06:51
echo-areaspiv: Problem is that, file1 was added in revision 1, and bzr merge -r 1..0 tries to delete file1.06:52
echo-areaThe conflict comes from revision 3, in which revision file1 was changed06:53
echo-areaThe only way to achieve what I want is to manually remove file1.  While in larger context this is not that handy06:54
spivecho-area: revert is not the only way to resolve that conflict06:57
echo-areaspiv: What is the other possible way?06:58
spivecho-area: it's certainly a conflict if the selected revisions attempt to modify a deleted file.06:58
spivecho-area: it's up to you what you think is the right resolution: the most common choice I think is to ignore the changes to the deleted file.06:59
echo-areaspiv: I tried that.  Paste come in a minute.06:59
spivIn which case deleting that file1.THIS file and doing 'bzr resolve file1' or maybe 'bzr resolve file1.THIS' should work.07:00
spivOr even just 'bzr resolved --all'07:00
spivThere's also 'bzr resolve --take-this' and 'bzr resolve --take-other', which you may find useful.07:00
vila<cough> 'bzr resolve --all' is evil, it just deletes all known conflicts without any attempt to resolve them, it should be used as a last resort only (think throwing sea water on nuclear plants)07:02
* vila almost there07:03
spivvila: if that's what it takes to stop a meltdown… ;)07:03
echo-areaspiv: Hm.  Delete file1 and bzr resolve file1 worked.  Why does "bzr resolve" not work in that context?07:06
spiv'bzr resolve' only detects when you've resolved text conflicts (i.e. removed the <<<<<<< etc markers from a file)07:07
spivI think it'd probably be good to make it detect when contents conflicts like yours are resolved too.  File a bug :)07:08
vilaecho-area: 'bzr resolve' doesn't *yet* work in this context, as spiv said, only text conflicts are automatically resolved07:08
spivFWIW, "bzr help resolve" does explicitly say to use 'bzr resolve FILE' for contents conflicts, but I agree it's not very intuitive.07:08
vilaecho-area: 'bzr help conflict-types' gives a summary of what is supported so far07:09
echo-areaOkay.  I was unaware of various conflict types until now.07:12
spivYes, the distinction between "contents conflict" and "text conflict" is something you're unlikely to grok just by seeing the words in your terminal occasionally.07:13
vilaecho-area: yeah, that's a bug, the conflicts should be better explained and these explanations should be easier to discover07:13
echo-areaspiv: But the bzr I'm using (2.3.1) does not explicit refer "content conflict" in bzr help resolve07:13
vilaecho-area: 'bzr help conflict-types' does07:14
spivMaybe "contents conflict" should be called "existential conflict" ;)07:14
spivecho-area: ah right, yes, in trunk too07:14
vila'content' is this context refers to an internal pov and is misleading for users07:14
spivecho-area: my mistake, although you could argue it implicitly suggests that.07:14
echo-areavila: Reading that.  I was replying to spiv's message07:14
vilaecho-area: sure, no worries07:15
echo-areaMaybe we can make an explicit note on this in the user guide.  I'll try to make a patch later07:16
vilaecho-area: highly welcome !07:16
spivecho-area: that'd be wonderful, thank you07:17
vilaecho-area: see also http://wiki.bazaar.canonical.com/VincentLadeuil/ConflictResolution for what is cooking in this area07:17
vilahmm, yeah, re-reading that, 'content conflict' may be better understood if it was named 'tree shape conflict'07:20
vilathat is, the merged trees disagree about an object kind: deleted, file, dir, symlink07:22
spivvila: or "file kind conflict"?07:23
spivvila: that's a bit less jargony07:23
spivvila: or, hmm07:27
spivvila: file/dir/symlink, that's "kind conflict", but deleted vs. modified is "status conflict"?07:27
spivvila: I think that's pretty consistent both with our internal terminology and the terms we expose to users at other times.07:28
vilavalentine : under his shower, will coming soon :)07:30
vilaspiv: well, IMHO, what is consistent is that most of our users are saying: 'wtf is a content conflict' :-)07:36
vilabut yeah, separating kind conflict and status conflict seems like a good idea07:37
spivvila: hehe07:37
spivvila: ok, I'll file a bug07:38
vilathe main issue is in the implementation which is hard to modify (see url above for some explanations)07:38
spivvila: filed https://bugs.launchpad.net/bzr/+bug/745491, please elaborate or disagree as you see fit :)07:45
ubot5Ubuntu bug 745491 in Bazaar "“Contents conflict” is unclear to users, replace with “kind conflict” and “status conflict”" [High,Confirmed]07:45
spivecho-area: you may be interested in that proposal too (bug 745491), I'd be interested to hear if you think it would have helped you07:46
ubot5Launchpad bug 745491 in Bazaar "“Contents conflict” is unclear to users, replace with “kind conflict” and “status conflict”" [High,Confirmed] https://launchpad.net/bugs/74549107:46
spivubot5: yes yes we know07:46
echo-areaspiv: Okay, I'll follow that.07:46
* jelmer waves07:47
vilaspiv: done07:49
vilajelmer: \o/ feeling better ?07:49
jelmervila: yup, thanks07:50
jelmervila: do you know if we're mumbling this morning?07:51
vilajelmer: no, but given that poolie uses a 3G connection, I doubt he can mumble07:51
jelmerah, good point07:51
spivjelmer, vila: yes07:52
spivjelmer, vila: but skype, and we call poolie on pots07:52
* spiv -> afk07:52
* vila has no skype setup :-/07:53
* jelmer dusts off his skype setup07:57
* vila finally remembered his skype login08:02
* jelmer waves to poolie08:37
jelmervila: for when do you have b2 planned?08:39
vilajelmer: I keep the release dates up to date on lp, so: 2011-04-28 from https://launchpad.net/bzr/2.408:40
vilawell, I *try* to keep them up-to-date ;)08:41
vilajelmer, maxb : the ppa:bzr/beta needs love ;)08:41
vilaoh wait, I already said that in the topic ;-D08:41
jelmervila: thanks08:46
maxbI was actually just contemplating my notional compatibility layer for painless dh_python2 rebuilds for older series08:46
maxbI think I've got an idea which should work:08:47
maxbRebuild python-defaults with 2.6.6-3really2.6.4-0ubuntu1 etc. versions, whilst adding a Depends: python-backport-helper08:48
maxbCreate a new package python-backport-helper which Depends: python-support, python-central, and installs a fake dh_python208:48
maxbEmbed a table in the p-b-h package which maps sourcepackagenames to pysupport or pycentral following what they currently do, to avoid unnecessary transitions08:49
maxbI think I'll have a go at implementing what I just said at lunch today08:49
jo-erlendI have a project directory like /home/jo-erlend/devel/Projectname where my sourcecode resides. This thing about branches, how does that work? Should I move my files into a subdirectory like ~/devel/Project/trunk and work on the code from there and push to ~/devel/Project/1.0 when I reach the first major version, for instance?09:41
jo-erlendas you can understand, I'm quite the beginner with this VCS thing. :)09:42
maxbjo-erlend: In Bazaar, branches are modelled as separate directories on disk. So, yes, a .../trunk directory is a very reasonable thing to have if you expect to have multiple project branches side by side. However, marking versions seldom merits a whole new branch - there is a separate concept of tags for that.09:48
maxbYou can always branch from a tag later, if there is a need to create a maintenance branch for a released version09:49
jo-erlendoh, ok. Then a tag is just a way to emphasize a commit?09:50
mr-russ1tags have a danger on bzr at the moment, you can't push them if you delete them.09:53
=== mr-russ1 is now known as mr-russ
jo-erlendI didn't really understand that.09:54
mr-russjo-erlend: I would setup a shared-repository in ~/devel/Projectname and create a branch called trunk under that.09:54
mr-russjo-erlend: are you going to have a central storage location for your code, or just work from your home directory?09:54
jo-erlendit's just me for now, but I'd like to be able to invite others later, if they're interested.09:55
mr-russI just added the following to bzr 2.4 docs.  http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html?highlight=ssh%20restrict#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories09:56
mr-russthat's how I have a setup others can use.09:57
mr-russbut to start with a single branch setup.09:57
mr-russin your code folder, bzr init09:57
mr-russbzr add09:57
mr-russbzr commit09:57
mr-russ.. code away ...09:57
mr-russbzr commit09:57
mr-russand you are using the revision control.09:57
pooliehi mr-russ09:58
mr-russhi poolie.09:59
mr-russsemi disturbingly, I'm starting to feel part of the family.09:59
mr-russjust to work out how and if I could work for canonical...  Not programming python though.  I know zero python.10:00
jo-erlendmr-russ: hmm. I'm reading a "mini-tutorial" on doc.bazaar.c-c and it sais something about a "saved parent location". Where is that set?10:00
jo-erlendperhaps that's just the location I branched from?10:03
mr-russyou don't need a parent, or saved parent.10:14
mr-russBut it is where you branched from.10:17
poolieknowing python helps10:18
pooliebut, ubuntu.com/employment :)10:18
pooliejelmer, hi?10:19
poolieo/ Riddell10:19
jo-erlendok. bzr stores diffs for text files, yes? What about binaries and other stuff that can't be diffed, does it make copies of those?10:19
Riddellhi all10:19
pooliejo-erlend, they're all stored using a binary diff format10:19
poolieat that level, it doesn't care if they're text or not10:19
jo-erlendhmm. Ok. So if I wanted, I could set my whole home directory under version control so I could skip back if I did something stupid?10:23
pooliebut, a specific backup tool may be better10:27
pooliei like duplicity and rdiff-backup10:27
jelmerpoolie: hi10:29
pooliehey, jelmer10:29
pooliei was just wondering if you had registered sessions for bzr at uds10:30
jelmernot yet, I saw Alisons email earlier but hadn't figured out how to name the blueprints etc yet10:30
pooliethere is some scheme but i don't remember it, and for that matter it may have changed10:31
pooliedholbach could probably help10:31
jelmerI'll ask him - thanks for the reminder.10:31
poolienp, thanks for doing it10:32
pooliejelmer, can i just ask your bzr-colo recipe to build for maverick too?10:44
pooliewell, i _can_; will it break things though?10:45
jelmerpoolie: I'm not sure if it will work, as it uses dh_python210:45
jelmerpoolie: dh_python2 is only available on natty I think, and we've disabled most other builds for maverick because the debian packages require dh_python2 at the moment. maxb has a plan on how to deal with this.10:46
poolieah, ok10:46
pooliei should upgrade my laptop soon anyhow10:46
spivjam: hey, I've got an updated patch for Twisted, just running tests again before I push10:47
maxbI intend to try to put that plan into practice today10:48
spivjam: it adds a noVars param Failure, so you still get tracebacks with files, line numbers and lines, but skips the locals and globals work.  It's about 10x faster rather than 16x on my crude benchmark, but is probably a good compromise.10:48
spivjam: stripping tracebacks entirely in maybeDeferred was starting to have wider test suite fallout in Twisted, mainly in Trial, but tracebacks are clearly desireable there :)10:49
spivjam: it's actually overall faster at running Twisted's tests than my original patch, presumably because it does fix maybeDeferred too10:49
spivjam: woah10:54
spivjam: I think I just saw that intermittent push issue you had, where the client spends ages doing get_parent_map rather than pushing10:54
spivWow, that's weird, it's getting NotStacked back for my branch from the lp smart server10:55
spivBut http://bazaar.launchpad.net/~spiv/twisted/deferred-no-failure-tracebacks-by-default/.bzr/branch/branch.conf looks pretty stacked to me!10:56
spivOh, no, I just can't read a -Dhpss log, ignore me.10:57
spivI don't know why it's not working, though.10:57
pooliebug pls :)10:58
* spiv works around it for right now10:58
spivpoolie: yeah, definitely10:58
jamspiv: it was 'bzr branch lp:a-stacked-branch' rather than getting the dev focus first10:59
jamspiv: I was just starting to write some test cases, and found a few more edges11:01
jamlike "deferred.errback()" defaults to fail=None ,which calls Failure(none), which would also create a traceback11:02
jamspiv: so I'm happy to wait for wherever you want to leave off11:02
jamI was a bit surprised to see "twisted.test.test_defer" rather than "twisted.internet.test.test_defer"11:02
spivjam: see my update to http://twistedmatrix.com/trac/ticket/501111:03
spivjam: partly that's because originally there was only twisted.test, so old stuff tends to be tested in there11:04
jamI think the 16x vs 10x matches what I saw11:04
spivjam: and partly because defer.py really belongs in twisted.python not twisted.internet11:04
jamwhere commenting out __getstate__ had a good benefit11:04
jambut there was almost as much to be gained by not walking the frames in the first place11:04
jamspiv: in which case Failure could depend on it :)11:05
spivI found on my crude benchmark I could squeeze out a few more percent by aggressively avoiding repeated x.y in Failure.__init__, etc.11:05
spivWhich is a good sign, it suggests it's fast enough now for that sort of thing to be significant :)11:05
spivjam: it would still be backwards, layering-wise11:06
jamwell, it is a debug flag11:06
jamwhich should probably sit a lot higher than Deferred.debug11:06
spivWell, capturing more info in Deferreds is different to capturing more info everywhere11:06
jamspiv: not if you are writing real twisted code :)11:07
spivFailures are sometimes used entirely outside the context of Deferreds11:07
jamsince Deferreds are everywhere11:07
spive.g. the 'reason' param of connectionLost11:07
spivDeferreds only provide a way to do one-shot async calls11:07
jamspiv: where, again, it doesn't really make sense to include a traceback11:08
spivjam: I agree11:08
spivjam: I don't think capturing that info is a good default11:08
spivBut it's been the default for probably most of the lifetime of Twisted11:08
spivWhich is over a decade old now11:08
spivSo I think changing that default probably needs to be done cautiously to make sure it doesn't break people's code; Twisted is much pickier about backwards compatibility than most projects.11:09
* spiv -> dinner11:10
pooliei wonder if we have any overall data on connection time11:10
jampoolie: define overall data?11:11
jam(we might have some information in the access logs, etc., but I'm not really sure what you are looking for)11:11
pooliesorry, i meant, connection time 3 months ago vs now11:12
poolieto lp11:12
jampoolie: you mean other than the bzr ping graphs?11:12
poolieideally something measured from the real world11:12
pooliei wonder if i filed that bug long enough ago to be useful11:12
* jam really is pleased with perf boost to lpstats11:13
jampoolie: I wonder about just enabling 'debug_flags = hpss' on production, since the logs I've looked at give some really nice debug info11:13
jammight be too big of a flood for real world, though11:13
jampoolie: https://lpstats.canonical.com/graphs/CodehostingPerformance/20100331/20110331/11:19
jamdefinitely shows it has been trending down recently11:19
jamwell very short term back up11:19
jambut quite a bit down from last may11:19
spivjam: and less variable too, which is nice11:20
pooliedon't know if there's a very distinct trend11:24
pooliei guess if you said "the worst experienced lag" that's gone from 7 to 411:24
pooliein what, seconds? really seconds?11:24
jampoolie: yes, really 7+s just to get an ssh connection11:25
pooliethat's remarkable11:25
pooliei would have guessed more of it was rtt11:26
poolieso what else did we get done this calendar year that was good?11:26
AfCtime bzr missing bzr://... 0m3.042s11:27
jampoolie: If I can get this rolled out into production: https://lpstats.canonical.com/graphs/CodehostingPerformanceStaging/20110101/20110331/11:27
AfCtime bzr missing bzr+ssh://... 0m6.747s11:27
jamAfC: 'time ssh /bin/false' ?11:28
AfCjam: 0m3.357s as expected11:29
jamAfC: this is with openssh on both sides?11:29
jamOne interesting bit is that the twisted ssh service can actually connect faster than openssh11:29
jamnot sure the specific reasons11:30
jamI know at one point ssh switched the default to do reverse dns lookups11:30
jamand that made it a *lot* slower when the source didn't have a dns entry11:30
jambecause it would wait 2s to timeout, etc.11:30
poolieit would be horrible if that's live11:31
jamAfC: http://ubuntuforums.org/showthread.php?t=44567711:31
poolieprobably not11:31
jam"UseDNS no"11:31
jamAlso "GSSAPIAuthentication No"11:31
jamso it doesn't try to look up kerberos credentials11:32
AfCjam: yeah, I'm across that one11:32
AfC(wasn't complaining, just offering a few data points; I have bzr: and bzr+ssh: on the same trees)11:35
jamAfC, poolie: "time ssh localhost /bin/false" is about 800-900ms here11:37
AfCreally? 0.310 ± 0.040 here11:38
jamUsing '-v' seems to say the bulk of the time is right after: http://ubuntuforums.org/showthread.php?t=44567711:39
jamdebug1: Entering interactive session.11:39
jamAt least, that is where the terminal hangs for a bit before going to the next message11:39
spivpoolie: earlier this year we installed python-gmpy on the codehosting server, speeding up Twisted's SSH crypto11:39
jamspiv: after we fixed it not to bork the rest of the system :)11:40
jamwell, afterwards we fixed it :)11:40
jampoolie: this is the list you are compiling for s-tatik?11:41
jampoolie: loggerhead is now mostly actively maintained11:42
jampoolie: package importer improvements. Quite a few big "100 packages no longer failing" etc.11:43
jamlooking here: http://package-import.ubuntu.com/status/11:44
jamI see we're down to 476 failures, from a peak of ~3k11:44
jamin mid January11:45
jamAfC: well, technically that is a VM, since I don't yet run opensshd on my laptop directly.11:45
AfC→ zzz11:46
jampoolie: my 'iter_entries_by_dir' change makes 'bzr co --lightweight gcc-linaro' go from 3m48s down to 1m5s on Ubuntu for me.11:56
jampoolie: spiv's change to make 'fetch' transfer the revisions associated with tags11:56
thropewhen I try to bzr init in a directory on an ntfs partition mounted on linux I get a ERROR: Transport error: [Errno 1] Operation not permitted12:21
thropeit is mounted in latest ubuntu with fuse12:21
thropeso I can't use bzr over an smb mounted drive OR on a locally mounted ntfs drive12:21
=== hunger_ is now known as hunger
jelmerthrope: I think the number of system calls the fuse smb file system allows is pretty limited.12:25
jelmerHave you tried with the kernel one?12:25
thropedon't want to mess about with it really - just using standard ubuntu settings12:25
thropejust surprised to find another not that unusual situation where bzr fails completely and ungracefully12:26
pooliethere's a bug for it, which may have a workaround12:27
pooliebut, really it's a fuse bug12:27
pooliethrope, https://bugs.launchpad.net/bzr/+bug/19072512:28
ubot5Ubuntu bug 190725 in Bazaar "Bzr can't init branch on ntfs-3g filesystem" [Medium,Confirmed]12:29
idkyDid I see that correctly that one can write python scripts using a bazaar repo very easily?12:42
poolienight all12:43
jelmeridky: yep, it's fairly easy12:43
jelmerg'night poolie12:43
idkyjelmer: hmm, that is another thing that makes me tend to bzr instead of git ... why are these decisions so hard? :)12:44
idkyand is there a way to put the output of diff or cdiff into a pager automatically?12:46
jelmeridky: there's a bzr-pager plugin that can do that12:46
jmlI think this bug is fixed12:58
ubot5Ubuntu bug 301472 in Bazaar "need a way to uninstall a hook" [Low,Confirmed]12:58
jmlis it fixed?12:58
jmlhmm. maybe not.13:00
jmlwhat a pity13:01
jelmerI'm hacking on hooks at the moment, might as well have a look at that one too13:03
jelmerjml: would that help you?13:04
jmljelmer: yeah, but only a little. there's a legacy monkey patch in lp/codehosting/__init__ that I'd like to remove.13:05
jml(I had thought I could because it said "bzr 1.14" in the comments, but now I'm confused)13:05
jelmerjml: I don't see any other way to uninstall hooks. Perhaps a patch was proposed but it never made it in?13:09
jelmerAnyway, I'll have a look at adding an uninstall function.13:09
jmljelmer: I think in bzr 1.13, Branch.hooks was a list, not a HookPoint13:09
jmljelmer: so the way to remove hooks was to call 'remove' on that list.13:09
jmland when we upgraded, we did the monkey-patch presumably to avoid the break in API as well as provide the now-missing functionality.13:10
spivOur test suite resets hook registrations between tests13:15
spivjam: I'd love to know why my second pushes to lp:~spiv/twisted/* branches are repushing all of history!13:20
spivi.e. push new branch, stacked and fine.  Commit again, push: find all the ancestry missing and push it all.13:21
* spiv tries with bzr 2.313:22
spivThat worked.  Regression :(13:22
jamspiv: ouch. I wonder if it is something with the lp: redirect biting us again?13:26
spivjam: not sure, and it's too late in my night for me to find out13:28
spivjam: https://bugs.launchpad.net/bzr/+bug/74566413:28
ubot5Ubuntu bug 745664 in Bazaar "Incremental push to stacked branch on LP walks all of history" [Critical,Confirmed]13:28
jelmerjml: https://code.launchpad.net/~jelmer/bzr/uninstall-hook/+merge/5552713:41
jmlit looks as if Twisted can't use bzr-svn to maintain a mirror any more15:28
jmlbecause it requires more than 600MB of memory to do a pull15:28
jmland they don't have that much on their servers15:28
jelmerjml: Whoa; is the tree really that big?15:28
jelmerand this is just an incremental pull?15:28
jmljelmer: the history is pretty old15:29
jmljelmer: not sure about the tree size...15:29
jml/usr/bin/bzr svn-import -v --incremental15:29
jelmerah, svn-import15:29
jmlshould they be doing something else?15:29
jmloh, I guess that's a multi-branch thing15:30
jelmerI was thinking bzr pull. there's a known issue with svn-import and memory usage that I still need to look into15:30
jelmerperhaps this is a good excuse to..15:30
jmljelmer: is there a bug number that I can point the Twisted folk at?15:32
=== deryck is now known as deryck[lunch]
jelmerjml: bug 516999 IIRC15:35
ubot5Launchpad bug 516999 in Bazaar Subversion Plugin ""Finding branches" step takes waaay too much memory" [High,Triaged] https://launchpad.net/bugs/51699915:35
jmljelmer: thanks.15:35
jelmervila: hi16:06
vilajelmer: pong ;)16:06
jelmervila: just looking at your devnote on configuration files16:06
* vila nods and fix more typos :)16:07
jelmervila: some of the bullet points at the bottom don't seem to be formatted properly16:07
vilajelmer: I fixed some, try refreshing ?16:07
vilaargh, silly me, looking at my local copy ;-/16:08
jelmerUnder "user facing concepts"16:08
jelmerand under "stack examples"16:08
jelmerah :)16:08
jelmervila: the sheer number of configuration files worries me a bit16:09
vilajelmer: yup, fixed both16:09
vilajelmer: well, have a look at the number of IOs we do today then ;)16:10
jelmerI'm not entirely sure what to do about that; it seems like adding a project and a organization configuration file requires a particular workflow16:10
jelmervila: not just the performance, but also what it does to our UI16:10
vilajelmer: that's one read per option, I want to reach one read by config file (lazily triggered on first read)16:10
vilaright, we'll have to dig into specifics then, we will be able to merge some plugin conf files into the existing ones16:11
jelmervila: when you say organization configuration file do you mean a system wide configuration file?16:12
vilalocations.conf is mostly used to defined defaults today, this feature will be supported by bazaar.conf itself16:12
vilajelmer: yes, it could be /etc/bzr/xxx.conf16:12
vilajelmer: but more precisely, *what* are you worries there ?16:13
jelmervila: something like /etc/bzr/bazaar.conf ?16:13
jelmervila: or also /etc/bzr/canonical.conf ?16:13
jelmeror /etc/bzr/samba.conf ?16:13
vilahmm, I was thinking /etc/bzr/bazaar.conf16:13
vilayou could define samba.policy.* options there16:14
* fullermd . o O (/usr/local/etc...)16:14
jelmervila: In that case I think the naming in the devnote is a bit confusing16:14
vilanothing definite there which may explain the confusion :)16:14
jelmervila: I think system configuration rather than organization configuration explains it a bit better, at least to me :)16:15
jelmervila: How would the project be defined for the project configuration?16:16
vilaboth should addressed, I'm still not clear about the best way to dispatch options in files16:16
vilanot sure either about repoconf vs project.conf, many questions are related to the way these files are (or not) versioned and how they propagate16:17
vilabut I don't try to address that yet16:17
jelmervila: That's the main thing I noticed that is a bit worrying, looks like a great improvement over the current unclear system otherwise.16:19
* vila nods16:21
vilaSo you're worrying about having too many files too put one option into ?16:21
vilaMy main reaction was to write 'bzr config' and I now use it more than 'bzr info'...16:21
jelmervila: that (which makes it hard/confusing to decide which file to put the option into) and forcing a particular workflow on the user with a project.conf, where we don't have the concept of a project16:22
vilaha, right16:22
jelmerthough since your concept of project is still a bit vague I'm not sure about that second objection16:22
vilaSo, I separated read and write very explicitly because writing an option from bzrlib is the exception16:22
vilaThe whole framework is targeted at allowing a user to specify defaults values where *he* see fit16:23
vilaand avoid having to duplicate such settings all over the place16:23
vilaproject.conf is still nebulous, the idea is that you could describe where your trunk is, where to report bugs, etc16:24
vilaand have it propagated to all branches (with handwave:// transport ;)16:25
jelmervila: for example, is there really much value in having repository.conf when (as we've claimed) the repository is just the place where the revisions are stored, not a user-visible thing?16:25
jelmervila: it also limits the concept of a project; e.g. I currently have bzr-svn for which I probably want to apply the rules for the greater bazaar project and then a few specific bzr-svn ones16:26
vilarepo.conf may contain shared_storage so we can get rid of repository/shared_storage for example16:26
jelmervila: shared_storage is something repository-specific, I don't think we should inherit it in e.g. the branches below that repository16:27
vilaright, that's indeed a good example :)16:27
maxbalso default creation of trees setting16:27
vilaargh, the bzr-svn vs bzr I meant16:27
vilajelmer: right, but you can define properties for branch created under various prefixes (reviews, bugs, trunk, release, etc)16:28
vilaI'm not advocating doing that though, just mentioning the ideas16:28
vilaI tried to find a scope greater than the current needs to ensure I wasn't reducing the needs too much,16:29
vilaNow. I don't intend to implement every file described there when the most asked for is tree.conf16:29
vilabut I want a config framework that can support them if we decide we need them16:30
vilajelmer: if bzr-colo can be implemented with a branch.conf with sections instead of branches/ files hierarchy for example... I'd be delighted16:31
vilajelmer: regarding branch.conf inheriting from repo.conf, *some* options could inherit, but certainly not all16:33
jelmervila: the problem with definining a repository.conf and a project.conf is that we'd limit ourselves to a very strict interpretation of those, I'd rather see a more flexible mechanism for inheriting configuration options16:34
jelmervila: yeah, I agree it'd be nice to collapse the branch configurations / last-revision files with the next format bump16:35
vilajelmer: when (and if) you register an option, you can define *where* it is allowed16:35
jelmervila: I mean as a user16:35
vilajelmer: there may even be a compatibility path that doesn't require a format bump...16:35
vilawhat do you mean by 'more flexible' ?16:36
jelmervila: e.g. in my example of bzr-svn there isn't a single project that's relevant16:36
vilaRight, I agree on the conceptual level, but without specific options to think about, it's harder to come with good answers ;-/16:37
=== deryck[lunch] is now known as deryck
vilasocial conventions (where is trunk, where/how should I send contributions, mailing lists etc) seem pretty clear to me as project specific and can't really be shared across project16:40
vilaalso, with interpolation, you gain the ability to refer to the project with {project} which can be set in say, branch.conf but still referred to in project.conf16:41
vilaor overriden16:42
vilajelmer: ben also mentioned including config files. There are trick issues there and I didn't mention them but that may also be a mean to consider16:45
jelmervila: a lot of those options could be shared across the various bzr subprojects I think16:46
jelmervila: include files sound like an interesting alternative16:46
vilajelmer: one way to share across projects is to put them under the same path (in different directories of course)16:47
vilajelmer: another way is to allow some config files to be defined and used at different levels in the hierarchy (ignore files for example)16:47
vilaso my proposal tried to mention the *possible* files and define a framework that will allow us to implement them if/when needed16:48
vilaI also wanted a simple design and I'm not sure it doesn't provide too much already ;D16:49
vilathese are just *dicts* damnit :D16:49
viladicts of strings even16:50
vanguardhow can I convert a git repo to a bzr repo?17:30
=== beuno is now known as beuno-lunch
=== ccxCZ_ is now known as ccxCZ
jelmervanguard: "bzr git-import" command from the bzr-git plugin, or using bzr fastimport / git fastexport17:43
vanguardhmm, bzr fastimport crashed, I reported it on LaunchPad, but it does not seem too good :-/17:57
=== beuno-lunch is now known as beuno
awilkinsIs there anything for Bazaar that's like gitstats and shows things like commit time distribution19:45
awilkinsSomething that just used git-fast-export format would be perfect, no?19:45
awilkinsI want to really rub it in for my management the stupid hours I've been working and commit logs are the best evidence19:46
* beuno doesn't know of any19:48
awilkinsHmm, do you have to pick a file?19:54
luks_heh, I don't actually remember how does it work anymore :)19:55
luks_ah, the filename is the generated png file19:56
awilkinsHence "." doesn't work19:56
=== luks_ is now known as luks
luksit was really just a quick hack to see the stats for my pet projects19:57
awilkinsMight poke it a bit to take a list of aliases, etc19:57
awilkinsI have several aliases in this projects from committing on different machines with different WHOAMI, on SVN with a different username, etc19:57
awilkinsBut it already reveals a nice set of spots for 0400, 2100, 2300 :-)19:58
awilkinsMy, that was a quick hack19:59
* awilkins hacks it to use regex for the committer20:11
awilkinsWhy the hell does one guy always commit at 0900 on thursday...20:14
awilkinsMany thanks, heavy ammunition, that is20:16
awilkinsluks, https://code.launchpad.net/~adrian-wilkins/+junk/punchcard-regex-committer (as if you needed help to write it...)20:22
luksheh, I never noticed the wrong day abbreviations20:28
awilkinsJus tgot them wrong myself ... overwritten that rev20:28
awilkinsHave to justify that my Thu / Fri working at home is productive20:30
awilkinsBiggest blob is 1000 Friday morning :-)20:30
awilkinsCan see all sorts of extra dimensions you might add to this20:31
awilkinsColourize the blobs on average commit size, etc20:31
awilkinsBut no time ... wanted to do some visualization software for financials at one point, voxel graphics for interest, etc, but never got around to even trying20:32
* awilkins has all sorts of fun with for C in `bzr log --xml | xpath2 -q -e '//committer/text()' | sort | uniq` ; do bzr punchcard --committer $C $C.png ; done20:39
pooliehi all22:48
jelmer'morning poolie22:50
pooliehi there22:50
pooliehey there22:56
pooliedid you get to talk to daniel, jelmer?22:56
jelmerpoolie: yep, thanks for putting us in contact22:56
poolieso it's all set, or underway?22:57
jelmerit's underway, should be done by tomorrow22:58
jelmerJorge also sent out an email with more details on e.g. the naming scheme later today.22:59
jelmer(your yesterday)22:59
jelmerwb poolie :)23:12
jelmerdid you see my reply?23:12
poolie_yes, thanks :)23:13
poolie_hi spiv23:49
spivHi poolie, I'm not *quite* here yet ;)23:50
spivGood morning :)23:59

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