[00:00] <DaffyDuck_> I would like to be able to specify the permissions for the repository files in branch.conf (or some repository configuration file), and that bzr always makes sure that files have the appropriate permissions.
[00:00] <ronny> hmm, i have to make bzr a second-class thing in anyvc
[00:01] <lifeless> ronny: why?
[00:03] <ronny> lifeless: bzr is one of the 2 vcs's that think in terms of free form fs branches, basically everything else has repos that have branches
[00:04] <lifeless> the other being hg? or darcs?
[00:04] <ronny> darcs
[00:04] <lifeless> what about codeville?
[00:04] <ronny> didnt get a chacne to work with that one so far
[00:05] <lifeless> hg encourages free for fs branches too, its why they make local cloning hardlink - they expect it to be used a lot
[00:05] <lifeless> [and they don't support merged-branches in a single repo]
[00:05] <ronny> lifeless: each of those is a full repo which may have multiple branches
[00:05] <lifeless> ronny: not in the sense of a git or bzr branch
[00:05] <lifeless> a branch in hg must have outstanding commits
[00:06] <lifeless> its always semantic, never symbolic
[00:06] <ronny> lifeless: hg's "fs branches" are full repos each with full decupling of network ops and merge ops
[00:06] <ronny> what do you mean by outstanding commits?
[00:07] <lifeless> a fork in the revision graph
[00:07] <ronny> thats named branches
[00:08] <ronny> i think they are more comparable to more explicitly used branch nicks than bzr branches
[00:11] <ronny> my main gripe is the hiding of what is actually network operations, and what is local history operations
[00:12] <ronny> in hg/git i do a pull, then merge, done, in bzr i say merge, and then it might end up doing network ops or not
[00:18] <fullermd> DaffyDuck_: I used multi-local-accessed branches, and I haven't seen permissions get eaten in them.
[00:20] <thumper> ronny: funny, in bzr I do, pull, then merge, done...
[00:21] <lifeless> also, in git, you can have a single command update a branch, if its been configured that way
[00:22] <ronny> thumper: but usually not within the same workdir
[00:22] <lifeless> so, we want to make working with many branches substantially better
[00:23] <lifeless> if you can identify things that have made your experiences doing that with different vcs's dramatically different, that would be good info to have.
[00:25] <thumper> ronny: no, I have a script alias that pulls in my trunk branches
[00:29] <ronny> lifeless: i think what throws me off most the emphasis on different kinds of transparency i perceive, in bzr one can do kinda whatever, and it will just work, no matter the cost, while in others stuff just wont work if its inefficient
[00:31] <Tfnrsh> hey there which version of python needed for bzr ?
[00:31] <Tfnrsh> notify n gtk doesnt work for me py2.6
[00:35] <lifeless> Tfnrsh: it should work in 2.6; could you file a bug?
[00:37] <Tfnrsh> incompatible API
[00:37] <lifeless> Tfnrsh: it reports that as an error>?
[00:37] <Tfnrsh> yes
[00:38] <lifeless> that means your bzr and your bzr-gtk are not matching versions
[00:38] <lifeless> nothing to do with your python version
[00:38] <lvh> hi
[00:38] <lifeless> hi
[00:38] <lvh> big correlation between #bzr and #twisted again :-)
[00:38] <Tfnrsh> oh okay thanks
[00:40] <ronny> ok, time for me to play with commit building
[00:41] <lvh> ronny: I thought you had mercurial poisoning
[00:41] <ronny> lvh: well, for me it means making an api that works for hg, git, bzr and svn
[00:42] <lvh> ronny: em, I'm doing the same thing. Is your code up somewhere?
[00:42] <lvh> well, not svn. but hg git and bzr :-)
[00:43] <ronny> http://bitbucket.org/RonnyPfannschmidt/anyvc/, not yet history sipport
[00:43] <ronny> i"ll start writing more tests dor history ops now, then make em pass for hg, git and bzr
[00:45] <lvh> ronny: I wrote something that bumps versions for apps automagically, based on repository status, so a universal VCS API is useful for that :-)
[00:46] <ronny> lvh: i also hooked up with the roundup guys, the piano-man/pyvcs guys and the nautilus-vcs guys
[00:46] <lifeless> ronny: for commits, 'tree.comm()' is the primary external interface
[00:46] <lifeless> thats tree.commit
[00:47] <lvh> ronny: I didn't like hg's internals very much.
[00:47] <lvh> ronny: Cool. What are you doing with the roundup guys?
[00:47] <lvh> ronny: Also how is what you're doing different from pyvcses project?
[00:48] <Tfnrsh> hey there sorry to bother again but maybe u can take a look http://paste.arneburk.de/bzr_error.log
[00:48] <lvh> wait, nvm, pyvcs isnt what I thought it was
[00:48] <ronny> lvh: i'll do history building
[00:49] <ronny> lvh: and i do massively test-driven development
[00:50] <lvh> ronny: Cool. I found that to be hard when writing software that queries VCSes. Testing software that is entirely dependant on external state sucks :-D
[00:51] <lvh> ronny: What I need is something that given a file in a repository, finds the repository (shouldn't be so hard, recursively peeking up the tree) and then finds some state about it, like tags, branches, commit mesage, etc -- and based on that, create a version.
[00:52] <ronny> lvh: get me more hint, and you should have an api at the end of the week
[00:53] <ronny> i'll start with commit building, then continue with historz reading
[00:53] <lvh> ronny: hint?
[00:53] <lvh> are you asking me for drugs? :-p
[00:53] <lifeless> Tfnrsh: you need a newer bzr-gtk
[00:53] <ronny> just more data on what exactly you will do
[00:54] <lvh> ronny: okay, so. You have generic repository objects. How do you create them?
[00:54] <lvh> Root path for a repo? or is any path below a repo fine?
[00:55] <ronny> i try not to be smart about repo paths (i try to be smart about workdir paths)
[00:56] <lvh> okay, that probably makes sense given 90% of your use cases.
[00:56] <ronny> well, give me use-cases or give me tests :P
[00:57] <lvh> ronny: well, 'finding a repository that likely manages this file' is one of my use cases
[00:58] <lvh> which is sort of easy, I can do that myself and even add it to your project if you like. Just recursively peek up the tree for things like .git, .svn...
[00:58] <lvh> all I really need is a sane api (preferably like a property) for branch, commitmessage, tag, things like that.
[00:58] <lvh> I suppose it might be a problem that not all DVCSes agree on what the fundamental unit of a repo is.
[01:01] <lvh> ronny: the reason i dont really care about cwd cleverness is because im much more likely to import your modules than to run your binaries.
[01:01] <ronny> lvh: i trz to get away from invoking the tools
[01:02] <lvh> okay, cool.
[01:02] <ronny> *try
[01:02] <ronny> need to do that for svn and git at some point
[01:02] <lvh> also, it would be totally awesome if there was a more or less uniform interface for similar things, like HEAD vs tip, master vs default, etc.
[01:03] <ronny> lvh: i'll try to work that
[01:03] <lvh> unfortunately you're bound to pick a name, and then dvcs users who use a vcs different than the one that shares the names you pick will hate you.
[01:03] <ronny> lvh: thats whz i will choose one everzone will hate equally
[01:04] <ronny> get_default_master_head_tip_gtfo()
[01:04] <lvh> ronny: typing on us qwerty?
[01:04] <lvh> ronny: poor germans :-(
[01:05] <lvh> ronny: or on qwertz and used to qwerty? :D
[01:05] <ronny> lvh: yes, got a new keyboard shipped
[01:05] <lvh> ronny: im learning dvorak, dont feel bad
[01:05] <ronny> im used to qwertz, now i got a qwerty
[01:05] <ronny> my old one for the laptop broke, and dell agreed to ship a us one
[01:06] <lvh> ronny: ibm <3
[01:07] <ronny> lvh: ibm for laptops is gone, and i dont like lenovo (subjective reasoning)
[01:07] <lvh> ronny: I'm typing this from an X301
[01:07] <lvh> it's not as good as my old thinkpad, no
[01:08] <lvh> but it's still better than 90% of the shitty laptops out there
[01:09] <ronny> lvh: mz m1330 is pretty decent
[01:09] <ronny> lvh: btw, i"ll implement the same apis as the guy thats working on the new fs api pep
[01:10] <ronny> so revisions will be like a readonly fs and commit building will be like an transaction in a writable fs
[01:11] <lvh> ronny: that sounds really cool!
[01:11] <lvh> although for now im mostly interested in inspection rather than mutation
[01:12] <lvh> since having applications decide when versions are done is icky
[01:12] <lvh> and that should be done based on passing unit tests, not repo status
[01:16] <ronny> i could use such a thing to manage my release cycles later
[01:16] <ronny> vellum, anyvc, pida, a set of pida plugins, some wsgi apps - release-management is a pain
[01:20] <lvh> ronny: yes. I'd like to make something that makes it easier
[01:21] <lvh> versioning is a part of that of course, but it would be nice if we could integrate it with unit testing and perhaps ticketing systems.
[01:22] <lvh> however that would need an abstracted method of talking to ticketing systems, an abstracted method of talking to vcses (you're working on that apparetnly) and an abstracted way of running tests
[01:22] <lvh> and importantly checking if they fail
[01:22] <lvh> sooo, five perfect engineering motnhs :p
[01:23] <lifeless> lvh: subunit
[01:23] <lvh> also ,what's vellum? the only thing i can find is a weblog
[01:24] <ronny> lvh: task based build system, in need of some love tho
[01:26] <ronny> lvh: for an abstract way to run tests, count me in
[01:26] <lvh> lifeless: hm, maybe -- but how does that keep working when you meet something like hkr's wonderful py.test, or nosetests, which don't enforce the TestCase hierarchy at all?
[01:26] <ronny> i want way more metadata than subunit provides in a structured way tho
[01:27] <ronny> lvh: nose builds on unittest
[01:27] <lvh> ronny: yes, but py.test doesn't have to look like xUnit at all
[01:27] <ronny> lvh: py.test is what i use
[01:27] <lvh> ronny: yes, but you can write functional py.test like tetss in nose.
[01:27] <ronny> lvh: nose simply wraps it up in testcase instances
[01:27] <lvh> In fact if you dont need a setUp method (and ive had this once) the same module runs fine in both nose and py.test
[01:28] <ronny> lvh: i did some aliasing and default parameter tricks to get it work in both with setup <P
[01:28] <ronny> but by now i prefer pz.test
[01:29] <lvh> ronny: yeah, I like py.test too
[01:29] <lvh> but im afraid subunit doesnt
[01:30] <ronny> subunit only provides a subset
[01:30] <ronny> i"ll probablz use py.test as base and write a subunit consumer when i see fit later
[01:31] <lvh> cosnumer in what context?
[01:31] <lvh> maybe im too used to amqp
[01:31] <lvh> but I'd expect a producer
[01:32] <ronny> lvh: well, i want py.test to be the master running other stuff
[01:33] <lifeless> lvh: subunit doesn't care; just need an outputter for that format
[01:33] <ronny> lvh: so it consumes the result streams by others
[01:33] <lvh> oh, I see.
[01:33] <Tfnrsh> where to get a newer bzr-gtk just isntalled it from bzrs ppa
[01:34] <Tfnrsh> at least i think so
[01:34] <Tfnrsh> :D
[01:34] <ronny> i dislike subunits text format tho
[01:34] <lvh> ronny: so basically I see my project having a number (usually two) kinds of version numbers: releases, and nightlies.
[01:34] <ronny> imho it should be pipable into a shell
[01:34] <ofv> Hi. I have a very estrange problem with svn-import.
[01:35] <lvh> nightlies happen on trunk, or master, or default or whatever your vcs calls it
[01:35] <lifeless> ronny: perhaps bring it up on the subunit list, or file a bug? I pipe subunit around /all the time/
[01:35] <ofv> it "imports" revisions that does not exist on the svn server...
[01:35] <ronny> lifeless: doesnt make it valid shell code
[01:35] <ofv> ... but that existed on a test svn repo that i deleted time ago.
[01:35] <lvh> ronny: releases find the current release (im not sure how to do that -- do all vcses support something that looks like a tag?) and then increments it by one.
[01:35] <lifeless> ronny: I think I don't understand what you're assking fo then
[01:36] <ofv> the test repo was on the local machine. the real repo is on another machine.
[01:36] <lvh> ronny: the biggest problem is figuring out a system for decidng what kind of version we want that's simple enough to actually use and complex enough to support peoples weird versioning fetishes
[01:37] <ronny> lifeless: the subunit text format is not executable as shell code (given a few functions/executables are provided)
[01:37] <lifeless> ronny: yes, I get that it isn't; but I'm not sure why that would be desirable
[01:38] <lifeless> subunit does provide shell functions to output subunit
[01:38] <Tfnrsh> well ok subversion then again :/
[01:38]  * SamB renames bug 393349 such that "send" occurs in the title
[01:40] <ronny> lifeless: simply cause its a text format that existed before, and allows to write dead-stupid reporters bz just creating aliases and then running the reports in their context
[01:42] <ofv> found the problem. as the test repo was a copy of the real one, it had the same ID.
[01:43] <lifeless> ronny: I must be lost; I created subunit, it didn't exist before ;). And making subunit output shell scripts would still be escapable by bad output, unless the output has to be escaped.
[01:44] <ofv> svn-import remembered the location of the test repo(s) and imported from them insted of the real one. it imported from another test repo.
[01:45] <jelmer____> ofv, svn-import will only import from the repository with the location you tell it to import from
[01:45] <jelmer____> ofv, it won't try to open any repositories that it has imported from earlier, but it may cache data from repositories it has opened earlier
[01:46] <ofv> jelmer____: it had this on subversion.conf:
[01:46] <lvh> laptop nearly out of power, bye!
[01:46] <jelmer____> ofv, it does remember those locations, but they are not used for anything at the moment
[01:47] <ofv> locations = svn://qcore/tkidb;svn://localhost/repos/tkidb;file:///d:/repos/tkidb
[01:47] <jelmer____> ofv, you should never have multiple svn repositories with the same uuid but different contents - it violates svn's basic model
[01:48] <ofv> jelmer____: yeah, i know. it was a test. but bzr insists on remembering the test repo.
[01:48] <jelmer____> ofv: You might want to remove bzr's cache
[01:49] <jelmer____> ofv, or disable caching entirely - see the FAQ for details
[01:49] <ofv> jelmer____: where is it?
[01:49] <ofv> jelmer____: okay
[01:49] <ofv> the cache is new news for me. i'm a total beginner.
[01:49] <jelmer____> ofv, the cache would be in ~/.bazaar/svn-cache/<uuid> or ~/.cache/bzr/svn/<uuid>
[01:49] <jelmer____> ofv, the cache is not something you would normally have to bother with
[01:50] <ofv> i'm trying to find it. i'm working on windows.
[01:50] <jelmer____> ofv, you'd also want to throw away any bzr repositories created from the test svn repository
[01:50] <lifeless> ronny: its an interesting idea to make the output be function calls in shell, but it could be function calls in ocaml, or python equally.
[01:51] <ofv> jelmer____: already did that. this seems a nightmare: revisions coming from deleted repos! :)
[01:51] <ronny> lifeless: but shell is a universal standard interfacce on unix/posix, the rest not
[01:54] <ofv> jelmer____: the faq link on http://bazaar-vcs.org/BzrForeignBranches/Subversion points to a non-existent page.
[01:54] <jelmer____> ofv, I've fixed it to refer to the included FAQ with bzr-svn itself.
[02:01] <ofv> jelmer____: fixed the problem. thanks for your help and for bzr-svn. it's great stuff.
[02:01] <jelmer____> ofv, cool
[02:01] <jelmer____> 'night all
[02:04] <lifeless> ronny: C is also a standard :)
[02:04] <ronny> lifeless: but not for on the fly execution
[02:05] <lifeless> thats true.
[02:05] <lifeless> I'm not getting why this is an important thing for the streaming serialisation format though
[02:07] <ronny> lifeless: curently subunit is neither absilutelz stupidlz simple to parse, nor usalbe in neat powerfull hacks
[02:07] <ronny> my typo rate is approaching the enforce sleep marker
[02:07] <ronny> night
[02:11] <lifeless> gnight
[03:19]  * SamB wonders why the heck https://code.launchpad.net/~naesten/bzr/merge-1 doesn't contain anything from him at the tip ...
[03:20] <spiv> SamB: what's your local revno?
[03:21] <SamB> spiv: well, I think it came from a merge directive I sent in ...
[03:21] <SamB> somehow!
[03:24] <SamB> this one: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=7561#a7561
[03:24] <SamB> or raw at http://hpaste.org/fastcgi/hpaste.fcgi/raw?id=7561
[03:26] <SamB> leastwise, *I* never pushed it!
[03:27] <SamB> spiv: any ideas?
[03:43]  * SamB decides to report this against launchpad-code
[03:54] <spiv> SamB: yeah, file it against launchpad-code, provide the raw text of the email in the report I guess
[03:55] <spiv> SamB: a quick peek at the bundle suggests it does have your revision in it (as you'd expect)
[03:55] <SamB> spiv: I attached it
[04:01] <SamB> jelmer: you know, when you package a bzr release, you should check to see if any of the Debian bugs filed against it can be closed ;-)
[04:02] <SamB> for instance, bug #339385 was imported from Debian and you forgot to close it in the changelog entry for bzr 1.17-1 ...
[04:03] <SamB> I have, however, marked it fixed using bts(1)
[04:03] <SamB> so that it shows up as fixed in 1.17-1
[04:03] <SamB> as you can see at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=517770
[04:04] <SamB> wonder why ubottu had it cached -- or is it using launchpad's out-of-date info?
[04:08] <lifeless> ubottu only asks ubuntu
[04:08] <lifeless> sorry, launchpad
[04:09] <rellis> I am trying to use the xmloutput plugin 0.8.4 with bzr 1.16.1 and I am missing the "affected-files" tag.
[04:10] <rellis> Could this be a result of migrating from svn -> git -> bzr ?
[04:10] <rellis> but then i figure i have new ocmmits since them igration.. and they'rem issing hte tag(s) as well
[04:12] <SamB> lifeless: ah, that would do it
[04:12] <SamB> apparantly launchpad has had trouble updating that debbug's status :-(
[04:14] <lifeless> SamB: file a question in such cases on launchpad itself
[04:16] <SamB> lifeless: I was just going to assume it was transient for the moment
[04:16] <SamB> I'll come back to it if it's still stuck at the top of my bugs page next time I look at it
[04:21] <SamB> right now, I'm going to file a bug against launchpad for flattening the email I attached to https://bugs.launchpad.net/launchpad-code/+bug/405111 when I submitted by email into the report itself
[04:21] <rellis> ah i was missing the -v switch, fail
[07:00] <lifeless> spiv: if you're in a reviewing mood, 9307 please
[07:36] <lifeless> EODing
[07:51] <savvas0> hi, a newbie question: are the bzr commits signed with gpg? I just noticed the sign-my-commits command and was wondering :)
[07:51] <savvas0> I mean, if I bzr commit, aren't the commits signed automatically?
[07:52] <beuno> savvas0, no, you need to explictely sign them
[07:55] <savvas0> thanks beuno! is there a command that checks which commits are signed?
[07:58] <savvas0> ah.. there's --dry-run :)
[08:00] <beuno> :)
[08:01] <rellis_> is there a way to get bzr to tell me what changes exist in the branch source?
[08:01] <rellis_> like xmllog but just the changes sine my last update
[08:01] <bob2> bzr missing
[08:03] <rellis_> cool, thanks
[08:05] <rellis_> anyway to get that as xml instead of the normal format?
[08:05] <bob2> no idea
[08:05] <rellis_> fair enough
[08:07] <beuno> rellis_, you should be able with the xml-output plugin
[08:07] <beuno> bzr missing --xml
[08:11] <rellis_> indeed
[08:11] <rellis_> thanks
[08:22] <stefanlsd> I keep trying to understand this but somehow fail - whats the difference in idiot terms between bzr init and bzr init repo
[08:23] <bob2> init converts a dir to a branch
[08:23] <bob2> init-repo converts a dir to a repository
[08:23] <bob2> a repository has dirs in it, and they can contain branches (created with bzr init), but the actual revision data is stored in the repo root
[08:24] <bob2> so, if you have branches that share a lot of revisions, a repository can save some disk and time
[08:33] <stefanlsd> bob2: ok. thanks. that helps somewhat.   So if I understand it, in my case, i have a whole bunch of different projects non related to each other. So it would be better just using bzr init.
[08:35] <bob2> you can go back and forth, but that would be simplest
[08:36] <stefanlsd> bob2: great. thanks. If i start a project that will have multiple branches related to the same project, i will init repo. thanks. makes sense :)
[08:38] <mwhudson> jelmer: hi, i think you upgraded a bunch of branches launchpad mirrors to 2a format
[08:38] <jelmer> mwhudson, yeah
[08:39] <mwhudson> hm
[08:39] <mwhudson> i was thinking that in some cases the dev focus branch was a hosted branch launchpad and still in 1.9 format
[08:39] <mwhudson> and things had broken
[08:39] <mwhudson> but now i'm not sure what's going on...
[08:40] <jelmer> mwhudson: does the dev focus matter unless they're stacked branches?
[08:44] <ronny> moin
[08:44] <mwhudson> jelmer: all mirrored branches are stacked on the dev focus
[08:45] <ronny> can anzone point a lazy guy to a documentation on building in-memory commits with the api?
[08:45] <jelmer> mwhudson, that would certainly explain the breakage since 2a doesn't stack on 1.9 :-)
[08:45] <abhilashm86> i'm using ubuntu, i've installed bzr, do i have to create workspace,project files in /home/user or which is better?? bzr is installed in /usr/bin/bzr......
[08:45] <mwhudson> right
[08:45] <abhilashm86> i need to work in distributed CVS........
[08:45] <mwhudson> i don't understand why https://code.edge.launchpad.net/~jelmer/bzr-svn/inventory is failing though
[08:46]  * mwhudson will have to poke more tomorrow
[11:50] <llml> hi, could anyone please help me figure out how to know at which revision the trunk has been most lately merged into certain branch as an up to date merge?
[11:54] <luks> bzr qlog /path/to/trunk /path/to/a/feature/branch ?
[11:56] <llml> luks: i guess qlog is not available in bzr 13.1?
[11:56] <luks> qlog is from the qbzr plugin
[11:56] <luks> it's the easiest way I can think of
[11:57] <luks> but you can use bzr log on the feature branch, remember the revision and then look for the revision number in bzr log on trunk
[11:57] <llml> luks: you mean check the log content?
[11:57] <luks> yes
[11:58] <james_w> bzr missing will show you what hasn't been merged, and then you can infer what has from that
[11:58] <james_w> then "bzr log --show-ids" can help you identify when the merge was done
[11:58] <luks> it kind of tricky to tell the last merge point from a list of "missing" revisions
[11:59] <llml> james_w: against where it's pulled out from?
[11:59] <luks> since it's a graph
[12:04] <llml> james_w, luks: i love this trick. thanks:)
[12:24] <abhilashm86> i have a file in /home/abhilash/mypro/subdirectory, so if i want to push it to my account, its not working,  bzr push bzr+ssh://abhilashm86@gmail.com/~abhilashm86/+junk/mypro
[12:24] <abhilashm86> what is wrong with above command
[12:24] <abhilashm86> i'm using launchpad
[12:26] <awilkins> You're pushing to your email address?
[12:26] <abhilashm86> awilkins: its my launchpad login account
[12:27] <awilkins> How is it supposed to guess that you are pushing to launchpad when you're telling it to push to the gmail server?
[12:27] <abhilashm86> i made a branch called airline, i want to push a file into my launchpad account.....how to do it
[12:27] <ronny> lifeless: aware of any simple api-examples for building commits in memory?
[12:28] <abhilashm86> awilkins: i followed a tutorial, there it showed, if i gave abhilashm86.launchpad.net, there was an error.....
[12:28] <abhilashm86> http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html, this is the tutorial
[12:28] <awilkins> abhilashm86: https://help.launchpad.net/Code/UploadingABranch
[12:29] <abhilashm86> awilkins: https://code.launchpad.net/~abhilashm86/+junk/airplane, this is my account in launchpad
[12:29] <abhilashm86> awilkins: ok i'll try this.........
[12:29] <awilkins> abhilashm86: The first link you posted had your email address where the server should be
[12:31] <abhilashm86> awilkins: oh ok, through command line, i logged into launchpad, so i thought it was right:) no problem i'll see your link, fine.......
[13:05] <spiv> abhilashm86: "bzr+ssh://abhilash@gmail.com/..." tells bzr to connect to gmail.com via ssh
[13:05] <spiv> abhilashm86: which is not what you want :)
[13:06] <spiv> abhilashm86: in that URL, the part like "xxx@yyy" is not an email address, it's a username (xxx) and a hostname (yyy).
[13:12] <ronny> LarstiQ: got any howto on building bzr commits from only the api
[14:21] <ronny> can anyone plase point me to some kind of description on how to build a commit in a branch using only the api
[14:22] <Tak> builtins.py?
[14:33] <ronny> Tak: nop, thats not it, i dont want to commit a workingtree, i want to commit something generated entirelz in memorz
[14:33] <ronny> *y
[15:14] <abentley> ronny: Use TreeTransform.commit, which is new.
[16:24] <l1m5> does anyone know why i can no longer do 'bzr viz' in version 1.13.1?
[16:25] <ronny> re
[16:26] <ronny> abentley: uh, treetransform looks like it affects the workingtree, am i missinterpreting?
[16:26] <l1m5> i used to be able to do bzr viz or bzr vis and get the visual representaton
[16:26] <abentley> ronny: The TransformPreview variant does not.
[16:27] <awilkins> l1m5: Have you got the bzr-gtk plugin installed?
[16:28] <awilkins> l1m5: You may also wish to try qbzr (qlog command)
[16:29] <jam> morning all
[16:29] <ronny> abentley: i want something that doesnt affect the workingtree in any way ever, i want to operate directly on the repo
[16:29] <jam> abentley: I have a question about something that is happening in the bundle code, if you have a couple seconds to chat
[16:29] <jam> shouldn't take long
[16:29] <jam> and the answer may be "I don't remember"
[16:29] <abentley> ronny: The TransformPreview doesn't affect the workingtree in any way ever.
[16:30] <abentley> jam: Shoot.
[16:30] <l1m5> awilkins, ah, that's what i needed
[16:30] <l1m5> the gtk plugin
[16:30] <ronny> ok
[16:30] <jam> abentley: in bzrlib.bundle.serializer.v4.BundleWriteOperation.write_revisions
[16:30] <jam> you have the line:
[16:30] <jam> (s)
[16:30] <jam>         if self.target is not None and self.target in self.revision_ids:
[16:30] <jam>             revision_order.remove(self.target)
[16:30] <jam>             revision_order.append(self.target)
[16:30] <l1m5> ty
[16:30] <jam> Do you know why that was necessary?
[16:31] <ronny> hmm
[16:31] <jam> We first do a topological sort on the revisions, and then we have this code to push the current target to always be the last revision
[16:31] <abentley> jam: Hmm...
[16:32] <jam> the problem is in the bundle testing code we do "write(rev1, rev2)" and that interprets the arguments to mean that rev1 is the target
[16:32] <jam> even though it is older than rev2
[16:32] <jam> which causes *my* code to end up getting [rev2, rev1] which is *reverse* topological order
[16:32] <jam> and means I don't get my parent text before the child text
[16:35] <abentley> jam: I really don't remember.  It makes me think maybe it's backwards-compatibility code.
[16:35] <ronny> ok, so i have to use transformpreview and its commit method
[16:36] <jam> abentley: yeah, I tracked the line down to a rev which says "Refactor into separate reader and writer" but then it gets a bit lost
[16:36] <jam> I'll poke a bit more and see what happens
[16:38] <abentley> jam: It might be because bundle code interprets the last revision in the bundle as the target.
[16:39] <jam> sure
[16:39] <jam> if I change the test to be
[16:39] <jam> write(..., [rev2, rev1]) then everything works fine
[16:39] <jam> since the target is then a tip
[16:42] <ronny> hmm, that transform api is awfull
[16:42] <abentley> ronny: Can you offer some advice to improve it?
[16:43] <ronny> abentley: i'll implement the apis like the one of the new filesystem api pep draft, they are pretty pythonic and painless
[16:44] <ronny> (im doing that for bzr, hg, git and svn)
[16:45] <ronny> none of the vcs's have pleasant api
[16:47] <abentley> ronny: It solves a fairly awful problem, because it handles files regardless of name changes, file-id changes, parent changes, content changes, including files that have only a file-id and no contents, and files that have contents but no file-d.
[16:47] <ronny> abentley: file with content but no id = yet to be initially commited?
[16:48] <abentley> ronny: I don't know what you mean about initially committed.
[16:48] <ronny> well, when does a file get its id?
[16:49] <abentley> ronny: When you "bzr add" it, usually.
[16:50] <ronny> so files without id but content are unknown/ignored things in the wd?
[16:51] <abentley> ronny: yes.
[16:52] <ronny> so now the api question, if all the stuff has to be managed anyway, why expose all that magic confusing number to poor programmers
[16:54] <ronny> the ai should dee all the bookkeeping
[16:54] <ronny> *api
[16:54] <abentley> ronny: By "magic confusing number", you mean the trans_id?
[16:55] <ronny> abentley: yes
[16:55] <ronny> as far as i can see, i have to do at least 3/4 steps to deal with adding a file and its content
[16:56] <abentley> ronny: Because any other way of referring to the file is ambiguous and leads to the risk of accidentally overwriting files, or attemting to move files from places where they no longer are.
[16:56] <ronny> create path, add content, schedule for versioning
[16:57] <abentley> ronny: See new_file.  That creates the path, adds, the content, adds a file-id.
[16:58] <ronny> hmm, now, i also need to figure how the heck i would tell it a file changed
[16:58] <ronny> all i really want to do is operate on it like on a normal filesystem
[17:14] <abentley-lunch> ronny: To change a file, call delete_contents, followed by create_file.
[18:50] <dobey> what does "(format: unnamed)" mean exactly? :)
[18:56] <bialix> ronny: what is filesystem api pep draft
[18:58] <ronny> bialix: draft for a pep to get reasonable filesystem apis into the stdlib
[18:58] <bialix> it has the page?
[18:59] <ronny> http://eagain.net/blog/ is a good starting point
[18:59] <ronny> hmm
[18:59] <ronny> ok, no matter how much i tinker with the bzr treetransforms, i cant figure how to use them, they just suck
[19:04] <bialix> not very much info
[19:04] <ronny> bialix: there is more in the linked git repos
[19:05] <bialix> we Russians usually say about "spherical horse in a vacuum"
[19:21] <ronny> abentley: why the hell did you recommend PreviewTransform over MemoryTree, i despiese you now
[19:22] <abentley> ronny: because we've put a lot of work into making TreeTransform.commit work recently.
[19:23] <ronny> abentley: that doesnt change the amount of pain on using those
[19:23]  * Tak feel the love
[19:24] <abentley> ronny: I'm sorry that you feel that way.  I recommended the interface that I know works.
[19:26] <ronny> all i know is that the treetransform interface is a huge confusing pain
[19:29] <abentley> ronny: Not to me.
[19:32] <ronny> abentley: then you are appearantly very trained at bearing it
[19:33] <ronny> it fails at being intuitive and it fails at keeping practically useless data away from me
[19:33] <abentley> ronny: Well, I am its author, so that helps.
[19:35] <abentley> ronny: It is a low-level API.  It is designed to solve difficult problems.  The suggestions you've proposed to make it more intuitive would make it unable to solve those problems.
[19:37] <dgoulet> Hey people, someone can tell me how to get the committer string of the last revision of a branch via bzrlib ?
[19:40] <LarstiQ> dgoulet: branch.repository.get_revision(branch.last_revision()).committer
[19:42] <dgoulet> i need to open a Branch before? (branch.Branch.open(BRANCH_PATH) ?
[19:43] <dgoulet> from this object, can I get the get_revision function ?
[19:43] <LarstiQ> dgoulet: opening a branch like that is one way to get the `branch` object in my line, yes
[19:44] <LarstiQ> dgoulet: after that, exactly what I wrote will get you the committer for the last revision on that branch
[19:44] <LarstiQ> dgoulet: note that get_revision is on branch.repository, not on branch
[19:45] <dgoulet> hmm ok
[19:45] <dgoulet> i'll try right now
[19:47] <dgoulet> fantastic
[19:47] <dgoulet> thx a lot
[19:48] <LarstiQ> ronny: looking at some scrollback (but not all), if all you want to do is commit snapshots, memorytrees and perhaps commitbuilder sound easier than TreeTransform
[19:48] <luks> note that you migh want .get_apparent_authors instead of .committer
[19:48] <luks> .get_apparent_authors()
[19:48] <LarstiQ> dgoulet: right, what luks said.
[19:49] <LarstiQ> synic: are you the author of the synic vim colorscheme?
[19:49] <synic> in a post hook in a bzr plugin, how do I obtain the commit's comment?
[19:49] <synic> LarstiQ: yes.
[19:49] <dgoulet> ok ok
[19:49] <dgoulet> works very well
[19:49] <dgoulet> thx
[19:50] <ronny> LarstiQ: i'll use memorytree now
[19:50] <LarstiQ> ronny: did you get anywhere on the hg backend btw?
[19:50] <ronny> LarstiQ: didn't work on it yet
[19:50] <ronny> i decided to make the fun game again
[19:51] <ronny> ie do it for bzr, then do it for hg in a small fraction of the time
[19:54] <LarstiQ> ronny: I'll grant you that you might know hg better, but it is a bit of a cold vs hot cache comparison
[19:55] <ronny> LarstiQ: not really, hg is kind of a pleasure for reading and understanding and bzr reliably fails at that
[19:56] <LarstiQ> ronny: still allows for experimental bias *shrug*
[19:57] <ronny> well, everz time i hac something that uses bzr i end up reading 2 orders of magnitude more code than when i do the same for hg
[19:58] <LarstiQ> synic: assuming you mean post_commit, looking at `bzr help hooks` output but not testing, I'd say master.repository.get_revision(new_revid).message
[19:59] <LarstiQ> ronny: could you give me a hg codebase tour next time we're geographically colocated? (were you going to HAR?)
[19:59] <synic> LarstiQ: ok, thanks
[20:00] <ronny> LarstiQ: sure, btw, whats HAR?
[20:00] <LarstiQ> ronny: har2009.org
[20:01] <LarstiQ> ronny: Chaos summercamp, but in .nl
[20:01] <ronny> hmm, i wont be there
[20:04]  * LarstiQ nods
[20:04] <LarstiQ> after that the next event I'm attending is the CCC itself I think
[20:04] <LarstiQ> or maybe Maschinenfest, but that's not ideally suited to hacking :)
[20:07] <ronny> hmm, maschienenfest looks like fun tho
[20:08] <LarstiQ> I hope so :)
[20:10] <LarstiQ> synic: also, to be complete, post_change_branch_tip might be interesting as well
[20:57] <jfroy> Is there a way to get finer-grained changes for bzr shelve?
[20:57] <jfroy> A few of the clusters I get are too coarse :|
[20:58]  * SamB has been wanting the same from "darcs record"
[20:58]  * SamB also wonders why "bzr commit" doesn't offer even that level of control to those that want it
[20:58] <Raim> jfroy: yeah, hunk-splitting would be good
[20:59] <abentley> jfroy: No, sorry.  I plan to support pulling launching an external program for that case.
[20:59] <Raim> jfroy: but unfortunately there is no way at the moment
[20:59] <jfroy> :sad:
[22:27] <ronny> jelmer: sup, gout anz code around where you build complete commits with subvertpy?
[22:28] <ronny> (using the remoteaccess api)
[22:30] <jelmer> ronny, Yeah, see the examples/ directory
[22:30] <jelmer> (ra_commit.py)
[22:33] <ronny> jelmer: it doesnt add/change files tho, and i have no idea how fileeditors work
[22:52] <dobey> can anyone tell me how i can get the repository format updated for a branch on launchpad?
[22:53] <verterok> dobey: did you upgraded the branch in lp?, eg: bzr upgrade --<format> lp:<branch-name>
[22:54] <dobey> verterok: that's what i typed on the command line, yeah
[22:54] <dobey> verterok: it looks like Branch format: changed, but not Repository format:
[22:54] <verterok> dobey: and the upgrade finished ok? :)
[22:54] <dobey> it didn't die, and said it was ok
[22:54] <dobey> so i presume so
[22:54] <dobey> https://code.edge.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
[22:54] <verterok> dobey: it's a stacked branch?
[22:54] <mwhudson> it can take a while for the web page to update
[22:55] <dobey> verterok: no
[22:55] <mwhudson> (well, until you push a change basically)
[22:55] <verterok> dobey: I think lp will update the format info once it's re-scanned, e.g: type filter texta enw commit
[22:55] <dobey> hrmm
[22:55]  * dobey tries
[22:55]  * verterok can't write :/
[22:56] <mwhudson> bzr info nosmart+lp:~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
[22:56] <mwhudson> try that ^
[22:56] <dobey> hrmm
[22:56] <dobey> ok
[22:58] <dobey> i wonder why it doesn't say 2a though
[23:02] <lifeless> dobey: what does it say
[23:02] <dobey> Standalone branch (format: 1.14-rich-root or 1.9-rich-root)
[23:02] <lifeless> can you add -v to the command please
[23:02] <lifeless> the paste the repository line
[23:03] <dobey> to info or upgrade?
[23:03] <lifeless> info
[23:03] <dobey>     repository: Packs 6 rich-root (uses btree indexes, requires bzr 1.9)
[23:03] <dobey> which is what lp now says as well
[23:04] <lifeless> so, its definitely not 2a
[23:04] <poolie> hi jam
[23:04] <dobey> indeed
[23:04] <poolie> hi lifeless
[23:04] <jam> hi poolie
[23:04] <lifeless> and whats the exact upgrade line you used?
[23:04] <dobey> which is odd, given i did upgrade --2a and it said it succeeded and updated the repository
[23:04] <lifeless> hi jam, poolie
[23:05] <dobey> lifeless: i upgraded to 1.9-rich-root, and then i did 2a
[23:05] <jam> dobey: doing "bzr upgrade --2a repo/branch" only upgrades the branch, not the repo
[23:05] <lifeless> dobey: I'd like you to copy and paste the line you used
[23:05] <jam> and the latest format branch is the same as the 1.9-rich-root branch
[23:05] <lifeless> jam: its on lp, no shared repo
[23:05] <poolie> jam, shall we talk?
[23:05] <dobey> lifeless: bzr upgrade --2a lp:ubuntuone-client
[23:06] <dobey> lifeless: after a successful --1.9-rich-root upgrade
[23:06] <lifeless> do you have its output? could you pastebin it
[23:07] <jam> poolie: sure
[23:07] <jam> call the house or skype directly
[23:08] <dobey> lifeless: http://pastebin.ubuntu.com/234769/
[23:10] <lifeless> extremely odd
[23:10] <dobey> indeed
[23:11] <lifeless> dobey:
[23:11] <lifeless> robertc@lifeless-64:~$ bzr info -v nosmart+bzr+ssh://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/
[23:11] <lifeless> Repository branch (format: 2a)
[23:11] <lifeless> dobey: the upgrade worked, whatever info command you are using is failing
[23:12] <dobey> weird
[23:12] <lifeless> whats the info command you're using?
[23:12] <dobey> bzr info -v nosmart+lp:~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
[23:13] <dobey> oh crap
[23:13] <dobey> wow i'm dumb
[23:13] <lifeless> ubuntuone-storage-protocol != ubuntuone-client
[23:13] <dobey> yeah, i see that now
[23:14] <lifeless> I wish we had more flexible urls
[23:14] <lifeless> so
[23:14] <lifeless> ~
[23:14] <lifeless> ~group/ubuntuone/client/trunk
[23:14] <lifeless> would be nice
[23:15] <dobey> hrmm, though now i can't seem to upgrade --2a ubuntuone-storage-protocol
[23:15] <dobey> bzr: ERROR: File exists: '/srv/bazaar.launchpad.net/push-branches/00/00/9a/14/backup.bzr'
[23:15] <lifeless> you'll need to remove that backup
[23:15] <dobey> how?
[23:15] <lifeless> or pivot it back into place
[23:16] <dobey> ssh lp rm -rf?
[23:16] <lifeless> well, firstly, check the branch is currently intact
[23:16] <lifeless> info -v will do
[23:17] <lifeless> assuming it is, lftp sftp://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-storage-protocol/trunk
[23:17] <lifeless> rm -rf backup.bzr
[23:17] <dobey> yeah it looks ok
[23:23] <lifeless> win 35
[23:24] <dobey> ok, cool. now they are both upgraded to 2a
[23:24] <dobey> lifeless: thanks, sorry for my pebkac :)
[23:24] <lifeless> np
[23:24] <lifeless> its happened to folk before
[23:24] <lifeless> I think allowing more freeform branch structure would help
[23:25] <lifeless> as you are squashing multiple bits into a single directory component
[23:27] <dobey> i don't think it would have helped. my problem was that i just typed a completely different thing than what i wanted. if i would have typed the same thing in a different format, i still would have been just as confused at the results :)
[23:28] <lifeless> it may have been easier to spot
[23:29] <ronny> jelmer: how does FileEditor.apply_textdelta work ?
[23:31] <dobey> maybe. but i don't think i would have spotted it as it didn't occur to me that i might have typed the wrong thing there, especially since it succeeded, just on the wrong project. and i guess one still wouldn't be able to arbitrarily replace - with / in a project name, as it would cause problems if someone started a foo-bar-baz project to implement foo-bar for baz, and they both were on launchpad.
[23:31] <dobey> but eh
[23:31] <dobey> it's all good now
[23:32] <jelmer> ronny, apply_textdelta will return a function that you can feed txdelta objects, to be terminated by a call with None
[23:32] <jelmer> ronny, you can use subvertpy.delta.send_stream(<file-like-object>, <txdelta-handler>) if you don't want to do this manually
[23:35] <ronny> jelmer: so i get the txdelta handler bz calling apply_textdelta, and then use send_stream?
[23:35] <jelmer> bz?
[23:35] <ronny> *by
[23:35] <jelmer> apply_textdelta() will return a txdelta handler
[23:36] <ronny> still getting used to the us layout
[23:36] <jelmer> ronny, yes
[23:36] <jelmer> ronny, :-)
[23:36] <jelmer> ronny, you had me wondering what bz was an abbreviation for :-)
[23:37] <ronny> well, i have a new found hate for many of bzr's apis tho
[23:37] <lifeless> ronny: ?
[23:38] <ronny> jelmer: so many things that are painfully more complex/complicated than necessary
[23:49] <lifeless> ronny: my guess would be you're using overly low level apis
[23:56] <ronny> lifeless: someone pointed me to TreeTransform instead of MemoryTree
[23:56] <ronny> lifeless: but both of them are pretty painfull
[23:58] <ronny> lifeless: both api"s require too much bookkeeping about magical id's
[23:59] <lifeless> ronny: bzr's data model is built around inodes, not paths
[23:59] <lifeless> ronny: but there are trivial mappings
[23:59] <lifeless> ronny: what are you trying to achieve?