/srv/irclogs.ubuntu.com/2011/04/05/#bzr.txt

michaelh1Hi 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:00
michaelh1bzr missing ../mainline, taking the lowest revno of the feature branch changes, then subtracing one would work but it's ugly...00:01
lifelesstheres a find-merge-ancestor or some such, or log -r ancestor:../trunk00:02
pooliefind-merge-base i think00:03
lifelessnote that where you branched is not supported at all, only where you have merged up to (which is subtly different :))00:03
pooliewell, where you branched from, or where you last pulled up to, is possible to compute00:04
pooliebut i don't think there's any ui to get it00:04
michaelh1OK.  That gives me a revid, and I can use bzr log to turn that into a revno00:05
lifelessmichaelh1: try bzr revision-info -r ancestor:path/to/trunk00:07
michaelh1lifeless: ta, that does it.  revision-info isn't in man bzr or bzr help commands...00:08
pooliehttps://bugs.launchpad.net/bugs/748141 asks for it to be shown00:10
ubot5Ubuntu bug 748141 in Bazaar "Please unhide some hidden commands" [Undecided,New]00:10
pooliefiled just yesterday ironically enough00:10
spivGood morning01:04
pooliehi there spiv!01:10
pooliespiv, i'm just looking at some of the branch privacy setup issues on lp01:16
pooliethen, i'm going to push a bit on our srus, do a few reporting chores, and then push on my in-progress branches01:16
pooliealso, bug 740932 is perfect john-bait :)01:16
ubot5Launchpad bug 740932 in Bazaar "building working tree doesn't update sha cache" [High,Confirmed] https://launchpad.net/bugs/74093201:16
spivI thought he was already working on that, actually :)01:18
spivAh, yep.01:18
poolieexactly01:20
lifelesshttp://yaxu.org/cyclic-revision-control/05:02
poolieinteresting05:29
=== michaelh1 is now known as michaelh1|away
pooliei think maxb is on the right track with a wiki page showing how the ppas are getting along07:49
pooliemaybe i will make a similar thing for srus07:49
vilahi all !07:52
pooliehi there vila07:52
pooliehow are you07:52
vilafine, good progress on configs07:53
poolievila, good07:53
vilaI don't quite get your comment on bug #72523407:53
ubot5Launchpad bug 725234 in Bazaar "config doesn't provide a --section parameter" [Low,Confirmed] https://launchpad.net/bugs/72523407:53
maxbYou mean DailyPpaStatus?07:53
vilapoolie: what could be simpler than [~/work]\nfoo=bar\n in bazaar.conf ?07:53
maxbThat was useful - on the other hand, ProposedPpaStatus ceased to be particularly useful after I had the first big push to bring it up to date07:53
maxbSpeaking of PPAs, I need to write a status email about the twisty chaos of dh_python2/pycentral/pysupport07:54
vilamaxb: +107:54
poolieyes07:54
maxbBut yes, in general: If you don't have time to code a status tracking webapp: Use a wiki! :-)07:55
vilamaxb: and its impact on the beta ppa ?07:55
poolievila, my point is that i'm not sure if at the ui level users should be thinking about sections07:55
pooliemaxb so it's kinda tracked in bugs07:55
pooliecertainly more so than the ppa failures07:55
pooliebut, perhaps not really clearly enough07:56
poolievila  if you can find the time helping spiv with reviews could be good07:56
pooliethe page is really long07:56
vilapoolie: what's wrong with that ? It looks like a common practice to me, especially if sections allow grouping so you DRY07:56
maxbI 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 form07:57
poolielet me back up07:57
vilamaxb: ok07:57
pooliein the case of my example where they want to set some policy for a particular directory (and children)07:57
pooliewhat do you think the user would say?07:57
vilabzr config foo=bar --scope bazaar --section ~/work07:58
pooliehow does that work?08:00
pooliecan bazaar.conf have per-directory sections?08:00
spivFWIW, 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
vilathat's the plan, yes, to replace their abusive use in locations.conf which should define overriding options while bazaar define defaults08:00
vilasection names can't be inferred, they need to be specified08:01
vila(when they are paths/globs)08:01
vilasupporting them fill the gap that requires hand editing today08:02
spivI 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
pooliehm08:02
poolieme either08:02
spivUnless the goal is to remove locations.conf entirely.08:02
pooliealso, i think the ui should be something like08:02
pooliebzr config --location ~/work foo=bar08:02
pooliewhich can internally may to "section ~/work in file locations.conf"08:03
vilalocations.conf is (and has always been) defined for *overriding* settings in branch.conf08:03
vilathat's not the way people expect it to be but that's the way it is implemented08:03
spivvila: oh *branch.conf*08:03
spivYou said bazaar08:03
vilaI said bazaar because I thought poolie wanted defaults08:04
vilapoolie: not all section names will be locations08:04
spivHmm.08:04
vilapoolie: if we had an easier way to parse options dynamically, they could depend on --scope, but that seems quite complicated08:05
spivI kinda like that only locations.conf is defined as having section name == location glob08:05
vilawhy ?08:05
spivI wouldn't want DEFAULT in bazaar.conf to suddenly match a directory I have that happens to have that name08:06
vilaI want to get rid of DEFAULT08:06
vilaexactly because it can conflict08:06
spivWell, or any other section type :)08:06
vilasame same :)08:06
spivAnd ALIASES?08:06
vilayup08:06
vilabzr.aliases.mylog08:07
spivHmm08:07
vilaI think it's described explicitely in http://doc.bazaar.canonical.com/devnotes/configuration.html08:07
vilatly08:07
spivThat's uglier to look at than what we have now :/08:07
vilacan you elaborate ?08:08
spivSorry, I haven't made time to read and digest that doc yet :/08:08
spivWell,08:08
spiv[ALIASES]08:08
spivcommit = commit --strict08:08
spivIs really clear and obvious I think08:08
vilawe *don't* have a way to specify defaults values per location *and* define exceptions in branch.conf today08:08
spivAnd bzr.aliases.mylog is not quite as much.08:08
spivSure, I'm not disagreeing with that :)08:08
spivIt seems to me there's a namespace problem with section names08:09
vila*because* sections have been used in bazaar.conf08:09
spivRight08:09
vilaindeed08:09
vilaspiv: have a look a bzr-bookmarks08:09
spivSo why not disambiguate by having location-matched sections be called [location:/path/...] ?08:09
pooliei think we need to be clear about what sections are for08:09
poolieare they basically part of the namespace of the option08:10
spivOr even [location /path/...]08:10
vilaspiv: it uses *both* a section [BOOKMARKS] in bazaar.conf *and* prefixed options in branch.conf08:10
poolieiow it's really ALIASES/commit08:10
poolieor are they something used to select which values are active08:10
poolieat the moment it's a bit of both08:10
vilapoolie: the later08:10
vilaexactly08:10
vilausing a hierarchical name space for options is powerful enough to free the section namespace08:11
vilaso the section namespace can be used for other things08:11
vilafor bazaar.conf, locations.conf, branch.conf and even tree.conf, repo.conf, rules and so on path/glob sounds good enough08:12
vilabut plugins may decide differently which is why I'm trying to not *force* path/globs for section names08:12
spivBut you have?08:13
vilanot yet08:13
vilaerr, not so far ?08:13
vilaand hopefully never08:13
spivIn your scheme, how can a plugin define e.g. [explorer] as a section and avoid having it match that path?08:13
spivSorry if I'm making you repeat your doc!08:13
vilabecause sections are selected when building the stack and this selection can be file-specific08:14
spivIn general though I think it'll be hard to understand for users if sections are mostly one thing but occasionally another.08:14
spive.g. see how I'm confused right now ;)08:14
vilait'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 place08:15
vilanot if documented by file08:15
spivOh, you're saying that in a plugin-specific conf file section names can have a different meaning?08:15
vilayes08:15
spivOk, but then it's the same as today?08:15
vilaqbzr can use window names for example08:15
spivlocations.conf uses them as locations, nowhere else does.08:15
vilaI'd rather use the name space too for that but for the sake of the example08:16
spivIs the main issue you want to solve that we can currently only define per-location overrides, and can't define per-location defaults?08:16
vilaspiv: 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 need08:17
vilathat's one issue yes, dunno if it's the main one08:17
spivWell, I can think of less radical changes that would solve that issue :)08:17
vilathe main one is to be able to define option values that apply to various contexts without duplication08:18
vilaspiv: yes ?08:18
spivAdd a location-defaults.conf (and maybe rename locations.conf to location-overrides.conf), for instance.08:19
spivOr allow bazaar.conf to contain e.g. [location-match /path…] section names.08:20
vilaah, yes, that's not ruled out, but you still need to support section that are not *only* path/glob08:21
spivNot saying these are better, but they would appear to require less change, at least in how users write out and read options.08:21
vilaerr, you still need to move parts of locations.conf to another file  right ? Why is that less changes ?08:21
spivWell, I don't need to rewrite my ALIASES section08:22
vilaspiv: and have you tried adding a conf file to BranchConfig ? And have it supported by RemoteBranchConfig ?08:22
vilahaaa, I didn't say [ALIASES} will disappear at once08:22
vilaIt can still be supported and deprecated in the future to address the collision issue08:23
spivOr otherwise rewrite any options, unless I want to change any existing per-location stuff I have from being an override08:23
spiv(And off the top of my head, I think I want most of my per-location conf to be overrides)08:23
spivIn my alternative, ALIASES wouldn't ever need to be removed08:23
spivAlso, it's a bit interesting that your way could perhaps allow per-location aliases08:24
spivI'm not sure if that's a good or bad thing08:24
spivI definitely don't want branches to even look like they can define them though!08:24
vilathe starting point was to use --location instead of --section, if you want to keep ALIASES, you want --section08:24
vilaspiv: you can't decide that for *all* options, but you can defined that for *some* options08:27
vilas/defined/define/08:29
vilaanyway, the implementation under work is about *allowing* more control, the current design just doesn't scale for the already existing (and unanswered) needs08:31
vilait gives ways to clear the section name space so it can be better defined and extended,08:31
vilaI won't implement more than paths/globs to start with because it's not needed *yet*08:32
vilaI won't implement selecting which config files allow which options either for the same reasons08:32
poolievila, i really don't want to get one big "take it or leave it" patch08:33
vilapoolie: which is why I'm creating different threads so they can be reviewed and discussed independently08:33
pooliebut you know that :)08:34
vilathe aim is that the first implementation should be 100% compatible with the existing config files08:34
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
spivI 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
spivICBW :)08:35
vilabzr alias can very well stay and be re-implemented on top of the new design to start with08:36
vilasee 100% compatible above08:36
spivIt's great to have nice command line UI inspecting and updating various config settings08:36
vilaimplementing -Ofoo=bar is just... beyond me with the actual design08:37
vilawith the new one, it will just be adding a new read-only section in stacks that want to support it08:38
pooliei might have a stab at that08:40
pooliethen either we will get the feature, or i will stop telling you it's easy :)08:40
vila:)08:41
vilapoolie: don't forget bzr.config.expand :-p08:42
pooliewhat about it?08:44
pooliemaxb, jelmer, i started http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates08:44
poolieis pretty ugly08:45
pooliei feel it ought to have red and green bits but i'll get to that later08:45
vilapoolie: expansion should be able to cross configs, especially for -O or it won't be taken into account08:45
pooliehm08:47
pooliei don't feel that is as important as the other config bugs08:50
maxbpoolie: It looks good, and it calls to my attention an issue - what are our plans re lucid - which is, after all, an LTS08:52
vilapoolie: for the sake of the experiment, have a look at it to avoid having to fix it twice, pretty please08:52
vilapoolie: +1 on maxb08:52
vilapoolie: I'm all for handling 2.2 *first* but 2.1 should be seen as dead yet08:53
poolievila my plate's pretty full so these are idle threats :) but i will08:55
maxbIn 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 done08:55
pooliewe should do it too08:55
pooliei mean we should do 2.1 too08:56
vilapoolie: not a threat, more like getting an apple-to-apple comparison ;)08:56
vilapoolie: expand_options is currently implemented for Config and that's a blocker for expansing across config files (without going into quite complicated implementations)08:57
vilapoolie: it really should be implemented on stacks08:58
poolieno, i mean "i'll do it" is an empty threat09:00
poolie:)09:00
poolieanyhow, i'm probably getting to the point of just holding you back09:00
pooliehm making this page is quite good09:00
pooliemight be better as a little api client app09:00
poolielater09:00
vilapoolie: ha, that, yeah, hehe09:01
poolieah, maxb, what's happened09:04
vilahmm, expanding not expansing ;)09:05
vilalet's not start about performance issues ;D09:06
poolieok, fixed09:06
pooliehm, what's the most interesting bug fix in https://launchpad.net/bzr/+milestone/2.3.209:13
poolie616878 will do09:13
jampoolie: 733350 is probably the biggest regression sort of bug09:15
poolieyeah, the other one might hurt more people09:17
poolieit's a bit arbitrary09:17
poolieok09:18
pooliei'm a bit scared of uploading to -proposed, and i need to go out soon, so i'm not going to do it tonight09:18
pooliebut i will tomorrow09:19
pooliegood night all09:35
loolHey10:49
loolI'm looking for a way to override specific bzr settings via the environment10:49
loolTo be precise, I'd like to override the email address used in commits10:49
elmolool: BZR_EMAIL ?10:52
loolelmo: Oh gosh, thanks!10:53
loolelmo: EMAIL doesn't override the config, but BZR_EMAIL does10:53
loolelmo: Thanks  :-)10:53
jamlool: you might also want "bzr whoami --branch" if you want to configure it for specific areas.11:08
=== damiro is now known as muhaaa
spivIs it just me, or does bzrlib.log._apply_log_request_defaults unintentionally mutate the _DEFAULT_REQUEST_PARAMS var?11:11
vilaspiv: you're probably right that it was unintentional (you're definitely right that it mutates it ;)11:14
=== zyga_ is now known as zyga
jelmerjam: Thanks for the reviews :)12:42
jamjelmer: happy to keep the queue flowing. Thanks for all the work :)12:50
jamjelmer: for some reason pqm seems a bit slower to me. Have you noticed a difference?12:51
jelmerjam: 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:53
jelmerjam: is cython preferable over pyrex? We seem to prefer pyrex at the moment.12:59
jamjelmer: we are stuck with a pyrex dependency (we support pyrex 0.9.6 or whatever)13:03
jamhowever, Cython is a lot nicer if you have a choice13:03
jammeliae is cython only13:03
jelmerjam: shouldn't we prefer cython in setup.py in that case?13:04
jamjelmer: hysterical raisons13:04
jamI would be fine changing that13:04
jamthe main issue is the *code* that you get to write13:05
jamnot so much the final performanec13:05
jamperformance13:05
jamyou get to write "cdef list foo; foo.append()" rather than "PyList_Append(foo, ...)"13:05
jelmerisn't cython supposed to be better performing?13:05
jamjelmer: there are a few things internally that are a little better. I don't have a great feeling about real-world perf13:05
jelmerah, it's just that certain pythonish code gets more efficiently processed by cython?13:05
jamthey do stuff like "likely()" macros, etc.13:05
jamjelmer: right13:06
jamthat is the *big win*13:06
jamhowever, if we have to do the work under Pyrex, then it doesn't matter whether we use Cython or Pyrex13:06
jamwe could use "cdef list foo" in Pyrex, if we bumped the minimum version to 0.9.813:06
jamor something like that13:06
jamjelmer: did you see my reviewe for "lazyimport-scope-etc" ?13:07
jamI just got a submit failure13:07
jelmerjam: Yep, thanks13:09
jelmerjam: A submit failure on lazyimport-scope-etc, or the 2.3->bzr.dev merge?13:09
jamlazyimport-scope-etc, I just copy and pasted it into the form13:09
jelmerjam: ah, thanks13:28
jelmerjam: do we have any way to remove the generated .c and .py files from e.g. the makefile?13:28
jelmerI can't find one (other than bzr clean-tree, which isn't usable here)13:29
jamjelmer: I don't know of any generated .py files13:30
jamI usually do "rm bzrlib/*.[ch]; bzr revert"13:31
jamwow, bzr-vimdiff was still in *knit* format13:31
jelmerjam: ah, there aren't any, I'm being stupid...13:32
jamjelmer: there certainly are generated .c and .h files13:32
jamwhich would be nice to have a simple clean target for13:32
jambut I don't know of any13:32
fullermdhttps://bugs.launchpad.net/bzr/+bug/13078313:35
ubot5Ubuntu bug 130783 in Bazaar "`make clean` should clean up after pyrex" [Wishlist,Confirmed]13:35
=== verterok` is now known as verterok
jelmerfullermd: the problem is that make clean shouldn't remove those files, they're included with the tarball13:50
jamjelmer: make dist is used to generate the tarball13:55
jamwhich uses 'make clean && make && copy .c/.h files'13:55
jamso make clean could delete them13:55
jamunless it is a debian-thing13:55
jelmerjam: that means that a user who has the tarball unpacked and runs "make clean" ends up deleting his copies of those files13:56
jamfairy-nuff13:56
jelmers/his/their/13:56
jamhttp://en.wikipedia.org/wiki/Singular_they13:57
jam(I personaly like singular they)13:57
jamjelmer: so it should be under dist-clean?13:58
maxbIt is of particular annoyance that there does not seem to be any consistent file name pattern for what is autogenerated and what is not13:58
jammaxb: it is pretty straightforward, .pyx => .c, .h, _api.h13:58
jamwell, you only get _api.h under certain circumstances13:59
jamand we're *pretty* good about naming it all _pyx.pyx13:59
jamso that you get foo_pyx.c , etc13:59
maxbjam: Not so - there are files matching *_api.h and *_pyx.h which are source-controlled13:59
jammaxb: sure, I was thinking about it in the reverse direction.14:01
maxbIt looks like *_pyx.c are all autogenerated, as are *_pyx_api.h14:01
maxbHowever _simple_set_pyx.h is autogenerated, whereas _bencode_pyx.h (for example) is not14:02
jammaxb: I think changing the _*_pyx.h to only have auto-generated files would be reasonable14:02
jamI think we have 2 (maybe 3) of them14:02
jamwhich is our way of adding extra DEFINE sort of things to the pyrex code14:03
jambut we could do a new notation for those14:03
maxbbencode, dirstate_helpers have a _*_pyx.h that is human-written14:03
maxbThere's also _static_tuple_c.h14:03
jammaxb: _c.h14:03
jamnot _pyx14:04
maxbyes - just pointing out the close similarity14:04
jam_static_tuple_c is specifically '_c' because it *isn't* from Pyrex source14:04
jammaxb: we could probably move both of those into python-compat.h and be done with it14:05
jamit is 2 defines for bencode, and a special-cased (by platform) import logic for dirstate_helpers14:05
maxbThat sounds like a promising solution. And it would make a suitable Makefile clean target easy14:06
maxbAlthough given how bencode-specific those two macros are, perhaps we should have _bencode_pyx_helpers.h14:10
maxbThis is of particular interest to me since the daily-ppa recipe builds are currently failing due to stale pyrex generated files :-)14:11
jelmermaxb: that's what prompted me to look at this14:11
maxbI have thus far been unable to figure out why natty is working and the rest are failing :-(14:12
jammaxb: so why does the recipe builds have compiled pyrex lying around. Shouldn't it all be built from scratch?14:28
jamor is it the -maverick building after -natty that is re-using the dir14:28
maxbIt gets imported from the tarballs into the debian packaging branches14:28
maxbFor some indeterminate reason, the natty build is seeing the timestamps such that it should rerun pyrexc, the rest are not14:29
jelmerthe convention is that distclean removes the files generated by configure, which we don't have14:35
jelmerI'll add a "make realclean"14:35
gypsymaurohi15:31
jelmerhi gypsymauro15:31
magciusif I have a bunch of changes in my working dir,15:54
magciusis there a way I can "clear" them to the last known thingy?15:54
magciusrevision15:54
jelmermagcius: bzr revert15:57
magciusoh15:57
magciusI did that, but saw "M foo.py"15:57
magciusand I didn't do a status afterwards15:58
jammagcius: right, it is just telling you what things it changed15:58
magciusthat's confusing15:58
jammagcius: would you rather we change things without telling you we did so?15:59
magciusI told you to change things with bzr rever.15:59
magciusrevert.15:59
magciusI don't really need to know what changed, as long as you "did the right thing."15:59
jamsure, though if you issue a bare revert, you may not realize *what* things changed16:00
ovnicrafthello 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
jamovnicraft: you can install the 'bzr-push-and-update' plugin16:02
ovnicraftjam thanks16:02
marvin2If "bzr pull" updates the local working tree, what is the use of "bzr update" (apart from use with checkouts)?16:11
marvin2Anybody?16:14
maxbmoving the working tree to historical revisions?16:16
maxbupdating the working tree if something went wrong during an update after a pull?16:16
magciuser16:27
magciuscan I rewrite the last commit message? I just made a typo.16:27
LeoNerduncommit / commit again. But that's kinda evil16:27
LeoNerd(it's rewriting history)16:27
magciusUh, I promise to use my powers for good?16:28
=== psynaptic|food is now known as psynaptic
marvin2maxb: Thanks.16:47
marvin2I 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
marvin2Can I undo the last step so that I don't lose A's history?16:49
maxbYou lost no history16:51
marvin2maxb: Sorry, let me rephrase that16:51
marvin2Can I undo the last step so that I don't lose A's "perspective" of things?16:52
marvin2I'll pull in changes from B.16:52
=== psynaptic is now known as psynaptic|away
maxbIf you locate A's previous tip revision, you can use pull / push --overwrite to reset A to it16:53
marvin2maxb: 3 in this case, if I understand "tip" correctly.16:54
marvin2?16:54
marvin2But the revision numbers have been inherited from B16:55
maxbrevnos 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 now16:55
marvin2maxb: Yeah, so how do I identify the "tip" of A before I pushed the merged version of B to it?16:56
maxbYou must browse history (e.g. using "bzr qlog") and pick it out through your knowledge of the branches16:56
marvin2bzr qlog. Thanks!16:56
marvin2maxb: Unknown command16:57
maxbpart of the qbzr extension16:57
marvin2maxb: Looking into it right now. Thanks for the pointers.16:58
=== deryck is now known as deryck[lunch]
=== zyga is now known as zyga-afk
=== Riddelll is now known as Riddell
=== zyga-afk is now known as zyga
=== Ursinha is now known as Ursinha-lunch
=== psynaptic|away is now known as psynaptic
ls3Hello. 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
ls3How can I get that single file back into my local repo?18:11
ls3(ops...deleted a single file from my local repo is what I mean...)18:12
=== deryck[lunch] is now known as deryck
maxb_bzr revert filename18:19
ls3got it with bzr cat18:21
ls3Appreciate it18:22
=== Odd_Blok1 is now known as Odd_Bloke
=== psynaptic is now known as psynaptic|food
=== Ursinha-lunch is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== psynaptic|food is now known as psynaptic
=== Ursinha is now known as Ursinha-afk
Odd_BlokeIs there a bug open for "bzr mkdir -p"?20:49
jelmer_Odd_Bloke, I believe so, though I don't have the bug # here..20:51
Odd_BlokeLaunchpad's search is being useless.20:51
Odd_BlokeI guess because basically all bug reports have mkdir in. ¬.¬20:52
=== maxb_ is now known as maxb
=== Ursinha-afk is now known as Ursinha
=== michaelh1|away is now known as michaelh1
achianghello, i'm having a little trouble with bzr merging21:17
achiangi'm in branch A, merged B21:17
achiangdiscovered a problem in B, so i reverted B (or so i thought i did)21:17
achiangnow i'm ready to test B again, so i try to merge again21:18
achiangbut nothing is actually happening21:18
achiangchanges introduced by B do not appear in A after the merge; i've tried --reprocess and that doesn't seem to help21:18
achiangoh joy, i guess i've found https://bugs.launchpad.net/bzr/+bug/15200821:29
ubot5Ubuntu bug 152008 in Bazaar "Ability to unmerge or revert a merge sensibly" [Wishlist,Confirmed]21:29
lifelessachiang: did you commit after merging, before the revert?21:31
achianglifeless: hm, this was a while ago, let me think...21:31
lifelessif you did, you can just revert/uncommit back to that point21:31
lifelessbut yeah, merge B; revert .; commit -> rejects that merge forever21:31
achianglifeless: well, there were definitely commits21:32
lifelessmerge B; revert; commit -> 'error: pointless commit'21:32
achianglifeless: the workflow was: merge B, upload to PPA, discover B was broken, revert B, commit, new upload to PPA21:32
lifelessrighto, thats defintely rejecting the changes21:32
achiang(because we were preparing for a release and didn't have time to fix B)21:32
lifelessthat will propogate21:32
achiangnow i'm ready to test B again21:32
lifelessmerge . -r rev-that-rejected-B..(rev-that-rejected-B-1_21:33
achianglifeless: is this a design choice or just a bug of some sort?21:34
lifelessstandard behaviour for every DVCS21:34
lifelessyou did a merge and accepted it21:35
lifelessthen you textually undid that change21:35
lifelessthe system is *expected* to propogate your change21:35
lifelessand the merge is already known as done21:35
achiangi don't know what the key word "textually" means there21:35
lifelesstext, source code,21:36
achiangmy mental model is that, revert introduces a new commit that makes the merge go away21:36
achiangyeah, but you say that like the objects underneath don't care or something21:36
lifelessright, they don't21:36
lifelesswhat was the exact command you used to revert ?21:37
lifelessif you used 'bzr revert .' it *keeps the merge record*21:37
achiangbzr merge . -2..-3, iirc21:37
lifelessso, that just changes the text in tree, it doesn't alter the revision graph21:37
lifelesssee bzr help merge21:37
lifelessand read about cherrypicks21:38
achiangwow, that is quite confusing21:38
achianglifeless: this is the key paragraph from bzr help revert -- http://pastebin.ubuntu.com/589890/21:39
lifelessachiang: yup; now read the merge help to see what that does21:40
achianglifeless: 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 getting21:41
lifelesshuh, its not there21:42
lifelessanyhow21:42
lifelessa cherrypick is not reflected in the revision graph21:43
lifelessmerge is completely ignorant about cherrypicked changes21:43
achiangok, i don't know enough about bzr internals to understand this behavior (or the explanation, really)21:45
achiangmy expectation is that any change i make to my tree should be reflected in the revision graph21:45
achiangi find it strange that some things would be in there, but other things not21:46
lifelessrevisions have a list of parents21:46
lifelesswhen you commit  amerge the list is of length 2 (or more)21:46
lifelessnormal commits, and commits of cherrypicks, have a list of length 121:46
achiangok, so what is the proper way to revert a change then?21:48
achiangbecause clearly i did something wrong or weird21:48
lifelessno21:49
lifelessthis is the expected behaviour if you back something out after recording the merge21:49
lifelessafter you back it out, its backed out, and it doesn't alter the behaviour of merge21:49
achiangok, i'm having trouble with this because from what i remember in git, it behaves differently. but perhaps i'm remembering incorrectly21:51
lifelessgit does a regular three way merge21:51
lifelesssame behaviour21:51
lifelessthe way to avoid it is to not commit the merge of B in the first place21:52
lifelessthere are bugs open to add more capabilities here21:56
lifelessbut 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 model21:57
achiangi'm just doing a little test right now in git to prove to myself that my memory is just bad/corrupted. ;)21:57
achianglifeless: ok, i must have had a bad memory. you are right, git behaves the same way, so thank you for the explanation22:03
achianglifeless: can you explain this comment again? merge . -r rev-that-rejected-B..(rev-that-rejected-B-1_22:04
achiangoh, now i see the "-1" in the 2nd revspec22:05
lifelessyeah, same thing you used to undo it22:05
lifelessto undo the undo22:05
achianglifeless: that worked, thank you22:11
=== mwhudson_ is now known as mwhudson
=== psynaptic is now known as psynaptic|afk
=== Ursinha is now known as Ursinha-bbl
=== s1aden is now known as sladen
=== psynaptic|afk is now known as psynaptic|away
jelmerg'morning poolie23:26
pooliehi jelmer23:27
jelmerpoolie: 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
pooliethanks, i feel i have more of a handle on things now two23:38
pooliei _think_ i just need to  upload to maverick-proposed23:39
poolies/two/too23:39
pooliei was just going to check that with an ubuntu developer23:39
poolieor perhaps you can confirm that for me?23:39
pooliethat does seem to be the next step on the sru checklist23:39
jelmerYeah, that's my understanding of it too.23:41
* jelmer links the branch for the lucid update to the bug23:43
jelmerhmm, the Lucid branches' changelog doesn't mention bug 70707523:45
ubot5Launchpad bug 707075 in bzr (Ubuntu Maverick) "[sru] lp-propose fails with a 404 error" [Undecided,New] https://launchpad.net/bugs/70707523:45
pooliei saw your packaging branch for that23:45
pooliei'll add that to the changelog23:45
jelmerVincent prepared a Lucid branch here: https://code.launchpad.net/~vila/ubuntu/lucid/bzr/sru-2.1.323:46

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!