[00:00] <lifeless> so its simpler to explain to say that bind just sets the flag
[00:00] <lifeless> if someone else has pushed, after binding, do 'bzr update; bzr commit'
[00:00] <lifeless> which will merge, and commit, keeping your local commits as a merge to the new origin tip
[00:00] <bob2> vila: is vc-bzr still developed, or has dvc subsumed it?
[00:01] <lifeless> if you want to do a fast-forward push, just bzr push url
[00:02] <w00t_> fast forward?
[00:02] <lifeless> w00t_: oh, using a git term; just a normal push :)
[00:05] <lamalex> vila: bob2 do either of you actually use dvc?
[00:06] <bob2> lamalex: no
[00:06] <lifeless> ok, going full screen hacking; I'll check back here from time to time - just don't expect fast turnaround on questions for a while ;)
[00:07] <vila> bob2, AFAIK dvc is still developed and vc is still developed, I *hope* vc-bzr is kept in think, I'd love to find the time to play a bit with some vc-bzr/pymacs/bzrlib approach... but don't jold your breath
[00:08] <vila> lamalex, I use dvc daily
[00:08] <lamalex> vila: is there a relevant section of your .emacs i could take a look at?
[00:09] <vila> sure, but what are you after more precisely ?
[00:09] <bob2> vila: evil but clever
[00:09] <bob2> have to incorporate ropemacs into that somehow
[00:09] <vila> ropemacs ?
[00:10] <lamalex> vila: i want to be able to just do C-c v c (or something) and have it commit, maybe another command to push, merge, diff, all from inside emacs
[00:10] <bob2> refactoring dealy, along the lines of bicycle repair man
[00:11] <lifeless> bob2: oh, can I orphan brm then?
[00:11] <vila> lamalex, I think the default binding is C-x V (not 'v')
[00:11] <lamalex> shouldn't a mode show up when I do M-x dvc-<TAB> though?
[00:11] <lamalex> I don't see anything
[00:12] <bob2> lifeless: dunno if it has any vim integration yet
[00:12] <bob2> lamalex: did you load it?
[00:12] <vila> lamalex, ha ! You're right... but you're wrong :-/
[00:12] <lamalex> lol
[00:12] <lamalex> good old emacs
[00:12] <vila> lamalex, try dvc-status when in a file under bzr control and see
[00:12] <lifeless> bob2: there is ropevim
[00:12] <bob2> huzza
[00:13] <lifeless> http://rope.sourceforge.net/
[00:13] <lamalex> that opens a new buffer
[00:13] <vila> lamalex, or try dvc-diff
[00:13] <lamalex> so do I type a commit message in that?
[00:13] <vila> lamalex, no wait
[00:14] <lamalex> ok yah now i see bzr status
[00:14] <lamalex> so i do -x  c
[00:14] <vila> no
[00:14] <vila> :_
[00:14] <vila> :)
[00:14] <lamalex> gr
[00:14] <lamalex> lol
[00:14] <lamalex> sorry ;)
[00:14] <vila> try dvc-diff first
[00:15] <lamalex> ok
[00:15] <vila> lamalex, sry. I prefer to drive you a bit around so you get a taste, but we'll get to commit fast enough
[00:15] <w00t_> lifeless: hmm. so i'll have to push each branch seperately?
[00:16] <vila> dvc-diff is my prefered "mode" but when some files are not yet under bzr control they don't show up, you need to use dvc-status for that
[00:16] <lamalex> ok so im in dvc-diff
[00:16] <lamalex> /now/ Do C-x V c?
[00:16] <vila> now, dvc-diff buffers are indeed in a specialized diff-mode mode
[00:16] <vila> no :)
[00:16] <vila> just 'c'
[00:17] <lamalex> ok so c takes me too a buffer with a commit message
[00:17] <lamalex> how do I accept that message
[00:17] <vila> should open a dvc-edit-log-mode buffer when you add your
[00:17] <vila> C-c C-c
[00:17] <w00t_> lifeless: heh, I'm now getting bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[00:17] <lifeless> w00t_: yes, most pushes in bzr are single branch (branch is the basic user object folk work with)
[00:18] <vila> lamalex, and now you *must* refresh your dvc buffers :-/
[00:18] <lifeless> jelmer: if you're around, can you offer some hints here, I don't know enugh about bzr-svn's guts to predict what is best for w00t_
[00:18] <w00t_> (when trying to push to the empty svn repo)
[00:18] <w00t_> lifeless: ok, thanks, I do appreciate your help and patience
[00:18] <lamalex> ah ha
[00:18] <w00t_> I'll wait around to see if jelmer has a few moments :)
[00:18] <lamalex> hmm how do i refresh the buffers?
[00:18] <lifeless> jelmer: he is trying to convert a full git repo to svn (preserving datestamps) by fast-export to bzr, then bzr-svn pushes to a new svn repo
[00:19] <jelmer> w00t_, lifeless: Hi
[00:19] <w00t_> hey there! :)
[00:19] <jelmer> w00t_, You can't push to the root of the repository, you probably want to push to /trunk
[00:19] <jelmer> w00t_, if you would like to push the merged revisions as well, use --merged
[00:19] <w00t_> jelmer: aha! a bit of a confusing error message :)
[00:19] <w00t_> hmm, merged revisions.. can you elaborate on that a bit for me?
[00:20] <vila> lamalex, all in all, there rough edges in dvc (lack of doc being one) but diff-mode is very useful as quick way to navigate into your current modifications and reverting/applying them at will (so be sure to look C-C C-c and C-c C-a in these buffers)
[00:21] <jelmer> w00t_, merged revisions are revisions which are not on the mainline
[00:21] <jelmer> w00t_, the revisions shown indented when running "bzr log"
[00:21] <w00t_> hm
[00:21] <w00t_> oh, I see
[00:21] <w00t_> revisions that occured on another branch
[00:21] <lamalex> vila: thanks for your help
[00:21] <vila> lamalex, you're welcome
[00:22] <lamalex> at the very least the diff and commit will be useful
[00:22] <lamalex> is there a way to push quickly?
[00:23] <jelmer> w00t_, Does that help?
[00:27] <w00t_> jelmer: hmm.
[00:27] <w00t_> jelmer: it went through a lengthy import process, and then:
[00:27] <w00t_> bzr: ERROR: Prefix missing for branches/merged; please create it before pushing.
[00:30] <jelmer> w00t_, please create the "branches" directory in the svn repository
[00:30] <w00t_> jelmer: hmm, that also imported, but didn't preserve committer name/timestamp -- i guess that is wishful thinking then
[00:30] <jelmer> w00t_, it can, but you have to set an extra option
[00:31] <w00t_> ..oh.. what do I do after creating that directory? just try push again?
[00:31] <lifeless> poolie: btw, for the tree logic, I'm allowing mutable nodes internally for now, to get it up and running.
[00:31] <jelmer> w00t_, yep
[00:31] <jelmer> w00t_, (newer versions of bzr-svn will do that for you)
[00:31] <jelmer> w00t_: to keep properties, set "override-svn-revprops = svn:date;svn:author"
[00:31] <w00t_> hm
[00:32] <w00t_> where do I set that? I imagine there is some kind of either repo or user-level config
[00:32] <jelmer> yeah, ~/.bazaar/subversion.conf
[00:34] <w00t_> thanks!
[00:34] <w00t_> i shall try experiment with this some more tomorrow
[00:34] <w00t_> it looks promising :-)
[00:36] <jelmer> cool :-)
[00:36] <w00t_> for now, bed for me
[00:36] <w00t_> thanks for your help lifeless and jelmer :-)
[01:38] <poolie> lifeless: hey, want to catch up sometime?
[02:04] <jelmer> lifeless, Could it be that PQM doesn't support ftp:// either atm ?
[02:21] <lifeless> jelmer: absolutely; different machine, firewalled
[02:23] <jelmer> lifeless: Ah, ok. I'll just fall back to http for now - thanks
[02:25] <lifeless> poolie: so what I was trying to say was - there is create_by_apply_delta already, but it and apply_delta have (I think) usefully different behaviours. Changing stuff where it makes sense to use create_by_apply_delta - +1. Avoiding having apply_delta - more trouble than it's worth I think.
[03:36] <adeel> is it possible to add/update a file to a bzr repo, without checking out the entire tree?
[03:37] <lifeless> spiv: care to join #gnome-bzr on gimpnet
[03:38] <lifeless> adeel: using the bzrlib api, yes, but not using the regular commands
[03:39] <adeel> lifeless, can you clarify how that'd work?
[03:40] <lifeless> adeel: you'd create a MemoryTree object from the branch tip, make your changes, and commit the MemoryTree
[03:40] <adeel> my situation is this...i work on multiple projects but not all at once , and carrying around the full repo for each project isn't viable at this moment, so i was wondering if it was possible to add/update files without a fulll checkout
[03:41] <adeel> lifeless, is that procedure documented anywhere?
[03:42] <lifeless> adeel: yes, in the bzrlib programming documentation
[03:42] <adeel> lifeless, one last question, does bzr support overlays?
[03:42] <lifeless> adeel: but I don't think its what you need; you want something like views, which is proposed but not finished
[03:43] <lifeless> I don't know precisely what you mean by overlays; I'm guessing you don't mean the 1980's programming model for loading libraries on CP/M and DOS
[03:43] <adeel> heh, no...i meant overlays in the svn sense
[03:43] <lifeless> I don't know what they are
[03:43] <adeel> or multiple working copies at the same time
[03:44] <lifeless> uhm, clearly we support that, or people couldn't ever work on more than one project
[03:44] <lifeless> or do you mean co-located ina single directory?
[03:44] <adeel> yes, in a single dir
[03:44] <lifeless> no
[03:45] <lifeless> you can nest working copies
[03:45] <lifeless> but you can't colocate multiple working copies at a single dir
[03:45] <adeel> good to know, i can work around that
[03:46] <adeel> thanks for the help
[06:20] <AfC> What is "CHK"?
[06:21] <lifeless> content hash key
[09:07] <robsta> hi
[09:08] <robsta> is there a(n easy) way to run bzr from the ppa with bzr-svn?
[09:09] <robsta> it says "bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~intrepid1 is to be installed"
[09:59] <siretart> robsta: yes. mkdir ~/.bazaar/plugins ; bzr get lp:bzr-svn/0.4 ~/.bazaar/plugins/svn
[09:59] <robsta> oh, thanks, guess i'll wait for the deb, then
[10:00] <siretart> OTOH, it would be nice if the ~bzr PPA would have updated packages for bzrtools and bzr-svn, though.
[10:00] <w00t_> jelmer: hmm, it seems the setting to preserve committer/timestamp didn't seem to take effect, or is it supposed to be in some subsection of subversion.conf
[10:52] <w00t_> jelmer: hmm, I really don't know what I've done wrong
[10:59] <w00t_> jelmer: I set override-svn-revprops like you mentioned, I tried changing it to comma seperated like your FAQ mentions, I tried moving it to bazaar.conf like the FAQ mentions, I enabled the revprop hook and made it executable.. nothing seems to not mangle time/author info :(
[11:38] <g0nzal0> hullo everyone
[11:38] <g0nzal0> I've just updated my Ubuntu to Intrepid
[11:39] <g0nzal0> I have PPA repositories configured
[11:39] <g0nzal0> and corrected them accordingly
[11:39] <g0nzal0> which updated bzr to 1.9
[11:39] <g0nzal0> so
[11:40] <g0nzal0> now I get
[11:40] <g0nzal0> bzr: ERROR: Version mismatch
[11:40] <g0nzal0> when I issue "bzr status"
[11:41] <poolie> g0nzal0: any other information?
[11:41] <g0nzal0> or "bzr diff somefolder/somefile"
[11:41] <g0nzal0> poolie: such as? I'm totally lost here :(
[11:42] <poolie> is that the only error message it prints?
[11:42] <poolie> how about if you try "less ~/.bzr.log"
[11:43] <g0nzal0> well, a warning about bzr-svn is also printed
[11:43] <poolie> ok
[11:43] <poolie> i think this means bzr-svn is out of date in the ppa
[11:43] <g0nzal0> $ bzr diff surveygen/views.py
[11:43] <g0nzal0> bzr-svn is not up to date with installed bzr version 1.9.
[11:43] <g0nzal0> There should be a newer version of bzr-svn available.
[11:43] <g0nzal0> bzr: ERROR: Version mismatch
[11:43] <poolie> and does it just stop there?
[11:43] <g0nzal0> yup
[11:43] <Kinnison> jelmer: What's the state of bzr-git these days?
[11:44] <verterok> 'morning
[11:44] <g0nzal0> poolie: whoa ~/.bzr.log has a Traceback!!!! :)
[11:45] <g0nzal0> poolie: http://dpaste.com/89976/
[11:51] <g0nzal0> poolie: removing bzr-svn (I didn't really used it much, will reinstall it if needed) did the trick, thanks!
[11:58] <poolie> ok
[11:58] <poolie> it should be updated soon
[12:04] <Spoob> hey
[12:05] <Spoob> when i try to push the newst version that error message comes: Permission denied (publickey).
[12:05] <Spoob> bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)
[12:05] <Spoob> whats the problem?
[12:05] <Odd_Bloke> Spoob: Are you trying to push to Launchpad without having set up a public key on Launchpad?
[12:06] <Spoob> Odd_Bloke: i already set my ssh key in launchpad
[12:06] <Odd_Bloke> Spoob: Well, apparently not. ;)
[12:07] <Odd_Bloke> Can you use ssh to Launchpad?
[12:07] <EarthLion_> hey how can i push a specific file from revno x?
[12:07] <EarthLion_> i don't want to revert
[12:07] <EarthLion_> i just want to get in into a serparate folder
[12:07] <Spoob> Odd_Bloke: how can i try it?
[12:08] <Odd_Bloke> Spoob: 'ssh bazaar.launchpad.net', maybe.
[12:08] <Spoob> Permission denied (publickey). :S
[12:08] <Spoob> how can i register the to bzr?
[12:08] <Odd_Bloke> EarthLion_: 'bzr cat -r<REVSPEC> <FILE>' will show you the contents of <FILE> at the given revision.
[12:09] <Odd_Bloke> Spoob: You haven't set your public key up properly, it would seem.
[12:09] <Spoob> Odd_Bloke: i already did it, im sure, https://launchpad.net/~spoob
[12:10] <EarthLion_> Odd_Bloke: thank you so much :)
[12:10] <Odd_Bloke> EarthLion_: No worries.
[12:11] <Odd_Bloke> Spoob: Well, your SSH client isn't using the key, I guess.
[12:11] <Spoob> how can i set bzr up to my ssh key?
[12:11] <Odd_Bloke> Spoob: You don't need to set bzr to use your SSH key, you need to set up your SSH client to use your SSH key.
[12:12] <Odd_Bloke> Then bzr should work fine.
[12:12] <Odd_Bloke> Spoob: Try 'ssh bazaar.launchpad.net -vv', that'll give you more output.
[12:16] <awilkins> Don't you need the username so it knows which authorized_keys to check?
[12:17] <Odd_Bloke> Hmm, yeah, but I'm guessing there'll be a message about not even finding a public key.
[12:17] <Odd_Bloke> Spoob: Try 'ssh <username>@bazaar.launchpad.net'.
[12:18] <Spoob> Odd_Bloke: yeah now it works, really thank
[12:29] <Odd_Bloke> Spoob: And you're able to push properly?
[12:29] <Spoob> yeas, but now i cant my files here https://code.launchpad.net/~spoob/+junk/main :P
[12:30] <Odd_Bloke> Spoob: Have you added the files and committed your changes?
[12:31] <Spoob> yes
[12:31] <Spoob> but i do it again now
[12:33] <Spoob> ah now it works thanks!
[13:28] <jelmer> w00t_, hi
[13:29] <w00t_> jelmer: morning! :)
[13:29] <jelmer> Kinnison, it can import from local git repositories, though it's a bit slow
[13:35] <Kinnison> :-(
[13:35]  * Kinnison prods someone to keep doing the svn mirror for now
[13:58] <jelmer> w00t_, if you use the latest revision from the 0.4 branch, there's a separate command-line option
[14:02] <w00t_> jelmer: i'm using ubuntu's packages.. :(
[14:18] <Steven1> hi
[14:19] <Steven1> i'm running intrepid, is there a way to enable nautilus integration?
[14:19] <chevdor> yes
[14:21] <Steven1> chevdor: how? i've not been able to find anything useful, and the readme file of bzr says it was packaged without nautilus integration
[14:22] <chevdor> Steven1, i don't remember, but it works here on my pc so I probably found a solution... I just followed the docs, can't tell u more
[14:23] <chevdor> Steven1, but it is not fully usable yet i'd say, it's on its way :)
[14:24] <Steven1> chevdor: thanks, i was just curious :P i think i'll wait a little, command line works well :)
[14:26] <chevdor> Steven1, it is moving fast though, check out in a few weeks
[14:27] <Steven1> ok, thanks, is there any chance to see loggerhead packaged?
[14:35] <jelmer> Steven1, there's a package in Debian experimental that will hopefully make it into jaunty
[14:37] <Steven1> nice
[14:53]  * rocky has given up on relying for bzr-connected pkgs in ubuntu ... always out of date
[14:57] <jelmer> w00t_, what did you set in subversion.conf exactly?
[14:58] <w00t_> jelmer: one moment
[14:58] <w00t_> I tried both:
[14:58] <w00t_> override-svn-revprops = svn:date, svn:author
[14:58] <w00t_> and: override-svn-revprops = svn:date;svn:author
[14:59] <w00t_> in subversion.conf as well as bazaar.conf (your FAQ said to use that, at least..)
[15:00] <jelmer> w00t_, in the section for the repository you're pushing to?
[15:00] <w00t_> jelmer: ah. no, does it need to be?
[15:00] <jelmer> w00t_, yeah
[15:00] <w00t_> jelmer: how can I get a section created before I push, then? it seems to only create one after I've started the push
[15:00] <w00t_> (also, is the comma or the semicolon version correct?)
[15:01] <jelmer> w00t_, The section name is the repository UUID (svn info <path-to-repository>)
[15:01] <w00t_> hmm and how may I retrieve the uuid?
[15:03] <jelmer> w00t_, it's printed by "svn info <path-to-repository>"
[15:04] <w00t_> jelmer: okay, I shall give it a go. which should I use, comma or semicolon?
[15:04] <rocky> so is bzr-hg essentially dead?
[15:04] <jelmer> rocky, yeah
[15:04] <jelmer> w00t_, Not sure, actually; I *think* it's semicolon
[15:05] <rocky> that's too bad, i wanted to mirror a hg branch in bzr to make it easier to work on
[15:06] <rocky> jelmer: don't suppose you have a pattern (or know of one written up on the web) for managing a bzr branch for a piece of software that uses a foreign non-supported vcs ? (essentially no vcs i guess)
[15:06] <jelmer> rocky, no, sorry :-/
[15:13] <hno> rocky: If there is no VCS then import their releases, and do your work on a separate branch merging from the vendor branch.
[15:14] <rocky> hno: right, i guess the hard part is determining what changed between vendor releases and applying just that into my separate branch
[15:14] <rocky> oh wait
[15:14] <rocky> hno: mind elaborating on the import-into-vendor-branch part?
[15:14] <hno> rocky: bzr does that for you.. just import as-is into the vendor branch..
[15:14] <jelmer> w00t_, any luck?
[15:15] <rocky> hno: so import the first release as a vendor branch... and then when another release comes out extract it on top of the old vendor branch and do a add/commit ?
[15:15] <hno> rocky: Yes.
[15:16] <rocky> hmm
[15:16] <hno> and do your own work on a separate branch, using bzr merge to bring changes over from the vendor branch.
[15:16] <rocky> right
[15:16] <rocky> awesome thanks
[15:16] <rocky> that's the sort of pattern i was looking for
[15:17] <hno> rocky: this pattern works with any VCS supporting merges...
[15:17] <rocky> hno: sure, i've just never had to do anything like this before ;)
[15:19] <w00t_> jelmer: kind of caught up in an emergency.. sorry
[15:24] <rocky> jelmer: another bzr-svn issue...  http://cluebin.appspot.com/pasted/3002
[15:25] <jelmer> whoa
[15:27] <rocky> jelmer: btw, when i do a branch like that, does it download all the rev info for the entire remote svn repo ?
[15:27] <rocky> i hope not, because that svn repo is HUGE and hosts many many projects
[15:28] <jelmer> yes, it downloads the metadata for all revisions (not the contents)
[15:28] <rocky> that repo has 75k revisions :(
[15:28] <jelmer> it's a one-time operation though
[15:29] <jelmer> and it's quite fast (looks like it's only a couple of minutes here)
[15:30] <rocky> ah cool
[15:31] <rocky> jelmer: btw if you do fix that bug i just pasted and it's a simple fix i'd like to apply it against my working bzr-svn
[15:52] <jelmer> rocky, can't reproduce that here
[15:53] <jelmer> rocky, can you remove the svn cache and try again ? Are you running the 0.4 branch?
[15:55] <jelmer> rocky, did you use earlier versions of bzr-svn with this repository?
[16:06] <rocky> jelmer: i'm using 0.4.15 release tarball ... and i don't believe i've ever used this with the repo, but i can remove my svn cache
[16:06] <rocky> jelmer: but if you look at my paste you can see it is initializing the svn cache for that repo
[16:06] <rocky> so that makes it seem like it's "from scratch"
[16:06] <jelmer> hmm, right
[16:06] <jelmer> are you out of disk space perhaps?
[16:08] <rocky> 2gb free
[16:08] <rocky> not enough?
[16:09] <jelmer> yeah, that should be plenty
[16:09] <jelmer> can you try again, just in case?
[16:09] <jelmer> would be really weird if it did work, but it does work here
[16:09] <rocky> i'm trying again
[16:10] <rocky> i deleted the specific cache dir
[16:10] <rocky> running a lot faster than i expected actually.. already through 14k revs
[16:10] <rocky> (last time i ran it under emacs eshell which meant i wasn't getting status info)
[16:11] <rocky> jelmer: when you ran it, did you run it against python2.5 or python2.6 ?
[16:11] <rocky> it just blew up again
[16:11] <jelmer> 2.5
[16:11] <rocky> i'm using 2.6 which probably comes with a diff sqlite3 version which could be the difference
[16:11] <jelmer> can you try with 2.5 perhaps?
[16:13] <rocky> hrm, would have to rebuild my environment
[16:20] <rocky> jelmer: it's a lot further along now with py2.5
[16:21] <jelmer> if it does turn out to be python2.6, please file a bug
[16:21] <jelmer> I'll be back in a couple of hours
[16:35] <w00t_> jelmer: does this look correct, then? (emergency over ;-)) [33d11fd1-86b3-441f-987f-5b8a439e6865]
[16:35] <w00t_> locations = file://localhost/var/git/public/crazyshit/a-s
[16:35] <w00t_> override-svn-revprops = svn:date, svn:author
[16:35] <w00t_> (excuse language, that really is the dirname, should have thought first)
[16:36] <jelmer> w00t_, yeah, that looks ok
[16:36] <w00t_> right, I shall give it a go then
[16:37] <jelmer> alternatively, you can just set it to "True"
[16:37] <jelmer> instead of "svn:date, svn:author"
[16:37] <w00t_> hmm, that sets all properties I assume
[16:37] <w00t_> bzr: ERROR: Unable to set revision property svn:author.
[16:38] <w00t_> I guess that means my hook is wrong
[16:38]  * w00t_ investigates
[16:38] <jelmer> yeah, that would indeed suggest the hook is wrong
[16:41] <w00t_> jelmer: yeah, that messed up the metadata on the first commit - but worked on the rest, so I guess we're on to a winner now! :)
[16:41] <jelmer> cool :-)
[16:41] <w00t_> jelmer: if I might make a suggestion -- would it not make sense to default this setting to on?
[16:41] <jelmer> The first one would've been incorrect because it adjusts the properties after you push the commit
[16:41] <jelmer> (and after the first commit you got that warning)
[16:42] <w00t_> *nod*
[16:42] <w00t_> I understand why it messed that up, I shall do another import to fix it
[16:42] <jelmer> You can also just adjust the first revision manually
[16:42] <w00t_> (*sigh*, this has to be like the 99th time I've recreated this repo now :-))
[16:42] <w00t_> oh. I didn't know that..
[16:42] <jelmer> (svn propset --revprop -r<rev> <name> <value>)
[16:43] <w00t_> now I guess I need to read up on bazaar so I can use it properly :-)
[16:43] <jelmer> w00t_, There are very few actual SVN repositories out there that allow changing the svn:date and svn:author, that's why it's not enabled by default
[16:43] <w00t_> jelmer: oh. good point!
[16:44] <rocky> jelmer: turned out to be specific to py2.6 ... i'll setup a bug report here when i get a chacne
[16:44] <jelmer> rocky, thanks
[16:44] <w00t_> elmer: (though a param to svn-push would perhaps work too?
[16:44] <jelmer> w00t_, there is a parameter to svn-push in the 0.4 branch :-)
[16:45] <w00t_> jelmer: oh! fantastic
[16:45] <w00t_> now I'll just have to wait until ubuntu picks it up... :-P
[16:45] <jelmer> jaunty should have it..
[16:46] <w00t_> ah.
[16:46] <w00t_> good, because I'll probably be running it when it hits alpha
[17:56] <Peaker> I'm looking at https://zooko.com/badmerge/concrete-good-semantics.html -- and it makes a convincing argument that a 3-way merge loses interesting information
[18:32] <abentley> Peaker: Bazaar supports more types of merging than just 3-way.
[18:33] <Peaker> abentley: what advantage does 3-way have over looking at all the intermediate revisions?
[18:33] <abentley> Peaker: It's faster and easier to understand.
[18:34] <Peaker> correctness over performance? :-)
[18:35] <Peaker> I don't know if it is easier to understand, if a newbie is facing a conflict that would not be there if the merger looked at all available information, its probably harder for the newbie to understand
[18:36] <abentley> Peaker: It is.  We have experience with peoples' reaction to weave merge conflicts, and they can't tell what's going on.
[18:37] <abentley> With 3-way, you can look at the different versions and see why it's doing what it's doing.
[18:37] <abentley> When there are N versions, that's essentially impossible.
[18:38] <Peaker> abentley: I see
[18:38] <abentley> Peaker: Also, Zooko is not presenting a case that causes conflicts.  Situations where 3-way produces conflicts but weave merge would not are rare, except for criss-cross merge.
[18:40] <Peaker> abentley: zooko says its worse, you get no conflict, but a wrong merge silently
[18:41] <Peaker> abentley: square was renamed and a new square function was written, and the merge takes the new square to be the old..
[18:41] <abentley> You were talking about "a newbie facing a conflict".
[18:41] <Peaker> oops, my bad ;)
[18:41] <Peaker> I guess its a newbie getting a wrong merge
[18:42] <abentley> Peaker: Yes.  No merge will ever be perfect.  The best defence is a test suite.
[18:42] <Peaker> abentley: does weave introduce confusing conflicts that 3-way doesn't?  If not, what was confusing about its merges?
[18:45] <abentley> Peaker: I don't think it produces them more often, but when it does, they may be more confusing.
[18:46] <abentley> Because they are caused by information that you can't see.
[18:48] <Peaker> you could see the whole 2 diff paths side-by-side, rather than 2 big patches side-by-side?
[18:48] <abentley> Peaker: I don't understand the question.
[18:49] <Peaker> abentley: you said its based on information you cannot see, why not show it?
[18:49] <Peaker> the information is all the intermediate revisions, right?
[18:50] <abentley> Peaker: The information is the graph of revision history and the annotation of the lines, and the resulting status of the lines.
[20:00] <gauthierm> Has anyone here used bzr-svn?
[20:00] <jelmer> yep :-)
[20:00] <bob2> lol
[20:01] <yml> I am trying to port some of the modif done in a bzr repo to a git repo. I try to use something like bzr export <git_folder> <bzr_branch>
[20:01] <gauthierm> I exported an svn repository and made several hundred changes in bzr. I now have svn commit access. Is it possible to replay my bzr commits as svn commits?
[20:02] <mDuff> gauthierm, being able to push to svn repositories is one of bzr-svn's big bullet points, though I haven't used it personally.
[20:02] <yml> bzr is telling me that : bzr: ERROR: [Errno 17] File exists: '<git_folder>/'
[20:03] <mDuff> yml, you're not trying to keep history, just move a snapshot? export to a new directory, rsync from that into the git folder.
[20:04] <yml> mDuff: ok that will do I was looking for a --overwright option
[20:05] <yml> mDuff: but what you propose seems to be a workable solution
[20:05] <jelmer> gauthierm, if the history is linear (no merge commits) you should be able to just use "bzr push"
[20:12] <yml> mDuff: Do you know the option on top of your head to overwrite with rsync
[20:13] <mDuff> yml, rsync -ra source_dir/. dest_dir/. should do that by default.
[20:13] <yml> I try rsync <exported_branch> <my_git_folder>
[20:13] <mDuff> yml, the /. is there for a reason.
[20:14] <mDuff> yml, same with the -ra
[20:14] <yml> ok
[20:14] <yml> mDuff thank you for your kind assitance
[20:14] <gauthierm> jelmer: Yep, its linear. Do I just point to hte svn repo in the bzr push command?
[20:15] <jelmer> gauthierm, yes
[20:15] <gauthierm> nice
[20:18] <gauthierm> jelmer: bzr says the braches have diverged and I should merge. The merge command says my .bzr repository is not compatible with the svn repository.
[20:18] <gauthierm> It's worth mentioning that I did a clean export of the code (no svn info) before starting my work in bzr.
[20:18] <jelmer> gauthierm, ah, so the original branch wasn't created using bzr-svn ?
[20:18] <gauthierm> jelmer: nope. I used svn export and then bzr init.
[20:19] <mDuff> ...oh; that's not good.
[20:19] <jelmer> gauthierm: In that case, it's not so easy to push your changes into svn
[20:19] <gauthierm> hmm.. is it impossible or just more difficult?
[20:20] <mDuff> gauthierm, well, you can write a script that reapplies as patches one-at-a-time; with a bit of elbow grease, nothing's *impossible*
[20:20] <gauthierm> Is there any example of doing that sort of thing online?
[20:20]  * mDuff would probably make a new branch, created *with* bzr-svn, and transfer patches onto that; safer than trying to apply straight to the real svn repo.
[20:20] <gauthierm> agreed
[20:23] <mDuff> gauthierm, does your branch include renames, move operations, or the like?
[20:23] <gauthierm> mDuff: Yep. Quite a few.
[20:24] <mDuff> ...hrm; that makes things trickier.
[20:26] <gauthierm> Trickier in the get-patch, apply-patch sense?
[20:31] <mDuff> gauthierm, hmm -- looks like the fastimport stream format is name rather than arbitrary-ID based; you *might* be able to use the bzr-fastimport toolchain to move revisions between the branches, but YMMV, some-assembly-required.
[20:33] <gauthierm> So if I did this correctly from the start, how would it work?
[20:34] <mDuff> gauthierm, if you'd used bzr-svn to check out from the svn repo in the first place, and there hadn't been changes made to the repo in the meantime? You'd run "bzr push svn://whatever" and it'd Just Work.
[20:34] <mDuff> ...at least, that's my understanding.
[20:34] <jelmer> yeah, that's right
[21:13] <adeel> anyone mind helping me think through a repo layout?
[21:15] <hno> adeel: can try
[21:16] <adeel> hno, thanks...i'm pretty much trying to setup a central repo for personal & project files over windows/mac/linux on 3 different machines
[21:16] <hno> ok.
[21:17] <adeel> in svn, i would have used the svn:external feature, which would let me create multiple repo profiles that i could check out for a semi-custom tree
[21:17] <adeel> where svn:externals has this functionality: http://svnbook.red-bean.com/en/1.0/ch07s03.html
[21:18] <adeel> i recall reading about a 'meta-repo' for bzr, but can't seem to find any meaningful documentation on it
[21:18] <hno> adeel: Do you really really want a split repository where some parts is hosted here and some parts there?
[21:19] <adeel> hno, well all my project files should be separate from my personal ones...because i'll need my project files on the 3 different os's, but i don't need the . files in windows but i do in mac/linux, nor do i need the Library folder in linux/windows but i do in Mac
[21:20] <adeel> hno, i was hoping not to have multiple repo's, but 1 common repo between them all, and each is in it's own top level dir
[21:20] <Peng_> What's the difference between bzr+http and http? Why are they different?
[21:21] <hno> Peng_: bzr+http is the bzr smart http server, with bzr extensions. http is plain http file serving.
[21:22] <adeel> hno, i was thinking of using 10.2.1.2 as the layout....http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#choosing-a-shared-repository-layout
[21:22] <adeel> or 10.2.1.1
[21:22] <Peng_> hno: I know that. I mean that "http"'s smart server auto-detection behaves differently from bzr+http.
[21:22] <Peng_> BTW, "bzr branches" is *really* inefficient over a smart server, heheh.
[21:25] <Peng_> Haha, it made like 500 requests.
[21:25] <Peng_> To scan a fairly small directory tree.
[21:26] <Peng_> ...Seriously, there were like 5 branches there.
[21:29] <adeel> hno, any thoughts on the layout?
[21:29] <LarstiQ> Peng_: I assume it's trying to to a vfs tree walk?
[21:30] <Peng_> LarstiQ: Probably.
[21:30] <Peng_> s/Probably/I guess/
[21:30] <Peng_> Why does walking...64 directories take 500 requests though?
[21:30] <Peng_> (And why do I have 64 directories there anyway?)
[21:31] <LarstiQ> I don't know the answer to that, but I do know 'branches' is horribly inefficient over http (or other transports without a reliable listdir)
[21:32] <Peng_> Does bzr+http should have a reliable listdir?
[21:32] <adeel> apparently not
[21:32] <hno> adeel: Never needed to do anything like that.
[21:33] <LarstiQ> Peng_: no
[21:33] <Peng_> Wait...is the mailing list at lists.canonical.com or lists.ubuntu.com?
[21:33] <LarstiQ> Peng_: bzr+http is supposed to not use vfs methods when it can. But I doubt there is a `Repository.branches` verb.
[21:34] <adeel> hno, well from the bzr doc's, it says i can get similar functionality with nested trees, so i might give that a shot...but right now i'm still 1 step behind that...i'm still not sure how to setup the repo right...do i init-repo with or without trees?
[21:34] <LarstiQ> Peng_: I'd guess canonical, but both hosts have resolved to the same thing in the past iirc
[21:34]  * LarstiQ needs to start learning section numbers by haert
[21:35] <Peng_> They're different hosts ATM.
[21:35] <Peng_> s/hosts/IPs/
[21:35] <hno> adeel: Without generally if it's a shared repository accessed remotely..
[21:37] <adeel> hno, and what does that result in practice? the --without-trees option just adds the blank dir without any of the subdirs to a repo?
[21:37] <hno> adeel: Yes, only the .bzr control files.
[21:37] <hno> adeel: actual content only stored within bzr.
[21:38] <adeel> and the benefit of that is?
[21:38] <abentley> jml: Quick talk?
[21:38] <jml> sure.
[21:39] <jml> voice?
[21:39] <LarstiQ> adeel: not storing things you're not using.
[21:39] <abentley> jml: yah
[21:40] <adeel> LarstiQ, i'm still unclear on that....i can understand using that when checking out a repo, but why would i do that when creating a repo, unless i was trying to nest branches or something?
[21:41] <hno> adeel: With a shared repository you have the checkout in your working directories, not the repository. In a non-shared repository the repository and working directory is the same.
[21:42] <adeel> i never knew RCS's could be so confusing....svn seems trivial compared to bzr at this point
[21:43] <adeel> hno, can you clarify the 'you have the checkout in your working directories, no the repository' for me? i think i'm interpreting it wrong
[21:43] <LarstiQ> adeel: well, in the case of a repository on a remote server you don't do any actual work on, it's purpose is publishing/archiving branches.
[21:44] <LarstiQ> adeel: you will never edit files or merge things there. So you don't need a working tree.
[21:44] <adeel> LarstiQ, yeah, i get that
[21:44] <adeel> ahhh, ok; so where does bzr store the files on the repo then?
[21:45] <hno> adeel: It stores them in the bzr repository. Located in the .bzr folder in the directory you specified to init-repo
[21:45] <Peng_> Oh, I bet I understand why. "bzr+http" uses the smart server for VFS operations, while "http"...doesn't.
[21:45] <Peng_> That probably makes http more efficint.
[21:46] <hno> Peng_: Do "http" ever use the smart server?
[21:47] <Peng_> hno: Yes.
[21:48] <Peng_> hno: "http" has automatically probed for .bzr/smart since 1.4rc1.
[21:49] <LarstiQ> adeel: the files are stored as history, just like svn would.
[21:49] <adeel> LarstiQ, so is there a preferred layout for a shared repo in bzr? i was thinking of doing multiple TLD
[21:49] <adeel> LarstiQ, true, but svn also stores the files/revision history in either a bdb or flat file structure, i'm not sure how bzr stores it...seems like flat files
[21:49] <LarstiQ> adeel: personally, I have one repository per project, and a reasonably flat namespace within
[21:50] <adeel> LarstiQ, does that add a lot of overhead?
[21:50] <Peng_> adeel: No.
[21:50] <LarstiQ> adeel: nope
[21:50] <adeel> the only reason i ask, is that i expect to have multiple common files in some of the projects & personal files
[21:51] <adeel> and instead of having duplicate files everywhere, just have the common file projects be branches
[21:52] <haaseg> I must be doing something wrong  - I can't get any of the team context menu options to be active up in bzr-eclipse
[21:52] <LarstiQ> adeel: that could make sense, yes.
[21:53] <adeel> LarstiQ, i'm still having trouble wrapping my head around what bzr calls branches and whatnot...even though i've read the user guide/intro materials a few dozen times
[21:57] <haaseg> anyone using bzr-eclipse?
[21:57] <hno> Peng_: Right. I get your original question now.
[22:00] <LarstiQ> adeel: branches are the major units you work with with bazaar.
[22:02] <adeel> LarstiQ, yeah, i've figured that much out...i guess a lot will get cleared up when i actually start doing work with it
[22:02] <LarstiQ> adeel: I sure hope so :)
[22:03] <adeel> otherwise i'll just be back here bugging everyone =cp
[22:03] <LarstiQ> adeel: one branch versions a set of files/directories together as a logical unit.
[22:03] <LarstiQ> adeel: that's ok :)
[22:03] <adeel> LarstiQ, so each branch has it's own revision numbers, correct?
[22:04] <LarstiQ> adeel: correct
[22:05] <adeel> ok, so it seems like i'm going to do the nested style repo....
[22:05] <adeel> with a nested repo, i can still do --local commits if i choose to, correct?
[22:06] <haaseg> So...  what I guess I don't understand with all the branches - what is the trunk?
[22:06] <adeel> haaseg, it depends on what style of a repo you have
[22:07] <adeel> you don't necessarily have to have an explicit trunk it seems
[22:07] <adeel> haaseg, http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#choosing-a-shared-repository-layout might clarify a few things
[22:10] <haaseg> thx adeel
[22:11] <adeel> np
[22:14] <mfoniso> When trying to commit changes using the command 'bzr commit -m "comment" filename', I get the following error -  bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Estefanlsd/%2Bjunk/source-switcher/.bzr/branch/lock): Transport operation not possible: http does not support mkdir()
[22:15] <mfoniso> can anyone please tell me what I'm doing wrong?
[22:18] <w00t_> is there a way to rename a branch?
[22:20] <lifeless> 'mv foo bar'
[22:21] <lifeless> mfoniso: you've checked out a branch over http; launchpad doesn't run an http write-demon, so you can't commit to it there
[22:21] <w00t_> lifeless: really that easy? hah, awesome
[22:21] <lifeless> mfoniso: also, unless you are stefanlsd, you're trying to commit to someone else's branch
[22:22] <lifeless> mfoniso: you can: convert your checkout to a branch (bzr reconfigure --branch), or you can 'bzr switch' to a writable url (but as I'm guessing its not your branch you'd need to make a branch first, doing the reconfigure is probably best)
[22:26] <lifeless> mDuff: btw
[22:27] <lifeless> mDuff: are you still doing that huge repo project?
[22:27] <mDuff> lifeless, no -- that was my former employer; I bailed out of there around January or so.
[22:27] <lifeless> ok. I was going to mention that the 1.9 format would be a significant upgrade
[22:27] <lifeless> good basic data types for the win
[22:38] <PeanutHead> Hey everyone, hopefully you guys can help me, I'm new on Bazaar, I already created my branch, commit my changes, and i'm trying to creat a patch to send by email, but the command send -o fix.patch is not working
[22:39] <PeanutHead> the error msg that pops up is: bzr: ERROR: No submit branch known or specified
[22:40] <PeanutHead> I have no idea what is wrong since I'm inside my brach directory
[22:41] <mDuff> PeanutHead, provide as an extra parameter the branch which you want to submit changes relative to
[22:42] <PeanutHead> mDuff, my branch is at the folder src, so I would have to write the send command like this: command send -o fix.patch src
[22:42] <PeanutHead> ?
[22:43] <mDuff> PeanutHead, src is what you have that you want to submit, not where you started from, right?
[22:44] <lifeless> PeanutHead: 'send -o fix.patch BRANCH_YOU_MADE_YOUR_BRANCH_FROM'
[22:45] <PeanutHead> src is the directory where I started my branch
[22:45] <PeanutHead> lifeless, BRANCH_YOU_MADE_YOUR_BRANCH_FROM means branch nick??
[22:45] <mDuff> PeanutHead, it isn't the branch that the upstream people you're submitting your patch to have, though, right?
[22:46] <mDuff> PeanutHead, when you did your initial "bzr branch", you provided a remote URL to someone else's system, I'm assuming; that URL is probably what you want to use here.
[22:47] <PeanutHead> no.. i didnt provide an URL
[22:47] <PeanutHead> mDuff, I'm using it locally and then I'm supposed to send the changes
[22:47] <lifeless> PeanutHead: how did you get your local branch
[22:48] <PeanutHead> lifeless, bzr init
[22:48] <PeanutHead> lifeless, bzr add
[22:49] <lifeless> PeanutHead: and the person you want to send these changes to, they are already using bzr?
[22:49] <PeanutHead> lifeless, bzr commit -m "msg"
[22:49] <PeanutHead> lifeless, yeah he is using
[22:49] <mDuff> PeanutHead, ahh -- you should have made your branch by branching their remote branch, not by running a new "bzr init"
[22:50] <lifeless> PeanutHead: so, what you have done is start a branch new project in bzr, rather than work on his project; you need to do 'bzr branch HIS-BRANCH LOCAL-PATH'
[22:50] <lifeless> then cd LOCAL-PATH
[22:50] <lifeless> make your changes
[22:50] <lifeless> bzr commit -m 'MSG'
[22:50] <lifeless> and then 'bzr send'
[22:52] <PeanutHead> lifeless, let me try
[22:52] <mfoniso> lifeless:thanks for the suggestions... it turns out I have to upload my ssh keys to launchpad, but it won't accept the ones I have which were supposedly created using a vulnerable ssh suite. And I'm having problems upgrading to the fixed ssh suite. I'll just leave it for later. I'm going to sleep
[22:53] <lifeless> mfoniso: gnight
[22:53] <PeanutHead> lifeless, it is asking for an email address.. should I simply add an email address?
[22:53] <lifeless> PeanutHead: of the person you want the changes sent to, yes
[22:55] <PeanutHead> C:\Documents and Settings\David Nemer\workspace\Projektarbeit\src>bzr send ../src dmerge@gmail.com
[22:55] <PeanutHead> bzr: ERROR: No mail-to address specified.
[22:55] <PeanutHead> lifeless, still says that no email is specified
[22:56] <lifeless> PeanutHead: 'bzr send HIS-BRANCH'
[22:56] <lifeless> PeanutHead: no other parameters
[22:56] <lifeless> PeanutHead: no other options
[23:01] <PeanutHead> lifeless, I guess it works now! thanks so much for your help
[23:01] <PeanutHead> mDuff, thank you too man
[23:12] <poolie> hi lifeless
[23:12] <poolie> net is flakey
[23:15] <lifeless> the hi poolie1
[23:15] <lifeless> was mailing jam
[23:18] <lifeless> poolie1: if jam can run up skype that would be better voice quality
[23:35] <Pieter> igc: did you see the fastimport patches?
[23:38]  * jml does a thing he hasn't done before
[23:43] <poolie1> lifeless: i was wondering about calling this new format 'mesh' to continue the theme
[23:43] <lifeless> mesh?
[23:44] <jdong> that's a neat buzzword :)
[23:44] <poolie1> knit, weave, mesh
[23:44] <poolie1> i think it needs some short non-acronym name
[23:45] <thumper> is there a way to reconfigure a shared repo with trees to be a shared repo without trees?
[23:45] <jml> yes
[23:45] <jml> (or maybe no)
[23:45] <jml> but probably yes.
[23:45] <thumper> jml: thanks, but I really want a command to run
[23:45] <jml> no, I can't see an option.
[23:46] <abentley> thumper: touch .bzr/repository/no-working-trees
[23:46] <jml> thumper: if you are trying to switch over to a "shared repo without trees + lightweight checkout" layout, I wrote a plugin to do just that.
[23:46] <thumper> abentley: oh, nice integrated command then :)
[23:46] <Odd_Bloke> That seems like something that should be 'reconfigure'able...
[23:46] <abentley> Odd_Bloke: indeed.
[23:47] <jml> thumper: https://code.edge.launchpad.net/~jml/+junk/bzr-establish -- the code is pretty bad.
[23:48] <thumper> jml: I'm sure it is awesome
[23:48] <Odd_Bloke> jml: Some of the docstrings are wrong. :)
[23:48] <jml> Odd_Bloke: all part of the fun :)
[23:49] <Odd_Bloke> :D
[23:49] <jml> thumper: your confidence overwhelms me :P
[23:49] <Odd_Bloke> Anyway, I should avoid getting sucked into that, as I have work tomorrow. D:
[23:57] <mDuff> btw -- I've been working with git recently; one of the (few) things I like about its UI is the ease of working with branches. Have helpers been added to bzr while I wasn't paying attention (read: anywhere in the last few years) to offer similar terseness in addressing different branches within the current project's repo? "bzr switch" appears to do The Right Thing, for instance, but I don't see a way to do something similar with "bzr branch" w
[23:57] <mDuff> ithout specifying a full path to the repo; likewise for ease of deleting old branches, checking branch status (ie. listing which are merged/unmerged)...
[23:58] <poolie1> only in a very limited way with switch
[23:59] <poolie1> there was a recent thread
[23:59] <lifeless> mDuff: there is a plugin that lists branches that can be deleted/merged
[23:59] <lifeless> jml: ^ was it yours?
[23:59] <poolie1> i think having easier access to branches would be good; otoh having branches simply at urls is good
[23:59] <jml> lifeless: yes.
[23:59] <jml> bzr-removable