| benzo | bye and thanks for your patiente | 00:00 |
|---|---|---|
| benzo | patience | 00:00 |
| benzo | LarstiQ, are you still there? | 00:00 |
| benzo | one last question | 00:00 |
| benzo | I made already a repository on the server but at the wrong place. | 00:01 |
| benzo | can I simply move the folder? | 00:01 |
| LarstiQ | how did you create it? | 00:02 |
| benzo | on the server: $bzr whoami | 00:02 |
| LarstiQ | ie, did you make a standalone branch and are you calling that a repository, or did you actually create a shared repository with branches underneath? | 00:02 |
| LarstiQ | since you seem to come from svn you might be conflating some terms there | 00:03 |
| benzo | seems so | 00:03 |
| LarstiQ | benzo: was all you did 'bzr init foo'? | 00:03 |
| benzo | i went to the 5-min tut http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html#viewing-the-revision-log | 00:03 |
| LarstiQ | or have you done a 'bzr init-repo bla' too? | 00:03 |
| benzo | just $ bzr init | 00:04 |
| benzo | then $ bzr add | 00:04 |
| LarstiQ | ok, you can just mv that around as you wish | 00:04 |
| LarstiQ | if you had branches in a repository, you would need to move around the entire repository | 00:04 |
| benzo | ok thanks - and good night now | 00:04 |
| LarstiQ | since branches store their actual revisions there, and if you move them out of their repository they won't be able to find any | 00:05 |
| LarstiQ | ok, thanks | 00:05 |
| * LarstiQ detaches | 00:05 | |
| ubotu | New bug: #202374 in bzr "pull and update should accept --show-base" [Undecided,New] https://launchpad.net/bugs/202374 | 00:21 |
| benzo | i try to checkout, but it dont work | 00:38 |
| benzo | something is wrong with my auth. config. | 00:38 |
| benzo | ... i guess ... | 00:38 |
| === mw is now known as mw|out | ||
| nekohayo | hey there folks, is there a way for me to know if one of my folders is a "branch" vs a "checkout"? | 15:35 |
| Peng | bzr info? | 15:35 |
| Peng | If it's a checkout, "bzr pull" would probably fail. | 15:35 |
| nekohayo | Peng: I think that's it! thank you :) | 15:36 |
| nekohayo | so Standalone tree (format: dirstate) means it's a branch, and that it's independent right? | 15:36 |
| dsargeant | hi, I'm using bzr 1.2 candidate 1 from Hardy. A file was renamed outside of bzr during a refacgtoring. How do I tell bzr that a file was renamed, not removed and another added? In previous versions of bzr I could use bzr mv, but now that fails. | 15:36 |
| schierbeck | dsargeant: have you made changes to the file? | 15:37 |
| schierbeck | it should figure it out by itself... | 15:37 |
| Peng | nekohayo: I dunno. I think so. | 15:38 |
| dsargeant | schierbeck: yes, some variables in the file were renamed | 15:38 |
| spiv | nekohayo: right | 15:38 |
| schierbeck | try moving it back manually, then redo the move with bzr mv | 15:38 |
| Peng | dsargeant: Well, bzr mv isn't supposed to fail. Got a testcase? | 15:38 |
| spiv | dsargeant: try "bzr mv --after ..."? | 15:39 |
| schierbeck | Peng: i think it's because the source of the move doesn't exist any more | 15:39 |
| Peng | schierbeck: That's the point of "bzr mv --after"... | 15:39 |
| schierbeck | spiv: oh, didn't know that one! cool! | 15:39 |
| schierbeck | awesome | 15:39 |
| Peng | Oh, ok. | 15:39 |
| schierbeck | well, you learn new stuff every day, huh? | 15:40 |
| Peng | :) | 15:40 |
| dsargeant | Peng: the reason it fails is that it says the source of the mv is unversioned. When I do a bzr st, the src is listed as removed. | 15:40 |
| dsargeant | spiv: --after produced the same result | 15:40 |
| Peng | Testcase? | 15:41 |
| james_w | hi jam. Hows the conference? | 15:42 |
| spiv | dsargeant: can you pastebin the error? | 15:42 |
| dsargeant | Peng: what's the best way of giving you a test case? | 15:42 |
| spiv | james_w: the connectivity seems better today. | 15:42 |
| james_w | ah, you're there as well :) | 15:42 |
| * spiv -> snacks | 15:43 | |
| dsargeant | spiv: the error is: bzr: ERROR: Could not rename Graph.java => TouchGraph.java: src/main/java/Graph.java is not versioned. | 15:43 |
| james_w | dsargeant: are you trying this in src/main/java? | 15:43 |
| james_w | dsargeant: if so try it in the root and use the full paths. | 15:44 |
| james_w | dsargeant: I don't know if it will help, but it is worth a try. | 15:44 |
| dsargeant | james_w: I'm trying it from the root of the project that contains .bzr | 15:44 |
| dsargeant | james_w: Very sorry, I rechecked my paths and was missing a directory. src/main/java/Graph.java, should have been src/main/java/graph/Graph.java. Thanks for your help guys. | 15:46 |
| nekohayo | hm, is there a way to merge things properly when two branches have no common ancestor? well actually they do codewise, but the 2nd is lacking the history of the 1st one and I'm trying to fix that x_x | 15:46 |
| james_w | dsargeant: no problem. | 15:48 |
| james_w | nekohayo: yes, bzr merge -r0..-1 ../other-branch | 15:49 |
| james_w | nekohayo: however it will give you lots of conflicts, and may not be very useful at all. | 15:49 |
| nekohayo | james_w: I still get an "ERROR: Revision {('wout@wout-laptop-20071012201326-65ijzopxe5uj94tq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c6cbcc>". | 15:51 |
| nekohayo | any idea what that means? | 15:51 |
| nekohayo | this happens whether I use -r0..-1 or not | 15:51 |
| james_w | oooh, interesting. | 15:52 |
| james_w | nekohayo: hmm, works on a quick test that I did. | 15:53 |
| james_w | nekohayo: what version of bzr are you using? | 15:53 |
| nekohayo | james_w: 1.2.0.candidate.1 | 15:54 |
| james_w | nekohayo: I'm not sure then. | 15:54 |
| nekohayo | james_w: would you like me to provide the two branches that I'm trying to merge as a sample for you? | 15:54 |
| james_w | nekohayo: can you try to run with -Derror and paste the traceback? | 15:55 |
| nekohayo | sure | 15:55 |
| james_w | nekohayo: that may be necessary, but we'll try this first. | 15:55 |
| nekohayo | james_w: http://pastebin.ca/943767 | 15:56 |
| james_w | nekohayo: and you get the exact same error with -r0..-1? | 15:58 |
| nekohayo | yes | 15:58 |
| nekohayo | james_w: need the debug output for that one too? | 15:59 |
| james_w | nekohayo: sorry, went to grab some lunch | 16:01 |
| james_w | nekohayo: I don't need to output if it is the same. | 16:01 |
| james_w | nekohayo: so, let's look a bit deeper. | 16:01 |
| james_w | are these branches sharing a shared repository? | 16:02 |
| nekohayo | how do I know? | 16:03 |
| nekohayo | both are Standalone tree (format: dirstate) | 16:03 |
| james_w | ls .bzr/repository in one of them. | 16:04 |
| nekohayo | formatinventory.knitlockrevisions.knit signatures.knit inventory.kndxknitsrevisions.kndxsignatures.kndx | 16:05 |
| james_w | ok, so there's no shared repo involved | 16:05 |
| nekohayo | the other branch has only "format indices lock obsolete_packs pack-names packs upload" | 16:06 |
| spiv | (bzr info output is a good way to determine that too) | 16:06 |
| james_w | spiv: yeah, I'm not always sure how to interpret that now. | 16:06 |
| james_w | nekohayo: so that means one is packs and one is knits, that may be significant. | 16:06 |
| james_w | nekohayo: which one was which in the above output (i.e. was it the first or second that you ran the merge command in)? | 16:08 |
| nekohayo | "format indices lock obsolete_packs pack-names packs upload" comes from "specto-jeff-new", which is the branch that contains the older history, into which I am trying to merge specto-jeff which contains newer stuff but no backwards history | 16:09 |
| james_w | nekohayo: cool, let me try that | 16:12 |
| nekohayo | james_w: you need my samples? | 16:12 |
| james_w | nekohayo: ok. so without -r0..-1 you should get "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." | 16:12 |
| james_w | so something seems to be broken in the branch "specto-jeff-new". | 16:13 |
| nekohayo | james_w: nay, when I do it without -r0..-1 I get the same errer | 16:13 |
| james_w | can you try "bzr log -r revid:wout@wout-laptop-20071012201326-65ijzopxe5uj94tq" in that branch. | 16:13 |
| nekohayo | that is ERROR: Revision {('wout@wout-laptop-20071012201326-65ijzopxe5uj94tq',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x8c3eb8c>" | 16:13 |
| spiv | Maybe also worth trying "bzr check"? | 16:14 |
| james_w | nekohayo: I understand that you do, but you should get the above more sane error, and as you don't it indicates that something is a bit broken. | 16:14 |
| james_w | also what spiv suggests make sense. | 16:14 |
| nekohayo | james_w: bzr log works in specto-jeff (obviously not in specto-jeff-new) | 16:14 |
| spiv | Although it seems fairly likely that that branch is referring to a revision that doesn't exist in its repository. | 16:14 |
| james_w | nekohayo: why doesn't it work in -new? | 16:15 |
| nekohayo | james_w: because -new contains older code (remember, I'm trying to merge specto-jeff into it :) | 16:15 |
| spiv | Which would mean specto-jeff-new is broken. I'd be interested to know how that happened. | 16:15 |
| nekohayo | spiv: the whole affair is that specto-jeff was started without the version history | 16:16 |
| nekohayo | and I'm trying to rectify that | 16:16 |
| nekohayo | spiv, james_w: http://pastebin.ca/943780 | 16:17 |
| nekohayo | also, see: ecchi.ca:8000/1.png | 16:20 |
| james_w | nekohayo: I'm a bit lost now. | 16:20 |
| nekohayo | that screenshot *might* help you | 16:20 |
| nekohayo | on the left is the "full history" specto-jeff-new | 16:20 |
| nekohayo | on the right is the newer but broken specto-jeff from which I'm trying to merge | 16:21 |
| james_w | and 'wout@wout-laptop-20071012201326-65ijzopxe5uj94tq' is the last revision in that branch? | 16:21 |
| james_w | -jeff I mean? | 16:21 |
| nekohayo | hmm, I doubt so | 16:23 |
| james_w | I guess not, it's not the first is it? | 16:23 |
| james_w | I'm just wondering why it is that revision in particular that it is choking on. | 16:23 |
| nekohayo | it's not the first either | 16:24 |
| james_w | nekohayo: ah, ok, that is a random revision from a set() of missing. | 16:24 |
| james_w | Can you please run the command again with BZR_PDB=1 set? | 16:25 |
| james_w | that will drop you in to a debugger as the error is raised. | 16:25 |
| james_w | you can then "p missing" | 16:25 |
| james_w | I am guessing it will print a large number of revisions. | 16:25 |
| nekohayo | "bzr merge ../specto-jeff BZR_PDB=1" ? | 16:26 |
| james_w | BZR_PDB=1 at the start please. | 16:26 |
| james_w | It's an environment variable, so it goes before the command, in this case "bzr" | 16:26 |
| nekohayo | (Pdb) p missing | 16:27 |
| nekohayo | set([]) | 16:27 |
| nekohayo | and I'm back at the debugger prompt | 16:27 |
| james_w | weird, so it is just that one revision. | 16:27 |
| spiv | That revision does exist, but not in -new. | 16:28 |
| spiv | It's odd wcurious that it's apparently trying to find it in -new. | 16:28 |
| nekohayo | need my branches :) ? | 16:30 |
| james_w | nekohayo: can you type "up" in the debugger 12 times please? | 16:30 |
| nekohayo | ok | 16:30 |
| james_w | then "p source" | 16:31 |
| james_w | "p self" | 16:31 |
| nekohayo | that's all? | 16:31 |
| spiv | Hmm, I wish looms had a "rename-thread" command. | 16:31 |
| nekohayo | james_w: http://pastebin.ca/943795 | 16:32 |
| james_w | spiv: you can probably edit something. | 16:32 |
| james_w | spiv: though I don't know if would be handled by merging. | 16:32 |
| james_w | I think eventually it will be supported though. | 16:32 |
| james_w | nekohayo: thanks, can you also "p inter" please? | 16:34 |
| nekohayo | james_w: <bzrlib.repository.InterModel1and2 object at 0x8750e2c> | 16:39 |
| james_w | nekohayo: thanks, one minute | 16:41 |
| nekohayo | it fascinates me that some humans can understand that one line of letters and numbers :) awesome | 16:43 |
| james_w | nekohayo: ok, I think I'll need the branches. | 16:48 |
| james_w | My current guesses are that it there is discrepancy between what it thinks it needs to fetch and what it then requires to be fetched. | 16:49 |
| james_w | Or there is corruption that is not being detected by check. | 16:49 |
| nekohayo | james_w: you should be able to pull them from ecchi.ca:8000/trunks/ normally | 16:52 |
| nekohayo | oops, doesn't work | 16:52 |
| nekohayo | ah ok, yeah branching works | 16:53 |
| nekohayo | james_w: were you able to branch from there correctly?= | 16:58 |
| james_w | nekohayo: yep, thanks I can reproduce the error, so I'll look in to it. | 17:00 |
| nekohayo | ok, so should hang around in this channel today I guess :) | 17:01 |
| james_w | nekohayo: try it, you might like it :) | 17:04 |
| james_w | nekohayo: sorry, I'm not familiar enough with the code that it is having trouble with to debug it. | 17:10 |
| james_w | nekohayo: would you like to post to the list about it? | 17:10 |
| james_w | nekohayo: or I can do it if you like. | 17:10 |
| nekohayo | james_w: if you could do it for me, it would be very nice :) | 17:10 |
| james_w | nekohayo: sure, want a cc? | 17:11 |
| nekohayo | especially because I think you know better than me what needs to be asked and what info needs be provided | 17:11 |
| nekohayo | yes, nekohayo at gmail | 17:11 |
| james_w | well I don't know much more. | 17:11 |
| james_w | nekohayo: are those branches going to stay there, or should I mirror them? | 17:14 |
| nekohayo | james_w: that's on my desktop computer which is on pretty often, but not 100%, so you might want to mirror them, or tarball+attach them? | 17:16 |
| james_w | nekohayo: I'll mirror them, it's no trouble. | 17:16 |
| nekohayo | I'll leave IRC on, but I have to go out for a few hours today so I may not reply fast | 17:17 |
| james_w | nekohayo: sure. | 17:17 |
| james_w | nekohayo: if you ever hit such an ugly error message again it's a bug, even if you think that you may be doing something silly. | 17:18 |
| james_w | nekohayo: so please feel free to report them anyway. | 17:18 |
| nekohayo | well I the hexadecimal stuff made me think so, that's why I came here immediately :) | 17:18 |
| james_w | :) | 17:18 |
| james_w | nekohayo: aha, just found something more. It appears as though there is corruption in specto-jeff. | 17:24 |
| mamato | hi, how can i completely remove files from bzr? i used 'remove' but my .bzr is still huge... | 17:25 |
| james_w | mamato: it's not currently possible to remove files from the history. | 17:25 |
| james_w | mamato: if you were to do that you would have to rewrite history anyway. | 17:26 |
| mamato | wow! | 17:26 |
| james_w | well, rewrite the history of your branch at least. You might be able to leave the rest of the universe alone. | 17:27 |
| mamato | that sounds crazy to me... basically i should just throw away my .bzr and restart one... | 17:30 |
| mamato | sounds like i might as well seriously consider remplacing it with different versionning soft then... :S | 17:30 |
| james_w | mamato: if you are allowed to change the contents of a previous revision then any distributed system will break. | 17:33 |
| james_w | mamato: you can remove old stuff in all of them by rewriting their histories, but you then break any branches that you have made from the one that you rewrite. | 17:34 |
| mamato | i dont really care about braking other branches, i'm the only one using my branch | 17:35 |
| mamato | what does rewriting history entail? | 17:39 |
| james_w | for each revision in your branch removing the stuff that you don't want, and then recording the revision again. | 17:42 |
| mamato | can i delete revisions? | 17:48 |
| mamato | nevermind | 17:50 |
| mamato | how can i how can i commit that modified old revision to its old revision number and not to new one? | 17:51 |
| mamato | james_w? | 17:58 |
| james_w | mamato: you need to do something like rebase. | 17:59 |
| james_w | I don't know a tool already written to do what you want. | 17:59 |
| mamato | i have no rebase command | 18:00 |
| mamato | found plugin | 18:00 |
| mamato | hmm, looks complicated | 18:04 |
| alexreg | hi... is there any way to change log messages of previous commits? | 18:44 |
| Peng | No. | 18:45 |
| LeoNerd | Not really... You could uncommit then recommit it.. but that'll only work for the most recent commit | 18:45 |
| LeoNerd | (I've done that occasionally, to fix up typoes or files I didn't mean to commit) | 18:45 |
| alexreg | ahh...that's what i was thinking | 18:45 |
| Peng | Yeah, you can do that. | 18:45 |
| Peng | But if you've already pushed the revision and other people have pulled it, it wouldn't work so well. | 18:46 |
| LeoNerd | Failing that, you could take a new branch, then somehow do some clever merging and rebasing.. but I wouldn't like to suggest chances of success | 18:46 |
| alexreg | yeah. it works fine for most of the time, but if you realise one of you're log messages before that is bad... | 18:46 |
| LeoNerd | Don't Rewrite History, is my advice | 18:46 |
| alexreg | fair enough | 18:46 |
| Peng | There are lots of typos in bzr.dev's history. :) | 18:46 |
| LeoNerd | A little fudging of something you did two minutes ago is fair enough if nobody's noticed.. Two months is just asking for trouble | 18:46 |
| alexreg | possibly. but just correcting typos or an inaccurate log message couldn't really hurt ? | 18:47 |
| Peng | It would be difficult to manage. | 18:47 |
| alexreg | are there any plans to add log message editting in a future release? | 18:47 |
| Peng | I doubt it. | 18:47 |
| LeoNerd | In theory, just changing the log message shouldn't be a problem.... there's no real data change, no possibility of conflicts with future patches | 18:48 |
| alexreg | that's what i thought | 18:48 |
| LeoNerd | However, in practice it doesn't work like that. The log message is part of the commit | 18:48 |
| alexreg | i see... | 18:48 |
| LeoNerd | The entire commit gets MD5ed or whatever, and becomes part of its hash.. its ID | 18:48 |
| LeoNerd | Changing the log would change the MD5sum, and thus change the identity of the commit | 18:48 |
| alexreg | interesting...why is the log message used to compute the hash? | 18:49 |
| LeoNerd | So anything built on top if it would need changing.. which changes its own hash. all the way down | 18:49 |
| alexreg | it need to be used, i'd think... | 18:49 |
| Peng | (Bzr uses pseudorandom revision IDs...) | 18:49 |
| LeoNerd | The hash is used to avoid sequencing problems a.la. tla | 18:49 |
| LeoNerd | One of tla's problems is that within a branch, the only identity of a patch is its sequence number.. 1, 2, 3,... | 18:49 |
| alexreg | yeah: but shouldn't a hash of the file contents (or even modified date/time) suffice? | 18:49 |
| LeoNerd | This means you can't split offline, and work independently, to merge again later. You'll both take 4 | 18:49 |
| alexreg | right | 18:50 |
| alexreg | ah, maybe i misunderstood "sequencing problems"... | 18:51 |
| alexreg | thanks for the explanations LeoNerd and Peng | 18:51 |
| alexreg | perhaps i'll submit this as a feature request, but it's not a straight-forward matter | 18:52 |
| Peng | Even if bzr wasn't so strict about history being immutable, mutable log messages would be a pain. | 18:52 |
| Peng | What if you pull, and a message has changed. What should it do? Silently overwrite your copy of the message? Prompt you, showing a diff or whatever? | 18:53 |
| alexreg | i don't see any problems if it just overwrites and notifies you | 18:53 |
| Peng | What if someone malicious changes it? | 18:53 |
| alexreg | malicious people wouldn't change things. if they have access to the repo anyway, they can include bad commits | 18:54 |
| Peng | alexreg: Yeah, but they couldn't silently change history. | 18:55 |
| alexreg | true... | 18:55 |
| alexreg | what if only the original commiter could edit their log messages? using their PGP key, that could be verified. | 18:57 |
| alexreg | admittedly, this is turning into a slightly complicated process, but i would still appreciate it existing. | 18:57 |
| Peng | That's an idea. | 18:57 |
| alexreg | so that could be worthwhile request for me to submit. i will need to write out the specifics, of course | 19:01 |
| alexreg | i appreciate the discussion... | 19:01 |
| alexreg | got to go now. bye | 19:02 |
| Peng | alexreg: Bye. :) | 19:02 |
| ubotu | New bug: #202613 in bzr "'bzr update' probes the master branch >=3 times" [Medium,Triaged] https://launchpad.net/bugs/202613 | 19:06 |
| spiv | jelmer: your 0.4.8 branch needs this patch to make initial branching work: http://rafb.net/p/f4Qt8T85.html | 19:44 |
| jelmer | spiv: Any chance you can "bzr send" it? | 19:51 |
| AfC | If you haven't seen it yet today, Elijah has written another missive. | 20:00 |
| AfC | http://blogs.gnome.org/newren/2008/03/15/how-not-to-write-newbie-friendly-documentation/ | 20:00 |
| AfC | While it's mostly a rant against Git, I'd encourage the Bazaar hackers to consider these points in relation to their own documentation. | 20:01 |
| === Toksyuryel` is now known as Toksyuryel | ||
| spiv | jelmer: sure. what's the preferred forum for that? bazaar@? | 20:05 |
| spiv | jelmer: or just direct to you? | 20:05 |
| spiv | AfC: yeah, I read that earlier today. It's a good post. He compliments bzr's documentation briefly, which is nice :) | 20:06 |
| jelmer | spiv: Either would be fine. "bzr send" defaults to me | 20:08 |
| spiv | Oh, nice. | 20:10 |
| spiv | ("bzr info" really ought to report that...) | 20:10 |
| AfC | I should probably note that despite all this Elijah seems to be strongly leaning towards sticking with Git. | 20:17 |
| AfC | Which is largely due to his having become enamoured of capabilities that Bazaar does not, unfortunately, accomodate. | 20:18 |
| jelmer | spiv: Thanks | 20:22 |
| jelmer | AfC: What sort of capabilities? | 20:22 |
| jelmer | AfC: The usual (speed, easier to switch branches, group copying) or other things as well? | 20:22 |
| jelmer | s/switch/switch in place/ | 20:22 |
| AfC | jelmer: {shrug} the usual list, I'm sure. I can't remember his specific ones, but they were all on the board in London | 20:24 |
| ubotu | New bug: #91931 in bzr-gtk "Should support showing signatures" [Wishlist,Confirmed] https://launchpad.net/bugs/91931 | 20:52 |
| jelmer | schierbeck: Hi | 20:55 |
| schierbeck | hi jelmer | 20:56 |
| schierbeck | jelmer: i'm having another look at the signature ui bits | 20:56 |
| schierbeck | hmm, can't seem to push to launchpad right now... | 20:58 |
| schierbeck | oh, there we go | 21:00 |
| schierbeck | jelmer: if i want to install icons, should i add them to $(prefix)/share/bzr-gtk/icons ? | 21:02 |
| schierbeck | currently we only add the olive icons to share/olive/icons | 21:02 |
| === schierbeck is now known as __schierbeck__ | ||
| chewy | when's the BoF for pycon? | 21:20 |
| nekohayo | james_w: corruption? in my branch? LIES!! | 21:57 |
| nekohayo | now, how come? :) | 21:57 |
| nekohayo | how can corruption happen? | 21:57 |
| schierbeck | nekohayo: lack of government control? | 22:07 |
| nekohayo | hahaha | 22:12 |
| nekohayo | schierbeck: any other explanation why corruption could happen in a bzr branch though? | 22:19 |
| schierbeck | nope :) | 22:20 |
| james_w | nekohayo: I'm not sure, maybe it's not corruption, but bzr confusing itself. | 22:20 |
| james_w | something sure is funky though. | 22:20 |
| nekohayo | james_w: as you can guess, code.launchpad.net/~specto is an ugly mess and I'm trying to merge the old history with the new one :| | 22:24 |
| NfNitLoop | Hmm. I'm using bzr-svn to check out a rather large svn repo, and the memory seems to be steadily climbing. I've run into this problem before, but now I'm running Ubuntu 7.10 which supposed has patches that fix the python-subversion binding memory leak. | 23:09 |
| NfNitLoop | supposedly* | 23:09 |
| NfNitLoop | is this a new issue? Something related? | 23:10 |
| NfNitLoop | And, in the meantime, is there a good workaround? (maybe a way to incrementally pull in a few separate runs instead of trying to do it all at once?) | 23:11 |
| james_w | NfNitLoop: that's the workaround yes. | 23:12 |
| NfNitLoop | how do I do that? | 23:12 |
| NfNitLoop | I tried interrupting the process... | 23:12 |
| NfNitLoop | but if I try to resume, it seems to start all over again. | 23:13 |
| james_w | I don't know if gutsy has the patches, I think it does, but I think that it can still have memory issues on large repos. | 23:13 |
| james_w | you need to use -r | 23:13 |
| james_w | bzr init trunk | 23:13 |
| james_w | cd trunk | 23:13 |
| james_w | bzr pull -r 1000 url | 23:13 |
| james_w | bzr pull -r 2000 | 23:13 |
| NfNitLoop | aah. | 23:13 |
| james_w | I think that's it. | 23:13 |
| james_w | you can obviously script it. | 23:13 |
| NfNitLoop | *nod* | 23:14 |
| NfNitLoop | thanks. | 23:19 |
| james_w | no problem. | 23:21 |
| NfNitLoop | Hmm... does bzr-svn not work with bzr 1.2? | 23:29 |
| NfNitLoop | TypeError: create_workingtree() got an unexpected keyword argument 'hardlink' | 23:29 |
| jelmer | NfNitLoop: it should work with 1.2 | 23:30 |
| jelmer | the hardlink stuff was introduced in 1.3 I think | 23:30 |
| jelmer | spiv just sent me a patch to fix that but I haven't gotten round to applying it yet | 23:30 |
| NfNitLoop | so I need to upgrade to bzr 1.3? | 23:31 |
| james_w | hi jelmer | 23:31 |
| jelmer | NfNitLoop: you're already on 1.3 I think | 23:31 |
| NfNitLoop | Bazaar (bzr) 1.2.0 | 23:31 |
| NfNitLoop | bzrsvn 0.4.9dev0 | 23:32 |
| jelmer | NfNitLoop: ah, you either need to use the 0.4.8 branch (which is compatible with 1.2) or use bzr 1.3 | 23:32 |
| NfNitLoop | aaah, ok. I'll get 0.4.8 | 23:32 |
| NfNitLoop | I just grabbed the 0.4 branch, I guess that's not always in-sync w/ bzr stable? | 23:33 |
| jelmer | NfNitLoop: the 0.4 branch is in sync with bzr.dev | 23:36 |
| NfNitLoop | gotcha. | 23:36 |
| NfNitLoop | thanks. | 23:36 |
| jelmer | NfNitLoop: Ubuntu 7.10 does not have the memory leak fixes, btw | 23:36 |
| jelmer | only 8.04 has | 23:37 |
| NfNitLoop | That would explain the memory leak, then. | 23:37 |
| NfNitLoop | I thought the wiki said they had been applied to previous ubuntu releases. | 23:37 |
| NfNitLoop | so I assumed they were in 7.10 too. | 23:37 |
| jelmer | nope, those are other fixes (the fixes required to run bzr-svn at all) | 23:39 |
| james_w | woo, sort-of-log emitting the first revision in about 5 seconds on emacs. | 23:39 |
| jelmer | james_w: nice! Any consequences for the overall performance of log? | 23:40 |
| james_w | jelmer: well it's about 10 seconds quicker to do the whole thing. | 23:40 |
| jelmer | I remember some of the other fixes that were posted to the list made a full "bzr log" run slower | 23:40 |
| jelmer | ah, nice | 23:40 |
| james_w | however it's not doing bzr log, it's doing git log. | 23:41 |
| james_w | but if you limit it to less than the 87000 revisions then it's pretty damn quick, e.g. 5s to emit 10000 revs | 23:41 |
| james_w | I know it's doing something different, but having a topo-sorted log option would help on this big projects. | 23:42 |
| james_w | it seems like around 5s is the minimum on the full history just due to extracting all the necessary data from the repo to topo-sort it. | 23:43 |
| jelmer | ahh, ok | 23:47 |
| jelmer | well, having that as an option would certainly not be a bad thing | 23:47 |
| james_w | yeah, speeding up the others is obviously important, but I wanted to see what the costs were of other things we were doing, so I just stripped it down to the minimum. | 23:50 |
| james_w | it took me a long while to beat the default log on overall time though, even though I quickly beat it too emit the first revision. | 23:50 |
| AfC | Been really interesting sitting with Carl Worth, Behdad Esfahbod, Rob Taylor, etc this week. They're all using Git (ie for Cairo) but Carl in particular is really open minded. | 23:50 |
| james_w | I missed on the batching of revision fetching it was doing. | 23:51 |
| james_w | One thing i noticed is that we seem to grab every revision twice, which might be something to look at. | 23:51 |
| AfC | ... and walking him through using Bazaar to do a few things on projects of mine that he was bringing up was a positive experience leading to much sharing of state. | 23:51 |
| james_w | AfC: yeah, Carl spent a long time in here some time ago talking to us about the similarities and differences between the two. He took a while to see the reasons behind some of the differences, but he definitely seemed open minded. | 23:52 |
| james_w | I can't remember if that was the trigger for the bzr/git thread or the result of it. | 23:52 |
| james_w | and I know he is one of the main reasons that the git UI has improved so much. | 23:53 |
| james_w | AfC: is the hackfest over now? | 23:53 |
| AfC | I was reflecting that as we are working on "git features" (ie, in-place-switching [which is very close to being sorted], managing-a-collection-of-branches and/or multiple-heads, etc) that it would be really useful to demonstrate [as he just did for me] his usage patterns and the things that are useful to him. | 23:54 |
| AfC | james_w: getting there. 50% are on their way home now, and most of the rest are out tomorrow. | 23:54 |
| james_w | AfC: was it successful? | 23:55 |
| AfC | Fantastic | 23:55 |
| james_w | I think there is plenty we can bring in from git, I do think it is a good system. | 23:55 |
| AfC | I actually plan to write a blog about the Bazaar sprint and the GTK hackfest (compare and contrast, as your year 8 English teacher would have told you to do) | 23:56 |
| james_w | AfC: are you sticking around Europe for a while, or are you jetting off elsewhere? | 23:56 |
| james_w | AfC: :-). That would be pretty cool actually. | 23:56 |
| AfC | james_w: nah, time to be on my way. I'm here until Monday morning, then Toronto next. We *really* need some new business. | 23:57 |
| james_w | I was just wondering why there was a naming difference, and whether this had any effect on the content or atmosphere. | 23:57 |
| AfC | james_w: I have a theory :) | 23:57 |
| james_w | AfC: too much time hacking I guess. | 23:57 |
| AfC | james_w: which I related to the crowd here. It was funny, because half of them had been in hacking mode, and half of them had been in what you would relate to as sprinting mode | 23:57 |
| AfC | and the two halves were looking at each other funny when I related my explanation of the difference | 23:57 |
| james_w | I thought sprints were more about hacking, is it just the bzr one that is more discussion, or is that pretty standard? | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!