[00:28] <controversial> bzr versus hg fight -- who wins?
[00:29] <spiv> clearly bzr, because it has more letters.
[00:31] <fullermd> No way, hg has that underhanded hook to sneak up.
[00:47] <lifeless> its a noshow, they both get distracted by git on the way to the arena
[00:48] <fullermd> How monotoneous.
[00:48] <bairui> hi, guys. Is this a place to ask about workspace layout, workflow, releases, etc...?
[00:49] <bairui> i have read the user guide and the advanced workspaces section, but i am still a bit vague on some of the mechanics
[00:50] <lifeless> fullermd: :P
[00:50] <lifeless> bairui: sure it, though I'm running out; I'm sure other folk here will help when you have questions
[00:50] <bairui> heh, ok. thanks :)
[01:01] <bairui> no. i don't even know enough to ask good questions. :-/ Is there an additional resource I could read? The User Guide feels a bit... sparse to me.
[01:06] <bairui> say I have a   release target   layout (taken from the shared_repository_layouts section of the UG). It has the main   trunk/   branch and containers   releases/   0.1/   0.2/   etc (all in the root of the project repo dir)
[01:06] <bairui> the term   container for foo branch   in the UG means what? Just a regular old directory in the filesystem, right?
[01:07] <bairui> well, for eg:   "container for release branches"
[01:18] <fullermd> bairui: I think so, yes.
[01:19] <fullermd> bairui: Don't forget (well, or "don't fail to learn", depending ;) that you can rearrange the branches around inside the repo any time, now or later (just watch out for other branches that might look for their old path).
[01:19] <bairui> ok. thanks, fullermd. I have to cook breakfast atm, so I'll be back. :) apologies for the monotony ;)
[01:19] <bairui> right - rearranging - that was on the Q list :)
[01:19] <fullermd> The only important thing is "stays under the repo's dir".
[01:20] <fullermd> The repo doesn't know where the branches are, or vice versa.  bzr just looks at the branch and says "is there a repo here?  No?  How about at $BRANCH/../?  No?  $BRANCH/../../?  ../../../?  [etc]"
[01:21] <fullermd> So if you mv one of the branches 'outside' the repo, the world will end and fire will rain from the sky (not necessarily in that order).
[01:21] <fullermd> But as long as you stay 'inside', it doesn't matter to the branch or repo where it is.
[01:29] <bairui> ok, fullermd... that's reassuring. Avoiding fire rain is good. So, if I could now move onto the topic of   creating releases...   Let's say it's a fresh project with nothing in production yet. Dev away, test and ready to release (small cycle with small changesets). What now? Do I tag it? Do I branch a copy as 1.0 and do I need to somehow "freeze" that branch so it can't get altered? Is that even close to the
[01:29] <bairui>  right path or am I wandering, lost in the scrub?
[01:32] <bairui> apologies again for the "now you see me; now you don't" - breakfast. bbl
[01:37] <fullermd> bairui: Well, that ends up being a question of your flow as much (or more) than a VCS thing.
[01:37] <fullermd> At one extreme you have "OK, I'm releasing this as 1.0 now", in which case you Obviously(tm) just tag it.
[01:38] <fullermd> At the other you have "OK, let's settle this down toward a 1.0 release in the next couple weeks, while we continue to let speculative stuff go on in head", in which case you Equally Obviously(tm) make a 1.0 branch.
[01:40] <fullermd> (or do you have a '1.x' branch, that you then tag 1.0 and 1.1 and ... on?  Or do you have a 1.x branch that you branch 1.0 from, work toward 1.0 on that branch, let 1.x keep working toward 1.next, and meanwhile still have the separate trunk moving toward 2.x?)
[01:41] <fullermd> There's no in-bzr way to 'freeze' a branch (though of course you could mess with FS permissions or the like to make it require increasingly heroic measures to commit on)
[02:07] <jimis> a "freeze" or "lock" feature would be good though
[02:07] <jimis> besides releases I've needed it for feauture-branches
[02:08] <jimis> let's say one week I hack on 15 different features, each on a separate branch
[02:08] <jimis> the *finished* features, I'd like to lock them somehow, to warn me against further changes
[02:09] <jimis> and also to be seen as status: locked, so that I know that this feauture is merged and I should not work anymore on this branch
[02:10] <jimis> At present I do it with all caps files at root dir, like branchname_IS_LOCKED
[02:18] <bairui> thanks, fullermd. That makes sense... I just have to choose a path. I'll experiment to make sure my understanding matches reality.
[02:19] <bairui> and yes... a lock would be nice and I'll consider an approach like IS_LOCKED, jimis, cheers.
[02:34] <bairui> let's talk feature branches...   say I have a main (shared) repo at   bzr+ssh://server/repos/project   with a /trunk/ under that. If I    bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1   to create a 0.1 pool   and then I   bzr branch bzr+ssh://server/project/0.1   to get a local working copy (into, say, another local shared repo structure). Would I then (locally)   bzr branch 0.1
[02:34] <bairui> 0.1-dev   (to keep the local 0.1 'pristine')?   Or am I now playing with the fairies again?
[02:52] <bairui> ok - something in there was not right... after doing   bzr branch bzr+ssh://server/project/trunk bzr+ssh://server/project/0.1   and then   bzr branch bzr+ssh://server/project/0.1   to create a local branch, going into the   0.1   dir and issuing the command   bzr status   gives me the error: bzr: ERROR: No WorkingTree exists for that one, mate.
[03:03] <spiv> bairui: what does 'bzr info' say?
[03:05] <bairui> that it's a repo branch (2a).  The shared repo, repo branch and parent branch look sane... the push branch is .
[03:05] <bairui> repo branch is . (which I assume is sane)
[03:06] <bairui> so, something that has been confusing me is:   Do I create a shared repo on both the server AND on each of my local dev boxes?
[03:40] <bairui> meh - newbie mistake - I didn't read the FAQ. It said to just do    bzr checkout   in my local branch (the one that was complaining about   bzr status   ).
[03:40] <bairui> however... now my local branch 'seems' to behave better, but it's not updating its parent when I do   bzr push
[03:41] <bairui> it says   Nothing to do.   My local says it's at revision 1 and the remote says revision 0
[06:55] <vila> hi all !
[06:56] <vila> haaa, pqm queue empty, finally !
[07:02] <maxb> Morning vila. 2.4.0 PPA uploads in progress.
[07:02]  * vila thanks maxb !
[07:02] <vila> \o/ o// \\o
[07:04] <maxb> Hmm. bzr-builddeb 2.7.7 FTBFS on <= maverick
[07:10] <jimis> How come some commands accept branches without full path, but others require it?
[07:11] <jimis> for example I can do "bzr switch branch1"
[07:11] <jimis> but I have to do "bzr log -rbranch:../root-dir/branch1"
[07:11] <vila> jimis: switch has some DWIM magic (iirc)
[07:11] <jimis> vila: DWIM?
[07:12] <vila> Do What I Mean
[07:12] <jimis> :-)
[07:12] <jimis> I love that kind of magic
[07:12] <vila> http://www.catb.org/jargon/html/D/DWIM.html
[07:13] <jimis> Can't -rbranch use that magic?
[07:14] <vila> -r uses some DWIM magic too :) So it can conceivably borrow some from switch... I don't know the details well enough
[07:15] <jimis> allright, thanks vila
[07:16] <vila> jimis: don't hesitate to file bugs when you encounter issues, that's the best way to bring feedback and attention to them
[07:17] <jimis> ok, will do
[07:18] <jimis> together with some other stuff, I've put it on my TODO list :-)
[07:18] <vila> great ;)
[07:18] <bairui> oops: bzr: ERROR: exceptions.ValueError: WorkingTree.set_root_id with fileid=None
[07:20] <vila> bairui: bzr version ?
[07:20] <bairui> 2.3.4
[07:21] <jimis> hmmm, log needs full path too, like "bzr log ../proj-dir/branch1"
[07:21] <vila> there was a bug with this kind of symptom, fixed in 2.4x, triggered when merging to an empty tree or empty branch
[07:22] <vila> jimis: log will be harder as you can specify a file/dir path
[07:22] <bairui> i am trying to learn how to manage distributed workflow with branches. I had made changes to a branch and merged it back into my trunk. Then it said trunk is out of date with respect to its parent; update. On the update I got that error. I did a commit successfully, and then update was a (successful) no-op.
[07:22] <bairui> vila: I did exactly that
[07:24] <bairui> pacman says 2.3.4-1 is the best I've got for now :-/ what's latest stable?
[07:25] <bairui> but on the *bright* side... I *think* I finally get DVCS and bzr's implementation (for small values of 'get')
[07:25] <vila> 2.3.4, but 2.4.0 is *just* around the corner (I'm waiting for a bit more available packages/installers before doing the official announce)
[07:25] <vila> bairui: what OS are you using ?
[07:25] <bairui> arch
[07:25] <bairui> er, well, i guess that's a distro, but it answers your q too :)
[07:26] <vila> pardon my ignorance, what package manager is used there and who package bzr (and when ?)
[07:26] <bairui> i dunno who and when, but the package manager is called   pacman
[07:26] <vila> oohhh
[07:27] <vila> bairui: well, in the meant time, the workaround is to avoid merging to empty branch/trees ;)
[07:27] <vila> mean
[07:27] <jimis> vila: arch is famous for packaging the latest stable really on-time
[07:27] <bairui> heh, thanks, vila :p
[07:28] <jimis> vila: if there is a bug in 2.3, proper solution would be to do a small 2.3.5 fix release
[07:28] <poolie> hi vila, jimis, maxb
[07:28] <vila> jimis: ok, thanks for teaching me ;)
[07:28] <jimis> :-)
[07:28] <vila> jimis: in theory, yes, in practice, 2.4 *is* the new stable series
[07:28] <vila> bah, not therory/practice, sorry, bad english
[07:29] <jimis> I'm sure that 2.4 will be packaged by arch very soon after released then
[07:29] <vila> jimis: right
[07:30] <jimis> vila: Nevertheless if there is a bug on 2.3, remember that many RHEL users will not be able to use that one
[07:30] <vila> jimis, bairui : feedback on when 2.4 is available in arch welcome !
[07:30] <vila> jimis: 2.4 ?
[07:30] <vila> jimis: because we drop support for python2.4 ?
[07:30] <vila> ghaa
[07:30] <jimis> vila: yes
[07:31] <poolie> vila what's a control.conf?
[07:31] <vila> so, the consensus was that getting python-2.5 on redhat/fedora was easy enough
[07:31] <jimis> I went through a lot to be able to run, as we were discussing some other time
[07:31] <jimis> vila: *only* if you have root access
[07:31] <vila> poolie: the most unknown config file used by bzr
[07:31] <jimis> if not, it's pretty hard
[07:32] <jimis> and RHEL users tend to have an admin over their heads :-)
[07:32] <vila> jimis: ghaaa, are you subscribed to the bazaar ml ?
[07:32] <poolie> vila "you're in a balloon!"
[07:32] <vila> poolie: ??? :D
[07:32] <jimis> vila: no, but I read it casually (have also posted once)
[07:32] <vila> poolie: control.conf is mainly used by launchpad to provide default_stacked_on
[07:33] <poolie> google it
[07:33] <vila> jimis: there was a long thread about dropping support for python-2.4
[07:34] <vila> poolie: oh, you mean my first answer was useless ?
[07:34] <poolie> a bit
[07:35] <poolie> i thought that was it but the cover letter might have been more clear with a reminder
[07:35] <vila> yeah, I know, but it took me so long to learn about this file and it's so well hidden, I feel *a bit* relieved that I'm not alone there
[07:55] <poolie> ok
[07:56] <poolie> perhaps a comment or two would be good
[07:56] <vila> in the stack types ?
[07:56] <vila> to explain how they are built ?
[07:56] <vila> the rationale and so on ?
[07:56] <poolie> something like that
[07:56] <poolie> yes, in the stack classes
[07:57] <vila> right, my next submission will probably be to introduce a stack registry and that's where I intended to explain that but I can as well start here
[08:00] <vila> poolie: roughly the idea is that you call the registry with a stack ID and a context, for example:
[08:00] <vila> poolie: stack_registry.get('bazaar') # no context
[08:01] <vila> poolie: stack_registry.get('branch', branch)
[08:01] <poolie> hm
[08:01] <vila> poolie: stack_registry.get('locations', url)
[08:01] <vila> and you get the right stack for the context
[08:02] <vila> branch should chose the appropriate stack depending on 'branch', remote or local
[08:02] <vila> or may be the registry gives bask a factory and *then* you provide the context
[08:03] <vila> back
[08:03] <poolie> so that sounds about right
[08:04] <poolie> i do wonder if having a factory function is a bit redundant with also having classes per stack?
[08:04] <poolie> also i wonder if it's more a matter of giving it a dict of relevant things
[08:05] <poolie> or even a set/list of relevant things
[08:05] <poolie> like stack_registry(a_branch, a_transport, etc)
[08:06] <vila> yes, the factory is redundant, the classes were an intermediate step
[08:06] <vila> ghaa
[08:07] <vila> yes, the classes are redundant, they were an intermediate step and the registry will replace them
[08:07] <Riddell> hi all
[08:07] <vila> Riddell: hey !
[08:09] <vila> Riddell: I'm not sure I was clear yesterday about your babune failure, you encountered a *transient* failure (cause not well understood, workaround: try again)
[08:09] <Riddell> vila: got that thanks, the change got merged in
[08:10] <vila> ok
[08:19] <jimis> Is there a way in launchpad to see a list of bugs I have subscribed to, or marked as affecting me?
[08:20] <vila> jimis: https://bugs.launchpad.net/~
[08:20] <vila> jimis: top right corner gives several links
[08:21] <jimis> perfect, thanks vila
[08:27] <jam> hi all
[08:27] <poolie> jimis: no link for bugs affecting you yet
[08:27] <poolie> hi jam
[08:27] <poolie> bad news on your hpss branch i'm afraid
[08:27] <jam> poolie: what's that?
[08:28] <poolie> it's still doing the initial pull of gcc-linaro after several hours and it's running one step at atime
[08:29] <nigelb> I wanted to try out an easy bzr bug, but not of the "easy" bugs seemed easy
[08:29] <nigelb> I :)
[08:30] <poolie> hi nigelb
[08:30] <nigelb> hey poolie :)
[08:30] <jam> poolie: I don't quite understand what you mean by "one step at a time"
[08:30] <jam> My fix was about initial discovery of revisions.
[08:30] <jam> If it has passed about 2MB transferred, it should have gotten the revs.
[08:30] <poolie> it's doing many, individually small, get_parent_map calls
[08:31] <poolie> with 19MB transferred
[08:32] <poolie> nigelb: https://bugs.launchpad.net/bzr/+bug/328910 should be genuinely easy and useful
[08:32] <poolie> it has a note about where to start but you're super welcome to ask more about it here, or on the bug
[08:33] <jam> poolie: so I just tested my branch as of right now, and things look fine, it got to "Using fetch locgic" in 79s
[08:33] <nigelb> poolie: hehe, thanks :)
[08:33] <poolie> so i did init-repo, then bzr branch lp:gcc-linaro/4.6 into there
[08:33] <jam> poolie: do you have the .bzr.log for me to look at?
[08:33] <jam> poolie: well, I'm doing "lp:gcc-linaro" just trunk, not a stacked branch. That may be the difference
[08:33] <nigelb> heh, there's something magical about doing bzr branch lp:bzr :)
[08:33] <jam> Try that first, see if it helps, and we may need to do more work w/ stacking
[08:35] <jam> but yes, trying /4.6 I see that I'm already at 4MB @ 50s
[08:36] <poolie> jam: in chinstrap:~mbp
[08:37] <jam> poolie: so I see similar behavior from a stacked branch, so I do think there is something we need to look at, but I think that is *in addition to* what I fixed
[08:37] <poolie> ok
[08:37] <jam> can you try lp:gcc-linaro directly?
[08:37] <jam> (I'm at 206s ,and a huge number of round trips)
[08:37] <jam> my guess is that the caching provider isn't triggering at the right layer
[08:38] <poolie> yes, starting it now
[08:38] <jam> so we make a request against StackedRepo find it isn't there, then fallback to StackedOnRepo and find it in the cache
[08:38] <poolie> good example of the value of having someone else test i suppose
[08:38] <jam> and we do that *for every step*
[08:38] <poolie> michaelh just reported a dupe of this today, and his was with /4.6
[08:38] <jam> sure
[08:39] <poolie> woo
[08:39] <poolie> that looks a lot better
[08:39] <poolie> got to 'using fetch logic' in 94s
[08:40] <jam> poolie: right, and compare that with bzr.dev
[08:40] <jam> so I think my fix is still practical and good, we just need to also fix the "stacked repo gets queried before we check in cache" sort of bug.
[08:40] <jam> I could be wrong, but that is what it looks like to me
[08:40] <poolie> i think you're right
[08:41] <poolie> i'm glad i avoided saying "it's fixed" to them prematurely though
[08:41] <jam> poolie: agreed.
[08:42] <jam> poolie: So I think I remember spiv poking in this area. Where he realized we were double caching, and moved to expose the cache to the higher levels.
[08:42] <jam> It is pretty vague, though.
[08:43] <jam> poolie: but yeah, I'm seeing 500s 10MB transferred, and still discovering for a stacked branch.
[08:46] <poolie> i'll comment on the bug
[08:47] <vila> poolie: I now get mails for list moderation but I'm not able to connect, I suspect it's because you used vila@c.c instead of vila_bzr@c.c, can you try to change that ?
[08:48] <vila> grr vila+bzr@c.c
[08:49] <vila> It's a bit strange that the login ask only for a password and not for an email, but it probably tries all passwords for all admins...
[08:52] <poolie> jam as a workaround we could unstack their 4.6 branch
[08:53] <jam> poolie: because they are branching from it a lot?
[08:54] <jam> poolie: certainly that will give them an immediate boost if it is something they are active on.
[08:54] <jam> (should it be the dev focus if it is the active branch?)
[08:55] <poolie> yes
[08:55] <poolie> i don't know about that
[08:58] <jam> poolie: so the *big* win is that unstacking it will mean they get immediate benefit regardless of what bzr client they are using
[09:00] <jam> poolie: so I would recommend for that because it helps them *today*, though I still want to fix this
[09:01] <vila> jam: but won't they run into issues when *pushing* if 4.6 is unstacked ?
[09:01] <vila> or is that the opposite ?
[09:02] <jam> vila: The main issue is that it will have all the history there, but if we do that part then it doesn't matter for them
[09:02] <jam> so *if* they bring in a lot of new data from trunk into 4.6
[09:02] <jam> that will get copied when they push to 4.6
[09:05] <vila> 'that part' == unstacking ?
[09:06] <jam> vila: yes
[09:06] <vila> k
[09:06] <jam> it will have to transfer, say 500MB, of history
[09:06] <jam> (not sure on the exact amount)
[09:06] <jam> but if we get someone close to the datacenter to do it, it should be pretty fast.
[09:07] <vila> and how about keeping it stacked but still add the missing revisions ?
[09:08] <poolie> vila i doubt they will be regularly merging such large amounts from trunk to 4.6 to outweigh the existing history
[09:08] <poolie> jam, ok, it completed in 27m
[09:10] <jam> poolie: well, you could stack it and leave the history, it would be a bit odd. And I think I'd just unstack it
[09:23] <nigelb> poolie: hm, unsure how to get the right info to raise ShortReadvError.
[09:23] <nigelb> Actually, unsure how to get the parameters for it.
[09:23] <poolie> biab
[09:24] <vila> nigelb: identify one file that is read, remove its content (or part of it, may the first few bytes needs to be there so the file can be identified properly)
[09:25] <vila> nigelb: a pack or a an index file will do
[09:26] <nigelb> heh, didn't understand that. let me grep where its used and try to decipher what you wwant
[09:27] <vila> ShortReadvError occurs when a file is truncated (it should never happen under normal circumstances)
[09:28] <nigelb> ah, so when the ftp does get disconnected, that's what would happen.
[09:28] <nigelb> *stfp
[09:53] <vila> nigelb: sry, didn't notice your reply
[09:54] <vila> nigelb: hmm, so, if you're working on ssh disconnections, that's a bit different
[09:55] <vila> nigelb: truncating the file may not be the right way to trigger the problem
[09:56] <vila> nigelb: reading bug report
[09:57] <vila> right, so what you really want is a test server that will drop the connection, catch that on the client side and (as spiv suggested) turn it into a ShortReadvError (I don't fully understand why spiv suggested that though)
[09:59] <vila> ShortReadvError are really serious, when we encounter them it has always been linked to hardware issues (or bad crashes), raising them for network issues seem a but weird
[10:06] <spiv> vila: we're talking about FTP?
[10:07] <spiv> vila: FTP doesn't have any standard way to tell you how many bytes to expect on your data channel
[10:07] <spiv> vila: and it's a separate connection to the control channel
[10:07] <vila> spiv: sftp, see bug above
[10:08] <vila> https://bugs.launchpad.net/bzr/+bug/328910
[10:09] <spiv> vila: in that case probably a ConnectionError of some sort is probably a better match
[10:09] <vila> spiv: why did you suggest to turn a network error into a ShortReadvError ?
[10:09] <vila> ha right
[10:09] <vila> k
[10:09] <vila> I agree
[10:09] <vila> nigelb: ^
[10:56] <jimis> Can I write a message for some changes I just shelved, but forgot -m?
[11:00] <vila> jimis: unshelve/reshelve :-/
[11:00] <vila> jimis: not ideal
[11:00] <fullermd> vi .bzr/....    ;)
[11:02] <fullermd> bairui: Hey, I snuck off to sleep while you were eating.  Hope you got on the right track.
[11:03] <vila> fullermd: you... what ?
[11:03] <fullermd> It's not my fault!  I'm sick!
[11:03] <fullermd> I mean, physically, this time.
[11:04] <vila> ha, ok
[11:19] <jml> mgz: hi. how's things?
[11:45] <Riddell> how comes there's no  bzr qremove command ?
[11:47] <jelmer> Riddell: what would it use qt for?
[11:47] <Riddell> well same as bzr qadd I would think
[11:48] <jelmer> I wasn't aware there was a qadd either :)
[11:48]  * jelmer gives it a try
[12:10] <bairui> fullermd: heh... yes, I did, thanks mate. I read dozens of bzr articles and wiki entries and whatnot... I grok it! Thanks for your pointers this morning - good start to digging further. :)
[12:11] <bairui> I'm doing up a dev & mig workflow doc & diag now
[12:19] <fullermd> bairui: Oh good.
[12:20] <fullermd> If you haven't come across them, some of the SpotDocs I wrote up a little while back may be useful.
[12:20] <fullermd> http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs
[12:20] <bairui> sweet :)
[12:20] <fullermd> Particularly the PiecesInBrief section.
[12:21] <fullermd> They're all totally useless as tutorials or introductions.  They're made to more fully explain the conceptual models of what happens, once you get used to basically using the system.
[12:21] <bairui> nice. i've added them to my read queue. cheers. :)
[12:25] <fullermd> (they're pretty rough; haven't had time to do much editing etc  :( )
[12:25] <bairui> that's cool... I know where you live if I need to clear anything up ;)
[12:28] <poolie> jam, so, anything else you need?
[12:28] <poolie> otherwise i might poke at some more jubany failures and then stop
[12:33] <jam> poolie: I think I'm good for now, probably time for you to take a break :)
[15:00] <jam> vila: ping
[15:00] <jam> jelmer_: do you still think you're going to be releasing bzr-svn ?
[15:01] <vila> jam: pong
[15:01] <jelmer_> jam: Yep, working on that at the moment. It's way overdue :-/
[15:01] <jam> jelmer_: k, I won't spin up ec2 yet.
[15:01] <jam> vila: Thoughts about get_parent_map and caching
[15:01] <jam> have some time to chat?
[15:01] <vila> always for you :)
[15:02] <jam> vila: mumble/voip/skype? I'm thinking it will be faster than trying to type it all
[15:45] <briandealwis> jelmer_: does bzr-git support accessing a repo over http?  I'm having problems branching from Eclipse's git repositories: trying 'bzr branch http://git.eclipse.org/c/platform/eclipse.platform.ui.git' results in HTML being spat out, and they don't seem to be running a git smart server
[15:48] <jelmer_> briandealwis, I can't clone that URL with git either, it just hangs
[15:48] <briandealwis> oh!  It works for me… or at least it was
[15:49] <briandealwis> just checked again: it's working from here
[15:53] <briandealwis> jelmer_: is there a way to force bzr to look at the URL for bzr-git?  There's no git+http scheme
[15:53] <briandealwis> (I vaguely recall there being some "+xxx" addition to do something different)
[15:54] <jelmer_> briandealwis: the problem is that that site doesn't return 404 for files that are not found :-/
[15:54] <briandealwis> oh!  that's not useful
[15:56] <jelmer_> briandealwis, bzr-git doesn't support smart server access over http to git repositories
[15:57] <briandealwis> jelmer_: and it doesn't support dumb access either? :)
[15:57] <jelmer_> briandealwis, it does support dumb access, but I'm not sure if that's enabled on the server
[15:58] <briandealwis> jelmer_: they're supposed to be running a smart server (their examples show using the 'git:' protocol too), so I'll bug them about that.
[15:58] <jelmer_> briandealwis, the main problem is the missing 404 though
[15:59] <briandealwis> I'll file a bug with them about that.  There's no +xxx I can append to force bzr-git to continue on?
[16:00] <jelmer_> briandealwis: no
[16:00] <briandealwis> ok. Thanks for the help, jelmer_
[16:31] <briandealwis> jelmer_: sorry to bug you again: would you happen to know what file is being probed for — the file that's returning 200?  (In case I'm asked)
[16:32] <jelmer_> briandealwis, *any* file that doesn't exist
[16:32] <jelmer_> briandealwis, e.g. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.git/foo
[16:33] <briandealwis> jelmer_: I understand that — they likely have done that to make things 'easier' for people.  They may be loathe to disable that.  But they might be willing for a particular file name…
[16:35] <jelmer_> briandealwis: I'm not sure if it's actually worth reporting this just yet
[16:35] <jelmer_> briandealwis: it'll be slow as hell until there is support for the smart server over http in dulwich/bzr-git
[16:35] <jelmer_> briandealwis, any reaosn you're not cloning over git:// ?
[16:36] <briandealwis> It's not working.  I've reported that to them too :)
[16:36] <jelmer_> briandealwis, seems to be working fine here
[16:37] <briandealwis> huh, weird.  I get an error.  I'll check that I'm running the latest dulwich and bzr-git
[18:41] <briandealwis> jelmer_: You mentioned that you were able to clone over git:// from the Eclipse server?  I'm now up to dulwich 0.8.0 and tip of bzr-git on bzr 2.4b4, but I'm unable to branch from http://git.eclipse.org/c/platform/eclipse.platform.ui.git/.  I get an 'bzr: ERROR: The remote server unexpectedly closed the connection.'  -Dtransport doesn't reveal anything in the log
[18:42] <jelmer_> briandealwis, does git:// work for you with git itself?
[18:52] <briandealwis> jelmer_: I can pull from github. Though I get a NotImplementedError exception when I try 'missing'
[19:00] <briandealwis> jelmer_: sorry — I misread.  No, git doesn't work with the URL either.  Weird.  But it works for you?  Maybe I should move to Europe.
[19:00] <jelmer_> briandealwis: "bzr missing" should "work" now (just pushed a fix to lp:bzr-git)
[19:01] <briandealwis> great!
[19:02] <briandealwis> ah right, now it doesn't error :)
[19:28] <briandealwis> jelmer_: the Eclipse sysadmins note that the 200 behaviour is part of cgit, the web front-end to git that they're using, and it isn't configurable.  They do run the git smart-server over http.  And I realize I had the wrong URL for the git:// smart server — not sure where I got it from.
[19:33] <jelmer_> briandealwis: ah, cool
[19:34] <jelmer_> briandealwis: so, bzr-git only supports "dumb" http access, but even if that works it'll be pretty slow for projects the size of eclipse
[19:35] <briandealwis> jelmer_: they do have working smart servers — it still feels slow as molasses, so I shudder to think of what it would be like to use the dumb access.
[19:35] <briandealwis> jelmer_: and thanks for your work with the ",branch=" work. Is this supported in bzr-git?  Out of curiosity, is there some more work required for that still?
[19:42] <jelmer_> briandealwis: yeah, should work with current tip of bzr-git and bzr
[19:43] <briandealwis> cool!  I'll give it a shot.
[20:44] <briandealwis> Is there some way to disable or prevent a particular plugin from being loaded from the CLI?
[20:46] <cody-somerville> Is there any way to make bzr update atomic?
[20:58] <briandealwis> Not sure how I missed it, but BZR_DISABLE_PLUGINS is what I was looking for
[21:04] <jelmer_> cody-somerville: what do you mean by atomic exactly?
[21:04] <cody-somerville> jelmer_, ie. if the operation fails (ie. conflicts, etc.) that nothing changes
[21:23] <jelmer_> cody-somerville: it is atomic, there just isn't any support for rollback if the transaction contains conflicts :)
[21:24] <jelmer_> cody-somerville: I agree it makes sense to have an option which can abort and not touch the tree if there are conflicts
[21:25] <cody-somerville> yea, I'm basically looking for it to be an atomic transaction
[21:55] <thumper> hi people
[21:55] <thumper> I have a weird merge problem
[21:55] <thumper> I've done a bunch of work in a branch
[21:55] <thumper> which ends up being branched from the packaging branch (with distro patches et al)
[21:55] <thumper> instead of the upstream mirror
[21:55] <thumper> now I want to make another branch
[21:56] <thumper> and merge in particular changes to particular files
[21:56] <thumper> is there a way to say "merge the changes to this file from that branch"
[21:56] <thumper> but not get the revisions?
[21:58] <jelmer_> thumper!
[21:59] <jelmer_> thumper: Do you perhaps just mean "bzr merge" followed by "bzr revert --forget-merges" and reverts of the other changes you don't want?
[21:59] <thumper> hi jelmer_
[21:59] <thumper> ah...
[21:59] <thumper> that should work
[21:59] <thumper> although I'm going to have to revert a bucket load of changes I don't care about
[22:00] <thumper> I did "bzr revert .", but it did the opposite of what I wanted and I couldn't remember the syntax
[22:00] <thumper> can I just merge changes from a particular file?
[22:00] <jelmer_> thumper: you can, just specify that specific file
[22:00] <thumper> kk
[22:00]  * thumper tries
[22:01] <thumper> nope
[22:01] <thumper> can't specify a file in merge
[22:02] <jelmer_> thumper: "bzr merge ../path/to/branch/file.txt" works here
[22:02] <thumper> ah... I was doing two parts
[22:03] <thumper> jelmer_: it also appears that just merging a file doesn't have pending revisions to merge
[22:03] <jelmer_> thumper: yep
[22:03] <jelmer_> we don't properly track cherrypick merges of individual files or individual revisions yet
[22:03] <thumper> yep
[22:03] <thumper> that works for me
[22:03] <thumper> ta
[22:53] <maxb> jelmer_: Do you have any plans to release subvertpy 0.8.4 soon?
[22:55] <maxb> I had been intending to not obsolete karmic from the ~bzr PPA until after bzr 2.4.0 happened, but there's no bzr-svn/karmic compatible with bzr 2.4, and there won't be unless subvertpy 0.8.4 happens, or I backport that. Which I was hoping to avoid :-)
[22:57] <jelmer_> maxb, sure, I guess I could do a release
[23:04] <maxb> If it's not too much effort, great
[23:05] <maxb> Otherwise, we can just obsolete karmic now, before bzr 2.4 hits ~bzr/ppa
[23:06] <maxb> Which, come to think of it, might be the sensible thing to do anyway
[23:07] <maxb> it is over 3 months EOLed
[23:24] <idnar> does bzr have anything like mercurial queues?
[23:25] <idnar> I guess loom is the thing I need to look at?
[23:25] <lifeless> pipelines are closer to queues
[23:25] <lifeless> loom versions the stack of patches as a unit, which is useful for distro / collaboration-around-the-queue
[23:26] <idnar> ah
[23:27] <idnar> I'm not yet sure which approach I want here
[23:29] <idnar> (some background: I'm trying to find out what changes I need to make this code run on pypy, so I'm just hacking stuff willy-nilly to get it working; later I want to clean things up and eventually break changes out as separate branches to hopefully be merged into upstream)
[23:31] <idnar> I think pipelines may be the easiest way
[23:35] <idnar> I guess I can't sync-pipeline to Launchpad
[23:37] <lifeless> idnar: pipelines fit that use case
[23:37] <lifeless> idnar: sure you can
[23:38] <idnar> bzr: ERROR: Permission denied: "~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy/": : Cannot create branch at '/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy'
[23:39] <idnar> er, the line before that was: Creating new pipe at bzr+ssh://bazaar.launchpad.net/~divmod-dev/divmod.org/divmod-on-pypy/.bzr/branches/divmod-on-pypy
[23:39] <lifeless> hmm, where is abentley when you need him :)
[23:39] <lifeless> idnar: oh
[23:39] <lifeless> idnar: so, what you do is have the pipeline local
[23:39] <lifeless> and publish all the pipes to lp as separate branches
[23:39] <lifeless> this is a bit different to loom
[23:39] <idnar> yeah
[23:39] <lifeless> pipelines is a less intrusive plugin :)
[23:40] <lifeless> poolie has a plan to merge various bits of guts and make them separate policy layers on a common substrate.
[23:40] <lifeless> I'm not sure that the substrate is enough for loom without being in the way of pipeline, but I guess we'll see ;)
[23:44] <idnar> I should have looked at pipelines again before now; I read about them a while back, then forgot about them
[23:44] <idnar> I did a think the other week that would have been much easier
[23:44] <idnar> *a thing
[23:49] <poolie> hi all
[23:51]  * idnar waves to poolie
[23:51] <poolie> hi idnar
[23:51] <poolie> some parts of that unification are now landing
[23:51] <poolie> for example 'bzr branches' will tell you about colo branches
[23:52] <poolie> it's not connected to pipelines or looms yet though