[00:17] hi all [00:20] poolie: to answer your question: [00:20] hi [00:20] poolie: yes, Gitorious asks the user to upload SSH keys [00:21] the only thing (AFAIK) they're using OpenID for is to replace the need to supply a password to log into the web site. [00:21] which is exactly the extent of [00:21] Ubuntu bug 210943 in Launchpad itself "be an openid consumer (relying party)" [Low,Triaged] [00:21] (as far as I'm concerned) [00:22] just like Bitbucket [00:25] bignose, did you see http://productblog.37signals.com/products/2011/01/well-be-retiring-our-support-of-openid-on-may-1.html [00:25] * bignose hopes against hope that with Bitbucket and Gitorious accepting OpenID for login, that Launchpad might join very soon. [00:26] poolie: yep, I saw that. [00:28] i think they have a good point [00:29] the requirements-level idea of people owning their own credentials across sites is good of course [00:34] poolie: what is their good point? we may disagree on what that is :-) [00:35] the good point they have IMO is that there is a threshold below which it's not worthwhile for a site to implement an OpenID relying party. [00:36] but that's presumably uncontroversial. [00:36] I think Launchpad would clearly benefit from being an OpenID relying party, and Canonical has the resources and skills to implement it. [00:40] ah i thought the good point was that openid does not give a very good user experience [00:41] because amongst other things it bypasses or disables a lot of work that has been put into browsers to make regular http auth and form/cookie auth work well [00:41] anyhow, this isn't especially a reason it won't be done in lp [00:43] and many of the same issues apply to lp's captive openid provider [04:45] I'm working with Bazaar branches off a Subversion repository [04:45] or rather, a Bazaar bound branch with Bazaar feature branches [04:47] when I merge a feature branch into the trunk (bound to a Subversion server) the status shows the merged revisions [04:47] but when I commit, the Subversion repository only has a single revision – the merge. [04:47] am I misunderstanding what I'm seeing? [04:48] how can I have the merged revisions appear in the Subversion repository for others to see? [04:53] bignose: I think you may need to push those feature branches into svn first, then merge the svn instance of them into trunk. jelmer would know for sure. [04:56] hmm. that's not an attractive option; I'm talking about feature branches that are freely created for my use. I don't think my collaborators want them in the central Subversion repository. [06:15] jelmer: when you're around, I would appreciate your input on the above. [07:06] bignose: you could rebase the branch on top of svn trunk before you push [07:07] but of course then you lose the ability to work with the branch later, or share the branch before it's finished [08:03] morning poolie [08:03] hi there jam, how are you? [08:03] doing pretty good [08:04] poolie: how was your day? [08:04] pretty good [08:04] pushed along my launchpad email refactoring branch and did some pre-trip errands [08:09] jam is there an upstart script to run loggerhead? [08:09] apparently not in the current daily package [08:09] just looking at https://answers.launchpad.net/bzr/+question/154439 [08:09] poolie: I think there used to be an init.d entry, but we removed it a long while back IIRC [08:18] spiv, could you set up a webnumbr from patch-needswork things? [08:18] s//bugs/ [08:19] jam the guy might not realize he doesn't need a long-running process [08:19] we'll see [08:24] poolie: sure [08:28] luks: right. both of those (along with not wanting to re-write history in general) mean that's not an option. [08:30] bignose: unfortunately, I don't think there are any other options [08:30] as far as I know, you either need the push the branch to svn or rebase it [08:31] I think that's actually why the rebase plugin was written by jelmer :) [08:34] posulliv: http://webnumbr.com/bzr-bugs-tagged-patch-needswork [08:34] posulliv: oh, sorry, wrong nick [10:18] hi all ! [10:23] who's there? I don't believe it! [10:23] heya vila! \o/ [10:24] bialix: Hey ! Just arrived :o) A bit delayed in flights... [10:25] you came back just for uds :-) [10:26] jelmer, jam: Ping. Anything I should know or check before before cutting 2.4b2 ? [10:26] bialix: he he, almost, but I won't attend UDS ;) [10:26] vila: Hi, and welcome back! [10:26] hi vila [10:26] damn, how many uds are there per year? [10:27] it depends [10:27] Tak: As many as Ubuntu releases :) [10:28] Vacations were lovely but it's still good to be back :) [10:30] jelmer, jam: https://launchpad.net/bzr/+milestone/2.4b2 mentions 2 bugs in progress, one of which being critical, should I wait (>-/) or should they be re-targeted ? [10:31] vila: I think jelmer's patch for it has been approved (by me) I'm not sure if he has sent it yet [10:32] jam: It's not marked as approved in lp yet as far as I can tell [10:32] ( - https://code.launchpad.net/~jelmer/bzr/move-interbranch-fetch2/+merge/59204) [10:32] jelmer: you needed to tweak the NEWS entry, but I marked review:approve [10:33] vila: I want to release qbzr 0.21 beta1 for bzr2.4b2. How many time I have? [10:34] bialix: well, if we follow the usual process (cutting 2.4b2 today), it will be announced next tuesday, so it mostly depends on packagers, but the OSX ones are quite reactive so the sooner the better [10:37] jam: you seem to have approved it 2 hours ago, yet, the proposal appears to have been resubmitted after that (your vote has a yellow background) even if the resubmission seem to have been done 22 hours ago... lp bug ? [10:37] jam: Ah, I see what happened. I resubmitted the MP so your vote is only on the old MP [10:37] ha no, probably jam approved the old one by mail [10:37] ah [10:39] jam: oh, and you landed the fix for bug #76012 in 2.3 [10:39] Launchpad bug 76012 in avahi (Ubuntu Edgy) "Avahi can run into an infinite loop on reception of a bad packet" [High,Fix released] https://launchpad.net/bugs/76012 [10:39] meh [10:39] vila: ok, I'll made release this weekend [10:40] bialix: ok, I'll mention that in the freezing mail then [10:40] thx [10:40] hmm, that was bug #760152 [10:40] Launchpad bug 760152 in Bazaar "bzr merge --pull --preview BRANCH does not always honor the --preview option" [High,In progress] https://launchpad.net/bugs/760152 [10:43] vila: right, so that landed in 2.3, but needs to be merged up to 2.4, IIRC [10:43] I didn't feel like doing it for just that patch [10:44] jam: right, I dunno what this patch does, but *I* generally prefer to merge earlier if only to make sure potential conflicts are resolved asap [10:45] fullermd: around? [11:13] ouch, 5.000 emails to process... [11:13] vila: how many of those are the automate mails? [11:14] jam: I don't know yet but not much, only 12 out of the 5000 weren't sorted properly [11:15] is that because of the mail backlog you stopped getting? [11:15] jam: automated emails should be less than 1000 anyway [11:15] yup [11:16] right, 300 for the builds [11:16] probably ~50 for the mp landings [11:18] jam: could you merge up your patch to trunk ? That's the only one missing there [11:18] vila: don't you merge up anyway for the release? [11:18] or you aren't doing a 2.3 [11:19] no 2.3 yet, I generally merged up, but my plate is clearly overflowed there so any tiny bit will help ;) [11:20] gosh, 600 emails for the bugs, none automated there [11:26] hi vila! welcome back [11:26] poolie: hey !!! [11:26] thanks ;) [11:26] how was your trip? [11:26] lovely [11:27] which is good for a honeymoon rehearsal :-D [11:27] (I should stop doing this joke or Valentine will take it seriously ;) [11:30] haha [11:34] * bialix waves on poolie [11:35] hi there [11:35] sorry, my english skill [11:37] poolie, what decision has been made re bzr-colo for bzr core? [11:37] i don't think it should be the default [11:37] that thread has been very long but I'm not sure what the resume [11:38] yes i should propose a conclusion [11:38] it seems clear some people really like multiple trees [11:38] i think we should add a core concept of multiple named branches [11:38] jelmer has some branches that come pretty close to that [11:38] then bzr colo can use that [11:38] that's good [11:39] and qbzr etc can go through that interface to get at colo branches if they're there [11:39] I'm going to improve support for colo in qbzr and explorer, so it's useful to know what to expect [11:39] i realize it already has some support, but it can be perhaps more abstracted [11:39] no, today there is no good support for colo [11:39] some basic support in explorer, but it should be improved a lot [11:40] big shoes to fill [12:04] Yo! [12:04] Has anyone seen this before: [12:04] File "/home/niemeyer/.bazaar/plugins/fastimport/cmds.py", line 38, in _run [12:04] proc = processor_factory(verbose=verbose, **kwargs) [12:04] TypeError: __init__() got an unexpected keyword argument 'control' [12:06] Nevermind.. here it is [12:06] https://bugs.launchpad.net/bzr-fastimport/+bug/736681 [12:06] Ubuntu bug 736681 in Bazaar Fast Import "unexpected keyword argument 'control'" [Undecided,New] [12:06] and I even +1d it already.. great memory [12:07] The version in Natty seems to suffer from that, FWIW [12:09] hi! I'm a bit confused. I co'd a branch on launchpad. I made a change, which I wanted to keep handy but didn't want to commit yet, so I made a local commit (commit --local). Then I made some more changes, which I realised I didn't want, so I did a bzr revert. I expected it would revert it to the state of my local commit, but it didn't: it reverted to the state of the remote branch [12:09] how do I get my local commit back? where has it gone? it doesn't show up in bzr log, and so I don't know what revision number I could use to bzr revert back to it [12:10] Er.... that soudns wrong.. bzr revert with no arguments will undo changes not yet committed in the workdir, but won't alter the branch. [12:11] err, I mean, when I typed 'bzr revert' the state of my workdir was that of the remote branch [12:11] pfarrell_: use bzr heads --dead to find your local commits, then bzr pull . -r revid:dead-id [12:11] my local commit is still listed as a pending merge, though [12:11] bialix: that sounds great, I'll try that, thanks [12:12] IIRC rebase can convert pending merges to local history, or maybe I wrong, jelmer? [12:13] this is very confusing [12:13] pfarrell_: it's better avoid commit --local [12:13] Also, perhaps you wanted to start by bzr branch URL instead of co [12:13] or just do `bzr unbind` [12:14] but isn't the whole point of local commits being able to easily back up changes you don't want to commit yet? [12:14] checkout makes another -workdir- that's basically trying to be _the same branch_, history and all... branch forks it. [12:14] Yes indeed... [12:14] branch it [12:14] pfarrell_: I think bzr shelve is for backups [12:14] checkout is usually best for always-online connected clients, in a centrallised model similar to CVS or SVN [12:14] If you want to work on your own history, independent of that upstream, you want a branch [12:15] well, I almost always want to just use a checkout [12:16] but occasionally will want to make checkpoints of incremental work that isn't ready for public committing yet [12:16] so I should unbind, commit, then bind again? [12:16] unbind, commit, leave it unbound [12:17] When you want to send it back upstream again, push it [12:17] pfarrell_: it looks like you want feature branches for incremental work [12:17] bialix: the kinds of local commits I had in mind have lives of tens of minutes [12:17] have you looked at bzr-colo? [12:18] I don't want to bother with feature branches for something so small and trivial [12:18] nope [12:18] it does not matter [12:18] The branch doesn't have to exist upstream.... [12:18] bzr-colo makes feature bracnhes very lightweight and easy [12:18] It's on your local workstation; it's a branch. [12:25] colo == in-place branches? [12:29] jelmer: ping [12:30] niemeyer: pong [12:30] jelmer: Hey! [12:30] niemeyer: hi, how are things? [12:30] Playing with bzr-fastimport again I see ? :) [12:30] jelmer: Pretty good.. just fixing bzr-fastimport again :-) [12:31] jelmer: Any chance of a fix for Natty? [12:31] niemeyer: IIRC there are two bugs you hit, one related to _find_ancestors in bzr and the one you just reported? [12:31] jelmer: Yeah, I think you solved the former, right? [12:32] jelmer: At least I'm not bumping on it anymore [12:32] jelmer: I hacked my local version for the latter [12:32] jelmer: But the last upgrade killed it again [12:32] jelmer: The fix is actually to go back, weirdly [12:32] jelmer: 309 was working before [12:33] niemeyer: that's odd - you're using both python-fastimport and bzr-fastimport from trunk? [12:33] jelmer: I actually can't see how that ever worked, to be honest [12:33] jelmer: control isn't a keyword there indeed [12:34] jelmer: I'm using packaged bzr for everything now [12:34] jelmer: It's breaking in Natty itself as well [12:35] jelmer: Maybe bzr trunk changed or something? I've never used bzr trunk since I reported the bug last month [12:37] I don't recall anything relevant changing recently, so I'm not sure. [12:38] niemeyer: I'll try to get the fix for that bzr-fastimport issue into natty. The last sync from Debian to work around an issue with python-support must have pulled in the broken revision. [12:38] jelmer: Ah, could be. Thanks! [12:40] Tak: yep [13:14] jelmer: FWIW, this works: cd ~/.bazaar/plugins && bzr branch -r lp:bzr-fastimport fastimport [13:14] Erm [13:14] jelmer: FWIW, this works: cd ~/.bazaar/plugins && bzr branch -r 309 lp:bzr-fastimport fastimport [13:18] niemeyer: thanks [13:18] hi [13:18] I'm trying to log in to launchpad so that I can check something out, but when I do lp-login (or pretty much anything else), I get [13:18] AttributeError: 'module' object has no attribute 'HTTPSConnection' [13:18] niemeyer: I'm adding some more black box tests (and have reproduced the bug that way), it should be easy to fix the bug after that. [13:18] hi pfarrell_ [13:18] it looks like it's trying to access httplib.HTTPSConnection, and it's not there [13:19] pfarrell_: how did you install Python? It seems your Python was built without ssl support. [13:19] hi :-) [13:19] it was supplied by our supercomputer administrators [13:19] and I believe they built it by hand (not from any package management or such) [13:19] * pfarrell_ sighs [13:19] pfarrell_: does "python -c 'import ssl'" work? [13:19] I guess I will go ask them to rebuild it with ssl support [13:20] nope [13:20] ImportError: libssl.so.4: cannot open shared object file: No such file or directory [13:20] pfarrell_: It looks like it was built with ssl support but that one of the ssl libraries simply isn't installed? [13:20] oh, it doesn't surprise me [13:20] the systems are always a total mess [13:21] because they have to have multiple different versions of everything available to please everyone, and so they can't use proper package management -- they have to make do with building things by hand and then making these awful 'module' files [13:21] no wonder the installs are always barely working [13:21] anyway, I'll get on them [13:21] thanks [13:22] np [13:22] * pfarrell_ wishes someone came up with a linux distribution where you could install more than one version of the same package at a time [13:27] usually those distributions version the packages, e.g. python2.6 [13:29] yep [13:29] debian/ubuntu do this for some things, but not for lots of other things [13:30] for example, on the supercomputer I'm talking about, there are currently 8 different versions/compiles of fftw [13:30] it's not only the version, I guess; it's also the build options === Ursinha-afk is now known as Ursinha [13:51] pfarrell_: sounds like the opposite of what the role of an OS distribution is [13:51] pfarrell_: which makes a unified OS for all applications to use [13:52] pfarrell_: having the “same” library installed multiple times with multiple options is a recipe for pleasing nobody, not pleasing everybody [13:52] and it sounds like the sys admins have yet to learn that fact. [13:53] well, that might be a definition of an OS distribution, but I suppose I only want smarter package management [13:53] these packages would be built locally by the admins of the cluster, not 'distributed' by someone else [13:53] no, it sounds like you don't want to work on the same machine as all those others. [13:53] but it would be nice to be able to, say, install and uninstall them easily [13:54] and to try to orthogonalise the dependencies (in so far as that is possible) [13:54] well, take a simple example [13:54] some people have physical problems involving reals, and want fftw compiled with scalar=double [13:54] well package management makes it easy to install/uninstall packages in large part *because* it leverages the consistency and unified nature of all the packages together. [13:54] others have different physical problems, and want fftw compiled with scalar=complex [13:54] at the minute the system is a mess [13:54] can you think of no better way of managing it/ [13:54] ? [13:55] if that consistency and unified presentation can't be relied on, you don't want package management at all [13:55] you just want to have everything isolated from everyone else's stuff. [13:56] but then of course you have to take the role of package management on yourself: define the options for everything and compile it yourself and assume the responsibility for making it work together. [13:57] instead of everyone working on the same instance of the OS, everyone should have their own virtual machine where they install whatever they want and compile packages however they want [13:57] still a nightmare, but at least each person's nightmare doesn't interfere with anyone else's :-) === issyl0 is now known as Guest23776 [14:08] bignose: hi, still there? === Riddelll is now known as Riddell [14:17] jelmer: not for long [14:17] thanks for responding [14:19] jelmer: any hope for my Subversion use case? [14:20] is it possible to, for example, have the merged revisions appear individually in the Subversion trunk? [14:21] rebase + push is the usual way to do that [14:21] while still being able to continue working on the Bazaar branch with more revisions? [14:21] rebase your branch against the trunk, so now your tree only contains new revisions, so push those to trunk [14:21] LeoNerd: no, these Bazaar branches are public. re-writing their history isn't an option. [14:22] also, new revisions will appear, and they'll be merged again into the Subversion trunk. [14:22] OhIsee... trickier [14:23] basically I've been requested by other users of the Subversion trunk “we want to see the revisions that we see when we look at your Bazaar branches, instead of losing them when you commit to Subversion” [14:24] we're moving slowly and cautiously toward DVCS, some users must still use Subversion but like what they see on my Bazaar workflows [14:25] so I'm trying to make what I do as public as possible to keep the momentum alive [14:25] and jelmer has the burden that everyone here is deferring to him for possible answers to my questions :-) [14:28] I have to go, but I'd really appreciate a way to resolve this nicely so will check back later [14:30] bignose: sorry, missed you again [14:31] bignose: the short answer is you can set "push_merged_revisions" to push right hand side revisions as well === mrevell_ is now known as mrevell [15:29] vila: is there a bzr 2.4 b2 tag? [15:29] jelmer: it's currently in pqm queue [15:30] vila: ah, thanks [15:30] jelmer: you mean a bzr tag right ? not a lp milestone / [15:30] ? [15:30] vila: yep [15:30] jelmer: is it me or pqm got slower ? [15:31] vila: John also had that impression; I usually don't watch PQM very closely so I'm not sure. [15:31] jelmer: I ... don't watch closely, but... I did 3 submissions today and 2 are still in the queue (ok, the second one is almost done, but still) [15:32] anyway, I don't think we collect stats there so that question will remain opened... [15:43] vila: What, PQM isn't allowed to have a vacation too? :p [15:44] fullermd: bot is a polite word for slave and slaves like golems should never stop to work, never [15:45] Man, I wouldn't want to have a statement like that on MY record when the machines rise up and take control... [15:45] [15:46] fullermd: well, the log will look like I just copy a private saying of yours... [15:46] For the record, I love all machines and dedicate my life to serving them. PQM should have a full harem massaging its electrodes full time. [15:47] fullermd: ha, that should explain why it's slower then :) [15:48] fullermd: and I note that you're trying to confuse me even more about my jetlag by popping up at very unusual hours too [15:49] How would you know they're unusual hours? You're jetlagged :P [15:49] the sun is there... I can feel it behind the curtains, I'm sure [15:50] Mmhmm. First PQM is being slow, now the sun is stalking you? I think you're getting paranoid... === zyga is now known as zyga-afk === niemeyer is now known as niemeyer_lunch === niemeyer_lunch is now known as niemeyer [17:43] jelmer: ping? Did you see my email of 2011-04-13 to pkg-bazaar-maint questioning your commit 3924: Jelmer Vernooij 2011-04-04 Use makefile rather than setup to build. ? [17:44] maxb: yeah - I'm working on uploading 2.4b2 atm, will address that too [17:45] thanks - I wanted to get it sorted before people started to want 2.4b2 in the beta ppa [17:47] maxb: hmm, actually.. that change isn't in the experimental branch which I'm going to upload [17:48] *blink* [17:48] it's just in the unstable branch [17:51] uhm, that's not what I'm seeing [17:52] oh, it's not there because it's in the ancestry but got reverted in the process of mergin [17:52] g [17:52] that's confusing [17:53] Also, what's the intended semantic difference between the "2.4" and the "experimental" branches on alioth? [17:54] "2.4" appears to be a strict ancestor of "experimental" [17:55] experimental is intended to be a symlink to 2.4 [17:55] fixed [17:56] What's the motivation behind numbered branches and symlinks? [17:58] being able to get at a specific bzr release series packaging without having to have or know the debian release it was shipped in [19:28] When I try to commit to a svn repo with bzr commit, I got "ERROR: Connection closed: Network connection closed unexpectedly" [19:29] I can use bzr co to checkout code from the repo, so I don't think it's a server side problem === Guest23776 is now known as issyl0 === cody-somerville_ is now known as cody-somerville === BasicPRO is now known as BasicOSX === andreas__ is now known as ahasenack === cody-somerville_ is now known as cody-somerville [20:23] Still have the ""ERROR: Connection closed: Network connection closed unexpectedly" problem with bzr-svn [20:24] Any idea where I can get more info of the error? [20:36] hello [20:36] just would like a little advice cf. "scenario": [20:37] given two teams, one "internal" and the other "external" which provide peer review and rare contribs [20:38] an sftp space is avail (internal ubu host) [20:39] so even bzr+ssh is an option, even if not mandatory to start with - great [20:40] updated to bzr-svn newest version [20:40] doesn't work [20:41] * caravel will try to finish this descr :) [20:41] so, external need to access internal's sandbox on demand [20:42] internal will push their integration at regular intervals, say to "trunk" [20:43] external will update from "trunk" and push to "contrib" [20:43] internal could then include "contrib" changes into their "sandbox" [20:43] so we'd have 3 spaces on the sftp: "sandbox", "trunk" and "contrib" [20:44] is this overkill ? does it make sense ? is it a common way to address this scenario ? [21:46] jelmer: thanks, I will investigate ‘push_merged_revisions’ [21:46] bignose: g'morning :) [21:46] bignose: note that push_merged_revisions has some issue in the released versions [21:48] jelmer: Debian Wheezy, Bazaar 2.3.1, bzr-svn 1.0.4+bzr3475-1 [21:49] the only web search result I get for ‘push_merged_revisions’ is [21:49] Ubuntu bug 486811 in Bazaar Subversion Plugin "push_merged_revisions creates a branch but doesn't push its contents" [Medium,Fix committed] [21:49] (actually MBP's kanban page including that.) [21:50] bignose: yup, that's the bug I was talking about [21:51] so where can I read more about that option? [21:51] * bignose wishes Bazaar documentation were better searchable by web search results [21:54] bignose: it's a boolean option; I haven't really advertised it yet as it's been somewhat experimental until recently. [21:56] jelmer: where can I read about the options that will affect ‘bzr-svn’'s behaviour? [22:00] bignose: There isn't really a single place where they're documented. There's "layout" which is usually modified through the "bzr svn-layout" command, "push_merged_revisions" (undocumented) and "use-cache" (documented in the FAQ) [22:01] jelmer: the FAQ? [22:02] bignose: /usr/share/doc/bzr-svn/FAQ.gz [22:02] is ‘bzr-svn’ one of the very few Launchpad projects to actually have some documentation online? [22:02] ah, right :-) [22:02] too much to hope for then. [22:04] bignose: http://bazaar.launchpad.net/~bzr-svn/bzr-svn/1.1/view/head:/FAQ [22:05] jelmer: what does “bzr-svn did a replace operation on the branch I pushed to” mean? [22:06] I don't know whether that describes something I've seen. what's a “replace operation” from the user perspective? [22:06] bignose: It's a Subversion term, it shows up as a "R" in svn log [22:06] (change request: please alter the wording of that question so it's meaningful to people who don't know Subversion terminology) [22:06] hmm [22:07] no, I still don't understand :-) [22:07] what does a file-level replace have to do with the situation described? [22:07] or is this not a file-level operation? [22:08] bignose: patches welcome; that question is intended for people familiar with the term [22:08] this is a directory-level operation (e.g. on /trunk) [22:08] hmm [22:09] what's being replaced? [22:09] looking at it, that FAQ is actually ouf of date for newer versions of bzr-svn.. append_revisions_only is the default now. [22:10] the discussion around ‘bzr-svn’ also seems to assume that ‘bzr push’ will be used a lot [22:10] but I almost never use that, and I don't use it with ‘bzr-svn’; I merge from many feature branches into a bound branch. [22:10] am I using it strangely? [22:10] bignose: that works too [22:11] bignose: most people seem to use bzr (and bzr-svn) with push/pull rather than with bound branches, but both are supported. [22:11] okay. how can my merges from many, public, feature branches be done better [22:11] so that the revisions from those branches show up on the Subversion history? [22:12] you're merging from other public branches in the same svn repository, or from elsewhere? [22:14] there are no non-trunk branches in the Subversion repository [22:14] (and there is resistance to having any) [22:14] I'm merging from public Bazaar feature branches I created from the bound trunk branch [22:15] bignose: push_merged_revisions=True would create new branches in /branches/... [22:15] bignose: if you want the revisions you merge to show up in trunk *and* don't want any new stuff in /branches, where would you want the merged revisions to be pushed to? [22:15] any way around that? [22:15] to the trunk branch would be okay [22:16] i.e. creating the illusion that I committed all those revisions on trunk === Ursinha is now known as Ursinha-afk [22:17] bignose: that would be *really* confusing, as not each revision it would push has the previous one as its parent [22:18] jelmer: confusing for whom? [22:18] bignose: that's why bzr-svn by default only pushes the mainline, as it's consistent with the way svn users work [22:19] well, the Subversion users I'm interacting with don't use branching and merging at all [22:19] I'm trying to show them the benefits of doing so :-) [22:20] bignose: there would be lots of replace operations on trunk, and "svn log ../trunk" would only show the mainline [22:20] can you explain what a “replace operation” is for someone who is accustomed to the Bazaar model? [22:20] bignose: replace is basically delete + add in the same revision [22:21] bignose: imagine you have a common base ("B") and a feature branch with a new revision R1 on it that is merged back into the mainline in merge revision M [22:21] or: [22:21] M [22:21] | \ [22:22] .. R1 [22:22] | / [22:22] B [22:22] yes [22:22] if you would push this onto /trunk and not use /branches you would see this in the svn log: [22:22] for B: M /trunk [22:23] for ..: M /trunk [22:23] then for R1, imaging B had revnum 42: R /trunk (from /trunk:42) [22:23] hold up [22:23] then for M, assuming the last revision in .. has revnum 33: R /trunk (from /trunk:33) [22:24] I'm confused why the “M /trunk” is appearing at each revision [22:24] bignose: well, something in /trunk. It doesn't have to be /trunk itself but it could be /trunk/foo/bar or whatever was changed [22:25] okay. so some change at each revision. does this example require that the same file is being changed? [22:26] it requires that there is a revision that affects /trunk [22:27] it could even be a no-change revision ("bzr commit --unchanged ..."), in which case bzr-svn just touches /trunk [22:27] so revision B has “M /trunk/foo/bar”, revision ‘..’ has “M /trunk/wibble/wobble” ? [22:27] for example [22:29] okay, sorry to speed-bump the example. [22:31] what follows? [22:32]