[00:17] <evn> i'm trying to use git-serve and get the following error
[00:17] <evn> ~ $ bzr git
[00:17] <evn> No module named foreign
[00:17] <evn> on Bazaar (bzr) 1.13.1
[00:18] <evn> where does the 'foreign' package live?
[00:23] <evn> :-(
[00:35] <evn> anyone?
[00:37] <emmajane> evn, This was part of jelmer's branch and apparently it was rolled into the main bzr, but I'm just going on past log files.
[00:37] <emmajane> http://irclogs.ubuntu.com/2009/02/06/%23bzr.html
[00:38] <emmajane> evn, the same thing was true in March as well.
[00:38] <emmajane> http://irclogs.ubuntu.com/2009/03/09/%23bzr.html
[00:39] <evn> i have a more recent version of bzr than that so it should be there, right?
[00:40] <emmajane> evn, "should be" but also "doesn't appear to be"
[00:40] <evn> should i try to downgrade bzr?
[00:40] <emmajane> I don't know what the right answer is, sorry.
[00:41] <emmajane> Previously the right answer has been to (1) use bzr.dev or (2) jelmer's PPA.
[00:41] <emmajane> I don't know if either of those are still true though.
[00:41] <evn> hrm
[00:41] <evn> i have the latest bzr from macports
[00:42] <emmajane> You have the latest "released" bzr, this isn't the same as the "development" verison.
[00:42] <evn> oh
[00:42] <Peng_> 1.13.1 isn't the latest release anyway.
[00:43] <emmajane> I *think* jelmer is at UDS this week (in Spain) so you could try again tomorrow.
[00:43] <emmajane> Unless Peng_ happens to know the right answer. ;)
[00:43] <evn> should i try to get https://launchpad.net/bzr/bzr.dev
[00:43] <evn> ?
[00:43] <evn> or would 1.15 have what i need
[00:44] <Peng_> I don't know.
[00:45] <emmajane> http://bazaar-vcs.org/BzrForeignBranches/Git/Server
[00:45] <evn> yeah, that's what i'm trying to use
[00:46] <emmajane> evn, Have you read through the page and followed all the links?
[00:46] <evn> yeah
[00:46] <evn> i installed dulwich
[00:46] <evn> and git-serve as a plugin
[00:46] <emmajane> When I read that page I don't see anything that says, "This is available in bzr as of version X."
[00:47] <emmajane> So I would assume that you have to use the development version that is referenced near the top.
[00:47]  * Peng_ goes /away
[00:47] <evn> lp:~johncarr/bzr-git/git-serve ?
[00:47] <evn> that's the plugin, not an actual version of bzr
[00:47] <emmajane> evn, Your best bet is to try and catch jelmer tomorrow.
[00:48] <evn> ok
[00:49] <emmajane> He was around today off and on until about two hours ago.
[01:17] <evn> i installed bzr 1.15 and now i get
[01:17] <evn> Unable to load plugin 'rebase'. It requested API version (1, 13, 0) of module <module 'bzrlib' from '/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bzrlib/__init__.pyc'> but the minimum exported version is (1, 15, 0), and the maximum is (1, 15, 0)
[01:17] <evn> oh nm
[01:17] <evn> it still says No module named foreign
[01:17] <evn> giving up for today
[03:22] <LaserJock> anybody know specifically what Launchpad is using for git imports?
[04:13] <johnf> Interesting bug. If anyone ever complains they can't add a directory containing a directory called objects then it could be because of bzr-git #380818
[04:28] <wgrant> LaserJock: bzr-git
[08:16] <kfogel> Anyone here used bzr-search plugin?  I just did (in the plugin's own directory) 'bzr index' followed by 'bzr search string_that_is_definitely_in_a_file_here', and it claimed no hits.
[08:17] <Peng_> I have used bzr-search, but I can't help much.
[08:17] <Peng_> Does .bzr/bzr-search look populated?
[08:18] <Peng_> Are you sure about the search string? Try something dumb, like "for". What about suggestions?
[08:18] <kfogel> Peng_: yes, it's there, and has stuff in it.
[08:18] <kfogel> Peng_: got it.
[08:18] <kfogel> Peng_: PEBKAC
[08:19] <Peng_> Okay.
[10:16] <mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/mnemosyne-proj/maemosyne
[10:27] <pygi> GaryvdM: pass the lp:~mario-danic/bzr/bzr-win branch to villa :)
[10:33]  * igc dinner
[10:33] <pygi> vila: greetings :p
[10:40] <vila> pygi: Haaaaaa, finally I link the nick and the human being ! :)
[10:42] <pygi> vila: hahahhaha :D
[10:43] <pygi> vila: lp:~mario-danic/bzr/bzr-win will be the branch for the win installer automation stuff
[10:45] <vila> pygi: yeah !
[11:05] <pygi> mvo: poke
[11:45] <johnf> abentley: ping
[11:46] <abentley> pong
[11:46] <johnf> abentley: any chance of a bzrtools release for 1.15
[11:47] <johnf> or isn't one needed/
[11:47] <johnf> ?
[11:47] <abentley> There should be a release for 1.15.
[11:47] <abentley> johnf: I'll do it tonight.
[11:48] <johnf> thanks could you ping me when your done so I can roll it out to the PPA
[11:48] <abentley> johnf: Okay.
[11:51] <johnf> So if I emailed a patch for merging and it's in budle buggy and someone has commented on it with some small changes. What is the process for for fixing the patch. Do I just reply to the email from bundle buggy with a new patch?
[11:53] <konnertz> hi, is it possible to have ehmm... three(?) repos "in a row"?
[11:53] <Peng_> konnertz: What do you mean?
[11:53] <mwhudson> jelmer: http://launchpadlibrarian.net/27200360/gitorious-trunk-log.txt <- thoughts?
[11:53] <Peng_> johnf: If it was just bb:tweak, you can resubmit the fixed patch, or perhaps someone will fix it up while merging it.
[11:53] <Peng_> mwhudson: G'morning. :)
[11:54] <konnertz> i mean i develop a web framework useful for my company but also for me (and maybe others), atm i use svn on my root server
[11:54] <konnertz> but i should make it accessible to alle coworkers asap
[11:54] <johnf> Peng_: as in just send a brand new email? Won't that create two merge requests?
[11:54] <konnertz> but i want to continue working also at home and on laptop
[11:55] <Peng_> johnf: Yes, send a reply. It will create a new merge request, but I think they'll be sort of linked. Anyway, the (minimal) administrative overhead of that is exactly why sometimes the person merging it will take care of it.
[11:55] <konnertz> so where should be the central repo? Or is this a misconception?
[11:56] <johnf> Peng_: Ok it's just a tweak for spelling and a branch name so I'll leave it
[11:56] <Peng_> konnertz: Bazaar is a DVCS. You don't /need/ a central repo. If you want one, you can put it wherever you want.
[11:56] <konnertz> Are all repos equally? And can changes be merged from A to B or from B to C and also from C to A ??
[11:56] <LarstiQ> Peng_, johnf: if the old patch is in the ancestry of the new one, they'll be subsumed into one by BB
[11:57] <Peng_> konnertz: Yes.
[11:57] <konnertz> Peng, okay.
[11:57] <johnf> LarstiQ: ahh ok cool
[11:58] <kfogel> jelmer: http://paste.lisp.org/display/80898   -- a 'bzr search' error on a package you are familiar with.
[12:02] <konnertz> so just another question pls to get into it again - i already setup two test projects some weeks ago and tried the basics, ...
[12:02] <konnertz> To start the first repo, i could start it on my local box, right?
[12:03] <konnertz> what cmd pls for my needs of decentral VC?
[12:07] <Peng_> konnertz: You can start it wherever you want.
[12:07] <Peng_> konnertz: Read the tutorial. :)
[13:12] <pygi> Guest52322: :p
[13:13] <pygi> hiding :D
[13:13] <Guest52322> whoops
[13:42] <jelmer> mwhudson, I can reproduce that bit unfortunately
[13:43] <jelmer> mwhudson, Do you have some easy way to file bugs from failed vcs imports ?
[13:44]  * jelmer wonders if gitorious is perhaps running a custom server
[14:30] <awilkins> .join ##csharp
[14:30] <awilkins> oops
[14:46] <awilkins> Any loom gurus here?
[14:47] <awilkins> I was just thinking ; do looms have to be 2-dimensional (a stack of branches) ; could you have levels that fan out
[14:50] <fullermd> A stack isn't 2-dimensional   :p
[14:57] <awilkins> fullermd: Well, they are stacks of 1-dimensional things
[14:57] <awilkins> fullermd: So I was thinking that was 2-d
[14:57] <awilkins> Stacks of linked lists (or DAGs)
[14:58] <awilkins> The problem I was thinking about was the maintaining-a-development-branch-with-multiple-patches-to-the-trunk
[14:58] <awilkins> Where you want each patch branch to be distinct and separate so that you can submit it for merging independantly
[14:59] <awilkins> but also want your development branch to hold them all
[15:03] <ronny> how can i get the tip revision of a branch, i cant find it in the branch api
[15:03] <awilkins> ronny: Get revision -1 ?
[15:06] <ronny> awilkins: but what api is for getting the revisions, i only found sometihng for trees
[15:07] <awilkins> ronny: Not sure about that
[15:11] <awilkins> http://imagebin.org/50545  ;
[15:11] <ronny> oh, looks like hg's pbranch
[15:13] <mwhudson> ronny: branch.last_revision() ?
[15:15] <awilkins> It sounds just like what loom is for, maybe I'm just not grokking it
[15:16]  * awilkins wonders if there's a qloom
[15:16] <ronny> mwhudson: that gives the id, now im in search of a way to get a revision object
[15:16] <ronny> i did get one over a cahin of other things that is probably tooooo complicated
[15:17] <ronny> oh.found it
[15:17] <mwhudson> ronny: b.repository.get_revision(b.last_revision())
[15:17] <ronny> wt.branch.repository.get_revision(wd.last_revision())
[15:20] <ronny> hmm, and now to figure a way to do push/pull from the api
[15:24] <Peng_> Not to be an ass, but has everyone forgotten about https://code.edge.launchpad.net/loggerhead/+activereviews ? There are several things up for review.
[15:25] <Peng_> I'm not demanding you review them or anything. I just want to be sure they're on the radar somewhere.
[15:25] <mwhudson> Peng_: UDS!!@!@!!one!
[15:25] <Peng_> mwhudson: As an outsider, UDS seems terribly unproductive. Development has shut down. You're not just playing video games, are you? :P
[15:25] <mwhudson> heh
[15:25] <mwhudson> no
[15:38] <ronny> how would i go about invalidating a branch/repository instance in case the on-disk data got changed
[15:39] <mwhudson> ronny: if you don't read lock, the disk gets consulted each time (i think)
[15:40] <ronny> mwhudson: i did a push, and it didnt seem to change
[15:40] <LarstiQ> ronny: .lock_read,write() and .unlock()
[15:40] <awilkins> ronny: Was the push over a remote transport?
[15:41] <LarstiQ> awilkins: that would be a ondisk tree state you're thinking of, not the Branch/Repository objects in python?
[15:41] <awilkins> LarstiQ: Yes
[15:43] <LarstiQ> ronny: if I do in ipython; b.last_revision(); *push outside*; b.last_revision(), the two revisions are different
[15:43] <ronny> hmm, same process here
[15:44] <ronny> part of the unittests, using different instances to the same data
[15:44] <LarstiQ> are you sure you're  pushing to the underlying branch, not somewhere else?
[15:45] <LarstiQ> if you are, I'm out of ideas without seeing the code
[15:45] <ronny> LarstiQ: its the same branch i push to, but not the same branch instance
[15:45] <ronny> currentlyim in an iteration of adding some crap to anyvc
[15:45]  * LarstiQ nods
[15:46] <LarstiQ> I literally did: import bzrlib.branch; b = bzrlib.branch.Branch.open('/tmp/foo'); b.last_revision(); b.last_revision()
[15:47] <LarstiQ> and for the pushing, bzr branch /tmp/foo; cd foo; bzr ci -m 1 --unchanged; bzr push /tmp/foo
[15:47] <ronny> unittest is the default_head one in http://paste.pocoo.org/show/119370 and the bzr repo code is http://paste.pocoo.org/show/119374
[15:48] <LarstiQ> ah, but it doesn't invalidate if it didn't start at the null-revision, hmm
[15:49] <ronny> ignore the bad api, its still in the early iterations where i try to add stuff, and make simple tests work
[15:49] <ronny> it needs a good deal of more iterations
[15:52] <ronny> LarstiQ: so any idea what i can do?
[15:52] <LarstiQ> ronny: not yet, looking still
[16:00] <LarstiQ> ronny: some things seem to have changed since last I looked
[16:01] <ronny> hmm, darn
[16:03] <LarstiQ> GAH I'm stupid
[16:04]  * LarstiQ was checking the wrong branch
[16:04] <pygi> vila: sidney won't come I guess
[16:05] <LarstiQ> now that the universe works again like I think it does, back to looking at anyvc code
[16:05] <LarstiQ> ronny: the assert head.message=="test commit" fails?
[16:06] <vila> pygi: lokks like so, we should hunt him tomorrow :)
[16:06] <ronny> LarstiQ: no, after the push from the workdir it doesnt have new revision
[16:06] <pygi> vila: we have to be here tomorrow as well? xD
[16:06] <LarstiQ> ronny: wd.repository.push() ?
[16:07] <ronny> in my case workdir = separate branch
[16:07] <ronny> that push seems to work fine, but te repo wont get the change
[16:07] <LarstiQ> what is wd.repository.branch.get_parent() ?
[16:08] <ronny> hmm, ok, the push seems to fail
[16:11] <ronny> LarstiQ: hmm, a string, but somehow i failed to get a propper bool value for repository
[16:13] <igc> night all
[16:14] <LarstiQ> night ian
[16:16] <ronny> LarstiQ: so, the bzr test passes now
[16:16] <LarstiQ> ronny: yay :)
[16:22] <ronny> LarstiQ: i just did the same for hg and it took vastly less time to implement
[16:25] <LarstiQ> ronny: how much of that is because you already know hg better?
[16:26] <ronny> LarstiQ: hg lacks much indirection, so there is much less to figure
[16:26] <mwhudson> what does an exit code of 4 mean for bzr?
[16:26] <mwhudson> and is having this exit code at all a new thing?
[16:27] <ronny> brb
[16:31] <beuno> Peng_, thanks for the review
[16:32] <replicant> is the fastest repository format 1.9 ?
[16:32] <beuno> Peng_, what should I do with the serve-fix branches then?
[16:33] <james_w> mwhudson: EXIT_INTERNAL_ERROR = 4
[16:33] <mwhudson> ah
[16:33] <mwhudson> soooooooooooooooooommmmmmmmmmmething is breaaaaaaaaaaaaaaking
[16:33] <mwhudson> then
[16:33] <mwhudson> (i love integration tests)
[16:34] <james_w> maybe your keyboard?
[16:34] <mwhudson> heh
[16:34] <jml> :D
[16:34] <mwhudson> i also love testsuites that take multiple hours
[16:34] <jml> bzr defines constants for those things?
[16:34] <jml> We should heck of use those.
[16:34] <mwhudson> beuno: review the branch i guess :)
[16:35] <mwhudson> yeah
[16:35] <james_w> bzrlib.errors
[16:37] <jml> james_w: why aren't you in the bzr room with all of the cool people?
[16:38] <james_w> jml: I am in the etckeeper room with the extra cool bzr people
[16:38] <jml> ahh.
[16:38] <jml> good idea.
[16:38] <OllieR> is it possible to suppress the bzr ouput for comands like bzr add ?
[16:39] <james_w> bzr add -q
[16:39] <OllieR> james_w: ty
[16:39] <james_w> it won't be completely silent though
[16:41] <OllieR> better than nothing, just doing an add over ssh on a large branch takes far too long due to slow downloads of all the files
[16:49] <nadavoid> I'd like to use a command like "bzr push sftp://your.name@example.com/~/public_html/myproject"
[16:50] <nadavoid> My username at the sftp server has an @ or a % in it.  I can log in using either.
[16:50] <mwhudson> Peng: hello, please land that branch :)
[16:50] <Peng_> mwhudson: Which branch?
[16:50] <mwhudson> the one i just reviewed
[16:51] <nadavoid> I can successfully SFTP in using serveradmin@example.com and serveradmin%example.com.
[16:51]  * mwhudson is running out of battery and brain at fairly similar rates
[16:51] <nadavoid> But when I try bzr push with those usernames, I get access denied.
[16:51] <nadavoid> It's like the % gets converted to something else.
[16:52] <nadavoid> Any suggestions on what I can try? (so I can bzr push to an sftp server using a username that has a % in it.)
[16:52] <Peng_> mwhudson: Thanks for the review.
[16:52] <mwhudson> Peng_: np
[16:54] <Peng_> landed
[16:54] <Peng_> Will I bother to add NEWS? :P
[16:55] <mwhudson> ah yeah NEW
[16:55] <mwhudson> S
[16:56] <mwhudson> Peng_: can't you use url_to_local_path to detect local paths in https://code.edge.launchpad.net/~mnordhoff/loggerhead/dont-suggest-serving-remote-branches/+merge/6758
[16:57] <Peng_> Eh, I added NEWS.
[16:58] <Peng_> mwhudson: Yeah, I could. Like I wrote, I don't know the right way to do it, so I just picked what looked simplest.
[16:59] <mwhudson> it seems more principled somehow
[17:01] <Peng_> It bothers me a little because the local path isn't actually *needed*, so it'd just be generated and discarded.
[17:01] <mwhudson> yeah
[17:04]  * mwhudson approves the branch
[17:04] <mwhudson> Peng_: have you tested that https://code.edge.launchpad.net/~mnordhoff/loggerhead/dont-suggest-serving-remote-branches/+merge/6758 basically works?
[17:06] <Peng_> mwhudson: Yes. I don't know *why* setting served_url to None disables the suggestion, but it does. I'd test it again before landing it.
[17:06] <mwhudson> i added the served_url is None hides the suggestion thing
[17:06] <mwhudson> for launchpad
[17:07] <mwhudson> Peng_: actually
[17:07] <mwhudson> Peng_: i meant to ask about the transport registry branch :)
[17:07] <fullermd> nadavoid: Try urlencoding it.  @ = %40 I believe.
[17:08] <Peng_> mwhudson: Oooh. Yes.
[17:08] <nadavoid> fullermd: thanks. I'll try that.
[17:09]  * mwhudson reviews that one too
[17:09] <nadavoid> fullermd: would something like an escape character be needed? like \@ ?
[17:11]  * mwhudson vanishes in a puff of beer
[17:14] <Peng_> Cue Firefox crashing before I check LP again.
[17:19] <danigm> Hi all, I'm trying to setup a bzr server to use with bzr+ssh. I create a group bzr and all users that can create branchs are in that group. I have a directory /bzr with user root and group bzr. An user can create a branch in that dir but any other can write over it. How can I set up for group write permission?
[17:19] <LarstiQ> danigm: setgid, or what I prefer, setfacl
[17:20] <danigm> LarstiQ: and how can I do it? I try chmod 2770 to /bzr and all directory created had the same group, but not writable
[17:21] <LarstiQ> danigm: chmod g+s
[17:23] <danigm> LarstiQ: I have this, but new files isn't writable
[17:23] <danigm> by group
[17:24] <LarstiQ> danigm: then I advise to make use of posix acls
[17:26] <LarstiQ> danigm: `setfacl -m group:bzr:rwx  /srv/bzr` and `setfacl -m default:group:bzr:rwx /srv/bzr`
[17:26] <LarstiQ> danigm: is what I did
[17:29] <danigm> LarstiQ: ok, I'll try it
[17:29] <Peng_> mwhudson: Thanks for all of the reviews. :)
[17:39] <nadavoid> fullermd: urlencoding the @ as %40 in my username worked perfectly for me.
[17:39] <nadavoid> fullermd: thanks again.
[17:42] <LarstiQ> fullermd: could you file a bug on that?
[17:42] <LarstiQ> ehm
[17:42] <LarstiQ> s/fullermd/nadavoid/
[17:43] <nadavoid> LarstiQ: uh, sure. where?
[17:44] <LarstiQ> nadavoid: https://bugs.edge.launchpad.net/bzr/+filebug
[17:45] <nadavoid> LarstiQ: ok. I'll do that. Let ask a couple questions about what some valid sftp urls "should" be then...
[17:45] <nadavoid> This is obviously valid: sftp://your.name@example.com/~/public_html/myproject
[17:45] <LarstiQ> yes
[17:46] <nadavoid> This has an added %: sftp://your%name@example.com/~/public_html/myproject
[17:46] <nadavoid> And this has an added @: sftp://your@name@example.com/~/public_html/myproject
[17:47] <nadavoid> Should both of those last two work?
[17:48] <LarstiQ> I think the client should handle them better than it does now, wether they're valid sftp urls or not.
[17:48] <LarstiQ> vila: you might now better ^^?
[17:49] <nadavoid> I don't know better. ;) I'll go ahead and mention both, and let the bzr devs sort out how it should be handled.
[17:50]  * LarstiQ nods
[17:50] <vila> Well, aliasing ~ to user home directory is not really standard AFAIK, a single % is definitly not standard, it should be escaped as well as the @
[17:51] <vila> Now, there has been discussions about being a bit more tolerant as far as bzr is concerned,
[17:52] <vila> so we indeed support ~, I seem to remember a patch about better supporting the @ without forcing it to be escaped, but the % will still be a problem
[17:52] <nadavoid> vila: I'd be happy if that was mentioned in the getting started guide "If your username has an @ or a % in it, be sure to enter it escaped as %40 or %25."
[17:53] <vila> nadavoid: patches welcome :)
[17:54] <vila> nadavoid: there is also the question about whether we should include std66 in the documentation...
[17:54] <nadavoid> Looks like this is already being addressed as a "bug" https://bugs.edge.launchpad.net/bzr/+bug/215059
[17:56] <nadavoid> mentioning std66 might be good in the full documentation, but probably not in the 5-minute quickstart.
[17:57] <nadavoid> vila: How would I submit a patch for the 5-minute quickstart?
[17:57] <nadavoid> http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[17:59] <vila> nadavoid: search for the doc/en/mini-tutorial directory in the sources
[17:59] <nadavoid> ok.
[17:59] <danigm> which users use bzr serve?
[17:59] <LarstiQ> danigm: everyone using bzr+ssh://
[18:00] <nadavoid> vila: then I create a patch, and attach it to a bug report?
[18:02] <vila> nadavoid: we prefer merge proposals on launchpad.net, see doc/en/developers/HACKING.txt
[18:02] <LarstiQ> nadavoid: Preferably use Launchpad to suggest merging your branch, or use `bzr send` to send a merge directive to the mailing list.
[18:04] <nadavoid> OK. I might give that a try. Thanks for the suggestions.
[18:16] <danigm> with bzr serve anyone can write in my server, and with bzr+ssh I can share branchs because acl is too instrusive
[18:17] <LarstiQ> danigm: I'm not sure what you mean?
[18:19] <danigm> LarstiQ: I'm trying to launch bzr serve, but with that it not needded to put your user and password to create or modify a branch
[18:19] <danigm> I can create a branch without a user
[18:19] <danigm> And I don't want that
[18:20] <LarstiQ> danigm: if you run it standalone (ie, bzr://) and you supply --allow-writes, then yes, anyone can write branches
[18:21] <danigm> LarstiQ: It's possible to launch standalone with write support for only users?
[18:22] <LarstiQ> danigm: you could have a look at http://projects.serverzen.com/pm/p/cluemapper/wiki/ClueBzrServer
[18:32] <danigm> LarstiQ: finally I use acl and it works
[18:34] <LarstiQ> danigm: glad to hear
[19:36] <axxman> Has anyone had trouble getting apache to allow access to the .bzr/branches/format file? It seems to just be unwilling to show any file named "format" for some reason...
[21:04] <ronny> sup
[21:05] <ronny> Guest12468: jelmer: is there any eta for when dulwich can read git status information? im kinda pissed off cause i need 3 subprocess calls
[21:06] <ronny> (wd, inex and tree=
[21:06] <jelmer> ronny, So, "git status" is a bit ambiguous. I'm likely to implement whatever bzr-git needs soon, what is the data that you need exactly?
[21:07] <jelmer> ronny, Whatever bzr-git needs to yield the results required for "bzr status" that is
[21:09] <ronny> jelmer: so it will be semilar to iter_changes from bzr branches?
[21:10] <jelmer> ronny: Not similar, it'll be something that makes sense in the git model
[21:10] <jelmer> but what I will put in is driven by bzr-git, basically
[21:10] <ronny> jelmer: the index is a huge pain
[21:11] <ronny> at least dulwich is really great for dealing with the history
[21:12] <ronny> jelmer: is writing objects already in somewhere, my very light skimming of the api didnt reveal something like that
[21:12] <jelmer> ronny: Is there any chance I could get you to describe the API of the function you're looking for?
[21:12] <jelmer> ronny, That way I can make sure whatever I'll implement is sufficient for what you need
[21:13] <ronny> jelmer: im in early stages of evolving how i get metadata access in anyvc
[21:14] <jelmer> ronny, dulwich can write new commits, based on an index object and an object store
[21:14] <ronny> jelmer: so no entirely in memory commit builder yet?
[21:15] <ronny> jelmer: anyway, my needs for workdir states is partially collected in http://bitbucket.org/RonnyPfannschmidt/anyvc/src/tip/anyvc/metadata.py
[21:15] <jelmer> ronny, (an object store being one of the parts of a repository)
[21:15] <ronny> there is some other crap in i tought that would be usefull (but i was wrong)
[21:15] <jelmer> ronny: In memory commit building is possible
[21:16] <ronny> im not entirely sure if a single string is enough tho
[21:17] <ronny> jelmer: my current translation of bzr workdir states is kinda messy tho
[21:18] <ronny> http://bitbucket.org/RonnyPfannschmidt/anyvc/src/tip/anyvc/workdir/bzr.py#cl-54 screams fragile
[21:19] <ronny> if anyone wants to review/give hints - please now ;P
[21:19] <mwhudson> jelmer: hello
[21:20] <mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/live-helper/trunk <- failing git import
[21:20] <jelmer> mwhudson: hey
[21:20] <mwhudson> jelmer: https://code.edge.launchpad.net/~vcs-imports/vlc/master <- initial import succeeded, update filed
[21:20] <mwhudson> failed
[21:20] <jelmer> mwhudson, If I recall correctly the first I fixed recently in bzr-git
[21:21] <mwhudson> jelmer: ok
[21:21] <jelmer> it's an issue that occurs when there are directories that are turned into files or the other way around
[21:21] <Peng_> jelmer: Oh hi. You misuse lstrip in a couple places in bzr-svn. "food".lstrip("of") -> "d", but you're trying to use it to strip off "of" exactly.
[21:21] <mwhudson> ah right, that would explain the error a bit
[21:21] <jelmer> Peng_, Ah, darn
[21:21] <jelmer> Peng_, Thanks
[21:22] <emmajane> jelmer, did evn track you down today?
[21:22] <jelmer> mwhudson, Do you know whether the original vlc import gave any warnings about incorrect modes/commit messages with funny characters?
[21:22] <jelmer> emmajane: I'm not sure actually, do you know what his fullname is?
[21:23] <emmajane> jelmer, it was in IRC last night. Question about git/bzr integration and a foreign something not being found.
[21:23] <mwhudson> jelmer: http://launchpadlibrarian.net/27212948/vlc-master-log.txt <- doesn't look like it, not 110% sure warnings would show up there
[21:23] <Peng_> jelmer: fwiw, all uses of rstrip and strip are okay.
[21:23] <mwhudson> jelmer: but yeah it looks like that issue
[21:23] <emmajane> jelmer, they were trying to follow: http://bazaar-vcs.org/BzrForeignBranches/Git/Server but running into problems.
[21:23] <mwhudson> jelmer: given that it's vlc, i bet it's commiter names or something
[21:23] <mwhudson> (lots of french people)
[21:24] <jelmer> Did you just say that French people cause import errors?
[21:24] <mwhudson> well
[21:25] <jelmer> emmajane: No, in that case I haven't talked to them
[21:25] <mwhudson> they have funny foreign mucky characters in their names
[21:25] <jelmer> emmajane: Are they here at UDS, do you know?
[21:25] <emmajane> jelmer, Not as far as I know.
[21:25] <emmajane> jelmer, it was a question in IRC last night.
[21:26] <jelmer> emmajane: Ah, sorry
[21:28] <jelmer> mwhudson, Is that log basically whatever ends up in .bzr.log ? If so, warnings should be in there
[21:28] <emmajane> jelmer, If they're back tonight in my time zone (North America) is there a specific branch I should point them at to make those instructions work?
[21:28] <mwhudson> jelmer: it's the stderr, with a somewhat customized uifactory
[21:30] <jelmer> emmajane: I fixed up the server side implementation yesterday, so unfortunately it'll only work with bzr-git trunk, dulwich trunk and bzr.dev
[21:30] <jelmer> emmajane: With those three branches, it should be a matter of running "bzr serve --git"
[21:30] <emmajane> ok
[21:31] <emmajane> jelmer, if I updated that wiki page to list those three branches could you take a look and make sure what i wrote is true?
[21:32] <jelmer> emmajane: the BzrForeignBranches/Git/Server one ?
[21:32] <emmajane> yeah
[21:33] <jelmer> emmajane, I don't see any changes there
[21:33]  * emmajane grins. *if* I haven't done them yet.
[21:33] <emmajane> I just opened the edit page. ;)
[21:34] <jelmer> Argh
[21:34] <jelmer> Sorry, my brain is half-asleep :-)
[21:34] <emmajane> assok.
[21:34] <emmajane> half a sec and I'll get them written up.
[21:37] <emmajane> https://code.edge.launchpad.net/~bzr/bzr-git/trunk <--- that's the plugin, right?
[21:38] <jelmer> emmajane, yep
[21:38] <emmajane> I'm just trying to figure out what the URLs are for those bzr-git trunk, dulwichi trunk and bzr.dev
[21:39] <jelmer> emmajane: Dulwich is at http://people.samba.org/bzr/jelmer/dulwich/trunk, bzr.dev is at http://bazaar-vcs.org/bzr/bzr.dev
[21:40] <emmajane> thanks.
[21:40] <emmajane> http://bazaar-vcs.org/BzrForeignBranches/Git/Server
[21:40] <emmajane> updated.
[21:42] <emmajane> diff here: http://bazaar-vcs.org/BzrForeignBranches/Git/Server?action=diff&rev2=11&rev1=9
[21:42] <jelmer> emmajane, Thanks, that looks good
[21:43] <emmajane> \o/
[21:44] <emmajane> jelmer, I'm amazed you're still awake after the brain fry of UDS. :)
[21:46] <jelmer> emmajane, Only half :-) But yeah, UDS is quite intense.
[21:46] <jelmer> I wonder how the Canonical folks deal with 2 weeks of this :-)
[21:46] <emmajane> jelmer, they're the ones who are already asleep. ;)
[21:50] <mwhudson> jelmer: badly
[22:33] <ronny> jelmer: i think the state for git can only be expressed in some kind of tuple, cause the index gets in the way
[22:33] <jelmer> evn, hi
[22:33] <evn> oh hey
[22:33] <jseabold> Hello all, I am relatively new to DVCS and bzr and was wondering if someone might help me out.
[22:33] <jseabold> I have a working directory that has a different push branch, parent branch, and submit branch.
[22:33] <jseabold> The push branch is my branch (which I just pushed to from another computer), how do I update the working directory on my other computer with these changes?
[22:33] <jelmer> evn, emmajane mentioned you were trying to set up bzr-git serve the other day?
[22:33] <jseabold> bzr update told me I was at the newest revision.
[22:34] <evn> yeah...it can't find the 'foreign' module
[22:34] <emmajane> jelmer, thanks :)
[22:34] <emmajane> jelmer, you rock!
[22:35] <evn> jelmer: http://pastie.org/491990
[22:35] <mwhudson> evn: you need a newer bzr, i bet
[22:35] <jelmer> evn: In order to run the server you need the latest development versions of bzr/bzr-git/dulwich
[22:35] <jelmer> evn: see also http://bazaar-vcs.org/BzrForeignBranches/Git/Server
[22:37] <evn> i installed dulwich
[22:37] <evn> oh that page looks changed
[22:37] <evn> at least from what i saw yesterday
[22:37] <evn> i will try it
[23:08] <bob2> jseabold: if the push was successful, 'bzr up' should update the working copy
[23:14] <yacoob> hello there.
[23:14] <yacoob> If I say "bzr ignore '*.pyc'", how come "bzr add *" is still adding those?
[23:17] <maxb> yacoob: Probably because your shell expands * into an explicit list of files, so it looks to bzr as if you're explicitly telling it to
[23:18] <mneptok> yacoob: don't quote *
[23:19] <mneptok> bzr ignore *.pyc
[23:20] <fullermd> No, you probably want to quote it...
[23:20] <yacoob> mneptok, no, that's not what I want. I want to ignore ALL .pyc files, and if I don't quote it, shell will expand it and add only specific files
[23:21] <yacoob> maxb, so explicit bzr add doesn't follow ignore rules? ok.
[23:21] <yacoob> (they disappeared from bzr status... so that's a good sign :)
[23:33] <Peng_> yacoob: That's correct. Explicitly adding things overrides ignore rules.