igcpoolie, spiv: call on today?00:04
poolieigc, yes, but i can't get in00:05
pooliestill trying00:06
igcpoolie: I'll hang up in case that helps00:06
* spiv hangs up too00:07
schierbec1jelmer: ping00:07
igcpoolie: I got straight back in ok00:08
igcis it your local phone maybe?00:08
poolieit might be my phone00:12
pooliewhen i tried i got through to varying extents00:12
poolielet's just catch up here on irc?00:13
spivSounds good.00:13
igcme too00:13
poolieso i think the PPA stuff is all settled now00:13
igctoday, I'm planning to review patches, particularly the xml8 serializer one00:14
pooliei'm going to look at what bugs i currently have assigned to me and either finish some of them, do reviews, or do startup time hacking00:14
igcI need to learn more about that so reviewing that patch will help me00:14
pooliei'd like to suggest the whole project do a bug day tomorrow, will send mail about that00:15
pooliealso i seem to have some Ubuntu bugs atm00:15
poolieso will file them00:15
igcpoolie: were you planning to tweak james_w's patch on lp: urls or shall I do that? we both voted tweak00:16
pooliei'll do that00:16
pooliealso when lifeless is back i'll call him re his conference submission00:17
poolieand i owe thumper a call or sketch of the branch listing page00:17
igcif you get a chance, I'd like some feedback on my hook patch/rfc too00:17
spivI've sent off the core bits of the fix for bug 207558.  I want to do a little more on it (as mentioned in the most recent email to the list about it), but it's essentially done.00:18
ubotuLaunchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/20755800:18
pooliei'll try to read that for you spiv00:18
pooliewhat is next for you?00:18
spivSo today will be mainly server-side hooks.00:18
igcpoolie: another thing for me today - kill & resume the OOo import00:20
igcit's at 157k out of 305k, taking 18 minutes per 100 revisions so dog slow00:21
igcI took the call to enable_cache out of the code yesterday at lifeless' request so I'll resume it with that code gone and see if it helps00:22
poolieok, good00:31
lifelessigc: We should find what the cache was masking and fix it.00:39
lifelessigc: I strongly suspect that using commit builder will give you better performance and let you get to an incremental-change approach safely for the importer00:44
lifelessigc: with appropriate tweaks to the builder of course; but thats what its meant to be used for - install_revisions shouldn't, IMO, need to exist.00:45
igclifeless: maybe. commit-builder currently does things much slower than the importer does00:46
igcit simply can't make some of the assumptions than an importer can00:47
igcwhich make big differences to speed00:47
lifelessigc: without details I can't comment; but if we're to continue to accelerate commit, commit builder has to learn how to work with very smart trees; which an import source can be considered to be.00:48
lifelessigc: in dealing with merge revisions, if commit builder is slower, I have to assume that the importer is wrong :>00:48
lifelessI'm going to do a couple of spikes today00:48
lifelessand get back to VF this afternoon00:48
lifelessI chatted with benno last night about python performance00:50
lifelessand he concurred with my import analysis, gave some commentary on os call performance readdir etc00:50
lifelessso I'm going to do this long threatened import hook00:50
spivlifeless: based on my stracing and experiments in London, I'm only expecting a very modest win (300ms improvement in cold cache time).  I'll be interested to see if the reality is different.00:53
lifelessspiv: strace doesn't show how much time python spends marshalling00:55
lifelessspiv: I suspect that there is some compiler overhead that won't be addressed by a simple import hook00:55
lifelessholy cow 'import bzrlib' hits a lot of shit00:59
lifeless34 modules00:59
poolieyes, i know00:59
lifelessmany are demand load stubs I think01:00
lifelessor something strange01:00
lifeless>>> type(sys.modules['bzrlib.struct'])01:01
lifeless<type 'NoneType'>01:01
spivThat's expected.01:02
spivWhen a module inside the bzrlib package tries "import struct", python first treats it as a relative import.01:03
spivAnd when an import fails, it caches misses as well as hits in sys.modules.01:03
lifelessah good01:03
spiv(Bring on python 2.5...)01:04
lifeless12 real modules imported then01:04
spivlifeless: I see 58 new modules imported by "import bzrlib" with bzr.dev.  (Only 12 with http://people.ubuntu.com/~andrew/bzr/faster-startup, though...)01:20
spiv(as measured with PYTHONPATH=. python -c "import sys; get_mods = lambda: set(name for name, mod in sys.modules.items() if mod is not None); before = get_mods(); import bzrlib; after = get_mods(); print len(after - before)")01:21
=== mwhudson_ is now known as mwhudson
=== kiko is now known as kiko-zzz
lifelessspiv: what does your faster-startup branch do ?01:27
lifelessspiv: (I am only planning to alter the behaviour of bzrlib specific imports)01:27
spivlifeless: basically, various hackery to defer unnecessary imports01:28
spiv(or avoid)01:28
spivlifeless: it's cumulatively a few hours of iterating on "bzr --profile-imports" on simple commands like "rocks" and "status" and seeing what cheap wins I could get.01:29
lifelesshas anyone tried running freeze on bzr ?01:30
spivOh, and specifically also reducing the amount of the universe that "import bzrlib" imports :)01:30
lifelesse.g. making *everything* import and running freeze01:30
lifelessspiv: so my thesis is that we should make importing everything fast01:31
=== bigdo2 is now known as bigdog
lifelessbecause in the general case most of the code is needed01:31
lifelessspiv: what do you mean about 2.5?01:46
mwhudsoni don't think he meant 2.501:46
mwhudsonat some point, imports written the normal way will be absolute01:47
mwhudsonwhich means less looking for things like bzrlib.struct01:47
spivI meant file:///usr/share/doc/python2.5/html/whatsnew/pep-328.html01:49
spiv2.5 introduces "from __future__ import absolute_import"01:49
mwhudsonoh, heh01:50
mwhudsonshows when i stopped paying microscopic attention to python development01:50
lifelessdamn, pkgutil doesn't exist in 2.401:54
lifelessso, I'm saving 130/4900 open calls02:08
lifelessall of which look like failures02:08
LaserJockquestion, how do I change the "parent branch" of a branch?02:18
poolieigc, is there a BB enttry for the patch from james_w you mentioned before?02:19
poolieigc, i take it you were referring to the one to give a warning when getting a readonly transport?02:20
igcpoolie: that's right02:20
* igc looks02:21
igcpoolie: ^^^02:21
lifelessLaserJock: pull --remember02:23
LaserJocklifeless: awesome02:26
* igc lunch02:35
* mwhudson tries to work out if it's strange or not for merge --preview to complain about uncommitted changes02:46
spivmwhudson: there was a thread about that on the list recently02:51
spivmwhudson: it shouldn't complain, IIRC02:51
mwhudsonthere was?  must have missed that in my catchup02:51
lifelessmwhudson: it should tell you, and take your changes as part of the merge03:04
lifelessmwhudson: IMO03:04
mwhudsoni guess that makes sense03:06
lifelessok, I now have my code being called consistently03:14
abentleylifeless: well, I'm not convinced.03:21
abentleyIt's not a very accurate preview that way.03:21
lifelessabentley: why is it less accurate?03:21
abentleybecause merge won't make any of those changes.  It will barf.03:23
poolieabentley: thanks for the review ofthe help change04:07
abentleySomething else I meant to mention is that people will still get criss-cross warnings if they are using --weave or --lca04:08
abentleyEven though those algorithms handle criss-cross better.04:09
abentleySo perhaps it should say not to remerge if you're already using --lca or --weave.04:10
poolieso would you overall suggest using remerge, or revert and merge again?04:10
lifelessback in a few minutes; getting lunch04:13
abentleypoolie: I'd suggest revert and merge.04:24
abentleyFewer commands to learn that way.04:25
lifelessabentley: when is remerge a good thing to learn and use then ?04:29
abentleyI generally use it when I've got a single file with really wacky conflicts, and I want to try out a bunch of different mergers to get the best result I can.04:30
abentleyIf there are basic, intermediate, and advanced commands, I'd consider it intermediate.04:31
lifelessone thing I've found with loom is that there was a bunch of 'when I use it' implicit in the thing that I hadn't written down.04:31
lifelessI think we may have something similar here.04:31
pooliethat is basically when i use remerge too04:32
poolierarely on the whole tree04:32
pooliecould we at least make it fail safe on looms - like give an error rather than mess things up?04:33
abentleylifeless: are you familiar with the problem?04:34
lifelessabentley: no, I've never used remerge like that04:35
lifelessoh, you mean with looms - I've seen the bug report04:35
abentleySo the problem is that remerge assumes the .THIS file coresponds to the left workingtree parent.04:36
abentleybut with up-thread, it is actually the rightmost parent.04:37
lifelessI think the things are about-face for performance04:37
lifelessI didn't want to transform; then merge04:37
abentleyI'm not sure your approach is wrong.  A different approach might lead to more conflicts.04:38
lifelessits on my long todo to teach bzr's merge the ability to be told different file suffixes04:39
lifelessso we can drop the 'right files' in the right places04:40
lifelessand give better herringbone labels04:40
abentleyYou'd also want to swap the conflict markers.04:40
lifelessI'd actually like to call them by their thread names04:40
fullermdSpeaking of merge, did --reprocess stop doing its thing sometime?  Or did it just never really cut things down a lot?04:40
lifelessfullermd: I think it became default04:41
poolieabentley: could you suggest some better help text?04:41
poolieshould we say "use remerge FILE, or revert and merge again?"04:41
abentleyLet's say "revert and merge again".04:42
abentleylifeless: So we understand the problem-- is there a short-term fix we can do like poolie suggested?04:42
abentleyfullermd: I don't think it became the default.  But it only helps a narrow class of merges, and only applies to --diff304:43
abentleylifeless: The problem so far is that we can't even tell that the merge was different.04:44
fullermdI've got kernel configs in bzr to easily merge upstream changes, and every time I do (last was some months ago), I get hyuge spurious conflicts that it doesn't help.04:45
=== mw is now known as mw|out
abentleyfullermd: line endings?04:53
fullermdNo, but changes in single lines ended up resurrecting giant blocks that I'd deleted.04:53
awmcclainImagine we pushed some changes for April Fools day. Like, 4 revisions. What would the easiest way, hypothetically, to check an older revision to head?04:53
fullermdI guess it's some artifact of the diff hunk for the revs where I whacked the blocks.04:54
spivawmcclain: bzr push -r NNN --overwrite04:55
spivawmcclain: (NNN == -4, I guess...)04:55
awmcclainspiv: And if it's a bound branch, can we do bzr ci -r NNN --overwrite?04:55
abentleyfullermd: I'd normally offer to help, but I'm behind already.04:56
spivawmcclain: ah, with a bound branch, use uncommit04:56
awmcclainspiv: 4 times?04:56
spivawmcclain: which also takes a -r arg.04:56
spivOr just run it 4 times, sure.04:56
awmcclainspiv: Gotcha!04:56
fullermdOr just pull -r-4 --overwrite .04:56
spivfullermd: heh.04:56
lifelessfullermd: pull overwrite affects master branch :)04:56
fullermdabentley: *shrug*  It's not that big a deal.  Bugs me for 30 seconds or so a couple times a year when I do it.  Hasn't been a high enough priority for me to build up a test case for it.04:57
abentleyfullermd: You might try --lca.  It's kinda got --remerge built in.04:57
fullermdLast time I tried was probably pre-lca; I tried both diff3 and weave, with/out reprocess; came up the same every time.04:58
awmcclainBut if I want to commit _over_ the current changes, not remove them.. could i bzr revert -r NNN then ci?04:58
fullermdI'll try getting creative next time it comes up.04:58
spivawmcclain: right04:58
poolieabentley, BB seems to be stuck, can you whack it?04:59
abentleypoolie: did it give you a lock error?05:00
spivabentley: I'm currently getting 502 Proxy Error05:01
spiv"Reason: Error reading from remote server"05:02
igcabentley: me too05:04
igc" The proxy server could not handle the request GET /."05:04
abentleyI have increased the database timeout to unreasonable levels.05:05
abentleySo there's an active lock, but I'm not sure whether it will resolve itself.05:05
abentleyThe last time I got a 502, it did.05:06
lifelessyou're using sqlite right?05:07
abentleyOkay, whacked.05:07
abentleylifeless: right05:07
lifelessthere is something funny in the python bindings AFAICT05:08
poolieabentley: how about this:05:08
poolieIn complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give05:08
pooliebetter results.  You may wish to `bzr revert` the working tree and merge05:08
poolieagain, or use `bzr remerge` on particular conflicted files.05:08
pooliei feel kind of reluctant not to mention remerge because it's what i usually run myself05:09
pooliei see your point though about involving less commands05:09
abentleyOkay, fair enough.05:09
poolieand if they did help criss-cross just after the failure they will not lose anything05:09
abentleyPerhaps we should omit the revert; remerge thing.05:09
abentleylifeless: Any suggestions on a band-aid for up-thread?05:10
lifelessabentley: w.r.t remerge ?05:11
lifelessI don't think there is a good band-aid; I think it just needs the bzrlib work done.05:11
poolie"""In complex merge cases, `bzr merge --lca` or `bzr merge --weave` may give05:11
pooliebetter results.  You may wish to `bzr revert` the working tree and merge05:11
poolieagain.  Alternatively, use `bzr remerge` on particular conflicted files.05:11
* poolie reads fix for 20755805:21
lifelesspoolie: call ?05:23
pooliein 6m?05:23
abentleypoolie: re that TT bug, it's due to adding a file to a deleted directory, when the deleted directory was the root directory.05:38
lifelessspiv: ping05:40
abentleyAnyhow, now that I can reproduce it, it shouldn't be a hard fix.05:40
lifelessI have a 'wtf' moment with my import hook05:40
poolielifeless: your phone's engaged?05:41
lifelessits trying to import 'debian_bundle' from '' in the Numeric path path_hook object05:41
lifelesspoolie: no??05:41
spivlifeless: pong05:44
lifelessdoes Numeric do crack?05:44
spivlifeless: I don't know if Numeric does crack or not.05:59
mwhudsonbeuno: around?06:00
lifelessspiv: you have mail06:13
lifelessspiv: should be self evident if you want to apply it to bzr.dev and play06:13
lifelessspiv: I get quite reduced syscalls with this but its buggy :/06:14
jameshlifeless: bzr-gtk has now been updated so that it functions correctly with my bzr-dbus patches, btw06:38
jameshthey're waiting on you for review though.06:39
spivabentley: bb seems to be wedged again06:51
=== mwhudson_ is now known as mwhudson
vilalifeless: regarding loom-specific conflict markers, please be sure you won't break external tools that are looking for them (i.e. may be *add* thread name after the usual markers instead of replacing MERGE-SOURCE and/or TREE)07:34
EgotripWant to make $$$ just by clicking? Sign up on http://bux.to/?r=eg0trip, and begin recieving checks!07:52
james_wno thanks07:54
Egotripyes you do07:54
mdkelifeless: still around?08:04
lifelessdunno who egotrip was, but we don't want spam here.09:03
fullermdHe didn't explain himself very well, certainly.  I kept clicking, but I got @@@ instead of $$$   :|09:08
jameshand I'd prefer to receive cheques rather than checks09:15
yaccHmm, how can I force a baseless merge with bzr?09:30
schierbeckjelmer: ping09:32
yaccschierbeck: I second that: ping jelmer09:32
yaccschierbeck: what's it for you? In my case bzr-svn seems to have forgotten about branch relationships ;(09:32
schierbecktough luck09:33
schierbecknah, i just want him to give his 2 cents before i send in a merge request09:33
james_wyacc:  merge -r1..-109:34
yaccjames_w: is that a good idea, considering that the branch contains the same revisions as the remote one? (bzr just seems to think that they are unrelated)09:35
james_wyacc: probably not09:35
james_whow did you create your local branch?09:35
yaccbzr branch svn+https://...09:35
james_wfrom the same branch you are trying to merge now?09:36
yaccLook at: https://bugs.launchpad.net/bzr-svn/+bug/21070509:37
ubotuLaunchpad bug 210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New]09:37
yaccjames_w: but basically yes.09:37
yaccjames_w: => it remembers where it pulled from, and pushed to in the past.09:38
yaccjames_w: just when doing a merge it complains about being unrelated.09:38
yaccOh, bzr missing lists all revisions as missing on both sides, plus the one that I did commit locally, which is only listed on one side.09:38
yaccbut the merge did not help anything, it still misses 3/4 revisions ;(09:39
yaccjames_w: despite the above merge -r1..-1, it still claims that the branches are diverging.09:40
james_wyacc: can you pastebin a bzr missing --show-ids09:40
yaccjames_w: just a moment, first I'm curious ;)09:40
yaccjames_w: they don't match :(09:42
yaccjames_w: guess that is what jelmer meant with the ids can change?09:43
james_wthey don't match is the reason that you are seeing this issue.09:43
james_wcalm down, he's been highlighted, if he's around he'll see it09:43
yaccjames_w: yeah, BUT: I had to change the scheme to include new trunks09:44
yaccrevision-id: svn-v3-list-QlpoOTFBWSZTWTtPdCgAACpRgAAQAAK3r94gIABIbVT1Mj0QeptEEpAAANMcdP3o3SqXf2KNSpL4ShxMTeA8adCslybHoqgxGgqoZA-LuSKcKEgdp7oUAA..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:5609:44
yaccrevision-id: svn-v3-list-QlpoOTFBWSZTWYDqAEcAADdRgAAQAAK3r94gIABISkMo0zUaemoEkkaZMAm1IM83f4FQYGxfzVWsvATONoa96yIoS8IEx1BxVRIGB_MCYIMwX5NxaET_F3JFOFCQgOoARw..:3e2713fb-81e7-48d5-8ee4-88d6b0cf85af:trunk%2Flogs%2Flookery-memberfind:5609:44
yaccsee the base64 encoded list of paths <= I had to change that to accomodate a new branch.09:45
james_wyou changed the svn branching scheme?09:45
yaccjames_w: list-path1-path2 => list-path1-path2-path3 <= I had to add path3 because it's a new branch I need access to?09:45
yaccjames_w: basicaly the revids for branch X contain the a list of all other branches that I'm accessing in the given SVN repo.09:47
yaccjames_w: Hmmm, I think the fix would be to make bzr-svn use svn-v3-list-$PATH_USED_IN_THIS_CASE instead of svn-v3-list-$PATH_OF_THE_COMPLETE_SCHEME?09:48
yaccjames_w: Any explanation what the different branching schemes are good for?09:50
james_wyeah, so it's caused by the change to the branching scheme09:53
james_wthe scheme is to tell bzr-svn which paths in svn to consider branches09:54
yaccyeah, but the problem is, appending one new "path" in the repository is a quite expected thing to do.09:56
yaccIt should not break all branches/checkouts in the wild, just because I need to track one additional location?09:56
james_wyacc: add this information to the bug report.09:57
yaccAlready done so.09:57
yaccjames_w: single would mean that I can only access exactly one path inside the svn repo?10:00
james_wI think so10:00
yaccSo basically I would need to parametrize the "schema name for property name" lookup thing.10:01
yaccIt basically needs to take the URL being accessed into account ;(10:02
* yacc wonders what the schemes are good for at all?10:06
igcjames_w: I'm hoping to review that gnome bug tracker patch tomorrow10:10
igcif you put through abentley's tweak tonight, that would be nice ...10:10
igcthough I realise you may not have time10:10
igcI'm heading off now10:10
igcnight all10:10
james_wigc: thanks, I'll try and get to it.10:11
jml_lifeless: ping10:13
yaccjelmer: ping10:22
yaccjelmer: would it be ok by you to implement a "EveryPathIsABranchScheme"?10:27
AnAntHello, when using bzr, can't I checkout just a single folder instead of the whole branch ?10:40
luksright, you can't10:41
luksbzr can only work with whole branches10:41
AnAntunlike svn10:42
lukssvn doesn't have branch :)10:43
yaccluks: and branches is (almost) all that bzr has ;)10:44
yaccHow do I make bzr send my local commits as a patch to the maintainer?10:44
luksbzr send10:45
yaccI just discovered that just switching schemes won't work => the svn repos contains pointers to the old scheme name, ...10:46
yaccMy only hope for a sane scheme is rapidly crashing.10:47
yaccjelmer: ping10:51
ChriS_TI am trying to convince a colleague to use bzr for our collaboration.  However, he has a mac OSX 10.4 intel.  Is there a ready to use disk image for that machine ?11:05
james_wthere's a macport I think11:13
ubotuNew bug: #210665 in bzr-svn "bzr svn-import fails" [Undecided,New] https://launchpad.net/bugs/21066511:18
ubotuNew bug: #210705 in bzr-svn "bzr-svn forgets relationship" [Undecided,New] https://launchpad.net/bugs/21070511:20
ubotuNew bug: #210723 in bzr "Some tests failed when selftest is invoked with -v" [Low,Confirmed] https://launchpad.net/bugs/21072311:21
jelmeryacc: pong11:22
jelmeryacc: EveryPathIsBranchingScheme will be incredibly slow11:23
yaccjelmer: why?11:24
yaccjelmer: and it misses to_list, which makes --set break, but I guess it breaks for other schemes too.11:25
jelmeryacc: When searching for revision ids, bzr-svn checks every possible branch path for properties11:25
yaccWell, it seems the that list paths get embedded in the properties somehow, so just doing a fresh branch with the ammended paths is not an option either.11:26
jelmerin the case of EveryPathIsBranchingScheme that means one call per file/directory in the remote repository11:26
yaccAnd let me guess it does not cache the results in any way ;)11:27
jelmerit does cache the results11:27
jelmerbut that's still too slow11:27
yaccso how to fix the list scheme then?11:32
jelmerhow do you mean?11:34
yaccWell, the list scheme embeds the paths in the revision stuff.11:52
yaccMeaning that when somebody adds a new path (because a new path got added), bzr-svn implods.11:53
yaccjelmer: : #21070511:53
yaccjelmer: easy to demonstrate: with a branch that uses a list scheme, add another path to the list => et voila, bzr thinks that the svn remote branch and your local bzr branch do not share any history.11:54
yaccWhich is wrong.11:54
yaccConsidering the fact that some svn users use very very creative directory setups, ...11:55
jelmeryacc: that's correct because they have a different branching scheme11:55
yaccOk, so how do I handle the case that my upstream project just got a new subproject?11:55
jelmeryacc: What you really want is a fix for bug 13037211:55
ubotuLaunchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/13037211:55
jelmeryacc: you can use wildcards in listbranchingscheme11:55
yaccjelmer: Only if I would have started with wildcards. Take a look at the later comments in 210705 and you'll notice that it seems impossible to switch the scheme for a given repo and recreate the bzr branch11:56
jelmeryacc: yes, that's correct11:57
jelmeryacc: that's why there's bug 13037211:57
ubotuLaunchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/13037211:57
yaccso what do I do? write myself scripts that replace ~/.bazaar/subversion.conf based on the directory I'm in when calling bzr?11:58
jelmeryacc: The error fetching after changing branching schemes is a bug12:00
yaccSo I open up a time loop window, and go studying the source code to fix that bug? <= I mean the scheme is part of the revision IDs?12:01
yaccSerious, new bug or known bug?12:05
jelmeryacc: the branching scheme is part of the revision id12:06
jelmeryacc: that's bug 130372 I mentioned earlier12:06
ubotuLaunchpad bug 130372 in bzr-svn "Abandon branching schemes" [Medium,Triaged] https://launchpad.net/bugs/13037212:06
yaccjelmer: 130372 is not about a bug fix, it's about joined branches, right? Meaning that you could drop to supporting only trunk/none for bzr-svn and make the people use split out parts of these repositories, right?12:07
jelmeryacc: no, it's about abandoning branching schemes completely12:08
jelmeras soon as by-value branches are supported12:08
jelmerwell, replacing branching schemes with a "repository layouts", which are not included in the revid12:09
yaccSo nothing simple for a newbie that has only a limited understanding of bzr internals might want to tackle ;(12:11
jelmeryacc: not really, though it should be possible to get that "not present in "... error fixed12:13
jelmerI'll see if I can fix that12:13
rexbronhey everyone, the docs on this function are a little bit unclear in what order the branch and tree objects are returned12:14
rexbronI think it is mentioned at the end, but I am still unsure12:14
jelmerrexbron: tuple with tree and branch12:15
rexbronjelmer: K, it mainly that the other funtions make that more clear12:15
bob2the first sentence should be fixed then12:16
yaccHow do I undo local commits?12:17
rexbronyacc: bzr uncommit?12:17
rexbronor revert12:17
rexbronbob2, jelmer: I think it should be changed to something like the method below: Returns (tree, branch)12:18
bob2tr -d f12:18
spivyacc: in bzr.dev, "bzr uncommit --local"12:19
spivI don't think that's in a release yet, though :(12:19
yaccspiv: Well, uncommit seems to have worked :)12:19
james_wrexbron: tree will be None if there isn't one if you hadn't figured that out yet.12:19
spivyacc: oh good :)12:20
rexbronjames_w: I think I need to refresh exactly what the difference between a branch on the file system and a workingtree (beyond different methods for those objects)12:20
james_wrexbron: i see ":return: (tree, branch)" for that method12:20
james_wrexbron: you can have a branch with no tree12:20
james_wi.e. you have .bzr/branch/12:20
james_wbut there are no files in the working directory, and there will be no .bzr/checkout/12:21
rexbronjames_w: My comment was that it could be more clearly stated, like in the other functions12:21
rexbronjames_w: ok12:21
james_wyou can get this with bzr remove-tree, or with a treeless repository12:21
bob2james_w: the furst sentence says the opposite, and I don't think it's unreasonable to assume that it should be correct also :-)12:21
james_wand it will also happen for remote trees.12:21
james_wbob2: that's true12:21
james_wrexbron: that is markup that used to denote the return value.12:21
rexbronjames_w: is the doc system supposed to format it differently that it currently is?12:22
james_wah, it appears to be spelt wrong, as other functions have it formatter12:22
=== mrevell is now known as mrevell-lunch
james_wsee open_containing_from_transport12:23
rexbronhttp://starship.python.net/crew/mwh/bzrlibapi/bzrlib.bzrdir.BzrDir.html#open_repository seemes to also have a formatting issue12:24
rexbronfor :param _unsupported:12:24
rexbronnow that I look for it, I see a lot of method docs that are (perhaps) not formatted correctly12:26
james_wyeah, they do seem to be a bit bad.12:26
james_wthe API documentation is very hit and miss12:27
rexbronjames_w: what system is being used, as I would be happy to submit patches12:29
rexbronok, looks like pydoctor12:30
sabdflis mail from the bazaar list getting doubled up?12:31
james_wsabdfl: I don't see it, you mean you receive multiple copies?12:33
rexbronIs there a page which documents the syntax for pydoctor? or is it the same as something else?12:34
james_wrexbron: I think it uses the pydoc ones or whatever they are.12:34
james_wrest markup in python docstring might get you some useful pages from google.12:35
sabdfljames_w: yes, i do get multiple copies12:35
sabdflperegrine% ./bzr pull12:35
sabdflUsing saved location: http://bazaar.launchpad.net/~bzr/bzr/trunk/12:35
sabdflbzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~bzr/bzr/trunk/".12:35
sabdflanybody know what would cause this?12:35
sabdflwhen I go to that URL I see the loggerhead page12:36
spivsabdfl: you're using bzr.dev12:36
james_wsabdfl: I think the default is for the list software not to forward it's copy to you if you are already in the to list, but it sounds like it's all mail.12:36
spivsabdfl: the fix is on the list12:36
sabdflok thanks spiv12:36
spivsabdfl: the bug is 20755812:36
spivubotu: bug 20755812:36
ubotuLaunchpad bug 207558 in bzr ""bzr branch http://bazaar.launchpad.net/...." fails with bzr.dev >= r3309" [Critical,In progress] https://launchpad.net/bugs/20755812:36
rexbronhmm, I can not seem to find what markup syntax bzr is using to generate the api docs12:42
rexbronpydoctor's site does not really mention anything12:42
spivrexbron: epydoc12:43
spiv(the ReST variant of it, IIRC)12:43
james_wrexbron: http://epydoc.sourceforge.net/manual-epytext.html12:48
james_wbut it uses : to start, rather than @12:48
rexbronya, I found that12:48
james_wit is the rest variant it uses, but that seems to suggest other markup.12:48
rexbronFrom a quick look, the reason some is being formatted correctly and others not is a lack of a blank line12:49
schierbeckjelmer: i've made the bugs tab look good: lp:~dasch/bzr-gtk/revisionview-bugs-page13:10
schierbeckwhat do you think?13:10
jelmerschierbeck: yeah, that's definitely an improvement13:16
jelmerhmm, the bug isn't clickable anymore13:17
schierbecktry double-clicking13:17
schierbecki'll fit a button in there13:17
schierbeckfor now, i removed the status string, since "fixed" is the only one supported...13:17
jelmerdouble-clicking doesn't work13:18
jelmerschierbeck: I'd rather keep it in there and make the message say something like "This revision changes the affects one or more bugs."13:19
=== mrevell-lunch is now known as mrevell
schierbeckjelmer: the status message?13:19
schierbecki think we should only do that when bzr supports more than one type13:20
jelmeryeah, or otherwise we should be making sure the status message == "fixed"13:20
schierbecki could do that13:20
jelmerotherwise if bzr supports more than one type in the future, users will get very confusing errors13:20
schierbeckjelmer: okay13:22
schierbeckjelmer: i think the bugs tab should always be visible13:23
schierbeckit's pretty confusing when ui elements magically appear on the screen13:24
jelmerI'd be fine with having it insensitive13:26
jelmerif there are no bugs13:26
jelmerbut one of the nice things now is that you don't actually have to switch to the bugs tab to see if a revision touches any bugs13:26
schierbeckjelmer: the same thing applies for signatures13:26
schierbeckbut if the user is not able to open the tab, he may think that he needs to install something13:27
jelmerschierbeck: Alternatively, we could show an icon in the branchview to indicate a revision touches bugs13:30
schierbeckjelmer: just my thought13:30
schierbecki just need a smaller icon then13:31
schierbeckcurrently i just copy-paste from the shared icons i've got lying around...13:31
schierbeckhope i don't get in any trouble13:31
jelmerschierbeck: yeah, we need to check what the license on those icons is..13:32
schierbecki'll get on it before we release, but most likely it won't be an issue13:33
ignasare there any documents on how to solve permission problems with shared repositories? i have a group stbaz that can commit to the shared repository, but it seems that after bzr push'es or bzr commits from a lightweight repos using sftp13:34
ignassome files get owned by my user13:34
ignasboth as a user and as a group13:34
InvisionfreeHi, I was just wondering, does BZR work with Kerberos?13:35
bob2it doesn't have specific kerberos support, afaik, but it would work with kerberised ssh13:36
jelmeryeah, I used it with kerberized ssh without problems13:37
jelmerkerberized ftp is not supported yet though (kerberized sftp should be fine)13:38
james_wignas: have you set g+s on the directories?13:39
ignasyes, it seems so13:40
ignaslet me check13:40
schierbeckjelmer: okay, i've pushed the changes to lp13:40
james_wignas: there's also a limitation of sftp in this area, bzr+ssh will serve you better.13:41
ignasjames_w: oh, i see, do i need to do something special? or just replace sftp with bzr+ssh and that's it?13:41
james_wignas: you need bzr installed on the server13:42
james_wbut otherwise probably not13:42
ignasi see13:42
james_w(the exception would be if you had bzr installed somewhere outside the $PATH on the server)13:42
ignasit's in $PATH13:42
ignasby the way - is there a way to get something like a lightweight checkout13:43
ignasthat would not need network connection13:43
ignasfor bzr status or bzr diff13:43
james_wbzr checkout --lightweight13:43
ignasi am using --lightweight13:43
ignasbut every operation like bzr st or bzr diff seems to be connecting to the server13:44
james_woh, not need network connection, sorry.13:44
bob2that's the 'lightweight' - most stuff is on the server13:44
james_wyou can use a normal, non lightweight, checkout.13:44
ignaswell - i want a compromise13:44
ignassomething that is not 70mb13:45
ignasand does not need network to tell if i have changed a file13:45
ignaslike with svn ;)13:45
james_wthat puts all of the data on your local disk, but pushes it to the server when you commit, so you only need network access for write operations.13:45
Pengignas: There is nothing like that yet.13:45
ignasi see13:46
Pengignas: All or nothing.13:46
bob2how far along are lifeless's shallow branches?13:46
* Peng points out that 70 MB isn't huge.13:46
james_wbob2: quite close I think, it's just a case of making everything "stackable-on"13:46
james_wthe smart server for one thing I think13:47
bob2hopefully 1.4 then13:47
jelmerschierbeck: I think the message in the bugs tab should say "This revision fixes one or more bugs." since we're not showing the status anymore13:48
abentleybob2: They aren't shallow branches.13:48
schierbeckjelmer: i'm editing it as we speak :)13:49
bob2abentley: oh13:49
abentleyThey're not intended to allow you to work when the source branch is unavailable.13:49
schierbeckjelmer: should we use "fixes" or "claims to fix"?13:50
abentleyStacked branches are mostly a storage optimization.13:50
bob2sounds about equivalent to co's bound to a shared repo?13:51
schierbeckjelmer: for now i'll go with "claims to fix", as we don't really know13:52
abentleyWell, stacked could let you create a checkout of emacs without downloading all its revisions.  And diff/status would be zippy.  But log would not be.13:54
bob2ah, of course13:56
jelmerschierbeck: yeah, claims to fix sounds fine14:04
abentleyIn a true shallow checkout, non-local revisions would be handled as ghosts, so log would be speedy but short.14:06
brongerIs "bzr branch" identical to "bzr init" + "bzr pull"?14:07
TFKylebronger: I wouldn't think so, but I could be wrong14:12
brongerThe background of my question is: If I want to update a remote SVN repo, I can create a branch of it locally, merge the new changes and pull it back.  Would it be different in any way if I pulled it to an empty revisioned directory first?14:21
brongerSorry "... push it back"14:22
gioelewhat is a "submit branch"?14:28
gioeleis it another name for a "push branch"?14:28
brongergioele: It may also mean a commit in the branch is bound.14:31
bronger"... if the branch is bound"14:32
=== kiko-zzz is now known as kiko
gioelebronger: bzr info in a bound branch (a checkout) says14:33
gioele  light checkout root: .14:33
gioele   checkout of branch: http://...14:33
gioeleis that the submit branch?14:33
james_wbronger: init + pull is the same as branch, yes.14:35
gioeleah, the submit branch is the location where "bzr send" sends changes14:36
brongerjames_w: Thank you!14:43
gioeleis there a revspec with the meaning "last time it was changed"?14:45
gioeleFor example, current revision is 20 and file foo has been modified at revision 12 and 8. Is there a revspec that I can use instead of 12 and 8 in "bzr diff -r 8..12 foo"14:45
PengThat would be useful, but I don't know of one.14:46
PengThe docs list all the types of revspecs.14:46
* Peng goes back to bed.14:46
schierbeckjelmer: ping14:47
jelmerschierbeck: pong14:47
schierbeckjelmer: do you think we should rename the "Signature" tab to "Authenticity"?14:47
james_wgioele: I don't think there is one.14:47
schierbeckafter all, that's really all it's about14:47
jelmerschierbeck: We need to verify the testament first14:49
jelmerschierbeck: but otherwise, sounds fine to me14:49
schierbeckjelmer: yeah, i was gonna ask that, too14:51
antoranzHi, guys!15:10
antoranzI was merging the changes from another branch yesterday (both local FS branches) and I got an error and don't know if It's a bug in bazaar15:11
antoranzI had made a post in linuxquestions but nobody replyed to it, that's why I looked if there was an IRC channel... and so I'm here.15:12
gioeleantoranz: link?15:13
antoranzthe post is here: http://www.linuxquestions.org/questions/linux-software-2/problem-with-bazaar-632262/15:13
bob2in future, I'd say that posting to the list is a lot more likely to find someone who knows bzr thatn linuxquestions :)15:13
gioelelist = mailing list on bazaar-vcs.org15:13
bob2someone reported almost that exact error yesterday15:14
bob2bzr in gutsy?15:14
antoranzmmm........... yes, it's gutsy15:14
gioeleI think this deserves a bug at https://bugs.launchpad.net/bzr/+filebug15:16
=== mw|out is now known as mw
james_wthere's already a bug for it I think15:17
bob2try upgrading (add 'deb http://ppa.launchpad.net/bzr/ubuntu gutsy main' to /etc/apt/sources.list, 'sudo aptitude update', 'sudo aptitude dist-upgrade')15:18
james_wI don't think it's fixed15:18
bob2ah, ok15:18
bob2I forget the conversation yesterday, but did -q workaround?15:19
antoranzwhat's the problem? My use of "á" in the directory name or something?15:19
antoranzcause I haven't had a problem so far with it in the branch where I created it committing to it.15:19
antoranzis that repository stable?15:20
james_wbob2: I think this is a different location to yesterday's15:21
ubotuLaunchpad bug 135320 in bzr "bzr merge - exceptions.UnicodeDecodeError" [Undecided,New]15:22
antoranzI'll append my info to that bug.15:23
antoranzThe bug a little old though15:28
antoranzanyway... I've already appended my trace to it.15:29
gioeleHow do you debug bzr plugins?15:30
gioeleIs there a way to make the plugin hook the eric debugger at a certain point? Any other IDE is OK15:30
antoranzI'll try changing the name of the directory to see what happens15:31
antoranzF***! It failed when I tried to commit the mv15:32
antoranzall I did was: $ bzr mv doc/Cities/Bogotá/ doc/Cities/Bogota15:33
ignasPeng: by the way - if 70 mb is not much, why is it taking ~30 minutes or more tu make a branch :/ how long does it take with "much" ;)15:38
james_wantoranz: can you pastebin the traceback you get for that please?15:39
james_wgioele: what I normally do is edit the source and add "import pdb; pdb.set_trace()" where I want it15:40
james_wif the problem is a plugin not loading then ~/.bzr.log will have the error.15:40
gioelejames_w: is there an API documentatio for bzrlib?15:41
antoranzI'm filling for a new bug including both bugs in https://bugs.launchpad.net/bzr/+filebug. Want to see it?15:41
james_wgioele: sort of yes15:41
antoranzHere it is: https://bugs.launchpad.net/bzr/+bug/21083815:42
ubotuLaunchpad bug 210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New]15:42
antoranzthat was fast! :-D15:42
james_wthere's also http://bazaar-vcs.org/Integrating_with_Bazaar15:42
james_wantoranz: he responds to what you say15:43
james_wthey'll be the new bug notification in a minute or two15:43
bob2ignas: btw, cp -r is a valid way to branch a standalone branch to anothoer standalone branch15:44
ignasbob2: i know, but cp -r does not work if your branch is on launchpad15:45
antoranzignas: that was good!15:45
ubotuNew bug: #210838 in bzr "Problems with non-ascii characteres in names" [Undecided,New] https://launchpad.net/bugs/21083815:51
antoranzI'll try the repository you provided mye with... hold on to your butts. :-)15:55
antoranzhell! I tried to commit just like that and it "added" the directory (didn't move it)15:58
antoranzI just checked the repository and I have 5 inconsistent parents15:59
antoranzhow do I get rid of those "parents"?16:00
schierbeckjelmer: what do you think about a "Tags" page in the revision view? i think it would boost the discoverability.16:05
schierbecki know they belong in the branch, but to the user who wants to add a tag to a revision, it's natural to select that revision in the viz and go from there.16:05
jelmerschierbeck: tags are already shown in the revisionview, in the main tab16:06
schierbeckjelmer: yeah, but i'm thinking more like a treeview, where you can "rename" and add tags16:06
antoranzcan I delete .bzr/branch/lock so I get rid of the lock on the repository?16:07
schierbeckjelmer: the current ui doesn't allow for deleting tags in the revisionview16:07
antoranzI've already done it, so I think it's safe, right?16:07
jelmerschierbeck: yeah, makes sense16:08
schierbeckjelmer: let's get the bugs and signature page branches merged first, then i'll refactor the revision view and go from there16:08
abentleyantoranz: You're supposed to use the bread-lock command.16:09
schierbeckjelmer: do you think there's anything missing from those two branches? i've already sent a mail to the tag icon artist16:09
antoranzI've should know better, wasn0't I? after I removed the lock (by deleting, by the way :(), I was able to commit into the stable branch even with the names with non-ascii characters16:10
antoranzmy godness... what a gramatical mess did I write! :-D16:10
jelmerschierbeck: the signatures branch disables the signature tab16:10
jelmerschierbeck: but that still says "this revision has one or more signatuers"16:10
schierbeckschierbeck: huh?16:11
jelmerschierbeck: that's all I can think of right now16:11
schierbeckjelmer: the seahorse-integration branch?16:11
schierbecki think that's the one we should ship16:11
antoranzI think my repository got completely busted (both the stable and the development one... as a matter of fact, I deleted the developemt one and can't branch from the stable)16:17
antoranzI just noticed I lost quite some hours of work goys16:18
antoranzsay-.... 2 days of work16:20
kohwjhi, can i get bzr serve to prompt clients for a password?16:21
antoranzthere's something strange going on here.16:23
antoranzI was able to commit the changes brought from the development branch in the stable branch.... I can see the diffs applied16:24
antoranzhowever, there are not "efective" in the physical files of the stable repository16:25
antoranzthey, I mean16:25
schierbeckjelmer: okay, i've sent in the merge requests16:46
schierbeckonce they're approved, i'll start refactoring the revision view16:47
gioeleschierbeck: olive? gtk?16:48
schierbeckgioele: bzr-gtk16:49
schierbeckthe bottom part of the viz16:49
gioeleI love viz16:50
gioeleHow do I get the arguments passed to bzr from my RevisionSpec?16:51
ignaswhy is bzr push to a remote repository is a mega pain? and what should I do instead?16:52
snodunter linux siehts auf jeden fall anders aus16:53
ignasi checkout the "trunk", checkout the branch, bzr merge the branch into the trunk, and am trying to bzr push the mainline back so everyone (especially our mega release tools) would see the changes...16:53
ignasbzr push seems to be taking ages16:53
ignaseven though there was only 1 small change made to the trunk16:54
bob2are they the same branch formats (should be unless you use a shared repo)16:58
ignashmm, ok it seems that it was taking so long because it was synchronizing the fact that i have enabled tags on the remote repository16:58
ignasi am using a shared repository16:58
ignasfor my remote branch16:59
ignasbecause all the release branches will be stored in the same location16:59
ignasbut yes, now that the first push got through it is bearable (takes only 10-20 seconds)16:59
ignaswhat can I do about "Value "bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/" is masked by "bzr+ssh://bazaar.launchpad.net/%7Eignas/schooltool/lyceum/" from locations.conf"?17:02
ignasand where is that locations.conf thing?17:03
ignasi have tried doing "bzr push --remember bzr+ssh://schooltool.org/var/local/bzr/schooltool/lyceum/trunk/"17:03
=== kiko is now known as kiko-afk
* gioele wonders when bzr will conform to XDG Base Dir spec17:07
ignasemm, why is it there? and why is it overriding parameters i am passing through command line?17:08
ignasi mean - maybe there is a reason, and i am doing something wrong...17:08
gioelethat file is used for the parameters that you didn't specify on the cmd line17:08
ignasso when i do "bzr info"17:09
ignaspaths are taken from that file17:09
ignasnot from some place in .bzr ?17:09
luksignas: old branch formats used to save it to locations.conf, new formats use .bzr/branch/branch.conf17:09
ignasoh, i see17:09
ignasso i should upgrade my branch and remove that file?17:09
luksif it was complaining about masked location, your branch is probably already upgraded17:10
luksyou can just remove the branch from locations.conf17:10
schierbeckjelmer: ping17:24
jelmerschierbeck: hi17:24
schierbeckjelmer: i've got permission to use the tag icon17:25
schierbeckcan i get you to review the merge request?17:25
jelmeryeah, just give me a few minutes17:25
ignashow do i convert a branch into a checkout?17:27
schierbeckignas: bzr help bind17:28
ignasschierbeck: thanks17:29
=== schierbeck is now known as schierbeck_afk
=== Peng__ is now known as Peng_
eddyMulhow do I "un-add" files?18:21
eddyMulantoranz: ah! thanx!18:26
antoranzif you haven't commited18:26
eddyMulantoranz: no, I haven't.  :)18:27
antoranzthere you go then.18:28
=== weigon_ is now known as weigon
gioeledoes the mailing list accept mails from Gmane?19:01
ubotuNew bug: #210938 in bzr "bzr status -v should show also non-modified files" [Undecided,New] https://launchpad.net/bugs/21093819:16
james_wgioele: I don't know. The list is moderated, so it might be that.19:29
gioelejames_w: no, it passed fine. Maybe Gmane is a bit slow today19:36
=== mw is now known as mw|food
james_wah, ok19:39
bialixhi, I have question about merge.py20:02
bialixabentley, may I ask you about merge.py?20:05
bialixthere is Merger, Merge3Merger and others20:06
bialixit seems like Merger is main of them20:06
bialixit's correct?20:06
abentleyYes.  It's been suggested that Merger should be renamed to MergeController.20:06
bialixso, it's always created Merger instance for merge operations?20:07
abentleyYes.  It's not required, but I believe all callers do go through Merger.20:08
bialixmy actual question is: where I should put my code for support merge of file properties20:08
=== mw|food is now known as mw
bialixis it Merger correct place, or Merge3Merger?20:09
abentleyProbably in Merge3Merger.20:09
bialixi.e. actual merge done in Merge3Merger, right?20:09
abentleyYes, the actual operation is handled by Merge3Merger or a subclass.20:10
bialixall other merge types is subclased Merge3 as I could see.20:11
bialixokay, thank you.20:11
=== kiko-afk is now known as kiko
abentleyeddyMul: More specifically, you use "bzr remove --keep --new".  That will avoid reverting any other changes.20:19
eddyMulabentley: I used `bzr revert specific_files`, and it worked for me.20:23
eddyMulabentley: judging from `bzr help remove`, it appears like `bzr remove --keep --new` is the like the "anti" of `bzr add`. Very handy. Thanx!20:24
james_whi bialix, Verterok20:31
bialixhi james_w20:32
james_wbialix: sorry I haven't had a chance to look over your file properties mail yet20:32
bialixit seems like nobody have this chance yet20:33
bialixthere was a lot of people who cry without line-endings support20:33
Verterokjames_w: hi20:33
james_wbialix: yeah, it would be great to have.20:33
bialixthey already worked20:34
bialixI need only to beat merge and to teach it write files to disk with proper eol20:36
bialixabentley: Merge3Merger.__init__: has arguments working_tree, this_tree, base_tree, other_tree -- what's difference between working_tree and this_tree? it's not the same?20:39
abentleythis_tree is the input tree that you read from in order to calculate the merge.  working_tree is the output tree that you write the changes to.20:41
abentleyThey are commonly the same, but this_tree is sometimes a RevisionTree.20:41
bialixin which case?20:42
bialixI see in constructor's code:         self.this_tree = working_tree20:46
bialixand it seems like this_tree argument is not used actually20:46
bialixso I'll ignore it.20:46
abentleyDon't be a jerk.20:49
james_wabentley: as far as I can see the "this_tree" argument to Merge3Merger is not used in Merge3Merger.__init__, and none of the subclasses in the same file override __init__.20:55
db-keenWhy can't I bzr mv from one branch in a repository to another?20:55
james_wso is it just there in case a subclass wants to?20:56
mwhudsondb-keen: because bzr is not like subversion?20:56
abentleyjames_w: WeaveMerger used to do that, and future mergers may also do that.  It's quite likely to be a performance win.20:56
james_wah, ok, thanks20:56
=== Toksyuryel` is now known as Toksyuryel
pooliedb-keen: well it's more complicated for us than for svn20:56
pooliewe should make it possible20:56
gioeleis there a way to have "external" branches inside a branch?20:56
james_wabentley: I think your reaction might have been a bit strong then, but maybe I misread it20:57
db-keenI'm trying to take a project and split it into smaller branches, what's the best way to do this?20:57
james_wdb-keen: are you splitting on directory boundaries?20:58
abentleyjames_w: If writes to this_tree or reads from working_tree, I'll veto his patch so fast his teeth will shake.20:58
db-keenmy initial reaction was to create new branches and move stuff from the old large one into these new small ones, but obviously that doesn't work20:58
db-keenjames_w: mostly20:58
james_wdb-keen: there's a split command that may help20:59
james_wabentley: but the default mergers read from working_tree?20:59
abentleyThey read from this_tree20:59
james_wabentley: they read from self.this_tree, which working_tree is assigned to in the constructor21:00
abentleywhich is entirely different.21:01
pooliethumper: hi, are we meeting now?21:02
thumperpoolie: yeah21:02
james_wabentley: well, I don't still fully understand, even with the extra discussion, so I still think your response was too strong.21:02
abentleyjames_w: think what you like.  When people ask me for advice, I expect them not to ignore it.21:06
datojames_w: I guess that the API/contract is that you read from this_tree, without caring what gets assigned to it before. or so. from my limited understanding. :)21:08
abentleyThey may decide that they don't agree, or that it doesn't apply.  But it's not okay if they just ignore it.21:08
james_wI read his statement as ignoring this_tree, just like the existing code does, not ignoring your answer, but I don't know what he meant21:09
abentleyThe existing code does not ignore this_tree.21:10
james_wmaybe I am wrong to say ignore, but the this_tree parameter passed to Merge3Merge.__init__ is unused as far as I can see. This may well be because working_tree fulfils the contract of this code just as well as this_tree.21:14
abentleyWe're not talking about constructors, so when you say this_tree, I assume you mean self.this_tree21:20
james_wsorry for the misunderstanding then, I tried to be clear that I was talking about this_tree passed to the constructor as opposed to self.this_tree21:23
abentleySo it looks like the Merge3Merge constructor is a bit broken.21:25
hmeland_Regarding the "fix botched log-message" discussion: Does any of the storage mechanisms actually have an API for "turn revision X into a ghost"?21:26
abentleyIt's probably due to the shuffling around we did to enable merge previews.21:26
abentleyhmeland_: No, all of our formats are append-only.21:26
abentleyYou would need to create a new repository, and not add those revisions.21:27
hmeland_In principle you could repair revision X by adding a X' (which has X and the parent(s) of X as its parents) with the fix, convert X into a ghost, and repeat for all revisions that are descendants of X.21:32
hmeland_But without an easy way to do the "convert X into a ghost" step, that sounds somewhat cumbersome.21:33
hmeland_The approach might also have bad (performance) implications for e.g. merge, especially if such fixing were to be as common as I gather git's "commit --amend" is.21:35
james_w"commit --amend" only works for the tip of the branch, and is another form of rebase.21:37
hmeland_Ah, good.21:37
james_wI think there are two cases being discussed, one is the "nuclear launch codes" and the "abusive commit message" case, and the other is the "spelling mistake case"21:38
dato"abusive commit message"?21:39
james_wthe latter could be solved by just adding a note somewhere saying "when displaying it, set the message of X to Y"21:39
james_wdato: it's an example from the list of where there was evidence of sexual harrasment in a commit message.21:39
datooh, wow, I missed that21:39
hmeland_james_w: I think *abusive* commit message is a form of nuclear launch codes, actually.21:40
james_whmeland_: yes, it is, but I was just using the two examples from the list discussion.21:40
hmeland_OTOH, an *incorrect* commit message might be solvable in the way you describe.21:40
james_wfor the former you need to remove X from history so that it is unreachable.21:41
james_wso this could either be a rebase type operation, or introducing a ghost, both of which have their issues.21:41
hmeland_Yes.  Both NLC and ACM goes in the former category, to my mind.21:42
hmeland_The nice thing about the ghost-introduction solution is that other existing branches would still be related to the original branch.21:43
hmeland_You might have to take care that merges from any such branches didn't re-introduce the ghosted revisions, though.21:44
james_whowever, currently ghosts have no information whatsoever, not even their parents, which means that you can't get at the history previous to the ghost.21:44
james_wand it would also be information disclosure, which some people in some circumstances wouldn't accept.21:45
=== schierbeck_afk is now known as schierbeck
hmeland_If you branched from revision Y, which has now been converted into a ghost, there will be a new revision Y' in the source branch, whose mainline history will take you all the way back to before the fixed revisions.21:46
james_whmeland_: no, when you branch you are based of Y still21:47
james_wit's not like svn where you have to make a commit to start a branch.21:47
james_wbut you are right, I think care would have to be taken not to get unwanted ghosts again when merging.21:47
hmeland_Yes, that's what I'm saying.  In the *source* branch there will be a Y'.21:47
james_whmeland_: ah, in your proposal for creating Y' from Y, sorry21:48
james_wthere would be the peverse case where you made Y a plain ghost, as now you can't do 3 way merging as you can't get the text from the base revision.21:49
lifelesshmeland_: the conversion of X's descendants to X''s descendants will not propogate21:52
hmeland_james_w: Right, you'd have to pull before merging, I think.21:52
hmeland_lifeless: In the case of multiple fixes, you mean?21:53
hmeland_X' will have (X + parents(X)) as parents.  X'' will have (X' + parents(X')) as parents.21:54
james_whmeland_: you can't pull before merging, if you have diverged then pulling is not allowed.21:54
james_whi lifeless21:54
lifelesshi james_w21:54
lifelesshmeland_: no, I mean in the case of having more than one repository which needs the correction done21:55
lifelesshmeland_: all other repositories will have the original X as their semi-ultimate descendant21:55
hmeland_Not X, but the tip of the branch X was in when X was fixed, I think?22:00
hmeland_But yes, ghosts do not propagate.22:00
schierbeckjelmer: ping22:04
jelmerschierbeck: pong22:04
schierbeckI've fixed the remaining issues with the Seahorse integration branch, and I've sent in an updated merge request. Could I get you to take a look at it?22:05
lifelesshmeland_: and neither does the conversion to 'fixed' revisions, only the ones actually fixed will propogate22:11
schierbeckwow, apparently you can be allergic to electricity...22:15
schierbeckthat's pretty f****d up!22:15
jelmerschierbeck: Iyou don't appear to be catching the errors if there is no seahorse interface22:17
schierbeckjelmer: have you tested it? i check for the seahorse service name22:19
schierbeckif seahorse is installed, the object paths and interfaces should be there22:19
schierbeckit worked when i uninstalled seahorse...22:19
hmeland_lifeless: Assuming a mainline-only history: If you actually fix revision 2 by introducing 2' (with 2 (now ghosted) and 1 as parents), and "fix" revision 3 by introducing 3' (with 3 (now ghosted) and 2' as parents), wouldn't a branch at e.g. 3 doing a pull cause both 2' and 3' to propagate?22:20
jelmerschierbeck: ah, I missed that - sorry22:20
schierbeckjelmer: :)22:20
jelmerschierbeck: any chance you can make two more changes?22:20
jelmerschierbeck: I'll reply to the email22:21
schierbeckjelmer: which?22:21
lifelesshmeland_: a new branch from 3' will take 3' of course. But *all* the other existing branches won't be fixed.22:27
james_wI think the suggestion is to mark some ghosts as propagating, so the next merge or pull will fix them22:28
hmeland_james_w: That's not what I'm suggesting; I'm just trying to understand if the algorithm I suggested above might be a viable starting point for the requested functionality.22:30
james_wah, ok, sorry22:31
lifelessthe general thing here is that revisions are immutable22:31
lifelesshaving efficient, safe trustable mutable revisions is possible, buts its a lot of complexity22:32
lifelessyou basically need a meta-timeline for versioning revisions too22:32
hmeland_If you the requires-fixing revision is present in branches you don't control, I'm leery of trying to propagate the fix to them automatically.22:32
hmeland_lifeless: Yeah.  So I'm trying to see whether the "convert to ghost and add alternative timeline" approach could get us at least some of the benefits without all the complexity.22:37
hmeland_Anyway, thanks for the input, I guess I'll sleep on it and see if I can come up with something.22:40
xma'lo #bzr22:52
schierbeckjelmer: okay, i've sent in yet another iteration22:55
schierbecki've also contacted the author of the bug icon22:56
jelmerschierbeck: ah, thanks23:02
jelmerschierbeck: (wasn't strictly necessary btw, I voted bb:tweak)23:02
xmais it me or the proportion for BB to be unavailable is increasing day after day ?23:04
jelmerit's been months since I've seen bundlebuggy downtime for bzr.dev23:05
yaccHmmm, does anyone maintain a bzr branch of the current Python code?23:15
yaccI'm not completly sure if branching the svn URL would be a very enjoyable experience.23:15
jelmeryacc: it's not too bad with 0.4.923:17
radixyacc: you mean CPython? I'm pretty sure I've heard others talking about such a thing, but I'm not sure where.23:20
mwhudsonyacc: you mean like http://www.python.org/dev/bazaar/ ?23:20
yaccjelmer: you are trying to sell me on going back to using a released version of bzr-svn ;)23:25
jelmeryacc: :-)23:26
jelmeryacc: If performance or reliability matters to you, you should be using a release23:26
jelmerperformance certainly matters for the python repo, given its size23:26
yaccjelmer: does it support bzr 1.3?23:26
jelmeryacc: yep23:26
yaccjelmer: And I ended up using a trunk scheme, so I guess this should work too?23:27
bob2yacc: http://www.python.org/dev/bazaar/23:27
jelmeryacc: yep23:28
bob2oh, oops, too slow23:28
mwhudsonbob2: well, maybe he'll tell _you_ why that isn't what he wants :)23:37
jelmerbob2: what's too slow?23:45

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