[00:32] <kbulgrien> wow.  Personally, I am not a fan of commit whole workspaces at once.  That means bad checkin comments.  And when I am the guy that debugs other's work, I hate bad checkin comments and large commits.
[00:33] <lifeless> kbulgrien: you can commit less than the whole
[00:33] <lifeless> kbulgrien: its merely a default
[00:33] <lifeless> kbulgrien: however, all of (git, hg, bzr) share this assumption that you want whole tree versioning
[00:34] <poolie> kbulgrien, there's also some support for per-file commit messages
[00:34] <poolie> it's not generally used though
[00:34] <poolie> kbulgrien, i'm in favour of people making small changes and then committing the whole change
[00:34] <poolie> when people commit only part of the changes to their tree
[00:35] <poolie> there's a good chance that what they committed was never actually compiled or tested as a whole
[00:35] <kbulgrien> I've just traditionally been the guy who had to fix other people's stuff.  Normally its not the author that cares about commits.
[00:35] <poolie> i think you need a new tradition :)
[00:35] <poolie> and maybe a water pistol
[00:35] <kbulgrien> Perhaps.  It'
[00:35] <kbulgrien> s a job.
[00:36] <kbulgrien> Water pistol. hmm. never thought of that.  maybe a super soaker.
[00:37] <kbulgrien> But then that doesn't work when the other guy isn't around anymore.
[00:37] <poolie> that's true, what's done is done
[00:38] <kbulgrien> as far as defaults on operating on the whole tree goes, that's not necessarily something I feel is worth getting bent out of shape about.
[00:38] <kbulgrien> Not that there is much worth getting bent out of shape about, but...
[00:39] <kbulgrien> its an expression.
[00:39] <fullermd> Nono, it's _best_ when they're not around any more.  That way they never expect it!
[00:40] <fullermd> For me, I was glad to get the full-tree action by default.  Took some getting used to, but still.
[00:40] <fullermd> Look over my old CVS commits, you'll find way too many "Whoops, here's the rest of some recent change that didn't get committed 'cuz I wasn't high enough in the tree"
[00:41] <poolie> yep
[00:41] <kbulgrien> won't happen for me.  If I don't know what I'm committing, I don't have any business committing, IMO.
[00:41] <fullermd> Typing "cd ../../../../../.. ; cvs diff ; cvs ci" gets old real quick.
[00:42] <fullermd> I tried for a while having a whole separate freakin' xterm that always stayed in the root of the checkout so I could do my diff's and ci's from there.  It was just too stupid though.
[00:42] <kbulgrien> people think fast is fast, but its usually not. slow (careful) is faster than fast.
[00:43] <kbulgrien> I see it all the time.
[00:43] <fullermd> True, but stupid tools are slower than slow.
[00:43] <kbulgrien> :-)
[00:43] <kbulgrien> And some discussions are like tarpits ;-)
[00:44] <lifeless> fullermd: pushd $(cvsroot .);cvs diff -Nrup; popd
[00:44] <lifeless> fullermd: where cvsroot is something you can write
[00:44] <fullermd> Things that make committing less convenient tend to make you less likely to commit.  And that leads to way worse commit logs   ;)
[00:45] <kbulgrien> hmph.
[00:45] <kbulgrien> Discipline is discipline.
[00:45] <kbulgrien> :-)
[00:45] <fullermd> And eventually to the guy whose every commit log is "It's 4:30 on Friday, here's this week's work".  And then there's yelling, and screaming, and discharge of firearms inside city limits, and lawsuits, and...
[00:45] <fullermd> That really slows things down.
[00:45] <kbulgrien> That's a management problem.
[00:46] <fullermd> Not any more   8-}
[06:29] <vila> hi all
[06:50] <vila> hey poolie
[06:51] <poolie> hi there vila
[06:53] <poolie> vila, we can have a chat whenever you like
[06:57] <vila> poolie: see pm ?
[07:58] <mgz> morning all!
[08:01] <poolie> hi mgz
[08:15] <Riddell> hello former colleagues, would anyone like to a peer performance review for me?
[08:18] <mgz> less of the former
[08:21] <mgz> maybe vila or jelmer would like to
[08:21] <mgz> well, I'd like to, but am less useful.
[08:21] <vila> mgz: hey !
[08:22] <vila> Riddell: As long as it doesn't require any comment about driving, no problem ;)
[08:23] <Riddell> vila: :)
=== quicksil1er is now known as quicksilver
=== jam1 is now known as jam
[09:07] <|_emming> hello, could anyone help me out with bzr basics?
[09:07] <|_emming> which command do I use to just display the current revision of a remote branch?
[09:08] <jelmer> hi |_emming
[09:08] <jelmer> |_emming: bzr revno <url>
[09:08] <|_emming> I tried that but it somehow does not work and always keeps telling me "not a branch"
[09:10] <jelmer> |_emming: what sort of URL are you specifying, and what's the full error?
[09:10] <|_emming> ah it works now, thank
[09:10] <|_emming> just forgot to specify which branch to look at (stable/testing)
[09:20] <mgz> hm, it seems like bugs 839426, 958551, and 963161 are all basically bug 663593
[09:20] <ubot5> Launchpad bug 839426 in Bazaar "bzr crashed with UnicodeDecodeError in write_revision_to_string(): 'ascii' codec can't decode byte 0xe2 in position 4759: ordinal not in range(128)" [Undecided,Expired] https://launchpad.net/bugs/839426
[09:20] <ubot5> Launchpad bug 958551 in bzr (Ubuntu) "Crash while committing" [Undecided,New] https://launchpad.net/bugs/958551
[09:20] <ubot5> Launchpad bug 663593 in Bazaar "String inputs should be clearly defined and validated in commit builder" [Low,Confirmed] https://launchpad.net/bugs/663593
[09:20] <jelmer> ah, hmm
[09:20] <mgz> but what I don't get is why this new form is only showing up now
[09:20] <jelmer> bzr-builddeb's commit hook?
[09:20] <mgz> they're all on bzr-builddeb 2.7.0dev
[09:21] <mgz> the fix is in 2.7.8
[09:21] <mgz> but... why the run of recent reports with the different traceback?
[09:22] <mgz> wait, linked the wrong bug
[09:22] <mgz> maybe from oneric-proposed picking up a newer bzr version?
[09:23] <mgz> but there not being a corresponding builddeb backport?
[09:24] <jelmer> ah..
[09:24] <mgz> bug 853664 fixes it I think.
[09:24] <ubot5> Launchpad bug 853664 in bzr-builddeb "tries to decode debian/changelog as ascii, and fails when it's not" [Medium,Fix released] https://launchpad.net/bugs/853664
[09:41] <mgz> hm, maybe I should have duped against the original bug and opened an ubuntu task for Oneiric?
[09:41] <jelmer> mgz: I think that'd be the most sensible thing
[09:41] <mgz> not that I'm sure backporting dev stuff is really the right thing, we expect everyone doing this to switch to Precise shortly right?
[09:42] <jelmer> yes
[09:42] <jelmer> (to both questions)
=== jam3 is now known as jam
=== yofel_ is now known as yofel
[15:22] <vila> anyone knows a way to *change* a root-id ?
[15:22] <vila> bug #965403 took me off-guard :)
[15:22] <ubot5> Launchpad bug 965403 in Bazaar "all bzr plugins use TREE_ROOT as their root-id as does bzr itself" [Undecided,Confirmed] https://launchpad.net/bugs/965403
[15:31] <jelmer> vila: I know how to do it programmatically, but not from the cli
[15:31] <jelmer> vila: perhaps we should have a (hidden) 'bzr refresh-file-id' command?
[15:35] <vila> jelmer: it's a delicate issue as I'm not sure you can still merge branches with different root-ids then
[15:35] <jelmer> vila: you can, but you get conflicts when the other branch has added files
[15:35] <jelmer> those conflicts can be resolved though
[15:35] <jelmer> I have a few projects (especially packaging branches) where that's the case
[15:35] <vila> hmm
[15:36] <vila> I seem to be able to work around my issue by join'ing twice
[15:36] <jelmer> whu?
[15:36] <vila> (and some more hackery)
[15:41] <vila> I created an empty branch to get a new root-id, join bzr-webdav into that, moved files, joined the resulting branch into bzr
[15:41] <jelmer> ah, right - that's another way of changing the root id
[15:42] <vila> oh, committed --unchanged after 'bzr init' to make sure jion won't get the webdav root-id ;)
[15:42] <vila> yeah
[15:42] <vila> at least in this use case, I won't ever try to merge this branch back into lp:bzr-webdav
=== deryck is now known as deryck[lunch]
[17:03] <jelmer> vila: any chance of a quick review of https://code.launchpad.net/~jelmer/bzr/2.5-config-help-topics/+merge/99372 ?
[17:04] <vila> jelmer: EOD'ing, but I will PP as hell tomorrow, I swear :)
[17:04] <jelmer> nevermind, you already merged it :)
[17:04]  * jelmer should've updated his 2.5 branch
[17:04]  * vila blinks :)
[17:04] <jelmer> that's the help topic fix for config options
[17:05] <vila> yeah, merged long ago no ?
[17:05] <jelmer> ah, actually - no
[17:06] <jelmer> I'll let you look at it tomorrow
[17:06] <jelmer> have a great evening :)
[17:06] <mgz> ah, it's not in 2.5.1? the bug is wrong?
[17:07] <mgz> and 2.6b1 isn't active any more...
[17:07]  * mgz does some juggling
[17:08] <jelmer> mgz: it's not fixed in 2.5 yet, only in 2.6b1
[17:08] <vila> jelmer: make sure it doesn't trigger the doc building error for sphinx ?
[17:09] <vila> jelmer: not sure they are related but ~worried
[17:09] <vila> jelmer: bah, I'll check it myself tomorrow, don't worry
[17:09] <jelmer> vila: I'm not sure why the two would be related?
[17:09] <jelmer> works for me :)
[17:09] <vila> jelmer: I don't remember the details 'make dosc-sphinx' ?
[17:10] <jelmer> no, that's a different issue
[17:10] <jelmer> this is 'bzr help branches'
[17:10] <vila> ok
[17:10]  * vila really off ;)
=== deryck[lunch] is now known as deryck
[18:42] <mgz> ha, its great when writing some silly trivial test... and it actually fails because of a bug
[19:23] <dakira> Hi. I just pulled an ubuntu source package using bzr (bzr branch lp:ubuntu:precise/package) and fixed a bug. I already pushed a private branch to launchpad (lp:~me/ubuntu/precise/package/fix). Do I just propose this for merging now, or is the process for ubuntu packages different?
[19:42] <diodor> hi
[19:42] <diodor> is there a way to create a branch from a subdirectory of a branch?
=== jml_ is now known as jml
[20:21] <poolie> hi all
[20:21] <mgz> hey poolie
[20:22] <mgz> must be time for me to descend
[20:22] <poolie> ah, probably
[20:23] <poolie> yeah that is pretty late
[20:23] <poolie> you're on dst now?
[20:25] <wgz> poolie: yep
[20:25] <poolie> sleep well, i'll see you tomorrow
[20:26] <jelmer> 'evening wgz, poolie
[20:27] <poolie> hi there
[20:33] <mwhudson> :(
[20:33] <poolie> ?
[20:33] <mwhudson> jelmer: what does "AssertionError: Invalid sha for <Commit bea9a47ad0d16bcfbe30b73f78730e351e25a881>: fc4e5248d29cf7264481cbff82343eade5fcc2ca" in a failing import mean again?
[20:34] <mwhudson> jelmer: it's killing https://code.launchpad.net/~vcs-imports/notmuch/trunk
[20:34] <jelmer> mwhudson: most likely that it's an import with a merged tag in it
[20:34] <mwhudson> ah
[20:34] <jelmer> which is a new thing in git
[20:34] <jelmer> mwhudson: there's an open bug against dulwich/bzr-git/launchpad about it
[20:34] <mwhudson> i thought git forbade new things :)
[20:34] <jelmer> that I've been working on - it affects a fair few imports
[20:34] <mwhudson> jelmer: how can i tell if that's the case on the git side?
[20:35] <jelmer> mwhudson: git cat-file -p <commit-id>
[20:35] <jelmer> mwhudson: it doesn't really forbid it, but it requires you preserve those fields
[20:35] <jelmer> mwhudson: dulwich does this, but bzr-git doesn't round trip them properly (since it doesn't know about them)
[20:35] <mwhudson> mergetag object 9325cae5f46e543aedb790cfe62a4faabcba949c
[20:35] <jelmer> yep, that's it
[20:35] <mwhudson> ok
[20:35] <jelmer> should be fixed soon :)
[20:35] <mwhudson> cool :)
[20:36] <mwhudson> anything i can do to help?
[20:37] <mgrandi> hello
[20:47] <poolie> o/
[20:47] <mgrandi> are there any plugins or planned features to have nested trees in bzr?
[20:47] <mgrandi> like svn does i guess
[20:47] <poolie> yes, i think the best at the moment is bzr-scmproj
[20:48] <mgrandi> what doe scm stand for? oo
[20:48] <mgrandi> o.o*
[20:48] <poolie> software configuration management?
[20:48] <poolie> there is also some work towards built in nested trees
[20:48] <mgrandi> oh
[20:48] <mgrandi> that just seem like it would be nested trees, probably why my google came up empty
[20:49] <jelmer> mwhudson: some help testing would be great once it's done
[20:49] <jelmer> mwhudson: also, you should get a more appropriate error with lp:bzr-git
[20:49] <mgrandi> im just getting tired of extracting source releases of a library and then copying them over to a source tree i have and then updating =P would be nice to have it automated and just do update or something
[22:11] <idnar> what project should I report a bug against if I want to complain about lp-propose-merge?
[22:13] <mgrandi> might just be the bzr project
[22:13] <mgrandi> i dont see a bzr-launchpad page on launchpad
[22:14] <jelmer> idnar: yep, just the bzr project
[22:14] <idnar> okay, thanks
[22:17] <idnar> filed bug #965759 in case anyone else watching is as terminally curious as I am :)
[22:17] <ubot5> Launchpad bug 965759 in Bazaar "lp-propose-merge has poor error reporting" [Undecided,New] https://launchpad.net/bugs/965759
[22:26] <jelmer> idnar: hmm, that looks like a dupe
[22:26] <jelmer> bug 704606
[22:26] <ubot5> Launchpad bug 704606 in Bazaar "launchpad.branches.getByUrl() doesn't support properly urlencoded URLs" [Medium,Triaged] https://launchpad.net/bugs/704606
[22:28] <mgrandi> but the idea of that it should also say the underlying error so its easier to debug =P
[22:28] <idnar> hmm, maybe I was a little unclear
[22:28] <idnar> although I'm pretty sure #704606 isn't actually related to either of the error messages in my report
[22:29] <idnar> but I'm just complaining that it's impossible to tell what operation actually caused the error messages
[22:29] <idnar> not any of the specific error messages, those were just examples to show how hard it is to figure out what went wrong
[22:31] <mgrandi> that should be pretty easy
[22:31] <mgrandi> you just have the original error message + the exception that originally got called
[22:31] <mgrandi> unless there is some standard on how error messages should look that im not aware of
[22:31] <idnar> I believe the first error message was actually caused by having submit_location set to something not on launchpad (at least once I fixed that, it stopped happening)
[22:33] <idnar> (not really sure what caused the second one about diverged branches, I reran the same command later and it worked without me apparently changing anything; I think it may just have been Launchpad's bzr mirror catching up too slowly or something)
[22:34] <mgrandi> hmm maybe
[22:35] <idnar> (the last thing I did to the branch I was submitting before trying to run bzr lp-submit was a push --overwrite)
[22:35] <idnar> anyhow yeah, not directly relevant to my actual bug report
[22:36] <jelmer> idnar: bug 704606 is the cause of the second bug in your bug report
[22:36] <ubot5> Launchpad bug 704606 in Bazaar "launchpad.branches.getByUrl() doesn't support properly urlencoded URLs" [Medium,Triaged] https://launchpad.net/bugs/704606
[22:37] <jelmer> sorry, the first
[22:37] <idnar> huh, okay
[22:37] <idnar> I don't really understand why urlencoding would have anything to do with it
[22:38] <idnar> the URL would have been something like file:///home/mithrandi/code/blahblah without any + signs or anything like that
[22:38] <idnar> oh it might have had a . in it
[22:39] <jelmer> ah, oh
[22:39] <jelmer> so it's just the same error message but a different cause
[22:39] <jelmer> never mind me then :)
[22:40] <idnar> okay :)