/srv/irclogs.ubuntu.com/2012/07/30/#bzr.txt

=== jam1 is now known as jam
jelmermoin07:32
mgzmorning!08:12
jelmersup mgz!08:12
vilahi all !08:13
mgzjam around yet today?08:17
jelmerhe was around in #-kitchen earlier08:17
mgzace.08:20
jammgz: /wave08:21
jelmermgz: do you still happen to have the PQM output for merge-grep?08:44
mgzforwarded08:48
mgzand you have too many email addresses with no obvious pattern for when you use which ones :)08:48
jelmermgz: gracias :)08:50
PengSolution: CC all?08:51
Peng:)08:51
jelmermgz: hmm, there are also a bunch of tests that fail in a different locale09:05
mgzhm, I'll branch and see09:05
jelmerI'm running with spanish here - it at least appears to have enough things translated09:06
mgzyou're learning spanish?09:06
jelmermgz: different computer :)09:07
jelmerlaptop is German, desktop is Spanish09:07
jamjelmer: IIRC lifeless was using Latin for a while09:16
jamthat, and vila tried to use French, but found it too confusing09:16
vila:)09:16
* jelmer chuckles thinking of vila being confused by French09:17
vilayup, same here ;)09:18
vilatruth is, to clear confusion, the best way for me is often to translate back to english...09:19
jelmervila: do you "think" in English when you speak it, or do you translate back to French mentally?09:20
vilajelmer: I'm at the point where I sometimes think in English but need to speak in French ;)09:21
vilafamily hate that ;)09:21
jelmer:)09:21
vilamostly depends on the topic discussed09:21
vilaso, for technical matters, I often don't know how to translate idiomatically09:22
vilabut people around me are helpful ;)09:22
jelmerheh09:27
vilamgz: ping me when you're ready to discuss some resolve proposals of yours09:52
mgzping!09:52
vilaI'm looking at the introduction of the auto action and I09:55
vilameh09:55
vilaI'm not sure I agree09:55
vila--done seems fine to me to include what you put in --auto09:55
mgzwait, which one?09:56
* mgz went a bit overboard with different branches09:56
vilaI'm back to resolve_auto_refactor09:56
mgzokay09:56
vilaback to the basics: merge creates a conflict because bzr cannot decide which action is required09:56
vilaresolve should be taught to recognize that the user did something and the conflict is not there anymore09:57
vilathat's what '--auto' seem to do in your proposals09:57
vilabut in fact, I'd prefer that --done cover that09:57
mgzso, really 'auto' here is "I've done some changes to the tree, have another look and see if you still think there are conflicts"09:58
vilai.e.: the context has changed, bzr does not see a conflict anymore, the conflict object can be deleted09:58
vilayup09:58
mgzwhich is mostly what people want09:58
mgzbut --done is still needed09:58
vilawhen ?09:58
mgzotherwise, how for instance, with a conflict that involves a deletion09:59
mgzdo you say "no, really, keep it"09:59
mgzdeleting the object and --auto works, you clearly want the deletion to stick09:59
vilasay that again in commands executed by the user ?10:00
* vila tries to get it10:00
mgzbut there's nothing to distinguish "haven't decided if I want this object still" and "want to keep the object"10:00
mgzeg, I delete d/10:00
mgzyou add d/f10:00
mgzI merge your branch10:00
mgzget a conflict on d/10:01
mgzfilesystem looks like [d/, d/f]10:01
* vila nods, that's 'merge' this specific case10:01
mgzif I want my change to stick, I delete d/ (and maybe move d/f somewhere else)10:01
mgzif I decide against deleting d/ because you're now using it, I need bzr resolve --done d10:01
mgzI don't see a neater way out of that10:02
vilawhat does --auto does in this case then ?10:02
mgzwe could alos move d/ to d.conflicted/ and make the user delete or move it back10:02
mgzbut that doesn't seem easier.10:02
vilathe key is that an action should automate what is manual otherwise, --auto sounds a bit like 'just do the cleanup' which --done is already targeted at10:03
mgzthere's also the "my file has the line '=======' in it" case10:03
vilaand preferably the action comes in two flavors: favor this or favor other10:03
mgzauto is bascially just a generalisation of `bzr resolve` which is pretty much all I ever use10:04
mgzit's unlikely to ever be passed in, it's just a good safe default10:04
vilastill sounds like a variation of --done rather than a different action10:05
mgz--done is by definition not safe10:05
vilayup10:06
mgzit's a shut-up-and-believe-me option10:06
vilathat's what the thread was about IMHO: make it safer10:06
mgzokay, so I disagree10:06
vilawhen in doubt, requires --force10:06
mgzwe still need the unsafe option10:06
vila--done --force10:06
mgzand I don't see the benefit of `resolve --done` and  `resolve --done --force` over using `resolve --auto` and `resolve --done`10:07
vilamay be we just disagree on the name10:07
vila--auto sounds magical: do the right thing (including actions like deleting a file or add'ing it or whatever)10:07
mgzthey're clearly different options, --done already does the right thing, our auto logic already does the right thing just isn't exposed as a flag10:07
mgzwe can name auto whatever, I doubt anyone will ever actually pass it, it's just the default10:08
mgzit's auto in the existing code is all10:08
vilawhat triggered my question is that you modified existing tests by adding --auto, as if the default behavior (or command-line option default value) has changed10:09
=== zyga is now known as zyga-afk
mgzright, the whole point is to change `bzr resolve FILE` to be 'safe'10:09
mgzbut then go back around and make `bzr resolve FILE` still do the right thing10:10
mgz(by making auto smarter)10:10
vilastill blurry10:13
mgzI need to write up some user story type things for the list really10:13
vilasome conflicts just can't be "checked" without asking tree-transform to rebuild the conflicts10:13
mgzit doesn't help that a lot of the conflict cases we have are bugs at about three different levels10:13
vilayeah, hard stuff10:14
vilaalso, action_* in conflict objects should *always* use a tree transform10:14
mgzlike... not having precious/junk distinction, switch being unsafe, doubling conflicts on deleted directories...10:14
vilaI made the mistake in the past of using direct actions, that's not robust and may introduce subtle failure modes10:14
vilayeah, lots of entangled stuff10:15
mgzas in, the ones using tree.remove are wrong?10:15
vilayup10:15
vilathere are still some left right ?10:15
vilabah, better check myseflf10:15
mgzyup, and I added a another one because I couldn't work out how to change state 'missing' to unversioned/gone10:16
mgzbasically just want to remove the file_id from the inventory but couldn't find a good way of doing that10:16
vilaright, DuplicateEntry is wrong and should be rewritten10:16
vilaright, so tt.unversion() or something10:17
vilatree.revert may be ok (if it relies on tt under the hood)10:17
mgzunversion checks that the file exists10:17
vilaurgh10:19
vilaerr, are you sure you don't just need to register a trans_id ?10:20
mgzno, not sure, I didn't try using a tree transform.10:21
vilaright, then that's an example of why tt should be used ;)10:22
vilahmm, I wonder if just building a tt against the current working tree will get rid of the conflicts already resolved by the user...10:24
mgzhm, and there is a bug in the current auto resolve logic, though earlier than I thought:10:24
mgz<http://pastebin.ubuntu.com/1119180/>10:24
vilawith a pristine bzr.dev  ?10:25
mgzyup.10:26
vilahmm, sounds like a fallout from a very old fix, here, kind() should just returns None (if the file does not exist anymore, it's kind is None)10:27
mgzand a similar one with bzr rm rather than rm: <http://pastebin.ubuntu.com/1119185/>10:27
vilagreat :-}10:29
vilaworth fixing10:29
* vila still paging in context10:30
mgzokay, so I think that check wants to be `if not tree.has_id(self.file_id) or tree.kind(self.file_id) != 'file': return`10:32
mgzin otherwords10:32
mgzwe have a conflict in a text file10:32
mgzif the user has removed the file - it's resolved, they deleted it10:33
mgzif the user changed the file into a symlink or directory - it's also resolved, it's not text any more10:33
mgzotherwise we peek at the bytes on disk looking for conflict markers, if they're gone, it's resolved10:34
mgzotherwise we should raise ConflictUnresolved or whatever we go for over NotImplementedError10:35
mgzideally with contenxt like line number10:35
vila"not text anymore" and we never try to keep the file-id when the kind changes, it makes no sense10:37
* vila agree with ConflictUnresolved of StillThere or whatever10:38
vilacoming back to the internal 'auto' action"10:38
vilas/"/:/10:38
vilawhen I started working on 'resolve' I first thought that it should have been called 'resolveD'. Then I started added actions which made 'resolve' get some meaning10:39
vilabut really, 'done' and 'auto' (as internal actions) are still in the 'resolved' realm10:39
vilawhich is also part of my reluctance to accept --auto as an action from the user pov10:41
vilain fact, the idea while discussing with poolie at the time was that the user should never have to issue 'bzr resolve --auto FILE' because other parts of bzr will have taken care of the conflict10:42
vilaanother way to look at it is that if --done cannot clean up safely, the user still have to do something.10:43
vilaIf there are multiple choices there, --auto won't be able to decide10:44
vilait's ok for the conflict markers because there is a single possible action: remove the markers10:44
vilabut I fear it won't be true for all conflicts10:45
mgzhm, `bzr resolve -d g g/f" ... does not work10:45
mgzthe path is taken as relative to the repo10:45
mgznot cwd.10:45
mgzis that the normal form for -d?10:45
vilaha ha, and that's not mentioning multiple conflicts that can interact and should be resolved in the proper order :-}10:46
vilaregarding -d, I think you've just entered unexplored territory :)10:46
mgzokay, I agree there's a lot of mess in resolve currently10:47
vilaright, which is why I'm unclear about whether --auto is legit or would just add to the confusion10:48
mgzbut... the current state is we have a number of broken common cases10:48
mgzwhich are not actually hard to fix, and the code basically supports doing it in a sane manner10:49
vilain other words: if you were talking about enhancing 'resolveD' I'll be +1, for 'resolve'... it's less clear10:49
vilabut the content of your auto_* methods are certainly valuable10:50
mgzI don't see the benefit in the kind of procrastination over details, like in that bazaar mailing list thread10:50
vilaright10:51
mgzwhen we can just make the code a bit better and get most of the pain resolveD10:51
vilaright too10:51
vilahow about just rewriting auto_resolve then and don't touch the command itself yet ?10:51
mgzI'm not attached to the name 'auto', but the behaviour from `bzr resolve` is useful and is worth generalising10:51
vilaseem we are in agreement ?10:52
mgzdoing that takes me back to this just being a code refactor10:52
vila'that' 'this' /me lost :)10:52
mgzwithout also making auto understand when other kinds of conflict are done with, we need the unsafe --done or --all far more often10:53
mgzso the extra pain of requiring that isn't worth the interface breakage for users10:53
vilaso you still agree with turning auto_resolve into conflict.action_auto kind of refactor ?10:54
vilathat may not be enough to address all multiple conflict cases but neither does the actual code10:55
mgzyes. there's a nice mechanism for removing conflicts, using that rather than having a seperate method on tree clearly makes sense.10:55
vilagreat10:55
vilalunch here but after that I'm still available to discuss or even help writing tests and/or code10:56
mgzI understood 'just rewriting auto_resolve' as you not wanting bzrlib/conflicts.py touched.10:56
mgzjelmer: so, I didn't get any different failures in another locale with -d bp.grep, do they only show up when the other failures are fixed? or can you give me a test that fails and the traceback?11:03
jelmermgz: those were other bzr tests11:19
mgzokay, will do a full test run over lunch11:25
vilamgz: back, indeed, I do want to pursue the efforts in conflicts.py11:28
mgzokay, bb.test_debug.TestDebugBytes.test_bytes_reports_activity is broken11:30
mgzneeds to either not install translations or not check for the english string11:30
mgzI expect there are a few others like that11:30
vilaa way to force english messages (as expected by tests) sounds like a useful resource11:31
mgzwe've got one :)11:32
mgzI assumed all the blackbox tests used it, but apparently it's just some of them11:32
jamjelmer: is it ok if we push back our call by a couple of minutes?11:33
jamlike at 2:30?11:34
jam(I have a 3:30 with Francis, so I still need to finish on time.)11:34
mgz...I thought Francis was on holiday still?11:35
jammgz: I think he is in Isle of man this week, and he was still hoping to get ahold of me11:35
jamat least, he still has our meeting scheduled11:35
mgzah, yes, that might be it.11:35
jammgz: it is possible that *next* week is Isle of Man, though.11:36
mgzI think it's this week, but then he's off next week as well.11:36
jamjelmer: anyway, I'm going to go for a quick run, I'll check back in when I get back.11:38
jelmerjam: sure, that's okay for me11:43
vilamgz: damn, according to bug #688506 I've changed my mind...11:46
ubot5Launchpad bug 688506 in Bazaar ""bzr help conflict-types" suggests incorrect "bzr resolve --auto" command line" [Undecided,Confirmed] https://launchpad.net/bugs/68850611:46
* vila goes back to the attic to find the read-my-own-mind-in-the-past machine11:47
mgzI'm far too polite to point such things out...11:47
mgzbut yes, you wrote all the code to make this easy.11:48
vilaso at one point I considered that the disctinction auto/done was valid, why I don't get that feeling *now* is... either irrelevant or indicates a source of issues ;)11:49
vilaon the other hand, I was knee-deep in the code at the time and may have missed the distinction I'm making today: --auto carries the idea that suddenly bzr knows how to resolve the conflict (that's wrong because bzr wouldn't have generated a conflict in the first place otherwise).11:51
vilamgz: and I think you captured the right idea with: `bzr resolve` followed by `bzr resolve --done FILE` if the auto resolution fails for something in particular11:53
vilawhich doesn't require auto to be an action the user can specify11:53
=== zyga-afk is now known as zyga
vilain summary: let's make auto an internal action used by `bzr resolve` or in other places (bzr rm), keep --done for the cases where it fails11:54
vilaand may be rename it to carry the idea that the intent is to get rid of the conflict is there enough evidence that the user did what was needed11:55
vilamgz: are we still in agreement ?11:56
mgzvila: so, mulling over that while I had much lunch13:00
mgzI think we basically agree on the implementation?13:00
vilathat's my feeling as well13:01
mgzI don't see the benefit in having three choices for actions to remove conflict markers, and a fourth that's only selected if you don't specify one of the others13:02
vilaerr, which choices ?13:03
mgzgenerally with pick-one options, we include all the options, even if one is a default and won't normall be passed13:03
vilaindeed13:03
mgzwe have --done, --take-this and --take-other13:03
mgzI don't see why it's important to avoid adding a new option if that's how the underlying implementation actually works13:04
mgzand it wouldn't get in the way of future ui reshuffling should anyone want to take that on.13:04
vilabecause --done is already an alien and adding another one makes this even more confusin13:18
vilag13:18
mgzokay, but I don't think it's less confusing having a magic differen behaviour when there's no --action13:20
vilasome people don't even understand that they need to resolve the conflicts, give them --auto... and they will complain that it doesn't resolve the conflict ;)13:20
mgzat least with a flag it can be documented in the help.13:20
vilabecause as you argue, `bzr resolve` will clean up what it can13:21
vilaboth done and auto should not be needed in an ideal world, auto would be called as soon as bzr it involves and --done shouldn't be needed at all13:23
vilas/bzr it/bzr is/13:23
vilaI don't mind keeping done, adding auto seems to go in the wrong direction though, if it's auto, why the hell should I tell you ??13:24
mgzvila: because bzr is not a daemon13:25
vilafewer cases13:25
vilain presence of conflicts you can imagine 'bzr st' calling 'bzr resolve'13:26
vilawhat will be left then ?13:26
mgzor `bzr commit` for that matter.13:26
mgznot much, but that doesn't really matter. we have a legacy command to deprecate that happened to grow a name for a default switch more recently.13:27
mgzand in the mean time, things at least reflect the current state of the code.13:27
vilawhich default switch ?13:28
mgz`bzr resolve --auto` as a new alias for `bzr resolve`13:28
vilahuh ? This didn't land right ?13:29
mgzsorry, confusing you with tenses13:29
mgzI was using the past, but from imagining a future state where we make `bzr st` and other things remove resolved conflicts13:30
mgzso, *when we land better conflict handling*, we *would* have a legacy command...13:30
vilaha right, which is why I arguing (and thought you agreed) to keep things as they are but internally add action_auto13:31
mgzthis kind of thing is much easier in german...13:31
vilai.e. do not add --auto13:31
mgzokay, so that's the disagreement13:31
mgzI think changing the internals to use the fanciness in conflict is good13:31
mgzwhich you also think13:31
vilayyes13:31
mgzbut think it makes sense for the ui to reflect the implementation, given it's a small but real change13:32
mgzsimplest thing and all that.13:32
vilawell, I say it's confusing and doesn't provide additional feature. Simpler to explain: if you don't know: `bzr resolve`, if you know `bzr resolve --action=xxx ITEM`13:34
vilaand 'bzr resolve` is getting better13:34
mgzbut the docs will be the same regardless13:34
mgzmagic is bad, but refusing to name it doesn't make it any better13:36
vilathen you should be able to give a better explanation between auto and done13:38
mgzthat would be good indeed13:38
mgzand the help in general would benefit from some polish13:38
vilabecause, really, my reluctance to document auto is that I can't describe what it does (especially because it's currently undefined for most of the existing conflicts) :)13:38
vilawhereas done, well, as brutal as it is, is clear13:39
mgzit tries to detect conflicts that have been manually resolved and marks them as such13:39
vilafor a given conflict13:40
mgzfitting that in a flag description isn't terribly easy it's true13:40
vilabut they are cases where several conflicts can be involved which there is still hope to address as a whole13:40
vilaif --auto were --check or something innocent  like that evoking a non-destructive action (as far as user data is concerned), that will be different13:43
vila'resolved --auto' makes sense 'resolve --auto' implies that bzr will magically resolve the conflict, that's the part that I dislike13:45
vila'resolved --done' makes sense, 'resolve --done', well, is acceptable13:47
mgzcheck doesn't seem bad13:52
mgzany other suitable names?13:52
vilacleanup ( less good IMHO)13:53
vila--refresh ?14:04
mgzhave we got a less lame way of creating a branch in memory than bzrlib.branchbuilder?14:28
vilano14:33
vilamgz: don't feel bad writing less than perfect tests for conflicts, that would still be better that the actual lacking tests ;)14:34
vilaI mean, missing ones14:34
vilamgz: and keep in mind you are starting a new kind: action between merge and resolve, none of them exist IIRC14:35
nessitahello everyone. I was wondering if I could get some help on fixing an issue I'm consistently having with bzr pipelines: every time I pump changes in the pipeline, the pipes get broken with a "IndexError: list index out of range" (full traceback here http://pastebin.ubuntu.com/1119547/ )14:52
nessitaI asked about this a couple of weeks ago, I was told to run bzr repair-workingtree, and if I run it with --force it fixes the IndexError, but I would like, if possible, not to have to run the repair eveyr time after a bzr pump14:53
mgznessita: is there a bug against bzr-pipeline for creating the dirstate corruption in the first place?14:59
mgzif you can reliably reproduce it, I'd try to get as minimal a case as possible15:00
nessitamgz: makes sense, will try to do so15:00
mgzthe pyx and py versions look much the same, so you could also try running in a clean bzr source dir with BZR_PDB=1 set then poking around the entry that's broken15:04
nessitamgz: got a minimal example, will file the bug now, what project shall I file it against? bazaar? (or is there a pipeline specific project?)15:08
mgzbzr-pipeline15:09
mgzthere's possibly a core issue as well as we should really let plugins break dirstate, but it's easy to add tasks and move things later15:12
* mgz branches the source and looks at what pump actually does15:13
mgz...various aarony magic, but basically switch/merge/commit repeated15:17
nessitamgz: bug filled at https://bugs.launchpad.net/bzr-pipeline/+bug/103092315:21
ubot5Ubuntu bug 1030923 in bzr-pipeline "After bzr pump, "next" pipelines have a broken dirstate (got IndexError: list index out of range)" [Undecided,New]15:21
nessitamgz: let me know if I can help debugging any further15:21
nessitamgz: shall I also attach the "/var/crash/bzr.1000.2012-07-30T15:07.crash" that the bzr st reported?15:21
Dan_Hi ... I have a question.  I thought my branch was bound and I made a bunch of commits that turned out to be local.  I did bzr bind.  I did bzr update which made my local commits show up as a pending merge.  But I don't want it to show as a merge, I wanted to bzr push instead.15:47
Dan_I see that my head is still in the repo.15:47
Dan_Hold on I skipped a step.15:47
Dan_I then did bzr revert and I'm back to before I started my commits.15:48
Dan_I can see that my revision is still in the repo by doing bzr heads --all.15:48
Dan_But I don't know the command to make that dead head the head of my branch.15:48
Dan_I found it:  bzr pull . -r revid:blahblahblah15:52
vilaDan_: out of trouble ? Looks like you understood what happened and did what was needed :)16:14
Dan_Yes, I figured it out ... thanks ... I just couldn't find the answer with google very quickly and thought IRC might be faster.  :)  I just uncommitted a revision because I know it prints out some message like, "You can restore the revision you just uncommited by using this command."16:34
vilayeah, also, you could have done the pull earlier and just push16:36
vilawith a valid use case for 'bzr revert --no-backup' (which I never recommend otherwise)16:37
vilaand finally, I'm pretty sure 'bzr missing' would have ring a bell about the commits while unbound16:38
vilanever heart to use bzr missing16:38
vilaor 'bzr config' even16:39
=== deryck is now known as deryck[lunch]
mnnvila: when I created a branch, added files, then I ignored a folder... however then I decided to move this ignore into bzr user config file (bazaar\2.0\ignore)... but when I remove ignore from .bzrignore in branch 'bzr status' shows unknown folder (the one I wanted bzr to ignore)17:28
mnnvila: well that's weird - Bazaar Explorer (I believe correctly) doesn't show that folder as unknown (in working tree I see that it's ignored)... however 'bzr status' shows that folder as unknown17:35
* vila blinks at mnn 17:46
vilamnn: even if you quit/start explorer ?17:47
mnnvila: still the same17:52
mnnisn't this a bug? I mean bzr must be using bazaar\2.0\ignore because it works on my other repo/branch17:52
=== deryck[lunch] is now known as deryck
mnnbzr add obviously isn't helping (adds whole directory and its children)17:54
vilayou can test your ignore file with 'bzr ignored17:57
vila grrr17:57
vilayou can test your ignore file with 'bzr ignored' and 'bzr add --dry-run'17:57
mnnyeah ... 'bzr ignored' returns nothing17:57
mnnbzr add --dry-run wants to add supposedly ignored folder17:58
vilaI can't imagine why explorer differs... but if 'st'and 'add' agree, then there is something fishy there...18:00
viladinner time here, file a bug giving as much context as you can18:00
mnnok, thanks for the help in the meantime18:01
mnnI can't reproduce it :(18:06
mnn... on a new, clean repo/branch18:07
vilaalready added files are not taken into account when dealing with ignored files, this matters only for 'bzr add'ing unversioned files18:13
mnnwell... I removed the folder: 'bzr remove --keep folder'18:14
mnnI must have broken something here18:14
mnn> when dealing with ignored files, this matters only for 'bzr add'ing unversioned files18:24
mnnI believe that ignored files should be taken into account by 'bzr status' as well, right?18:24
vilamnn: right, but displayed as unknowns there *iff* they are unversioned18:42
mnnso basically there's no way to make bzr ignore these files without adding them to .bzrignore?18:45
mnn*this folder18:45
tsdhHi.  Is bzr-fastimport-0.13.0 incompatible with bzr-2.5.1?  At least I get "ImportError: cannot import name error" at "from bzrlib.trace import error, note" in bzrlib/plugins/fastimport/branch_updater.py and checking bzrlib.trace in the 2.5-branch, there's indeed no error function.18:45
vilamnn: err, the way to make nzr ignore these files *is* to add them to .bzrignore OR add the right regexps in ~/.bazaar/ignore19:21
vilas/nzr/bzr/19:21
mnnwell they already are in %AppData%\bazaar\2.0\ignore (I'm using WinXP)... and the same ignores work for other repos/branches19:23
mnnthe problem is that I removed the ignores from .bzrignore and added them to global ignores (in bazaar\2.0\ignores)19:23
mnnand now bzr is showing them as unknown (Bazaar Explorer doesn't show them)19:24
viladoesn't make sense, so I should be missing some info19:24
vilaor there is a bug19:24
vilaif you can't reproduce in  a clean branch, something is going on in your branch19:24
mnnwait I might just have reproduced it... need to try it again19:26
mnnvila: sorry for bothering you - when I discovered this "bug" I was using different BZR_HOME path than normal in %AppData%... when I used regular one in %AppData% unknowns doesn't show up19:33
mnnbut thanks for help anyway19:33
viladoh, then of course you don't find the right ignore file, no worries, thanks for giving the answer to this puzzle :)19:34
mnnyeah, I'm aware of that... just didn't notice it :(19:34
DrDynamic2Hey folks, I recently upgraded to OS X Mountain Lion and it borked my bzr install. Upon running any bzr * command, it tells me bzrlib is not in my pythonpath. How can I add it back?19:39
mgzin mac ignorance, just reinstall it?19:46
vilaDrDynamic2: better file a bug against bzr-mac-installers on launchpad (https://bugs.launchpad.net/bzr-mac-installers), I don't have osx ML to test so I can't tell which python version is provided nor where your bzrlib is installed19:46
vilaor rather was installed nor whether it's compatible with your installed python19:46
DrDynamic2vila: It's 2.7 that is provided, that seems to be the cause.19:49
DrDynamic2Alright I'll file a bug and reinstall :(19:49
txomon|homehi, is bazaar recommended to be a DAM ?20:05
txomon|homeI want to get Versioned a Maya project, and I know git is not very keen on big files, so I am looking for a native support (git-annex)20:06
lifelessbzr has the same issue git does20:14
=== iBasic is now known as BasicOSX
mnncould someone explain to me, when does iter_changes() returns (None, None) for kind?22:21
mnnbecause right now it seems that it does for delete directories... but I noticed that just now22:21
mnnalso what are the exact meaning of versioned tuple? it's all fuzzy to me, what's written in InterTree.iter_changes()22:24
mnnreally? nobody? oh, come on... :(22:46
wgzthe two tuple from iter_changes?22:51
wgzit's like the others, first item is state in the old tree, second is state in the new tree22:52
wgzah, you'd quit22:52
mnnyeah, it shut me down22:52
mnndid you wrote something?22:52
wgzby versioned tuple you mean the 2-tuple that's the fourth item in iter_changes results?22:53
wgzit's like the others, first item is state in the old tree, second is state in the new tree22:53
mnnyeah22:53
mnnah22:53
mnnyes, thanks22:53
wgzbut note aloo want_unversioned defaults to False22:53
mnnbecause my auto-rename-fix has failed on one autorenaming a few hours back and now I want to reproduce it and got into situation where kind is (None, None) (which I really didn't anticipate)22:55
mnnalso why is kind (None, None) - both for old tree and new tree?22:56
wgzit does seem a little suprising22:56
mnncould it be because it's a directory that's ignored?22:57
wgzI suspect it could happen if a file was added in this revision22:58
wgzbut is then removed from disk22:58
wgzso, 'missing' state with no parent in the last revision22:58
lifelessyes, exactly that.23:01
mnnwgz: thanks for approving auto-rename-fix, but that was a bit to early... I mean I just reported that it does not work on the situation described above23:26
wgzI also put it up for another review at the same time :)23:31
wgzI should have added a text string as the review time to emphasise I've not actually thought about the logic in it yet23:31
wgz*review type23:31
wgzadding more failing test cases for things that break is a good way to proceed I'd say if you're still having issues23:32
mnnwell first I need to wrap my head around whole iter_changes() and its return values for various tree states23:34
wgzmaybe grep for some tests that use iter_changes and add some variations on your test that also check its output maybe?23:36
wgz...anyway, I need to go to bed before I get any more cross-eyed23:36
mnnI will go as well23:36
mnnthanks for help and guidance23:36
mnngood night23:36
wgznight!23:38

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