[00:25] lifeless: G'day [00:26] just wondering if there is an overview of pqm anywhere [00:27] the lp page suggests it has a web ui, magically manages trunk etc.. I installed it via apt and it has no doco, I browsed the repo and found a readme that is fairly silent on what it actaully does :) [00:30] If we knew how to use it, what fun would the Canonical wizards have? [00:31] heh [00:31] tjs: There's my OSDC talk (and paper) from last year, I guess, which briefly covered what PQM is useful for from a high level. [00:31] tjs: But I'd hope there's something more specific and useful than that :) [00:33] spiv: ah cool, I'll check it out. jml mentioned yesterday that I might find it useful, we started with combinator last week and due to how our build system works (buildout) combinator just wont work for us, we're going to switch to bzr [00:34] tjs: hooray! [00:34] tjs: If it helps, I can probably answer most questions about PQM. [00:35] tjs: (lifeless isn't around atm) [00:35] ah neato [00:36] so jml called it a robot, the lp site says it has a web UI, yet the .deb has nothing that looks like a daemon [00:36] or a config file [00:37] I believe it's typically kicked off by procmail. [00:37] as we're moving from svn we'll be using bzr initially like svn, central repo etc. the company wants their assets backed up and central [00:37] oh [00:37] tjs: I never said "robot" [00:38] The way we use it for bzr is that we use the "bzr pqm-submit" command (from the bzr-pqm) plugin to generate and send gpg-signed emails asking PQM to merge such-and-such a branch onto such-and-such a branch. [00:39] PQM will receive that email, check its configuration to make sure the GPG signature is from someone that is allowed to change the relevant branch, then do the merge, and run a configured command to verify that the merge is good (e.g. "make check"). [00:39] And then it'll email back the results. Obviously if the merge has conflicts or the "make check" (or whatever) command fails, it won't commit the merge. [00:40] aah [00:40] tjs: There is also a web UI so that people can see the queue of merge requests. [00:41] There's an instance at https://pqm.bazaar-vcs.org/, although there's not much to see right at the moment :) [00:41] tjs: did I give you that link to http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html [00:42] jml: I'm reading it atm :) [00:43] so under 5.2 Publishing a branch, it mentions your central repos should be built with --no-trees so that it holds history only and no source files [00:43] tjs: Btw, browsing the source for PQM, I see stuff like http://codebrowse.launchpad.net/~lifeless/pqm/trunk/annotate/173/manual.xml [00:43] wouldnt that proclude people being able to 'check out a branch' ? [00:43] tjs: which sounds like more docs than you've found in the .deb package. [00:43] No. [00:44] tjs: no. You only need the .bzr dir to pull from a branch [00:44] tjs: a --no-trees repo just doesn't hold checkouts. [00:44] aah [00:44] tjs: that's just like a SVN repo. [01:13] so with the central server workflow outlined in http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html#team-collaboration-central-style, devs bzr checkout, update, commit, all is well. When they want to create a new branch on the central server, do they do that locally then 'push' to a new location on the central server? then they delete their local branch and check out the one they pushed? [01:13] anyone know what version of bzr-svn works with bzr 1.0rc1? [01:13] that sounds a bit clumsy [01:15] thumper: The latest one, I guess. The bzr-svn page mentions it. [01:15] tjs: no need to delete the local branch then checkout - just use bind to turn the local branch into a checkout [01:16] ah [01:16] tjs: you don't need to delete the local branch, you can use "bzr bind REMOTE_URL" instead. [01:16] (And similarly you can unbind a checkout to turn it into an independent branch) [01:16] ok [01:16] tjs: section 5.3 explains that I hope [01:21] New bug: #174275 in bzr "Test and improve Mac OS X installation experience" [Medium,In progress] https://launchpad.net/bugs/174275 [01:45] tjs: full docbook docs [01:46] tjs: if you want drop in bzr for svn, you want the bzr+ssh server [02:01] * spiv -> lunch [02:03] Hm... [02:04] viz seems to be on strike. [02:17] fullermd, how do you mean? [02:20] It bombs out trying to import from 'about'. I see about.py there in the root of .../plugins/gtk/, so... [02:20] Wasn't there some discussion recently about fiddling with import paths? [02:28] Removing the current working directory from the path, yes. [02:29] Well, I'm nowhere near that dir. Just the only thing that sprang to mind. [02:32] * Peng shrugs. [02:32] I'm not sure a patch even came from that. [02:32] Well, that just means it's not tested. Obviously at fault, then :) [02:36] tjs: 'bzr branch remoteurl otherremoteurl' [03:38] * igc lunch === kiko-afk is now known as kiko-zzz === ajmitch_ is now known as ajmitch [04:03] lifeless: by 'bzr+ssh server' do you mean 'just use bzr over ssh to a server' or do you mean the 'smart server' thing there is a blueprint for? [04:04] tjs: if you have bzr installed on the remote server, you can literally use e.g. "bzr push bzr+ssh://host/path" === thumper is now known as thumper-afk [04:04] tjs: e.g. "bzr push bzr+ssh://bazaar.launchpad.net/~spiv/bzr/feature-X" [04:05] *nod* [04:07] (Which is the "smart server". You can also use it over TCP ("bzr://") or with some effort HTTP, but bzr+ssh is most common.) [04:09] cool [04:09] and that allows server side commit hooks ? [04:09] It will. [04:09] :) [04:09] It doesn't quite yet, although it's fairly close. [04:10] If you wanted, I could point you at the right bits to hack on the close the gap :) [04:21] naw, its ok for now [08:30] New bug: #174337 in bzr "bzr diff ERROR [bzr 1.0.0.candidate.1 on python 2.5.1.final.0 (win32)]" [Undecided,New] https://launchpad.net/bugs/174337 [09:52] spiv: thanks for the review, top class one :) [10:53] hmm, [10:53] use_revno = global_config.get_user_option('cia_send_revno', default='f') [10:53] NameError: global name 'global_config' is not defined [11:11] hi, me is very new to bzr and is still digging around to see if its the RCS he should use amongst his team [11:11] ive just pushed a branch in my central sftp locatoin [11:11] bzr push --directory project-foo sftp://server/srv/bzr/repo/project-foo [11:12] i can list the contents of sftp://server/srv/bzr/repo/project-foo with bzr ls sftp://server/srv/bzr/repo/project-foo [11:12] but how do i list the contents of sftp://server/srv/bzr/repo/ [11:12] so my developers can see what other branches have been pushed to this central location? [11:12] With sftp, I guess [11:13] i cant do it with bzr? [11:14] Actually, I don't know, don't listen to me :-) [11:14] Lo-lan-do, thanks for the suggestion though. :) [11:14] * terdmonk keeps reading bzr doco === me_too is now known as too_short === too_short is now known as me_too === kiko-zzz is now known as kiko [11:36] New bug: #174389 in bzr-eclipse "bzr command limited to one file" [Undecided,New] https://launchpad.net/bugs/174389 [11:41] terdmonk: the "bzrtools" plugin adds a "bzr branches" command that can do that. [11:41] terdmonk: but it's not built-in to bzr yet. [11:41] vila: thanks! [11:44] vila: I just hacked up selftest to use the trace stdlib module, and got this result: http://rafb.net/p/9LizHs38.html [11:45] vila: the >>>>>> lines are lines that "./bzr --no-plugins selftest '(?i)http'" did not execute [11:45] vila: thus these appear to be gaps in your test coverage :) [11:46] vila: e.g. your implementation of RangeFile.seek(..., 1) seems to be untested. [11:46] vila: otherwise it's mainly error handling, which is a good sign. [11:49] spiv: cool.. ill check out bzrtools.. thanks! [12:30] spiv: wow, any chance your hack get into bzr.dev ? [12:31] indeed RangeFile.seek(...,1) has not been tested, in fact bzr requires only seek(...,0) seek(...,2) is only used by dead code, but I didn't to be controversial ;-) [12:31] s/to/ want to/ [12:32] and yes, some seek(.., 2) can be implemented even if we can't seek backwards ;) [12:34] vila: interestingly, the whence=1 case appears to get exercised by the same selftest invocation in bzr.dev (i.e. without your change). [12:34] vila: so superficially at least it looks like you're keeping a feature but losing test coverage for it. [12:34] vila: I find it very easy to believe it's unimportant, but I'm also extra paranoid given how close 1.0 is :) [12:35] spiv: indeed, the feature is not used in bzr.dev [12:35] vila: Hmm, but there was a test for it? [12:35] spiv: no problem, go, be paranoid ! So that I can relax a bit ;) [12:35] Or a test that used it. [12:35] Heh :) [12:36] spiv: from memory yes, only tests and only : [12:36] def test_seek_and_tell(self): [12:36] # Check for seeking before start [12:36] self.fp.seek(-2, 0) [12:36] self.assertEqual(0, self.fp.tell()) [12:36] self.fp.seek(5, 0) [12:36] self.assertEqual(5, self.fp.tell()) [12:36] self.fp.seek(-2, 1) [12:37] * vila don't use memory when looking at the code is faster [12:37] That's the only place [12:37] and since it's a backwards seek it explains why I deleted it [12:37] but I will add tests for whence in (1,2) [12:42] spiv: even if you hack didn't find its way into brz.dev, I'm *very* interested in a patch ;-) [12:45] vila: I posted it to the list already (I hope!) [12:45] vila: http://bundlebuggy.aaronbentley.com/request/%3C20071206121348.GA32675@steerpike.home.puzzling.org%3E [12:47] vila: I've updated my vote on your change to tweak, btw; see my latest post to the list. [12:48] hello [12:50] spiv: really, great ? [12:51] spib: regarding this xUnit book your pointed me at, have you a better book in mind on TDD or can I safely buy this one ? [12:52] vila: basically I decided that I couldn't pick any significant holes in your code, so we may as well start get people using bzr.dev testing it in the real world :) [12:52] vila: and I also decided to stop worrying about the 1.0 branch and let poolie2 make that call ;) [12:53] spiv: good, time to write that tiny plugin to make urllib the default http implementation then [12:53] vila: for TDD, I'd probably recommend Kent Beck's _Test Driven Development By Example_ over the xUnit Patterns book. [12:53] vila: the xUnit Patterns book is pretty good, but Beck's book is *much* shorter :) [12:54] They're about pretty different topics, though. [12:54] The xUnit Patterns book isn't really about TDD, it's about refactoring test code (whether or not you're writing tests first). [12:56] vila: If were to buy two books though, I'd buy both :) [12:57] looking into it, but only the first is available at amazon.fr so it will be here sooner ;) [13:01] and since my birthday was last week, I can afford both \o/ [13:01] done [13:02] vila: merry christmas and happy birthday :) [13:02] hehe, thks :) [13:03] Also, thanks to jam's swift approval, selftest --coverage is with PQM already! === me_too is now known as too_short === too_short is now known as me_too [13:11] * spiv -> bed [13:40] New bug: #174414 in bzr "bzr unable create lightweight checkout in the root of shared repo" [Undecided,New] https://launchpad.net/bugs/174414 === cprov is now known as cprov-lunch [15:26] New bug: #174437 in bzr "--coverage leads to traceback" [Undecided,Confirmed] https://launchpad.net/bugs/174437 [16:02] privet, guys [16:03] I'm thinking about idea "sam on top of bzr", and I'd like to discuss it a bit [16:04] s/sam/scm/ === cprov-lunch is now known as cprov [16:12] dato: Hi [16:12] dato: Can you sponsor another upload? [16:13] dato: bzr-rebase 0.3, I've already uploaded packages to http://samba.org/~jelmer/debian/ [16:13] This matches the version in bzr on bzr.debian.org === kiko is now known as kiko-fud [16:15] noted; it may take a couple days this time [16:30] bialix: what do you mean by "on top of bzr" [16:32] hi, jam. I mean this: for my current job project I have about 15 different branches. I nee the way to somewhat organize them all [16:32] need the way [16:33] Because currently bzr don't help in my needs, I should some tool on top [16:33] sorry, I need some tool on top of bzr [16:35] today I finally start writing some code. I highlight 3 base concepts I need: Project, Branch and Subproject [16:36] Project build up form Branches and Subprojects. Subproject is just link to another Project [16:37] so I can build hierarchical structure of my actual project [16:38] http://pastebin.com/d65d7215f [16:38] and here example of project.conf: http://pastebin.com/d346379b9 [16:39] it's just fast draft to start playing with indea [16:40] idea [16:40] When I will have valid project.conf with description I'd like to have ability to (lightweight) checkout project for work [16:41] something like modules in CVS [16:41] back in my TortoiseCVS days I've used modules in one big and complex project [16:42] I know that I'm reinventing the wheel [16:42] I just can't find ready-to-use solution [16:42] and can't stopping my idea flow === kiko-fud is now known as kiko [16:47] The main idea: I can list existing defined projects, do full checkout of big project, or only some subproject and so on [16:47] I'm also need somehow keep information about different variations for one project, per example for different customers some branches will be different, but body of project will stay the same [16:48] And I'm sure it's not the same as NestedTree we very long time talked about [16:49] It's just the way to describe relations between branches [16:50] I really like to talk about this idea with someone [17:02] could someone assist with a 'not a branch' error in bzr 0.91? [17:02] bialix: you might try "config-manager" as a way to track multiple sub-projects for a meta project [17:02] and getting things properly built, etc. [17:02] Last I heard it was rather crufty, though. But it might give you a starting point [17:03] jam-laptop: I try to look at this tool several times in the past. It looks too linux-centric [17:03] mrtuple: we can try, but certainly not without more information :) [17:03] mrtuple: the #1 thing I would check is that you really are giving it the right path [17:03] I have a .bzr/branch-format and a .bzr/branch/format files. [17:04] I'm pretty sure of the right path... one moment and I'll prove it (at least to myself) [17:04] yep [17:04] ssh-agent sbox$ ssh 138.67.142.48 cat ./sbox/pfind/.bzr/branch-format [17:04] Bazaar-NG meta directory, format 1 [17:04] but [17:05] bzr branch bzr+ssh://138.67.142.48/sbox/pfind ./pfind-repository [17:05] yeilds [17:05] mrtuple: you need the absolute path [17:05] not relative to your home dir [17:05] also [17:05] a;dkjfa;ldkjfal;kdflee3jaa;lkadfah;akldf [17:06] sorry to waste your time. [17:06] mrtuple: no problem :) [17:06] many thanks. [17:08] jam-laptop: config-manager's last commit was 1.5 years ago [17:08] bialix: doesn't mean it doesn't work :) [17:08] bialix: but really, I think NestedTrees *are* what you want, but we don't really have them yet [17:09] so in the short term, you need something else [17:09] I think it could easily just be a plugin [17:09] yes, may be as plugin [17:09] with stuff like "bzr build-project" etc [17:10] I don;t understand how NestedTree supposed to store meta-info about projects? [17:10] well, it is supposed to store locations of where you are updating your branches from, etc. [17:10] There may be some parts of what you want [17:10] that are not covered by NT [17:10] but I think a lot of it is [17:11] You may want to write up your use case on the NT wiki page [17:11] just to have another data point for how it should work. [17:11] I don't know how NT should work [17:11] bialix: the point is for you to write up what you want [17:11] (your use case) [17:11] and then people implementing Nested Trees [17:11] can take that into account [17:11] it may not do everything you have requested [17:12] but at least that gives us a starting point. [17:12] but I need several level of NT at the same time [17:12] bialix: NT should support several levels [17:12] and somewhat describe different variations for the same project [17:12] I'm not sure about different variations of the same tree [17:12] but I think it would be reasonable to have that concept mentioned [17:12] I mean some branches in NT may be different [17:13] bialix: sure [17:13] I certainly would expect to be able to create a NT for different releases [17:13] 1.0 would have different branches than 0.9 [17:13] and someone working on feature X would probably want their own branches [17:13] I don't mean different set of branches [17:14] I mean for some lib foo I have trunk, bar and spam branches [17:14] and I need the way to specify configuration when instead foo in NT will be used either trunk or bar [17:16] bialix: that is a 'different set of branches', IMO, and is definitely something NT needs to support. [17:17] NT wiki page, summary, item 2: Can we do better than configs? [17:17] so my idea with config is step backward? [17:17] well, for the existing configs, maybe [17:18] so nested tree itself should be some standalone being? [17:18] substance [17:19] I'm not sure what you mean by "standalone being" it is functionality we want as part of bzr core [17:19] not just the way to work with set of branches? [17:19] I mean separate object [17:19] I lack english terms here [17:20] something separate from branch/wt/repo [17:20] additional block in bzr model? [17:20] bialix: Not necessarily, it may just be that WT has the ability to do NT [17:21] at least, that was my feeling [17:21] I can't imagine how it will works in reality [17:21] some of why NT would be better than configs is that it would integrate with general workflow [17:22] rather than remembering "oh, I need to commit the snapshot of my set of branches" it would just be a "bzr commit" at the top level [17:22] what about log? [17:22] it will be summary log for all sub-branches? [17:23] what about tags? [17:23] I need tag all branches at one time [17:23] bialix: well, if you tag a top-level tree, then it implicitly references all sub-trees [17:23] With NT each tree keeps a reference to the current version of the sub tree [17:23] so if you tag a sub-tree, then it *effectively* marks that node, and everything underneath it [17:24] because a committed revision refers to everything underneath it [17:24] I would certainly expect NT to allow you to create a "release-1.0" tag for just a library [17:24] so I'll need to create some empty top-tree to put all my subprojects in? [17:24] (or at least a lib-release-1.0 tag) [17:24] bialix: Project is your top level tree [17:25] currently my set of branches is very loosely coupled [17:25] whether it is empty or not is probably just dependent on how you want to divide things up [17:25] I have sources to compile on Linux, another sources for Windows, some for microcontrollers, docs, schematics [17:26] it just a big basket [17:26] so most of the time I'm working only on some subtree [17:27] I probably never will checkout the whole project [17:28] I think this is all worthy of being put on http://bazaar-vcs.org/NestedTreeSupport [17:28] even if it amounts to "stuff that NTS is not meant to solve" [17:28] I think part of what you are discussing is a "branch registry" of sorts [17:29] I read http://bazaar-vcs.org/NestedTreeSupport but I still can;t imagine how it supposed to work in reality [17:29] so you can refer to things without having to use raw URLs [17:29] Which would also fall under some of our discussions about branch aliasing [17:29] I don't remember about branch aliasing [17:30] bialix: just being able to use an alias to refer to a full url [17:32] btw, I'm starting to put all my unrelated branches in one pack repo. I have about 44 MB of packs and about 23MB in obsolete_packs section. Is it normal? [17:33] bialix: in a couple of commits you will get 44MB of packs, and probably a few hundred KB in obsolete_packs [17:33] Well, as long as you are using something newer than 0.92 [17:34] do I need time-to-time run repack manually? [17:34] IIRC, 0.92 didn't clean up obsolete_packs [17:34] I'm using 1.0rc1 [17:34] bialix: 'bzr pack' is purely optional, but probably beneficial at the moment [17:34] Robert has a patch which will make it do a bit of extra sorting for Revisions which helps 'bzr log' [17:35] but right now managing the extra indexes is the actual overhead of multiple pack files [17:35] yes, I read your mail [17:39] so my use case is more about keep set of loosely related branches together [17:39] than actual NT? [17:42] I think NT could do it, but you may want them to be looser than that [17:42] but I've thought about using NT to manage a repository of branches [17:42] which some might consider heretical [17:42] (bad) === me_too is now known as too_short === too_short is now known as me_too [18:03] need to go, bye [18:32] Hey, if I do 'bzr merge -r x..y', is it normal for 'bzr missing' to indicate to me that I don't have y? [18:34] fbond: As I understand it, cherry-picked revisions don't get recorded as included in a branch [18:35] radix: I think I understand why (I merged a diff, not a revision) ... but that seems a bit confusing for users, doesn't it? [18:35] fbond: rich cherry-picking support is a known limitation of bzr, (again) as I understand it. [18:36] Okay. So there really isn't any difference between using 'bzr merge' and creating a patch and applying it via 'patch', right? [18:36] (for cherry picks) [18:36] fbond: well, yeah. if you use "bzr merge" without "-r" it records all the information wonderfully :) [18:36] radix: right :) [18:36] but indeed. I think what you said is pretty close to the truth. [18:37] I'm not a bzr developer, though. [18:37] radix: okay, thanks! [18:37] Well, I did notice one thing, though: [18:38] If I have two branches (a and b) and I do 'bzr merge -r 2..3 a b' and then do 'bzr merge a b', changeset 2..3 only gets merged once (like I want). [18:38] So bzr must be tracking *something* ... [18:38] fbond: well, bzr just goes "oh, this hunk of diff looks like it's already there" [18:38] diff/patch wouldn't be quite so smart ... [18:38] Yeah. [18:39] it's not really rich revision tracking that's doing the work here, it's just resilient diff application [18:39] I guess you can tell patch to ignore already applied diffs .... [18:39] so yeah, it's a bit smarter than patch [18:39] oh. well then :) [18:39] Okay, I'm just trying to understand what's happening. [18:39] * radix nods [18:39] -N or --forward [18:40] Ignore patches that seem to be reversed or already applied. See also -R. [18:40] That's from patch(1) [18:40] Anyway, thanks for your help, I understand the situation now. [18:40] It seems like cherry picks deliberately lose information that other merges wouldn't. [18:41] I wonder if the user should be notified that metadata is not merged with cherry picks. === BasicMac is now known as BasicOSX === mw is now known as mw|food [19:48] what is the command for reverting the changes in a file ? [19:48] ita: bzr revert [19:49] ita: with `bzr revert` you'll undo any changes, and will get the file back to the last committed revision. it'll make a backup copy just in case. [19:49] thanks === cprov is now known as cprov-out [19:52] hi dato [19:52] dato: did you see my message earlier? [19:55] 17:15 noted; it may take a couple days this time [20:16] dato: no hurries, thanks :-) [20:26] fbond: also, if you cherry pick at the tip of a branch its recorded as a regular merge [20:32] lifeless: like 'bzr merge -r 3..4 a b' where rev 4 is the tip of a? === mw|food is now known as mw [20:36] bazartools is .. wtf?? [20:37] Please send this report to bazaar@lists.ubuntu.com with a description of what you were doing when the error occurred. [20:38] lifeless: good morning [20:40] converting an arch repository to bzr looks really complicated [20:40] ah, btw, what is the opposite of "python setup.py install" - how to uninstall ? [20:42] ita: there isn't one, I don't think. [20:44] is PQM down again? [20:44] jml: am i the only one to think that really sucks ? :-) [20:45] New bug: #62275 in bzr "pull and update with lightweight c heckouts should only affect the working tree" [Undecided,Incomplete] https://launchpad.net/bugs/62275 [20:46] ita: not the one [20:47] ita: I'd only go so far as "kind of" [20:47] ita: mostly because I rarely use 'install'. :) [20:47] jml: no, completely, because if you install once again it does not tell you what files are installed === kiko is now known as kiko-afk [20:52] Aha, I am #100! :) [20:54] jelmer: I just got an error trying to do a co of an Svn trunk. [20:54] (guessing you are the one to talk to) [20:56] gokr: hi [20:56] gokr: What error exactly? [20:57] bzr: ERROR: Path "SerialExtendedMacOS9.¹.xml.sit" is not unicode normalized [20:57] Haven't googled yet. [20:57] Ouch, I don't have the newer subversion - perhaps should fix that first. [21:01] where is the program "baz" ? [21:01] New bug: #162466 in bzr "Branch6 bound to SvnBranch left in inconsistent state" [Medium,Triaged] https://launchpad.net/bugs/162466 [21:04] ita: why don't you do 'python setup.py install --prefix=tmp' and see what gets installed there? [21:04] ita: http://bazaar-vcs.org/Baz1x [21:06] fbond: nice [21:06] i love this [21:09] Btw, bzr seems to have come a long way lately. I have used Mercurial for a while - but hey, bzr is looking quite tempting now. [21:13] good to hear :-) [21:18] This file is obviously committed from a Mac, but I am unsure about the character right before ".xml.sit" [21:18] In the SVN checkout there is no character there. [21:20] Aha! It *had* a bad name, but not anymore. [21:27] jelmer: Ok, so the problematic character is "SUPERSCRIPT ONE" utf8: c2b9 [22:04] gokr: that's odd, bzr-svn works with various other utf8 characters ok [22:04] jelmer: Sounds like this might be interesting to test: https://bugs.launchpad.net/bzr/+bug/172383 [22:04] Launchpad bug 172383 in bzr "Cannot add NFD normalized Unicode file to repo" [Medium,Triaged] [22:05] ubotu: Right. :) [22:05] Sorry, I don't know anything about right. :) - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [22:05] Oh, a robot. [22:05] gokr: we prefer to call them the personality-deprived. [22:06] Anyway, I will try again with trunks instead of what is in Etch. [22:07] gokr: you were running bzr-svn on Mac earlier? [22:07] No, I am on Etch. But some of the files in the svn repo I am trying to checkout has been committed from a Mac. [22:07] Or rather - an old file had such a name, it is not there anymore but since we fetch all history... :) [22:08] This is the Squeak VM btw. [22:10] Trying again. [22:10] Btw, if this works it is darn neat. [22:11] (bzr-svn I mean) [22:30] What's the difference between "bzr pull --overwrite" and "bzr merge --pull (and --force)"? [22:30] hello [22:30] theuiguy, if the branches have diverged, then [22:30] If I just want a branch to match its parent, what's the best way to do that? [22:30] pull --overwrite will discard your changes and put you on their version [22:30] whereas merge will do a merge [22:31] in that case you want pull --overwrite [22:31] possibly followed by revert, if you want to discard your uncommitted changes [22:32] poolie2: Thanks, I think I followed that... === poolie2 is now known as poolie [22:33] just for better understanding, what would the merge --pull version do? [22:33] I know merge would try to combine my changes with the parent [22:35] poolie: Is a revert only necessary for unadded changes? Does pull --overwrite not remove files? [22:35] theuiguy, merge --pull differs from regular merge in that [22:35] only necessary for removing unadded changes (mainly new files)? [22:35] it basically tries to do a pull --no-overwrite first [22:36] jelmer: Trying the patch now. Just using the trunk didn't help. [22:36] theuiguy, revert is only needed for uncommitted changes [22:38] Is it generally good practice to do a pull before the merge anyway? [22:38] or does that more depend on what you're doing [22:54] gokr: using which trunk? [22:57] Emmm, I am using the latest bzr and bzr-svn I could find. [22:59] This: http://bazaar-vcs.org/bzr/bzr.dev and this: http://people.samba.org/bzr/jelmer/bzr-svn/trunk [23:04] jelmer: It looks promising, I think it has passed the problematic spot. [23:08] jam: we increase the branch puller timeout, but it seems your branches have failed often enough to be disabled [23:09]