=== bpeterson is now known as gutworth === gutworth is now known as bpeterson [00:35] moin [00:45] Verterok: o/ [00:55] Odd_Bloke: hey, my ssh connection works again :-) [00:55] :) [01:32] New bug: #200816 in bzr-loom "combine-thread sounds like it merges, but it doesn't" [Undecided,New] https://launchpad.net/bugs/200816 [01:35] New bug: #200819 in bzr-loom "combine-thread silently drops unmerged changes" [Undecided,New] https://launchpad.net/bugs/200819 [01:43] jelmer: http://bundlebuggy.vernstok.nl/bzr-gtk//request/%3C1200860579.32181.3.camel@dasch.egmont-kol.dk%3E is giving me a 500 error, traceback at http://paste.pocoo.org/show/32888/ === mw is now known as mw|out === lamont` is now known as lamont__ [05:03] * mwhudson points people with brain cells to spare at his mailing list post === lamont` is now known as lamont [05:42] the help says that with push target branch will not have its working tree populated, but when i do push all the files get there. what does it mean? [05:43] push only updates working copies on the local machine (i.e. file:/// urls) [06:05] ok push does not actually 'push' the files. do i have to use checkout? [06:06] it pushes the branch [06:07] does the thing you're pushing /to/ have a checkout already? if so, "bzr up" (or ssh remotehost 'cd /remotepath ; bzr up' or whatever) [06:08] (If you really want to update the working copy when pushing, and have a good reason for it, and are using sftp or ssh, get the push-and-update plugin.) [06:11] no, i am pushing to a place that was empty [06:12] "bzr up" should get the files then (and'll need to be run after every push or you need the plugin Peng mentioned). [06:13] unfortunately i am confused about these commands, and i have read manuals and online help. [06:14] which part's got you? [06:15] right now pulling, pushing, updating. they all sound similar and not exactly sure what they are now meant to do. [06:15] ah, ok [06:15] push only seems to copy over the .bzr dir [06:15] Exactly. [06:16] pull and push work on the branch level - they pull/push changes at the internal bzr data level [06:16] (Of course, pull also runs update afterwards, making things more confusing.) [06:16] "update" updates a working copy, incorporating any changes that have been stored by bzr, but haven't been applied to the workign copy files yet [06:18] it does the same as "svn up" would [06:19] i haven't used svn, so update always makes sure local working tree is up to date with where ever it came from? [06:20] right [06:20] though the local working tree might have local uncommited changes [06:21] so apart from the plugins, is there a way to get the files over to remote side with one local command? [06:22] no, that's the point of the plugin - it is transport dependent [06:22] er, "being able to do update is transport dependent" === doko_ is now known as doko [07:28] any reason that we still have the 1.2 release candidate in hardy? === weigon_ is now known as weigon [09:21] doko: Don't think it matters, AFAIK, RC was identical to release [09:22] Dead in here, innit. THey're all knackered after the Sprint in London [09:46] There was one change in 1.2: "Fix failing test in Launchpad plugin." [10:40] New bug: #200927 in bzr-svn "crash when generating file id map" [Undecided,New] https://launchpad.net/bugs/200927 [12:16] hello [12:16] is bzr faster than svn? [12:18] Stavros: it sort of depends on what you are doing. For many things bzr can work purely locally, making it a lot faster [12:18] If you are using a checkout in bzr, and are on a local lan, and committing changes to a 500MB file, I think svn is faster [12:19] jam: it seems that for all operations bzr is much faster (svn takes about ten seconds to even begin committing/whatever), but i don't know if it depends on wc siz [12:19] size [12:19] And you don't have the option to pull history locally for svn === mrevell is now known as mrevell-lunch [12:19] So "initial checkout" can be misleading [12:19] oh yeah, local diffs are great [12:19] well, it's worth a slow initial checkout for fast diffs [12:20] So yeah, not having to connect to a remote server can give bzr a big speed advantage [12:20] is there a good bzr gui, by the way? [12:20] bzr-gtk is the standard one, which is evolving a tortoisebzr/nautilusbzr and Olive [12:20] aha [12:20] There is also qbzr, which I haven't used [12:20] yes, i tried qbzr, it was nice [12:20] its diffing was better than bzr-gtk [12:20] http://bazaar-vcs.org/QBzr [12:21] Because it did side-by-side diffs? [12:21] yes [12:21] bzr-gtk could probably grab "meld" to do that [12:21] rather pretty, too [12:21] but sure [12:22] Is it true that initial checkout of a bzr branch is slower than initial checkout of a Subversion one? I'm sure there are times, where that's true, but in general, bzr is getting faster and faster each release. Subversion has always been pokey. [12:22] AfC: well, if you have a project with 3GB of history, downloading that is a bit slow [12:22] AfC: well, it has to transfer everything... [12:22] I would imagine with shallow branches it gets better [12:23] We could also do a lightweight checkout, but I don't think we've done a lot of work optimizing that path over the network [12:24] jam: yeah === FreeNode is now known as herb === FreeNode is now known as herb [12:45] So I've got bzr-svn pulling a (large) Subversion repo for the first time. Hooray and all that. Now, obviously I can branch from this locally, work on my branches, push/merge back, etc. [12:45] But what about collaboration? Going through the n-hours it'll take to pull this thing down, [12:46] is not an experience I'd like to force on the (mostly Git) users around here. Can I just hand them the bzr branch [12:46] or, do I like cp -a / scp -pr the "repo" containing what bzr-svn pulled down, ...? [12:46] (around here == a hackfest on that project) [12:47] (so if I can use an ethernet cable and two seconds of pushing to move the revisions to a compatriot that would be good, I expect) [12:50] AfC: you could bzr serve it up I guess, or ship them the repository + branch === mrevell-lunch is now known as mrevell [12:52] LarstiQ: Thanks. The variation here is that they all too have read/write access to the upstream Subversion repository, so ideally they could likewise use the trunk branch. Not sure if that's the sort of use case that people had in mind [12:52] LarstiQ: but you think handing them a tarball of the fetched and init'ed and champagned repo would work? [12:53] AfC: I'm not entirely clear on what they need to do with it and such. But with the repo and branch they should have all revisions used and a branch handle to it. [12:54] AfC: if they need to communicate with svn again, they need bzr-svn as well and it might do caching of svn data again [12:54] Oh, I just thought of one thing that could be a problem: the URL I checked out has my username in it (as it is svn+ssh). That's not going to be very sharable [12:54] * LarstiQ has never tried shipping the result [12:54] LarstiQ: I'm just trying to avoid them having to do the initial bzr-svn pull. Which is ... lengthy [12:54] right [12:55] AfC: I suggest testing under a different user if it will need to do the bzr-svn caching again [12:55] and makes Bazaar look really bad, unfortunately. And as there is increasing momentum towards Git around here I want to try and compete with that before it is too late [12:55] * LarstiQ nods [12:55] LarstiQ: good idea [12:56] LarstiQ: (I rather suspect it might; that part only took a minute, so that's not so bad) [12:56] AfC: if it were plain bzr, bzr pull --remember url-without-username will then prompt them for their username later on. Not sure how bzr-svn deals with auth [12:56] Interesting [12:56] those are the only things I can think of right now [12:56] * LarstiQ does a small test [12:57] * AfC supposes he should have used something smaller than GTK+ as his first use of bzr-svn :) [12:57] maybe :) [13:00] The trick that someone suggested of doing init && pull rather than branch [13:00] to provide resumability seems a good idea === mw|out is now known as mw [13:04] AfC: yes, although qua data it should already be resumable if you use a shared repository, the actual revision objects get shoved into that [13:04] Mmm [13:04] LarstiQ: Yes, of course [13:04] AfC: then the branch is only a pointer to the last revision, remaining problems are that the branch isn't initialised as being one, so you need to remove the directory and branch again [13:05] so yeah, init and pull is a nicer ui [13:05] unfortunately [13:05] * LarstiQ got his svn branch, procedes to test with a different user [13:05] I'm only using whatever the current release is (0.4.7?) so I'm not sure if this has been addressed, but it sure is a bit lean on progress reporting. [13:07] AfC: ok, I copied over a repo plus branch, the other user can log/st/diff/ci without having bzr-svn [13:07] now to test if they can push up to svn [13:07] Yup [13:08] * AfC is only seeing about 3 revisions per second coming in. This is clearly going to take a while. === lamont` is now known as lamont [13:13] AfC: my suspicion was right, the second user after installing bzr-svn and running bzr push http://svn... gets to also cache the svn information. Which is rather quick I'm happy to say. [13:14] yeah [13:14] committing fails because of auth, let me check that [13:14] did the fact that the thing that was copied had a different URL as its origin cause a problem? Doesn't sound like it [13:14] Ah, ok [13:15] hello === Af1 is now known as AfC [13:16] AfC: I was using anonymous http at first [13:16] there is no svn+ssh running there [13:17] np [13:17] Now that I think about it: in bzr context it shouldn't matter at all. You just push to the URL you're pushing to. It just remains to be seen whether the guts of bzr-svn are unable to cope with that usecase [13:18] ok, I'm think I'm shafted on that front [13:18] svn python bindings prior to 1.5 don't allow you to do anything with authentication [13:18] you can work around it by forcing svn to cache credentials [13:19] AfC: if you don't require people to push to svn, everything should work nicely [13:19] Well, I'll see if I can find a) a small project at that host + b) someone sympathetic to test with [13:19] if not, there is the bit of authentication I can't test for you atm [13:19] AfC: cool [13:19] * LarstiQ heads of to his appointment [13:20] LarstiQ: {shrug} the project is in Subversion. Nothing I can do about that at the moment. And given that some people are using svn, others git-svn, and (I hope more than 0) bzr-svn to get to it, I expect it will remain the common point for some time to come, unfortuantely. [13:20] LarstiQ: see ya. Thanks for checking things [13:20] AfC: I believe there is a bzr-svn cache that you will also need to give the other users [13:20] with that and the bzr branch [13:20] they shouldn't have to do the 'mega-pull' [13:21] jam: based on LarstiQ's experiments just now, not passing the bzr-svn cache across wasn't a show stopper - it just went and "re" did it. The cost of that was about a minute, so no biggie. [13:21] ah, ok [13:21] I thought that was one of the bigger expenses, but I guess not [13:21] (bit harder to tuck into a tarball or whatever, so that worked out well) [13:21] jam: I would have thought so too [13:21] but hey [13:21] AfC: is that for the large project? or a small one [13:21] GTK+ [13:22] that sounds pretty big :) [13:22] The launchpad import was 15256 revisions and 197929 KB as reported by bzr info -v. [13:22] But I don't want to use that. [13:23] sure, bzr-svn can be used to collaborate between the two [13:24] I (and everyone else here) has write permissions on the upstream project. So it's not a case of export and abandon, it's "want to use bzr to show it off, but unfortunately against a Subversion project" [13:24] and so the launchpad import is kinda useless. [13:45] If you can get bzr-svn absolutlely ironclad, it's the major reason to use BZR [13:45] Well, A major reason [13:47] Justifying things to risk-averse managers is a major decider of project adoptance in the real world [13:49] Oh, can anyone give me feedback about using bzr with WebDAV? Do you just install a standard WebDAV plugin on your Apache instance? [13:54] jam: any sense if it is indeed best practise to frequently restart bzr-svn when doing its "mega-pull"? [13:55] AfC: I wrote a script to do it a few hundred revisions at a time [13:55] AfC: Otherwise it would just fill all available memory and crap out [13:56] I define best practice in this case as "it works, so go with it" [13:57] New bug: #200993 in bzr "AssertionError on revert" [Undecided,New] https://launchpad.net/bugs/200993 [14:35] AfC: when the svn binding leak, it is definitely recommended to loop over "bzr pull -r XXX" by like 100 or 1000 at a time [14:35] Since we also have the possibility of getting disconnected, etc, I would also recommend it. [14:35] I don't know the internals of svn => pack pulling, if it commits anything while it is running or not [14:35] I can check real quick [14:45] AfC: it seems that bzr-svn is opening and closing a "write group" for every revision [14:45] which might be part of the performance issue [14:45] but it does mean that after any pull the data will be in the target [14:45] even if stopped halfway [14:46] jam: Yes, it repacks after each revision [14:46] sounds rather like something spiv and jelmer looked at at the sprint [14:46] * awilkins cheers [14:47] I certainly would recommend doing it every 100 or so [14:47] That's what I do in cvsps and some other converters [14:47] I think Ian has fast-import hooked up to do it every 10000 [14:47] As far as I can tell, the hardlink support is the only API break that effects bzr-svn, so you can just add a None parameter to the API and run on [14:48] Would this "not packing every revision" thing be present in a more recent revision? [14:48] awilkins: well, I have tip, and it seems to be there [14:48] sorry, it still packs every revision [14:48] I was unclear [14:48] jam: tip of 0.4? [14:49] or trunk? [14:49] 0.5.0.exp.0 [14:49] Oh, nice. I left bzr-svn running for the last hour, and it grew to 1.7 GB [14:49] trunk, I believe [14:49] Yeah, it does that [14:49] of RAM in use. [14:49] http://bazaar.launchpad.net/~jelmer/bzr-svn/trunk/ [14:49] the RAM use gets bigger than the source repository is :-P [14:51] * awilkins waits for his MKS resync to finish [14:52] Ancient VCS programs and hokey operating systems ain't no match for a good blaster at your side.... [14:56] * awilkins is still waiting for MKS [15:00] * awilkins is still waiting for MKS [15:01] Is bzr-svn trunk safe to use? (ie, is it recommended, more performant, etc? Or is that branch considered unstable except at releases [I don't know jelmer's release practises]) [15:03] "bleeding edge, may break existing imports every now and then" [15:07] AfC: it is recommended to use releases [15:07] * awilkins is still waiting for MKS [15:09] 15:01:10< nevans> jelmer: I'm up to date with http://people.samba.org/bzr/jelmer/bzr-svn/stable/, and I'm getting "using experimental bzr-svn mappings; output may change [15:09] 15:03:20< jelmer> nevans: you should not be using it for production type data but a release instead [15:09] specifically [15:10] LarstiQ: very well [15:11] Incidentally, as I was trying to grab that branch I got [15:11] bzr: ERROR: Repository KnitPackRepository('file:///home/andrew/vcs/launchpad/bzr-svn/.bzr/repository/') is not compatible with repository KnitRepository('http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/trunk/.bzr/repository/') [15:11] which is an error I don't understand [15:12] Means the repository formats are not compatible === kiko is now known as kiko-fud [15:13] were you doing a branch inside a repsository folder? [15:13] Or pulling into a pre-inited repo? [15:15] Incpompatible repo formats are one of the things about bzr I find discomfiting [15:15] * awilkins is still waiting for MKS [15:19] AfC: yeah, that sucks :( [15:19] AfC: ties into the 'too many formats in play' [15:19] discussion we had [15:19] * awilkins is still waiting for MKS and now wants to wage Jihad on Mortice Kern Systems [15:20] You should deprecate some of them, split them out of the codebase and make them plugins, including conversion routines to newer formats. Of course, that needs robust converters..... [15:20] awilkins, LarstiQ: originally, yes, but then I got the same error when I tried to pull into a --knits repo. [15:21] "1.0". Sure. [15:21] It's dirstate-with-trees AFAIK [15:21] Yeah, 1.0 was a bit premature... SVN waited for almost geological time before delcaring 1.0 [15:25] * awilkins is still waiting for MKS [15:27] * AfC is trying the 100 revisions at a time approach. It's taking a while. [15:27] Yup, it certainly does [15:27] It's not too bad once it's finished. [15:30] I got the trunk of a 1.5GB repo converted in about 12 hours... then deleted it accidentally :-( [15:34] jam: yes, bzr-svn does commit a write group for every revision [15:34] jam: I asked jelmer about it, it's done intentionally so that interrupted imports can be continued. [15:35] jam: I agree though, I think I'd like to see a less extreme policy like every 100 commits. [15:35] 15:54:52 nadeel van meerdere revisies per write group is dat je eigenlijk heuristiek nodig hebt om te bepalen hoeveel revisies je per keer wilt [15:36] 15:55:44 en dat is oa afhankelijk van hoe duur het sluiten/openen van een write group is, en dat is weer repository-specifiek [15:36] drawback of multiple revisions per write group is that you need a heuristic to determine how many revisions you want per batch [15:36] My Dutch is a leeeetle bit rusty [15:36] which among others depends on how costly it is to open/close a write group, and that again is repository specific [15:36] awilkins: hey, you saw it was Dutch ;) [15:37] anyway, that's the translation [15:37] LarstiQ: Nope, I just know Jelmers NS maps to .nl [15:37] awilkins: ah. [15:38] Dutch and English really look a lot alike to me [15:38] * dato sends glasses in LarstiQ's direction. [15:38] LarstiQ: well, there already is a heuristic [15:38] LarstiQ: it's just that it's hard-coded to 1 ;) [15:39] spiv: I'm just the messenger! ;) [15:40] does anybody know what this error means: 'bzr: ERROR: Files are in different branches' ? [15:41] more importantly, how to fix that? :) [15:43] barry: what's the command? [15:43] spiv: bzr branch rocketfuel pristine; cd pristine; bzr diff . ../rocketfuel [15:44] barry: bzr diff -r branch:../rocketfuel [15:45] LarstiQ: thanks, that seems to work. is that something that's changed since 1.0? [15:46] barry: let me look that up, it changes when I wasn't present to object at least [15:46] barry: yeah, 1.1rc1 [15:46] barry: oh, the NEWS entry suggests --new [15:47] There's bzr diff --old/--new now. [15:47] LarstiQ: ok, cool, thanks. yesterday i updated from 1.0 to 1.2 [15:47] * The syntax ``bzr diff branch1 branch2`` is no longer supported. Use ``bzr diff branch1 --new branch2`` instead. This change has been made to remove the ambiguity where ``branch2`` is in fact a specific file to diff within ``branch1``. [15:47] * LarstiQ mourns the passing of `bzr diff branch1 branch2` [15:48] * barry does too, but atleast there's a workaround! [15:48] LarstiQ: thanks! [15:48] barry: glad to be of help [15:48] * LarstiQ tries the expense form once again [15:53] * awilkins has finished waiting for MKS [15:54] * awilkins wonders why MKS is still eating a whole CPU when it's claiming to be doing nothing [15:55] Perhaps it something to do with having 42 threads going..... [15:57] New bug: #201040 in bzr "Break-lock of a branch bound by another branch causes "infinite" recursion" [Undecided,New] https://launchpad.net/bugs/201040 [16:04] can i version my code automatically? i.e. include a placeholder that bzr will fill in automatically with revision number/version? [16:05] Stavros: iirc not supported yet [16:05] ah, thanks [16:13] Stavros: you can use `bzr version-info` [16:20] LarstiQ: oh, i see, so i can output a python file with the relevant strings, then? [16:21] Stavros: rather, in any format you want, with --template (I think) [16:22] yes, thanks, that's a good solution === lamont is now known as lamont` [17:19] Hi! [17:20] I did bzr add on a folder and addded recursively all the files in it, but I needed only the folder. Now how can I remove versioning from files inside this folder without removing them? [17:21] I got this one in project ideas, "Update the PQM with an XMLRPC interface instead of an email based one. So that when 'pqm-submit' is finished, you know the pqm has your data. Also, it would be nice if the pqm could perform quick sanity checks at this time." [17:21] could some body explain it more clearly ?? [17:25] sque: bzr rm --keep [17:26] LarstiQ Ty!! :D [17:37] itzsid: PQM at the moment only works by email, this means that you send an email, and then some time later you either get a confirmation or an error. Adding XMLRPC means that you get an error straight away, rather than having to worry about emails being held up. [17:38] itzsid: are you interested in doing a bzr SoC project then? [17:38] hi LarstiQ [17:39] james_w: may be, i was just looking for ideas [17:41] itzsid: there are probably more ideas not on the page if you have any you want to suggest. [17:45] heya james_w === kiko-fud is now known as kiko [17:47] james_w: do you know if anyone doing that XMLRPC interface ?? I am quite interested [17:49] itzsid: I think Odd_Bloke was interested in that one. [17:50] james_w: its ok [17:51] itzsid: PQM could validate requests earlier than it currently does [17:52] itzsid: if you send a request with the wrong GPG key, or for a branch you don't have access to, or for a branch that PQM doesn't know about, PQM should be able to report that problem immediately. [17:52] itzsid: instead, it waits until the request hits the top of the queue before doing even basic checking. [17:55] spiv: ok, Is there any similar idea left, where some work can be done ? [17:57] similar in what sense? [17:57] itzsid: well, the problem I just mentioned is still waiting for someone to work on it AFAIK : [17:57] :) [18:00] spiv: Are you talking about a different idea than james_w ? [18:00] spiv: because he told Odd_Bloke was interested in this one [18:02] itzsid: yeah, I am. [18:03] itzsid: the "it would be nice if the pqm could perform quick sanity checks at this time." part. It's orthogonal to adding an XML-RPC interface in my opinion. [18:03] spiv, is the fact that you need to break-lock multiple times to free a branch up a known bug? [18:03] kiko: partly [18:04] kiko: it seems that there's multiple server-side processes waiting (one per client that attempted to acquire the lock while it was already locked?), so you need to break-lock to clear the backlog. [18:05] could the smart server be smarter about that? [18:05] kiko: although the server-side ought to have a lock wait time of 0 seconds now, IIRC. [18:05] So I'm a bit surprised it's still occuring. [18:06] So "known bug" in the sense of "known to happen", but not in the sense of "fully understood". [18:06] I see. [18:07] spiv: I got it [18:08] spiv: it is, but I'd think both can be done under one PQM umbrella this summer. [18:09] Moin. [18:09] (he said, at 6:10pm) [18:19] LarstiQ: ah right, I came in halfway through and didn't realise we were talking about GSoC projects. [18:21] I want to push some changes on my branch at lauchpad [18:22] from linux it worked with my ssh key [18:22] now that I am from windows how can I do it? [18:23] pagent? [18:25] just discovered it [18:25] spiv: I looked at the ideas page but couldn't get it. Do you have any more ideas which could be worked ?? [18:26] LeoNerd: must I create a new ssh key? or can I use it the one created inside linux? [18:27] Either will work.. [18:27] Best practice says you should make a new key per client machine [18:27] The private key ought never to leave the machine it was generated on, see [18:27] itzsid: what would you like to work one? [18:27] it is the same machine [18:27] dual-boot [18:31] LarstiQ: anything involving XMLRPC [18:32] itzsid: I don't know that we have much of that. Somewhat related would be SmartServer work. [18:32] LarstiQ: what's SmartServer [18:34] itzsid: a smart server that implements higher level logic, as opposed to dumb vfs transports [18:41] itzsid: http://bazaar-vcs.org/Specs/SmartServer and http://bazaar-vcs.org/SmartServer/RemoteObjectHacking [18:43] LarstiQ: is it there for GSoC ? [18:43] itzsid: you can propose anything you like for GSoc. [18:45] james_w: I mean, is it in the scope to be done as a GSoC Project [18:46] itzsid: yeah, if you define what you want to do well enough. [18:46] There is plenty to do on the smart server, so just "work on the smart server" is probably too generic, but "add verbs for this, this, and this to the smart server" may be better. [18:47] james_w: ok === kiko is now known as kiko-afk === nevans__ is now known as nevans === mw is now known as mw|food [19:40] Here's maybe a better question that what I was asking earlier: are the revisions created by Launchpad's vcs-import and by bzr-svn compatible? [19:40] AfC: Nope [19:40] ie, can I use the vcs import, and then update it with, and push back to, with bzr-svn? [19:40] jelmer: I didn't think so. Damn, etc [19:40] AfC: That's actually what you were asking earlier worded differently :-) [19:40] jelmer: sorry. [19:41] jelmer: (though I have long ago learned that sometimes you need to ask the right question :)) [19:41] no worries, it's a fair question [19:41] jelmer: LarstiQ was quite helpful with some testing there [19:41] AfC: what sort of testing? [19:41] jelmer: someone should tell the launchpad people that their import is pretty difficult to make use of as a result [19:42] jelmer: oh, I was exploring what would happen if someone tar'ed up a bzr-svn created branch+repo and scp'd it to another person locally (or over the net for that matter) t [19:42] to amortize the cost of constructing the initial bzr-svn branch [19:43] AfC: ah [19:43] AfC: if you have the memory leak fix that's in ubuntu hardy it should be pretty quick I expect [19:43] what did you find? [19:43] I'm getting about 1 revision every 5 seconds; it will be a non-starter if I try to promote Bazaar to the people championing Git if it takes this long to compose [19:43] jelmer: he got most of the way, but couldn't test whether or not pushing back to a different username would work [19:44] AfC: What version are you using exactly? [19:44] I fixed a quite large performance bug in it with spiv during the sprint [19:44] (I know; awesome) [19:44] the patched version of subversion 1.4.6 and bzr-svn 0..4.7 [19:45] [where "patched" is "that which was necessary to make it run at all, as defined by bzr-svn"] [19:45] Anyway, I'm doing the "pull 100 at a time" thing right now. [19:46] The memory leak fix may help somewhat there [19:46] the memory leak also slows it down because of the way the APR memory pools are implemented [19:46] I tried building Subversion from source but it didn't go very well [19:47] it only works during a full moon [19:47] and with the exact right version of SWIG, etc [19:48] Is the "memory leak fix" something other than "that which was necessary to make it work at all"? [19:48] yes [19:48] (I mean, my Gentoo ebuild builds it from source fine. I just couldn't quite replicate those conditions by hand very well) [19:48] jelmer: ah [19:48] We fixed the memory leak only a couple of months ago [19:49] the other patches are over a year old by now I think [19:49] Maybe I should do 10 revisions at a time [19:49] ah [19:49] gotcha [19:49] Sure would be nice if the Subversion team would do 1.4..7 [19:49] {sigh} [19:50] or 1.5.0, that would remove the need to do any patches at all [19:50] jelmer: thinking of making releases, when's the next bzr-svn release? :) [19:50] spiv: 5 minutes from now :-) [19:50] I'm fixing the last 5 tests at the moment [19:50] Sweet. [19:50] spiv: I dunno. Do you think we can wait that long? [19:50] * AfC wonders if the Subversion crew do snapshot releases? [19:52] I think they may do something like that for Subversion 1.5 [19:53] I just poked around on their website, and couldn't find anything in released form [19:56] Ouch. This is taking 2 minutes per 10 revisions. Only 14,000 to go [19:57] [Now I understand why shallow branches are going to be important when they land] [20:05] jelmer: Want a win32 test log? [20:05] awilkins: Sure [20:06] jelmer: Hold on... for which bzr version [20:06] awilkins: Please use the 0.4.8 branch [20:06] That's the one I'm trying to release at the moment [20:06] Revision 939? [20:06] Oh, it diverged from r 939? [20:06] yes [20:06] that's the 0.4 branch [20:06] which will become 0.4.9, not 0.4.8 [20:06] well, it's on both branches [20:06] 0.4 is on 945 [20:07] o.w 20 [20:07] * awilkins pulls 0.4.8 again [20:07] it looks like the Summer of Code project to integrate bazaar in Visual Studio didn't happen. [20:07] Zectbumo: It's up on launchpad [20:07] August 2007 was supposed to be the code checkin [20:07] jelmer: oh, where is that? [20:08] Zectbumo: yes, where are you looking for it? [20:08] https://edge.launchpad.net/bzr-visualstudio [20:08] aha, perfect, thanks jelmer [20:13] jelmer: Erm, am I getting this right, http://people.samba.org/bzr/jelmer/bzr-svn/0.4.8/ at r 906? [20:15] jelmer: does the VS plugin work? [20:21] I just used bzr-svn to commit something to a project I work on and bzr set some properties on the subversion trunk... is there a way to keep that from happening? [20:29] mxpxpod: no, they are necessary for bzr-svn to keep track of what happened. [20:29] awilkins, yep [20:29] Zectbumo: not sure, I've never used it myself [20:29] mxpxpod: are you using trac by any chance? [20:29] Zectbumo: afaik it at least works to some degree [20:30] awilkins: I'll be back in a couple of hours [20:30] james_w: yeah, I am [20:30] james_w: http://trac.dojotoolkit.org/changeset/13037 [20:30] awilkins: Thanks for doing this. Kevin Light is also interested in packaging Subversion 1.5 (with the memory leak fix) and bzr-svn 0.4.8 for Windows [20:30] awilkins: So hopefully bzr-svn 0.4.8 will rock on Windows! [20:31] mxpxpod: yeah, it's ugly and that's unfortunate. However if you want to make bzr-svn work two way it is necessary, as svn doesn't track the merges itself. [20:31] mxpxpod: IIRC there was some option to hide those properties in trac [20:31] svk has the same problem [20:31] james_w: so, I should just specify the files I'm committing explicitly each time? [20:32] mxpxpod: it will always set those file properties [20:32] jelmer: hi. OOI are you compatible with svk in any way? [20:32] jelmer: darn... that's kinda ugly [20:32] mxpxpod: it's the way these things work in Subversion [20:33] a buddy of mine uses git-svn and it doesn't set props like that... [20:33] mxpxpod: yes, but git-svn doesn't allow roundtripping afaik [20:33] roundtripping? [20:33] yes, working on a svn branch as if it was a native bzr branch [20:34] sorry, really have to go now. back in a couple of hours [20:37] mxpxpod: It looks ugly in Trac, but that's about it ; and I strongly suspect SVN 1.5 implements merge tracking a similar way [20:37] svk also sets custom props [20:38] Although not *quite* so heavily [20:38]