[00:00] so its simpler to explain to say that bind just sets the flag [00:00] if someone else has pushed, after binding, do 'bzr update; bzr commit' [00:00] which will merge, and commit, keeping your local commits as a merge to the new origin tip [00:00] vila: is vc-bzr still developed, or has dvc subsumed it? [00:01] if you want to do a fast-forward push, just bzr push url [00:02] fast forward? [00:02] w00t_: oh, using a git term; just a normal push :) [00:05] vila: bob2 do either of you actually use dvc? [00:06] lamalex: no [00:06] 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] 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] lamalex, I use dvc daily [00:08] vila: is there a relevant section of your .emacs i could take a look at? [00:09] sure, but what are you after more precisely ? [00:09] vila: evil but clever [00:09] have to incorporate ropemacs into that somehow [00:09] ropemacs ? [00:10] 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] refactoring dealy, along the lines of bicycle repair man [00:11] bob2: oh, can I orphan brm then? [00:11] lamalex, I think the default binding is C-x V (not 'v') [00:11] shouldn't a mode show up when I do M-x dvc- though? [00:11] I don't see anything [00:12] lifeless: dunno if it has any vim integration yet [00:12] lamalex: did you load it? [00:12] lamalex, ha ! You're right... but you're wrong :-/ [00:12] lol [00:12] good old emacs [00:12] lamalex, try dvc-status when in a file under bzr control and see [00:12] bob2: there is ropevim [00:12] huzza [00:13] http://rope.sourceforge.net/ [00:13] that opens a new buffer [00:13] lamalex, or try dvc-diff [00:13] so do I type a commit message in that? [00:13] lamalex, no wait [00:14] ok yah now i see bzr status [00:14] so i do -x c [00:14] no [00:14] :_ [00:14] :) [00:14] gr [00:14] lol [00:14] sorry ;) [00:14] try dvc-diff first [00:15] ok [00:15] 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] lifeless: hmm. so i'll have to push each branch seperately? [00:16] 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] ok so im in dvc-diff [00:16] /now/ Do C-x V c? [00:16] now, dvc-diff buffers are indeed in a specialized diff-mode mode [00:16] no :) [00:16] just 'c' [00:17] ok so c takes me too a buffer with a commit message [00:17] how do I accept that message [00:17] should open a dvc-edit-log-mode buffer when you add your [00:17] C-c C-c [00:17] lifeless: heh, I'm now getting bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. [00:17] w00t_: yes, most pushes in bzr are single branch (branch is the basic user object folk work with) [00:18] lamalex, and now you *must* refresh your dvc buffers :-/ [00:18] 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] (when trying to push to the empty svn repo) [00:18] lifeless: ok, thanks, I do appreciate your help and patience [00:18] ah ha [00:18] I'll wait around to see if jelmer has a few moments :) [00:18] hmm how do i refresh the buffers? [00:18] 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] w00t_, lifeless: Hi [00:19] hey there! :) [00:19] w00t_, You can't push to the root of the repository, you probably want to push to /trunk [00:19] w00t_, if you would like to push the merged revisions as well, use --merged [00:19] jelmer: aha! a bit of a confusing error message :) [00:19] hmm, merged revisions.. can you elaborate on that a bit for me? [00:20] 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] w00t_, merged revisions are revisions which are not on the mainline [00:21] w00t_, the revisions shown indented when running "bzr log" [00:21] hm [00:21] oh, I see [00:21] revisions that occured on another branch [00:21] vila: thanks for your help [00:21] lamalex, you're welcome [00:22] at the very least the diff and commit will be useful [00:22] is there a way to push quickly? [00:23] w00t_, Does that help? [00:27] jelmer: hmm. [00:27] jelmer: it went through a lengthy import process, and then: [00:27] bzr: ERROR: Prefix missing for branches/merged; please create it before pushing. [00:30] w00t_, please create the "branches" directory in the svn repository [00:30] jelmer: hmm, that also imported, but didn't preserve committer name/timestamp -- i guess that is wishful thinking then [00:30] w00t_, it can, but you have to set an extra option [00:31] ..oh.. what do I do after creating that directory? just try push again? [00:31] poolie: btw, for the tree logic, I'm allowing mutable nodes internally for now, to get it up and running. [00:31] w00t_, yep [00:31] w00t_, (newer versions of bzr-svn will do that for you) [00:31] w00t_: to keep properties, set "override-svn-revprops = svn:date;svn:author" [00:31] hm [00:32] where do I set that? I imagine there is some kind of either repo or user-level config [00:32] yeah, ~/.bazaar/subversion.conf [00:34] thanks! [00:34] i shall try experiment with this some more tomorrow [00:34] it looks promising :-) [00:36] cool :-) [00:36] for now, bed for me [00:36] thanks for your help lifeless and jelmer :-) [01:38] lifeless: hey, want to catch up sometime? === mw is now known as mw|out [02:04] lifeless, Could it be that PQM doesn't support ftp:// either atm ? [02:21] jelmer: absolutely; different machine, firewalled [02:23] lifeless: Ah, ok. I'll just fall back to http for now - thanks [02:25] 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] is it possible to add/update a file to a bzr repo, without checking out the entire tree? [03:37] spiv: care to join #gnome-bzr on gimpnet [03:38] adeel: using the bzrlib api, yes, but not using the regular commands [03:39] lifeless, can you clarify how that'd work? [03:40] adeel: you'd create a MemoryTree object from the branch tip, make your changes, and commit the MemoryTree [03:40] 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] lifeless, is that procedure documented anywhere? [03:42] adeel: yes, in the bzrlib programming documentation [03:42] lifeless, one last question, does bzr support overlays? [03:42] adeel: but I don't think its what you need; you want something like views, which is proposed but not finished [03:43] 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] heh, no...i meant overlays in the svn sense [03:43] I don't know what they are [03:43] or multiple working copies at the same time [03:44] uhm, clearly we support that, or people couldn't ever work on more than one project [03:44] or do you mean co-located ina single directory? [03:44] yes, in a single dir [03:44] no [03:45] you can nest working copies [03:45] but you can't colocate multiple working copies at a single dir [03:45] good to know, i can work around that [03:46] thanks for the help === cprov is now known as cprov-zzz === arjenAU2 is now known as arjenAU [06:20] What is "CHK"? [06:21] content hash key === jamesh_ is now known as jamesh === RAOF_ is now known as RAOF === Mario__ is now known as pygi === jszakmeister|awa is now known as jszakmeister [09:07] hi [09:08] is there a(n easy) way to run bzr from the ppa with bzr-svn? [09:09] it says "bzr-svn: Depends: bzr (< 1.8~) but 1.9-1~bazaar1~intrepid1 is to be installed" === lifeless_ is now known as lifeless [09:59] robsta: yes. mkdir ~/.bazaar/plugins ; bzr get lp:bzr-svn/0.4 ~/.bazaar/plugins/svn [09:59] oh, thanks, guess i'll wait for the deb, then [10:00] OTOH, it would be nice if the ~bzr PPA would have updated packages for bzrtools and bzr-svn, though. [10:00] 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] jelmer: hmm, I really don't know what I've done wrong [10:59] 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] hullo everyone [11:38] I've just updated my Ubuntu to Intrepid [11:39] I have PPA repositories configured [11:39] and corrected them accordingly [11:39] which updated bzr to 1.9 [11:39] so === jszakmeister is now known as jszakmeister|awa [11:40] now I get [11:40] bzr: ERROR: Version mismatch [11:40] when I issue "bzr status" [11:41] g0nzal0: any other information? [11:41] or "bzr diff somefolder/somefile" [11:41] poolie: such as? I'm totally lost here :( [11:42] is that the only error message it prints? [11:42] how about if you try "less ~/.bzr.log" [11:43] well, a warning about bzr-svn is also printed [11:43] ok [11:43] i think this means bzr-svn is out of date in the ppa [11:43] $ bzr diff surveygen/views.py [11:43] bzr-svn is not up to date with installed bzr version 1.9. [11:43] There should be a newer version of bzr-svn available. [11:43] bzr: ERROR: Version mismatch [11:43] and does it just stop there? [11:43] yup [11:43] jelmer: What's the state of bzr-git these days? [11:44] 'morning [11:44] poolie: whoa ~/.bzr.log has a Traceback!!!! :) [11:45] poolie: http://dpaste.com/89976/ [11:51] poolie: removing bzr-svn (I didn't really used it much, will reinstall it if needed) did the trick, thanks! [11:58] ok [11:58] it should be updated soon [12:04] hey [12:05] when i try to push the newst version that error message comes: Permission denied (publickey). [12:05] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [12:05] whats the problem? [12:05] Spoob: Are you trying to push to Launchpad without having set up a public key on Launchpad? [12:06] Odd_Bloke: i already set my ssh key in launchpad [12:06] Spoob: Well, apparently not. ;) [12:07] Can you use ssh to Launchpad? [12:07] hey how can i push a specific file from revno x? [12:07] i don't want to revert [12:07] i just want to get in into a serparate folder [12:07] Odd_Bloke: how can i try it? [12:08] Spoob: 'ssh bazaar.launchpad.net', maybe. [12:08] Permission denied (publickey). :S [12:08] how can i register the to bzr? [12:08] EarthLion_: 'bzr cat -r ' will show you the contents of at the given revision. [12:09] Spoob: You haven't set your public key up properly, it would seem. [12:09] Odd_Bloke: i already did it, im sure, https://launchpad.net/~spoob [12:10] Odd_Bloke: thank you so much :) [12:10] EarthLion_: No worries. [12:11] Spoob: Well, your SSH client isn't using the key, I guess. [12:11] how can i set bzr up to my ssh key? [12:11] 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] Then bzr should work fine. [12:12] Spoob: Try 'ssh bazaar.launchpad.net -vv', that'll give you more output. [12:16] Don't you need the username so it knows which authorized_keys to check? [12:17] Hmm, yeah, but I'm guessing there'll be a message about not even finding a public key. [12:17] Spoob: Try 'ssh @bazaar.launchpad.net'. [12:18] Odd_Bloke: yeah now it works, really thank [12:29] Spoob: And you're able to push properly? [12:29] yeas, but now i cant my files here https://code.launchpad.net/~spoob/+junk/main :P [12:30] Spoob: Have you added the files and committed your changes? [12:31] yes [12:31] but i do it again now [12:33] ah now it works thanks! === mlh_ is now known as mlh [13:28] w00t_, hi [13:29] jelmer: morning! :) [13:29] Kinnison, it can import from local git repositories, though it's a bit slow [13:35] :-( [13:35] * Kinnison prods someone to keep doing the svn mirror for now [13:58] w00t_, if you use the latest revision from the 0.4 branch, there's a separate command-line option [14:02] jelmer: i'm using ubuntu's packages.. :( [14:18] hi [14:19] i'm running intrepid, is there a way to enable nautilus integration? [14:19] yes [14:21] 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] 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] Steven1, but it is not fully usable yet i'd say, it's on its way :) [14:24] chevdor: thanks, i was just curious :P i think i'll wait a little, command line works well :) [14:26] Steven1, it is moving fast though, check out in a few weeks [14:27] ok, thanks, is there any chance to see loggerhead packaged? [14:35] Steven1, there's a package in Debian experimental that will hopefully make it into jaunty [14:37] nice === sdboyer is now known as sdboyer|class [14:53] * rocky has given up on relying for bzr-connected pkgs in ubuntu ... always out of date [14:57] w00t_, what did you set in subversion.conf exactly? [14:58] jelmer: one moment [14:58] I tried both: [14:58] override-svn-revprops = svn:date, svn:author [14:58] and: override-svn-revprops = svn:date;svn:author [14:59] in subversion.conf as well as bazaar.conf (your FAQ said to use that, at least..) [15:00] w00t_, in the section for the repository you're pushing to? [15:00] jelmer: ah. no, does it need to be? [15:00] w00t_, yeah [15:00] 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] (also, is the comma or the semicolon version correct?) [15:01] w00t_, The section name is the repository UUID (svn info ) [15:01] hmm and how may I retrieve the uuid? [15:03] w00t_, it's printed by "svn info " [15:04] jelmer: okay, I shall give it a go. which should I use, comma or semicolon? [15:04] so is bzr-hg essentially dead? [15:04] rocky, yeah [15:04] w00t_, Not sure, actually; I *think* it's semicolon [15:05] that's too bad, i wanted to mirror a hg branch in bzr to make it easier to work on [15:06] 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] rocky, no, sorry :-/ [15:13] 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] hno: right, i guess the hard part is determining what changed between vendor releases and applying just that into my separate branch [15:14] oh wait [15:14] hno: mind elaborating on the import-into-vendor-branch part? [15:14] rocky: bzr does that for you.. just import as-is into the vendor branch.. [15:14] w00t_, any luck? [15:15] 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] rocky: Yes. [15:16] hmm [15:16] and do your own work on a separate branch, using bzr merge to bring changes over from the vendor branch. [15:16] right [15:16] awesome thanks [15:16] that's the sort of pattern i was looking for [15:17] rocky: this pattern works with any VCS supporting merges... [15:17] hno: sure, i've just never had to do anything like this before ;) [15:19] jelmer: kind of caught up in an emergency.. sorry [15:24] jelmer: another bzr-svn issue... http://cluebin.appspot.com/pasted/3002 [15:25] whoa [15:27] jelmer: btw, when i do a branch like that, does it download all the rev info for the entire remote svn repo ? [15:27] i hope not, because that svn repo is HUGE and hosts many many projects [15:28] yes, it downloads the metadata for all revisions (not the contents) [15:28] that repo has 75k revisions :( [15:28] it's a one-time operation though [15:29] and it's quite fast (looks like it's only a couple of minutes here) [15:30] ah cool [15:31] 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] rocky, can't reproduce that here [15:53] rocky, can you remove the svn cache and try again ? Are you running the 0.4 branch? [15:55] rocky, did you use earlier versions of bzr-svn with this repository? [16:06] 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] jelmer: but if you look at my paste you can see it is initializing the svn cache for that repo [16:06] so that makes it seem like it's "from scratch" [16:06] hmm, right [16:06] are you out of disk space perhaps? [16:08] 2gb free [16:08] not enough? [16:09] yeah, that should be plenty [16:09] can you try again, just in case? [16:09] would be really weird if it did work, but it does work here [16:09] i'm trying again [16:10] i deleted the specific cache dir [16:10] running a lot faster than i expected actually.. already through 14k revs [16:10] (last time i ran it under emacs eshell which meant i wasn't getting status info) [16:11] jelmer: when you ran it, did you run it against python2.5 or python2.6 ? [16:11] it just blew up again [16:11] 2.5 [16:11] i'm using 2.6 which probably comes with a diff sqlite3 version which could be the difference [16:11] can you try with 2.5 perhaps? [16:13] hrm, would have to rebuild my environment [16:20] jelmer: it's a lot further along now with py2.5 [16:21] if it does turn out to be python2.6, please file a bug [16:21] I'll be back in a couple of hours [16:35] jelmer: does this look correct, then? (emergency over ;-)) [33d11fd1-86b3-441f-987f-5b8a439e6865] [16:35] locations = file://localhost/var/git/public/crazyshit/a-s [16:35] override-svn-revprops = svn:date, svn:author [16:35] (excuse language, that really is the dirname, should have thought first) [16:36] w00t_, yeah, that looks ok [16:36] right, I shall give it a go then [16:37] alternatively, you can just set it to "True" [16:37] instead of "svn:date, svn:author" [16:37] hmm, that sets all properties I assume [16:37] bzr: ERROR: Unable to set revision property svn:author. [16:38] I guess that means my hook is wrong [16:38] * w00t_ investigates [16:38] yeah, that would indeed suggest the hook is wrong [16:41] 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] cool :-) [16:41] jelmer: if I might make a suggestion -- would it not make sense to default this setting to on? [16:41] The first one would've been incorrect because it adjusts the properties after you push the commit [16:41] (and after the first commit you got that warning) [16:42] *nod* [16:42] I understand why it messed that up, I shall do another import to fix it [16:42] You can also just adjust the first revision manually [16:42] (*sigh*, this has to be like the 99th time I've recreated this repo now :-)) [16:42] oh. I didn't know that.. [16:42] (svn propset --revprop -r ) [16:43] now I guess I need to read up on bazaar so I can use it properly :-) [16:43] 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] jelmer: oh. good point! [16:44] jelmer: turned out to be specific to py2.6 ... i'll setup a bug report here when i get a chacne [16:44] rocky, thanks [16:44] elmer: (though a param to svn-push would perhaps work too? [16:44] w00t_, there is a parameter to svn-push in the 0.4 branch :-) [16:45] jelmer: oh! fantastic [16:45] now I'll just have to wait until ubuntu picks it up... :-P [16:45] jaunty should have it.. [16:46] ah. [16:46] good, because I'll probably be running it when it hits alpha [17:56] 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 === jszakmeister is now known as jszakmeister|awa [18:32] Peaker: Bazaar supports more types of merging than just 3-way. [18:33] abentley: what advantage does 3-way have over looking at all the intermediate revisions? [18:33] Peaker: It's faster and easier to understand. [18:34] correctness over performance? :-) [18:35] 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] Peaker: It is. We have experience with peoples' reaction to weave merge conflicts, and they can't tell what's going on. [18:37] With 3-way, you can look at the different versions and see why it's doing what it's doing. [18:37] When there are N versions, that's essentially impossible. [18:38] abentley: I see [18:38] 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] abentley: zooko says its worse, you get no conflict, but a wrong merge silently [18:41] abentley: square was renamed and a new square function was written, and the merge takes the new square to be the old.. [18:41] You were talking about "a newbie facing a conflict". [18:41] oops, my bad ;) [18:41] I guess its a newbie getting a wrong merge [18:42] Peaker: Yes. No merge will ever be perfect. The best defence is a test suite. [18:42] abentley: does weave introduce confusing conflicts that 3-way doesn't? If not, what was confusing about its merges? [18:45] Peaker: I don't think it produces them more often, but when it does, they may be more confusing. [18:46] Because they are caused by information that you can't see. [18:48] you could see the whole 2 diff paths side-by-side, rather than 2 big patches side-by-side? [18:48] Peaker: I don't understand the question. [18:49] abentley: you said its based on information you cannot see, why not show it? [18:49] the information is all the intermediate revisions, right? [18:50] Peaker: The information is the graph of revision history and the annotation of the lines, and the resulting status of the lines. === thekorn_ is now known as thekorn === kiko-afk is now known as kiko === mw is now known as mw|food [20:00] Has anyone here used bzr-svn? [20:00] yep :-) [20:00] lol [20:01] 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 [20:01] 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] 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] bzr is telling me that : bzr: ERROR: [Errno 17] File exists: '/' [20:03] 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] mDuff: ok that will do I was looking for a --overwright option [20:05] mDuff: but what you propose seems to be a workable solution [20:05] gauthierm, if the history is linear (no merge commits) you should be able to just use "bzr push" [20:12] mDuff: Do you know the option on top of your head to overwrite with rsync [20:13] yml, rsync -ra source_dir/. dest_dir/. should do that by default. [20:13] I try rsync [20:13] yml, the /. is there for a reason. [20:14] yml, same with the -ra [20:14] ok [20:14] mDuff thank you for your kind assitance [20:14] jelmer: Yep, its linear. Do I just point to hte svn repo in the bzr push command? [20:15] gauthierm, yes [20:15] nice [20:18] 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] It's worth mentioning that I did a clean export of the code (no svn info) before starting my work in bzr. [20:18] gauthierm, ah, so the original branch wasn't created using bzr-svn ? [20:18] jelmer: nope. I used svn export and then bzr init. [20:19] ...oh; that's not good. [20:19] gauthierm: In that case, it's not so easy to push your changes into svn [20:19]