[00:00] <michaelh1> Hi there.  I'm using feature branches for development.  How can I find the revno of mainline that I branched from? (Google doesn't help)
[00:01] <michaelh1> bzr missing ../mainline, taking the lowest revno of the feature branch changes, then subtracing one would work but it's ugly...
[00:02] <lifeless> theres a find-merge-ancestor or some such, or log -r ancestor:../trunk
[00:03] <poolie> find-merge-base i think
[00:03] <lifeless> note that where you branched is not supported at all, only where you have merged up to (which is subtly different :))
[00:04] <poolie> well, where you branched from, or where you last pulled up to, is possible to compute
[00:04] <poolie> but i don't think there's any ui to get it
[00:05] <michaelh1> OK.  That gives me a revid, and I can use bzr log to turn that into a revno
[00:07] <lifeless> michaelh1: try bzr revision-info -r ancestor:path/to/trunk
[00:08] <michaelh1> lifeless: ta, that does it.  revision-info isn't in man bzr or bzr help commands...
[00:10] <poolie> https://bugs.launchpad.net/bugs/748141 asks for it to be shown
[00:10] <poolie> filed just yesterday ironically enough
[01:04] <spiv> Good morning
[01:10] <poolie> hi there spiv!
[01:16] <poolie> spiv, i'm just looking at some of the branch privacy setup issues on lp
[01:16] <poolie> then, i'm going to push a bit on our srus, do a few reporting chores, and then push on my in-progress branches
[01:16] <poolie> also, bug 740932 is perfect john-bait :)
[01:18] <spiv> I thought he was already working on that, actually :)
[01:18] <spiv> Ah, yep.
[01:20] <poolie> exactly
[05:02] <lifeless> http://yaxu.org/cyclic-revision-control/
[05:29] <poolie> interesting
[07:49] <poolie> i think maxb is on the right track with a wiki page showing how the ppas are getting along
[07:49] <poolie> maybe i will make a similar thing for srus
[07:52] <vila> hi all !
[07:52] <poolie> hi there vila
[07:52] <poolie> how are you
[07:53] <vila> fine, good progress on configs
[07:53] <poolie> vila, good
[07:53] <vila> I don't quite get your comment on bug #725234
[07:53] <maxb> You mean DailyPpaStatus?
[07:53] <vila> poolie: what could be simpler than [~/work]\nfoo=bar\n in bazaar.conf ?
[07:53] <maxb> That was useful - on the other hand, ProposedPpaStatus ceased to be particularly useful after I had the first big push to bring it up to date
[07:54] <maxb> Speaking of PPAs, I need to write a status email about the twisty chaos of dh_python2/pycentral/pysupport
[07:54] <vila> maxb: +1
[07:54] <poolie> yes
[07:55] <maxb> But yes, in general: If you don't have time to code a status tracking webapp: Use a wiki! :-)
[07:55] <vila> maxb: and its impact on the beta ppa ?
[07:55] <poolie> vila, my point is that i'm not sure if at the ui level users should be thinking about sections
[07:55] <poolie> maxb so it's kinda tracked in bugs
[07:55] <poolie> certainly more so than the ppa failures
[07:56] <poolie> but, perhaps not really clearly enough
[07:56] <poolie> vila  if you can find the time helping spiv with reviews could be good
[07:56] <poolie> the page is really long
[07:56] <vila> poolie: what's wrong with that ? It looks like a common practice to me, especially if sections allow grouping so you DRY
[07:57] <maxb> I don't think the beta ppa is blocked on anything - just lower on my priority list than bringing the dh_python2 backport magic up to speed and in its final form
[07:57] <poolie> let me back up
[07:57] <vila> maxb: ok
[07:57] <poolie> in the case of my example where they want to set some policy for a particular directory (and children)
[07:57] <poolie> what do you think the user would say?
[07:58] <vila> bzr config foo=bar --scope bazaar --section ~/work
[08:00] <poolie> how does that work?
[08:00] <poolie> can bazaar.conf have per-directory sections?
[08:00] <spiv> FWIW, my initial reaction is that “--section ~/work” feels a bit weird.  There's nothing obviously “this for a location” in that command to my eyes, except by inferring it from the ~/work bit which looks like it's probably a directory name.
[08:00] <spiv> (reaction to that hypothetical command line)
[08:00] <vila> that's the plan, yes, to replace their abusive use in locations.conf which should define overriding options while bazaar define defaults
[08:01] <vila> section names can't be inferred, they need to be specified
[08:01] <vila> (when they are paths/globs)
[08:02] <vila> supporting them fill the gap that requires hand editing today
[08:02] <spiv> I don't understand why there's a beneficial difference between "define per-location setting in a section in bazaar.conf" and "define per-location setting in a section in locations.conf"?
[08:02] <poolie> hm
[08:02] <poolie> me either
[08:02] <spiv> Unless the goal is to remove locations.conf entirely.
[08:02] <poolie> also, i think the ui should be something like
[08:02] <poolie> bzr config --location ~/work foo=bar
[08:03] <poolie> which can internally may to "section ~/work in file locations.conf"
[08:03] <vila> locations.conf is (and has always been) defined for *overriding* settings in branch.conf
[08:03] <vila> that's not the way people expect it to be but that's the way it is implemented
[08:03] <spiv> vila: oh *branch.conf*
[08:03] <spiv> You said bazaar
[08:04] <vila> I said bazaar because I thought poolie wanted defaults
[08:04] <vila> poolie: not all section names will be locations
[08:04] <spiv> Hmm.
[08:05] <vila> poolie: if we had an easier way to parse options dynamically, they could depend on --scope, but that seems quite complicated
[08:05] <spiv> I kinda like that only locations.conf is defined as having section name == location glob
[08:05] <vila> why ?
[08:06] <spiv> I wouldn't want DEFAULT in bazaar.conf to suddenly match a directory I have that happens to have that name
[08:06] <vila> I want to get rid of DEFAULT
[08:06] <vila> exactly because it can conflict
[08:06] <spiv> Well, or any other section type :)
[08:06] <vila> same same :)
[08:06] <spiv> And ALIASES?
[08:06] <vila> yup
[08:07] <vila> bzr.aliases.mylog
[08:07] <spiv> Hmm
[08:07] <vila> I think it's described explicitely in http://doc.bazaar.canonical.com/devnotes/configuration.html
[08:07] <vila> tly
[08:07] <spiv> That's uglier to look at than what we have now :/
[08:08] <vila> can you elaborate ?
[08:08] <spiv> Sorry, I haven't made time to read and digest that doc yet :/
[08:08] <spiv> Well,
[08:08] <spiv> [ALIASES]
[08:08] <spiv> commit = commit --strict
[08:08] <spiv> Is really clear and obvious I think
[08:08] <vila> we *don't* have a way to specify defaults values per location *and* define exceptions in branch.conf today
[08:08] <spiv> And bzr.aliases.mylog is not quite as much.
[08:08] <spiv> Sure, I'm not disagreeing with that :)
[08:09] <spiv> It seems to me there's a namespace problem with section names
[08:09] <vila> *because* sections have been used in bazaar.conf
[08:09] <spiv> Right
[08:09] <vila> indeed
[08:09] <vila> spiv: have a look a bzr-bookmarks
[08:09] <spiv> So why not disambiguate by having location-matched sections be called [location:/path/...] ?
[08:09] <poolie> i think we need to be clear about what sections are for
[08:10] <poolie> are they basically part of the namespace of the option
[08:10] <spiv> Or even [location /path/...]
[08:10] <vila> spiv: it uses *both* a section [BOOKMARKS] in bazaar.conf *and* prefixed options in branch.conf
[08:10] <poolie> iow it's really ALIASES/commit
[08:10] <poolie> or are they something used to select which values are active
[08:10] <poolie> at the moment it's a bit of both
[08:10] <vila> poolie: the later
[08:10] <vila> exactly
[08:11] <vila> using a hierarchical name space for options is powerful enough to free the section namespace
[08:11] <vila> so the section namespace can be used for other things
[08:12] <vila> for bazaar.conf, locations.conf, branch.conf and even tree.conf, repo.conf, rules and so on path/glob sounds good enough
[08:12] <vila> but plugins may decide differently which is why I'm trying to not *force* path/globs for section names
[08:13] <spiv> But you have?
[08:13] <vila> not yet
[08:13] <vila> err, not so far ?
[08:13] <vila> and hopefully never
[08:13] <spiv> In your scheme, how can a plugin define e.g. [explorer] as a section and avoid having it match that path?
[08:13] <spiv> Sorry if I'm making you repeat your doc!
[08:14] <vila> because sections are selected when building the stack and this selection can be file-specific
[08:14] <spiv> In general though I think it'll be hard to understand for users if sections are mostly one thing but occasionally another.
[08:14] <spiv> e.g. see how I'm confused right now ;)
[08:15] <vila> it's used only by locations.conf today and implemented in LocationConfig, so I just have to *not* reuse that code or reuse it in the right place
[08:15] <vila> not if documented by file
[08:15] <spiv> Oh, you're saying that in a plugin-specific conf file section names can have a different meaning?
[08:15] <vila> yes
[08:15] <spiv> Ok, but then it's the same as today?
[08:15] <vila> qbzr can use window names for example
[08:15] <spiv> locations.conf uses them as locations, nowhere else does.
[08:16] <vila> I'd rather use the name space too for that but for the sake of the example
[08:16] <spiv> Is the main issue you want to solve that we can currently only define per-location overrides, and can't define per-location defaults?
[08:17] <vila> spiv: yes, nobody does *today*, but still, people use path as sections to define defaults in locations.conf (which breaks if you define exceptions in branch.conf), so given them section as paths in bazaar.conf address the need
[08:17] <vila> that's one issue yes, dunno if it's the main one
[08:17] <spiv> Well, I can think of less radical changes that would solve that issue :)
[08:18] <vila> the main one is to be able to define option values that apply to various contexts without duplication
[08:18] <vila> spiv: yes ?
[08:19] <spiv> Add a location-defaults.conf (and maybe rename locations.conf to location-overrides.conf), for instance.
[08:20] <spiv> Or allow bazaar.conf to contain e.g. [location-match /path…] section names.
[08:21] <vila> ah, yes, that's not ruled out, but you still need to support section that are not *only* path/glob
[08:21] <spiv> Not saying these are better, but they would appear to require less change, at least in how users write out and read options.
[08:21] <vila> err, you still need to move parts of locations.conf to another file  right ? Why is that less changes ?
[08:22] <spiv> Well, I don't need to rewrite my ALIASES section
[08:22] <vila> spiv: and have you tried adding a conf file to BranchConfig ? And have it supported by RemoteBranchConfig ?
[08:22] <vila> haaa, I didn't say [ALIASES} will disappear at once
[08:23] <vila> It can still be supported and deprecated in the future to address the collision issue
[08:23] <spiv> Or otherwise rewrite any options, unless I want to change any existing per-location stuff I have from being an override
[08:23] <spiv> (And off the top of my head, I think I want most of my per-location conf to be overrides)
[08:23] <spiv> In my alternative, ALIASES wouldn't ever need to be removed
[08:24] <spiv> Also, it's a bit interesting that your way could perhaps allow per-location aliases
[08:24] <spiv> I'm not sure if that's a good or bad thing
[08:24] <spiv> I definitely don't want branches to even look like they can define them though!
[08:24] <vila> the starting point was to use --location instead of --section, if you want to keep ALIASES, you want --section
[08:27] <vila> spiv: you can't decide that for *all* options, but you can defined that for *some* options
[08:29] <vila> s/defined/define/
[08:31] <vila> anyway, the implementation under work is about *allowing* more control, the current design just doesn't scale for the already existing (and unanswered) needs
[08:31] <vila> it gives ways to clear the section name space so it can be better defined and extended,
[08:32] <vila> I won't implement more than paths/globs to start with because it's not needed *yet*
[08:32] <vila> I won't implement selecting which config files allow which options either for the same reasons
[08:33] <poolie> vila, i really don't want to get one big "take it or leave it" patch
[08:33] <vila> poolie: which is why I'm creating different threads so they can be reviewed and discussed independently
[08:34] <poolie> but you know that :)
[08:34] <vila> the aim is that the first implementation should be 100% compatible with the existing config files
[08:35] <vila> *then* and only then, can we start discussing migration plans for new features (including removing [ALIASES] and [BOOKMARKS], allowing sections in bazaar.conf, etc)
[08:35] <spiv> I think you'll get a negative reaction from users if you make simple things like alias definitions less pretty than "foo = command --args"
[08:35] <spiv> ICBW :)
[08:36] <vila> bzr alias can very well stay and be re-implemented on top of the new design to start with
[08:36] <vila> see 100% compatible above
[08:36] <spiv> It's great to have nice command line UI inspecting and updating various config settings
[08:37] <vila> implementing -Ofoo=bar is just... beyond me with the actual design
[08:38] <vila> with the new one, it will just be adding a new read-only section in stacks that want to support it
[08:40] <poolie> i might have a stab at that
[08:40] <poolie> then either we will get the feature, or i will stop telling you it's easy :)
[08:41] <vila> :)
[08:42] <vila> poolie: don't forget bzr.config.expand :-p
[08:44] <poolie> what about it?
[08:44] <poolie> maxb, jelmer, i started http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates
[08:45] <poolie> is pretty ugly
[08:45] <poolie> i feel it ought to have red and green bits but i'll get to that later
[08:45] <vila> poolie: expansion should be able to cross configs, especially for -O or it won't be taken into account
[08:47] <poolie> hm
[08:50] <poolie> i don't feel that is as important as the other config bugs
[08:52] <maxb> poolie: It looks good, and it calls to my attention an issue - what are our plans re lucid - which is, after all, an LTS
[08:52] <vila> poolie: for the sake of the experiment, have a look at it to avoid having to fix it twice, pretty please
[08:52] <vila> poolie: +1 on maxb
[08:53] <vila> poolie: I'm all for handling 2.2 *first* but 2.1 should be seen as dead yet
[08:55] <poolie> vila my plate's pretty full so these are idle threats :) but i will
[08:55] <maxb> In fact, in the greater scheme of things, 2.1 is more important - not that it necessarily needs to get done first, but it's more important that it actually gets done
[08:55] <poolie> we should do it too
[08:56] <poolie> i mean we should do 2.1 too
[08:56] <vila> poolie: not a threat, more like getting an apple-to-apple comparison ;)
[08:57] <vila> poolie: expand_options is currently implemented for Config and that's a blocker for expansing across config files (without going into quite complicated implementations)
[08:58] <vila> poolie: it really should be implemented on stacks
[09:00] <poolie> no, i mean "i'll do it" is an empty threat
[09:00] <poolie> :)
[09:00] <poolie> anyhow, i'm probably getting to the point of just holding you back
[09:00] <poolie> hm making this page is quite good
[09:00] <poolie> might be better as a little api client app
[09:00] <poolie> later
[09:01] <vila> poolie: ha, that, yeah, hehe
[09:04] <poolie> ah, maxb, what's happened
[09:05] <vila> hmm, expanding not expansing ;)
[09:06] <vila> let's not start about performance issues ;D
[09:06] <poolie> ok, fixed
[09:13] <poolie> hm, what's the most interesting bug fix in https://launchpad.net/bzr/+milestone/2.3.2
[09:13] <poolie> 616878 will do
[09:15] <jam> poolie: 733350 is probably the biggest regression sort of bug
[09:17] <poolie> yeah, the other one might hurt more people
[09:17] <poolie> it's a bit arbitrary
[09:18] <poolie> ok
[09:18] <poolie> i'm a bit scared of uploading to -proposed, and i need to go out soon, so i'm not going to do it tonight
[09:19] <poolie> but i will tomorrow
[09:35] <poolie> good night all
[10:49] <lool> Hey
[10:49] <lool> I'm looking for a way to override specific bzr settings via the environment
[10:49] <lool> To be precise, I'd like to override the email address used in commits
[10:52] <elmo> lool: BZR_EMAIL ?
[10:53] <lool> elmo: Oh gosh, thanks!
[10:53] <lool> elmo: EMAIL doesn't override the config, but BZR_EMAIL does
[10:53] <lool> elmo: Thanks  :-)
[11:08] <jam> lool: you might also want "bzr whoami --branch" if you want to configure it for specific areas.
[11:11] <spiv> Is it just me, or does bzrlib.log._apply_log_request_defaults unintentionally mutate the _DEFAULT_REQUEST_PARAMS var?
[11:14] <vila> spiv: you're probably right that it was unintentional (you're definitely right that it mutates it ;)
[12:42] <jelmer> jam: Thanks for the reviews :)
[12:50] <jam> jelmer: happy to keep the queue flowing. Thanks for all the work :)
[12:51] <jam> jelmer: for some reason pqm seems a bit slower to me. Have you noticed a difference?
[12:53] <jelmer> jam: I haven't noticed anything, but I usually just send things off and then look at the email later so I probably wouldn't notice if it got slower either.
[12:59] <jelmer> jam: is cython preferable over pyrex? We seem to prefer pyrex at the moment.
[13:03] <jam> jelmer: we are stuck with a pyrex dependency (we support pyrex 0.9.6 or whatever)
[13:03] <jam> however, Cython is a lot nicer if you have a choice
[13:03] <jam> meliae is cython only
[13:04] <jelmer> jam: shouldn't we prefer cython in setup.py in that case?
[13:04] <jam> jelmer: hysterical raisons
[13:04] <jam> I would be fine changing that
[13:05] <jam> the main issue is the *code* that you get to write
[13:05] <jam> not so much the final performanec
[13:05] <jam> performance
[13:05] <jam> you get to write "cdef list foo; foo.append()" rather than "PyList_Append(foo, ...)"
[13:05] <jelmer> isn't cython supposed to be better performing?
[13:05] <jam> jelmer: there are a few things internally that are a little better. I don't have a great feeling about real-world perf
[13:05] <jelmer> ah, it's just that certain pythonish code gets more efficiently processed by cython?
[13:05] <jam> they do stuff like "likely()" macros, etc.
[13:06] <jam> jelmer: right
[13:06] <jam> that is the *big win*
[13:06] <jam> however, if we have to do the work under Pyrex, then it doesn't matter whether we use Cython or Pyrex
[13:06] <jam> we could use "cdef list foo" in Pyrex, if we bumped the minimum version to 0.9.8
[13:06] <jam> or something like that
[13:07] <jam> jelmer: did you see my reviewe for "lazyimport-scope-etc" ?
[13:07] <jam> I just got a submit failure
[13:09] <jelmer> jam: Yep, thanks
[13:09] <jelmer> jam: A submit failure on lazyimport-scope-etc, or the 2.3->bzr.dev merge?
[13:09] <jam> lazyimport-scope-etc, I just copy and pasted it into the form
[13:28] <jelmer> jam: ah, thanks
[13:28] <jelmer> jam: do we have any way to remove the generated .c and .py files from e.g. the makefile?
[13:29] <jelmer> I can't find one (other than bzr clean-tree, which isn't usable here)
[13:30] <jam> jelmer: I don't know of any generated .py files
[13:31] <jam> I usually do "rm bzrlib/*.[ch]; bzr revert"
[13:31] <jam> wow, bzr-vimdiff was still in *knit* format
[13:32] <jelmer> jam: ah, there aren't any, I'm being stupid...
[13:32] <jam> jelmer: there certainly are generated .c and .h files
[13:32] <jam> which would be nice to have a simple clean target for
[13:32] <jam> but I don't know of any
[13:35] <fullermd> https://bugs.launchpad.net/bzr/+bug/130783
[13:50] <jelmer> fullermd: the problem is that make clean shouldn't remove those files, they're included with the tarball
[13:55] <jam> jelmer: make dist is used to generate the tarball
[13:55] <jam> which uses 'make clean && make && copy .c/.h files'
[13:55] <jam> so make clean could delete them
[13:55] <jam> unless it is a debian-thing
[13:56] <jelmer> jam: that means that a user who has the tarball unpacked and runs "make clean" ends up deleting his copies of those files
[13:56] <jam> fairy-nuff
[13:56] <jelmer> s/his/their/
[13:57] <jam> http://en.wikipedia.org/wiki/Singular_they
[13:57] <jam> (I personaly like singular they)
[13:58] <jam> jelmer: so it should be under dist-clean?
[13:58] <maxb> It is of particular annoyance that there does not seem to be any consistent file name pattern for what is autogenerated and what is not
[13:58] <jam> maxb: it is pretty straightforward, .pyx => .c, .h, _api.h
[13:59] <jam> well, you only get _api.h under certain circumstances
[13:59] <jam> and we're *pretty* good about naming it all _pyx.pyx
[13:59] <jam> so that you get foo_pyx.c , etc
[13:59] <maxb> jam: Not so - there are files matching *_api.h and *_pyx.h which are source-controlled
[14:01] <jam> maxb: sure, I was thinking about it in the reverse direction.
[14:01] <maxb> It looks like *_pyx.c are all autogenerated, as are *_pyx_api.h
[14:02] <maxb> However _simple_set_pyx.h is autogenerated, whereas _bencode_pyx.h (for example) is not
[14:02] <jam> maxb: I think changing the _*_pyx.h to only have auto-generated files would be reasonable
[14:02] <jam> I think we have 2 (maybe 3) of them
[14:03] <jam> which is our way of adding extra DEFINE sort of things to the pyrex code
[14:03] <jam> but we could do a new notation for those
[14:03] <maxb> bencode, dirstate_helpers have a _*_pyx.h that is human-written
[14:03] <maxb> There's also _static_tuple_c.h
[14:03] <jam> maxb: _c.h
[14:04] <jam> not _pyx
[14:04] <maxb> yes - just pointing out the close similarity
[14:04] <jam> _static_tuple_c is specifically '_c' because it *isn't* from Pyrex source
[14:05] <jam> maxb: we could probably move both of those into python-compat.h and be done with it
[14:05] <jam> it is 2 defines for bencode, and a special-cased (by platform) import logic for dirstate_helpers
[14:06] <maxb> That sounds like a promising solution. And it would make a suitable Makefile clean target easy
[14:10] <maxb> Although given how bencode-specific those two macros are, perhaps we should have _bencode_pyx_helpers.h
[14:11] <maxb> This is of particular interest to me since the daily-ppa recipe builds are currently failing due to stale pyrex generated files :-)
[14:11] <jelmer> maxb: that's what prompted me to look at this
[14:12] <maxb> I have thus far been unable to figure out why natty is working and the rest are failing :-(
[14:28] <jam> maxb: so why does the recipe builds have compiled pyrex lying around. Shouldn't it all be built from scratch?
[14:28] <jam> or is it the -maverick building after -natty that is re-using the dir
[14:28] <maxb> It gets imported from the tarballs into the debian packaging branches
[14:29] <maxb> For some indeterminate reason, the natty build is seeing the timestamps such that it should rerun pyrexc, the rest are not
[14:35] <jelmer> the convention is that distclean removes the files generated by configure, which we don't have
[14:35] <jelmer> I'll add a "make realclean"
[15:31] <gypsymauro> hi
[15:31] <jelmer> hi gypsymauro
[15:54] <magcius> if I have a bunch of changes in my working dir,
[15:54] <magcius> is there a way I can "clear" them to the last known thingy?
[15:54] <magcius> revision
[15:57] <jelmer> magcius: bzr revert
[15:57] <magcius> oh
[15:57] <magcius> I did that, but saw "M foo.py"
[15:58] <magcius> and I didn't do a status afterwards
[15:58] <jam> magcius: right, it is just telling you what things it changed
[15:58] <magcius> that's confusing
[15:59] <jam> magcius: would you rather we change things without telling you we did so?
[15:59] <magcius> I told you to change things with bzr rever.
[15:59] <magcius> revert.
[15:59] <magcius> I don't really need to know what changed, as long as you "did the right thing."
[16:00] <jam> sure, though if you issue a bare revert, you may not realize *what* things changed
[16:02] <ovnicraft> hello i am using v2.3.1 always after push the transport does not update my remote tree, so can i configure or pass any arg to update my remote tree automatically?
[16:02] <jam> ovnicraft: you can install the 'bzr-push-and-update' plugin
[16:02] <ovnicraft> jam thanks
[16:11] <marvin2> If "bzr pull" updates the local working tree, what is the use of "bzr update" (apart from use with checkouts)?
[16:14] <marvin2> Anybody?
[16:16] <maxb> moving the working tree to historical revisions?
[16:16] <maxb> updating the working tree if something went wrong during an update after a pull?
[16:27] <magcius> er
[16:27] <magcius> can I rewrite the last commit message? I just made a typo.
[16:27] <LeoNerd> uncommit / commit again. But that's kinda evil
[16:27] <LeoNerd> (it's rewriting history)
[16:28] <magcius> Uh, I promise to use my powers for good?
[16:47] <marvin2> maxb: Thanks.
[16:49] <marvin2> I have the following situation: Have 2 branches A and B, both synced at rev 2. A goes from rev 2 to 3 while B goes to rev 4. I then merge changes from A to B; A stays at 3 and B moves to 5. I then push B to A which makes them identical.
[16:49] <marvin2> Can I undo the last step so that I don't lose A's history?
[16:51] <maxb> You lost no history
[16:51] <marvin2> maxb: Sorry, let me rephrase that
[16:52] <marvin2> Can I undo the last step so that I don't lose A's "perspective" of things?
[16:52] <marvin2> I'll pull in changes from B.
[16:53] <maxb> If you locate A's previous tip revision, you can use pull / push --overwrite to reset A to it
[16:54] <marvin2> maxb: 3 in this case, if I understand "tip" correctly.
[16:54] <marvin2> ?
[16:55] <marvin2> But the revision numbers have been inherited from B
[16:55] <maxb> revnos are meaningful only in the context of a branch. what was r3 in A before you pushed B into it is not necessarily the same revision as r3 in A now
[16:56] <marvin2> maxb: Yeah, so how do I identify the "tip" of A before I pushed the merged version of B to it?
[16:56] <maxb> You must browse history (e.g. using "bzr qlog") and pick it out through your knowledge of the branches
[16:56] <marvin2> bzr qlog. Thanks!
[16:57] <marvin2> maxb: Unknown command
[16:57] <maxb> part of the qbzr extension
[16:58] <marvin2> maxb: Looking into it right now. Thanks for the pointers.
[18:11] <ls3> Hello. I have a large repo and accidently deleted a single file. I don't want to commit this change but do want to re-download a copy of that file.
[18:11] <ls3> How can I get that single file back into my local repo?
[18:12] <ls3> (ops...deleted a single file from my local repo is what I mean...)
[18:19] <maxb_> bzr revert filename
[18:21] <ls3> got it with bzr cat
[18:22] <ls3> Appreciate it
[20:49] <Odd_Bloke> Is there a bug open for "bzr mkdir -p"?
[20:51] <jelmer_> Odd_Bloke, I believe so, though I don't have the bug # here..
[20:51] <Odd_Bloke> Launchpad's search is being useless.
[20:52] <Odd_Bloke> I guess because basically all bug reports have mkdir in. ¬.¬
[21:17] <achiang> hello, i'm having a little trouble with bzr merging
[21:17] <achiang> i'm in branch A, merged B
[21:17] <achiang> discovered a problem in B, so i reverted B (or so i thought i did)
[21:18] <achiang> now i'm ready to test B again, so i try to merge again
[21:18] <achiang> but nothing is actually happening
[21:18] <achiang> changes introduced by B do not appear in A after the merge; i've tried --reprocess and that doesn't seem to help
[21:29] <achiang> oh joy, i guess i've found https://bugs.launchpad.net/bzr/+bug/152008
[21:31] <lifeless> achiang: did you commit after merging, before the revert?
[21:31] <achiang> lifeless: hm, this was a while ago, let me think...
[21:31] <lifeless> if you did, you can just revert/uncommit back to that point
[21:31] <lifeless> but yeah, merge B; revert .; commit -> rejects that merge forever
[21:32] <achiang> lifeless: well, there were definitely commits
[21:32] <lifeless> merge B; revert; commit -> 'error: pointless commit'
[21:32] <achiang> lifeless: the workflow was: merge B, upload to PPA, discover B was broken, revert B, commit, new upload to PPA
[21:32] <lifeless> righto, thats defintely rejecting the changes
[21:32] <achiang> (because we were preparing for a release and didn't have time to fix B)
[21:32] <lifeless> that will propogate
[21:32] <achiang> now i'm ready to test B again
[21:33] <lifeless> merge . -r rev-that-rejected-B..(rev-that-rejected-B-1_
[21:34] <achiang> lifeless: is this a design choice or just a bug of some sort?
[21:34] <lifeless> standard behaviour for every DVCS
[21:35] <lifeless> you did a merge and accepted it
[21:35] <lifeless> then you textually undid that change
[21:35] <lifeless> the system is *expected* to propogate your change
[21:35] <lifeless> and the merge is already known as done
[21:35] <achiang> i don't know what the key word "textually" means there
[21:36] <lifeless> text, source code,
[21:36] <achiang> my mental model is that, revert introduces a new commit that makes the merge go away
[21:36] <achiang> yeah, but you say that like the objects underneath don't care or something
[21:36] <lifeless> right, they don't
[21:37] <lifeless> what was the exact command you used to revert ?
[21:37] <lifeless> if you used 'bzr revert .' it *keeps the merge record*
[21:37] <achiang> bzr merge . -2..-3, iirc
[21:37] <lifeless> so, that just changes the text in tree, it doesn't alter the revision graph
[21:37] <lifeless> see bzr help merge
[21:38] <lifeless> and read about cherrypicks
[21:38] <achiang> wow, that is quite confusing
[21:39] <achiang> lifeless: this is the key paragraph from bzr help revert -- http://pastebin.ubuntu.com/589890/
[21:40] <lifeless> achiang: yup; now read the merge help to see what that does
[21:41] <achiang> lifeless: i  must be missing the key paragraph there, because i've read that help many times and i'm not getting the enlightenment you think i should be getting
[21:42] <lifeless> huh, its not there
[21:42] <lifeless> anyhow
[21:43] <lifeless> a cherrypick is not reflected in the revision graph
[21:43] <lifeless> merge is completely ignorant about cherrypicked changes
[21:45] <achiang> ok, i don't know enough about bzr internals to understand this behavior (or the explanation, really)
[21:45] <achiang> my expectation is that any change i make to my tree should be reflected in the revision graph
[21:46] <achiang> i find it strange that some things would be in there, but other things not
[21:46] <lifeless> revisions have a list of parents
[21:46] <lifeless> when you commit  amerge the list is of length 2 (or more)
[21:46] <lifeless> normal commits, and commits of cherrypicks, have a list of length 1
[21:48] <achiang> ok, so what is the proper way to revert a change then?
[21:48] <achiang> because clearly i did something wrong or weird
[21:49] <lifeless> no
[21:49] <lifeless> this is the expected behaviour if you back something out after recording the merge
[21:49] <lifeless> after you back it out, its backed out, and it doesn't alter the behaviour of merge
[21:51] <achiang> ok, i'm having trouble with this because from what i remember in git, it behaves differently. but perhaps i'm remembering incorrectly
[21:51] <lifeless> git does a regular three way merge
[21:51] <lifeless> same behaviour
[21:52] <lifeless> the way to avoid it is to not commit the merge of B in the first place
[21:56] <lifeless> there are bugs open to add more capabilities here
[21:57] <lifeless> but the only systems I know of at the moment that can do better are darcs and arch; the latter is dead (and had other significant downsides) and the former is a totlly different model
[21:57] <achiang> i'm just doing a little test right now in git to prove to myself that my memory is just bad/corrupted. ;)
[22:03] <achiang> lifeless: ok, i must have had a bad memory. you are right, git behaves the same way, so thank you for the explanation
[22:04] <achiang> lifeless: can you explain this comment again? merge . -r rev-that-rejected-B..(rev-that-rejected-B-1_
[22:05] <achiang> oh, now i see the "-1" in the 2nd revspec
[22:05] <lifeless> yeah, same thing you used to undo it
[22:05] <lifeless> to undo the undo
[22:11] <achiang> lifeless: that worked, thank you
[23:26] <jelmer> g'morning poolie
[23:27] <poolie> hi jelmer
[23:38] <jelmer> poolie: thanks for adding that SRU overview page. Is there anything more we should do to get the SRU's going or do we just need to wait for review from pitti and spamaps?
[23:38] <poolie> thanks, i feel i have more of a handle on things now two
[23:39] <poolie> i _think_ i just need to  upload to maverick-proposed
[23:39] <poolie> s/two/too
[23:39] <poolie> i was just going to check that with an ubuntu developer
[23:39] <poolie> or perhaps you can confirm that for me?
[23:39] <poolie> that does seem to be the next step on the sru checklist
[23:41] <jelmer> Yeah, that's my understanding of it too.
[23:43]  * jelmer links the branch for the lucid update to the bug
[23:45] <jelmer> hmm, the Lucid branches' changelog doesn't mention bug 707075
[23:45] <poolie> i saw your packaging branch for that
[23:45] <poolie> i'll add that to the changelog
[23:46] <jelmer> Vincent prepared a Lucid branch here: https://code.launchpad.net/~vila/ubuntu/lucid/bzr/sru-2.1.3