[07:32] <jelmer> moin
[08:12] <mgz> morning!
[08:12] <jelmer> sup mgz!
[08:13] <vila> hi all !
[08:17] <mgz> jam around yet today?
[08:17] <jelmer> he was around in #-kitchen earlier
[08:20] <mgz> ace.
[08:21] <jam> mgz: /wave
[08:44] <jelmer> mgz: do you still happen to have the PQM output for merge-grep?
[08:48] <mgz> forwarded
[08:48] <mgz> and you have too many email addresses with no obvious pattern for when you use which ones :)
[08:50] <jelmer> mgz: gracias :)
[08:51] <Peng> Solution: CC all?
[08:51] <Peng> :)
[09:05] <jelmer> mgz: hmm, there are also a bunch of tests that fail in a different locale
[09:05] <mgz> hm, I'll branch and see
[09:06] <jelmer> I'm running with spanish here - it at least appears to have enough things translated
[09:06] <mgz> you're learning spanish?
[09:07] <jelmer> mgz: different computer :)
[09:07] <jelmer> laptop is German, desktop is Spanish
[09:16] <jam> jelmer: IIRC lifeless was using Latin for a while
[09:16] <jam> that, and vila tried to use French, but found it too confusing
[09:16] <vila> :)
[09:17]  * jelmer chuckles thinking of vila being confused by French
[09:18] <vila> yup, same here ;)
[09:19] <vila> truth is, to clear confusion, the best way for me is often to translate back to english...
[09:20] <jelmer> vila: do you "think" in English when you speak it, or do you translate back to French mentally?
[09:21] <vila> jelmer: I'm at the point where I sometimes think in English but need to speak in French ;)
[09:21] <vila> family hate that ;)
[09:21] <jelmer> :)
[09:21] <vila> mostly depends on the topic discussed
[09:22] <vila> so, for technical matters, I often don't know how to translate idiomatically
[09:22] <vila> but people around me are helpful ;)
[09:27] <jelmer> heh
[09:52] <vila> mgz: ping me when you're ready to discuss some resolve proposals of yours
[09:52] <mgz> ping!
[09:55] <vila> I'm looking at the introduction of the auto action and I
[09:55] <vila> meh
[09:55] <vila> I'm not sure I agree
[09:55] <vila> --done seems fine to me to include what you put in --auto
[09:56] <mgz> wait, which one?
[09:56]  * mgz went a bit overboard with different branches
[09:56] <vila> I'm back to resolve_auto_refactor
[09:56] <mgz> okay
[09:56] <vila> back to the basics: merge creates a conflict because bzr cannot decide which action is required
[09:57] <vila> resolve should be taught to recognize that the user did something and the conflict is not there anymore
[09:57] <vila> that's what '--auto' seem to do in your proposals
[09:57] <vila> but in fact, I'd prefer that --done cover that
[09:58] <mgz> so, 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] <vila> i.e.: the context has changed, bzr does not see a conflict anymore, the conflict object can be deleted
[09:58] <vila> yup
[09:58] <mgz> which is mostly what people want
[09:58] <mgz> but --done is still needed
[09:58] <vila> when ?
[09:59] <mgz> otherwise, how for instance, with a conflict that involves a deletion
[09:59] <mgz> do you say "no, really, keep it"
[09:59] <mgz> deleting the object and --auto works, you clearly want the deletion to stick
[10:00] <vila> say that again in commands executed by the user ?
[10:00]  * vila tries to get it
[10:00] <mgz> but there's nothing to distinguish "haven't decided if I want this object still" and "want to keep the object"
[10:00] <mgz> eg, I delete d/
[10:00] <mgz> you add d/f
[10:00] <mgz> I merge your branch
[10:01] <mgz> get a conflict on d/
[10:01] <mgz> filesystem looks like [d/, d/f]
[10:01]  * vila nods, that's 'merge' this specific case
[10:01] <mgz> if I want my change to stick, I delete d/ (and maybe move d/f somewhere else)
[10:01] <mgz> if I decide against deleting d/ because you're now using it, I need bzr resolve --done d
[10:02] <mgz> I don't see a neater way out of that
[10:02] <vila> what does --auto does in this case then ?
[10:02] <mgz> we could alos move d/ to d.conflicted/ and make the user delete or move it back
[10:02] <mgz> but that doesn't seem easier.
[10:03] <vila> the 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 at
[10:03] <mgz> there's also the "my file has the line '[10:03] <vila> and preferably the action comes in two flavors: favor this or favor other
[10:04] <mgz> auto is bascially just a generalisation of `bzr resolve` which is pretty much all I ever use
[10:04] <mgz> it's unlikely to ever be passed in, it's just a good safe default
[10:05] <vila> still sounds like a variation of --done rather than a different action
[10:05] <mgz> --done is by definition not safe
[10:06] <vila> yup
[10:06] <mgz> it's a shut-up-and-believe-me option
[10:06] <vila> that's what the thread was about IMHO: make it safer
[10:06] <mgz> okay, so I disagree
[10:06] <vila> when in doubt, requires --force
[10:06] <mgz> we still need the unsafe option
[10:06] <vila> --done --force
[10:07] <mgz> and I don't see the benefit of `resolve --done` and  `resolve --done --force` over using `resolve --auto` and `resolve --done`
[10:07] <vila> may be we just disagree on the name
[10:07] <vila> --auto sounds magical: do the right thing (including actions like deleting a file or add'ing it or whatever)
[10:07] <mgz> they're clearly different options, --done already does the right thing, our auto logic already does the right thing just isn't exposed as a flag
[10:08] <mgz> we can name auto whatever, I doubt anyone will ever actually pass it, it's just the default
[10:08] <mgz> it's auto in the existing code is all
[10:09] <vila> what triggered my question is that you modified existing tests by adding --auto, as if the default behavior (or command-line option default value) has changed
[10:09] <mgz> right, the whole point is to change `bzr resolve FILE` to be 'safe'
[10:10] <mgz> but then go back around and make `bzr resolve FILE` still do the right thing
[10:10] <mgz> (by making auto smarter)
[10:13] <vila> still blurry
[10:13] <mgz> I need to write up some user story type things for the list really
[10:13] <vila> some conflicts just can't be "checked" without asking tree-transform to rebuild the conflicts
[10:13] <mgz> it doesn't help that a lot of the conflict cases we have are bugs at about three different levels
[10:14] <vila> yeah, hard stuff
[10:14] <vila> also, action_* in conflict objects should *always* use a tree transform
[10:14] <mgz> like... not having precious/junk distinction, switch being unsafe, doubling conflicts on deleted directories...
[10:14] <vila> I made the mistake in the past of using direct actions, that's not robust and may introduce subtle failure modes
[10:15] <vila> yeah, lots of entangled stuff
[10:15] <mgz> as in, the ones using tree.remove are wrong?
[10:15] <vila> yup
[10:15] <vila> there are still some left right ?
[10:15] <vila> bah, better check myseflf
[10:16] <mgz> yup, and I added a another one because I couldn't work out how to change state 'missing' to unversioned/gone
[10:16] <mgz> basically just want to remove the file_id from the inventory but couldn't find a good way of doing that
[10:16] <vila> right, DuplicateEntry is wrong and should be rewritten
[10:17] <vila> right, so tt.unversion() or something
[10:17] <vila> tree.revert may be ok (if it relies on tt under the hood)
[10:17] <mgz> unversion checks that the file exists
[10:19] <vila> urgh
[10:20] <vila> err, are you sure you don't just need to register a trans_id ?
[10:21] <mgz> no, not sure, I didn't try using a tree transform.
[10:22] <vila> right, then that's an example of why tt should be used ;)
[10:24] <vila> hmm, 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] <mgz> hm, and there is a bug in the current auto resolve logic, though earlier than I thought:

[10:25] <vila> with a pristine bzr.dev  ?
[10:26] <mgz> yup.
[10:27] <vila> hmm, 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] <mgz> and a similar one with bzr rm rather than rm: <http://pastebin.ubuntu.com/1119185/>
[10:29] <vila> great :-}
[10:29] <vila> worth fixing
[10:30]  * vila still paging in context
[10:32] <mgz> okay, 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] <mgz> in otherwords
[10:32] <mgz> we have a conflict in a text file
[10:33] <mgz> if the user has removed the file - it's resolved, they deleted it
[10:33] <mgz> if the user changed the file into a symlink or directory - it's also resolved, it's not text any more
[10:34] <mgz> otherwise we peek at the bytes on disk looking for conflict markers, if they're gone, it's resolved
[10:35] <mgz> otherwise we should raise ConflictUnresolved or whatever we go for over NotImplementedError
[10:35] <mgz> ideally with contenxt like line number
[10:37] <vila> "not text anymore" and we never try to keep the file-id when the kind changes, it makes no sense
[10:38]  * vila agree with ConflictUnresolved of StillThere or whatever
[10:38] <vila> coming back to the internal 'auto' action"
[10:38] <vila> s/"/:/
[10:39] <vila> when 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 meaning
[10:39] <vila> but really, 'done' and 'auto' (as internal actions) are still in the 'resolved' realm
[10:41] <vila> which is also part of my reluctance to accept --auto as an action from the user pov
[10:42] <vila> in 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 conflict
[10:43] <vila> another way to look at it is that if --done cannot clean up safely, the user still have to do something.
[10:44] <vila> If there are multiple choices there, --auto won't be able to decide
[10:44] <vila> it's ok for the conflict markers because there is a single possible action: remove the markers
[10:45] <vila> but I fear it won't be true for all conflicts
[10:45] <mgz> hm, `bzr resolve -d g g/f" ... does not work
[10:45] <mgz> the path is taken as relative to the repo
[10:45] <mgz> not cwd.
[10:45] <mgz> is that the normal form for -d?
[10:46] <vila> ha ha, and that's not mentioning multiple conflicts that can interact and should be resolved in the proper order :-}
[10:46] <vila> regarding -d, I think you've just entered unexplored territory :)
[10:47] <mgz> okay, I agree there's a lot of mess in resolve currently
[10:48] <vila> right, which is why I'm unclear about whether --auto is legit or would just add to the confusion
[10:48] <mgz> but... the current state is we have a number of broken common cases
[10:49] <mgz> which are not actually hard to fix, and the code basically supports doing it in a sane manner
[10:49] <vila> in other words: if you were talking about enhancing 'resolveD' I'll be +1, for 'resolve'... it's less clear
[10:50] <vila> but the content of your auto_* methods are certainly valuable
[10:50] <mgz> I don't see the benefit in the kind of procrastination over details, like in that bazaar mailing list thread
[10:51] <vila> right
[10:51] <mgz> when we can just make the code a bit better and get most of the pain resolveD
[10:51] <vila> right too
[10:51] <vila> how about just rewriting auto_resolve then and don't touch the command itself yet ?
[10:51] <mgz> I'm not attached to the name 'auto', but the behaviour from `bzr resolve` is useful and is worth generalising
[10:52] <vila> seem we are in agreement ?
[10:52] <mgz> doing that takes me back to this just being a code refactor
[10:52] <vila> 'that' 'this' /me lost :)
[10:53] <mgz> without also making auto understand when other kinds of conflict are done with, we need the unsafe --done or --all far more often
[10:53] <mgz> so the extra pain of requiring that isn't worth the interface breakage for users
[10:54] <vila> so you still agree with turning auto_resolve into conflict.action_auto kind of refactor ?
[10:55] <vila> that may not be enough to address all multiple conflict cases but neither does the actual code
[10:55] <mgz> yes. there's a nice mechanism for removing conflicts, using that rather than having a seperate method on tree clearly makes sense.
[10:55] <vila> great
[10:56] <vila> lunch here but after that I'm still available to discuss or even help writing tests and/or code
[10:56] <mgz> I understood 'just rewriting auto_resolve' as you not wanting bzrlib/conflicts.py touched.
[11:03] <mgz> jelmer: 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:19] <jelmer> mgz: those were other bzr tests
[11:25] <mgz> okay, will do a full test run over lunch
[11:28] <vila> mgz: back, indeed, I do want to pursue the efforts in conflicts.py
[11:30] <mgz> okay, bb.test_debug.TestDebugBytes.test_bytes_reports_activity is broken
[11:30] <mgz> needs to either not install translations or not check for the english string
[11:30] <mgz> I expect there are a few others like that
[11:31] <vila> a way to force english messages (as expected by tests) sounds like a useful resource
[11:32] <mgz> we've got one :)
[11:32] <mgz> I assumed all the blackbox tests used it, but apparently it's just some of them
[11:33] <jam> jelmer: is it ok if we push back our call by a couple of minutes?
[11:34] <jam> like at 2:30?
[11:34] <jam> (I have a 3:30 with Francis, so I still need to finish on time.)
[11:35] <mgz> ...I thought Francis was on holiday still?
[11:35] <jam> mgz: I think he is in Isle of man this week, and he was still hoping to get ahold of me
[11:35] <jam> at least, he still has our meeting scheduled
[11:35] <mgz> ah, yes, that might be it.
[11:36] <jam> mgz: it is possible that *next* week is Isle of Man, though.
[11:36] <mgz> I think it's this week, but then he's off next week as well.
[11:38] <jam> jelmer: anyway, I'm going to go for a quick run, I'll check back in when I get back.
[11:43] <jelmer> jam: sure, that's okay for me
[11:46] <vila> mgz: damn, according to bug #688506 I've changed my mind...
[11:47]  * vila goes back to the attic to find the read-my-own-mind-in-the-past machine
[11:47] <mgz> I'm far too polite to point such things out...
[11:48] <mgz> but yes, you wrote all the code to make this easy.
[11:49] <vila> so 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:51] <vila> on 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:53] <vila> mgz: 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 particular
[11:53] <vila> which doesn't require auto to be an action the user can specify
[11:54] <vila> in 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 fails
[11:55] <vila> and 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 needed
[11:56] <vila> mgz: are we still in agreement ?
[13:00] <mgz> vila: so, mulling over that while I had much lunch
[13:00] <mgz> I think we basically agree on the implementation?
[13:01] <vila> that's my feeling as well
[13:02] <mgz> I 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 others
[13:03] <vila> err, which choices ?
[13:03] <mgz> generally with pick-one options, we include all the options, even if one is a default and won't normall be passed
[13:03] <vila> indeed
[13:03] <mgz> we have --done, --take-this and --take-other
[13:04] <mgz> I don't see why it's important to avoid adding a new option if that's how the underlying implementation actually works
[13:04] <mgz> and it wouldn't get in the way of future ui reshuffling should anyone want to take that on.
[13:18] <vila> because --done is already an alien and adding another one makes this even more confusin
[13:18] <vila> g
[13:20] <mgz> okay, but I don't think it's less confusing having a magic differen behaviour when there's no --action
[13:20] <vila> some 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] <mgz> at least with a flag it can be documented in the help.
[13:21] <vila> because as you argue, `bzr resolve` will clean up what it can
[13:23] <vila> both 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 all
[13:23] <vila> s/bzr it/bzr is/
[13:24] <vila> I 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:25] <mgz> vila: because bzr is not a daemon
[13:25] <vila> fewer cases
[13:26] <vila> in presence of conflicts you can imagine 'bzr st' calling 'bzr resolve'
[13:26] <vila> what will be left then ?
[13:26] <mgz> or `bzr commit` for that matter.
[13:27] <mgz> not 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] <mgz> and in the mean time, things at least reflect the current state of the code.
[13:28] <vila> which default switch ?
[13:28] <mgz> `bzr resolve --auto` as a new alias for `bzr resolve`
[13:29] <vila> huh ? This didn't land right ?
[13:29] <mgz> sorry, confusing you with tenses
[13:30] <mgz> I was using the past, but from imagining a future state where we make `bzr st` and other things remove resolved conflicts
[13:30] <mgz> so, *when we land better conflict handling*, we *would* have a legacy command...
[13:31] <vila> ha right, which is why I arguing (and thought you agreed) to keep things as they are but internally add action_auto
[13:31] <mgz> this kind of thing is much easier in german...
[13:31] <vila> i.e. do not add --auto
[13:31] <mgz> okay, so that's the disagreement
[13:31] <mgz> I think changing the internals to use the fanciness in conflict is good
[13:31] <mgz> which you also think
[13:31] <vila> yyes
[13:32] <mgz> but think it makes sense for the ui to reflect the implementation, given it's a small but real change
[13:32] <mgz> simplest thing and all that.
[13:34] <vila> well, 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] <vila> and 'bzr resolve` is getting better
[13:34] <mgz> but the docs will be the same regardless
[13:36] <mgz> magic is bad, but refusing to name it doesn't make it any better
[13:38] <vila> then you should be able to give a better explanation between auto and done
[13:38] <mgz> that would be good indeed
[13:38] <mgz> and the help in general would benefit from some polish
[13:38] <vila> because, 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:39] <vila> whereas done, well, as brutal as it is, is clear
[13:39] <mgz> it tries to detect conflicts that have been manually resolved and marks them as such
[13:40] <vila> for a given conflict
[13:40] <mgz> fitting that in a flag description isn't terribly easy it's true
[13:40] <vila> but they are cases where several conflicts can be involved which there is still hope to address as a whole
[13:43] <vila> if --auto were --check or something innocent  like that evoking a non-destructive action (as far as user data is concerned), that will be different
[13:45] <vila> 'resolved --auto' makes sense 'resolve --auto' implies that bzr will magically resolve the conflict, that's the part that I dislike
[13:47] <vila> 'resolved --done' makes sense, 'resolve --done', well, is acceptable
[13:52] <mgz> check doesn't seem bad
[13:52] <mgz> any other suitable names?
[13:53] <vila> cleanup ( less good IMHO)
[14:04] <vila> --refresh ?
[14:28] <mgz> have we got a less lame way of creating a branch in memory than bzrlib.branchbuilder?
[14:33] <vila> no
[14:34] <vila> mgz: don't feel bad writing less than perfect tests for conflicts, that would still be better that the actual lacking tests ;)
[14:34] <vila> I mean, missing ones
[14:35] <vila> mgz: and keep in mind you are starting a new kind: action between merge and resolve, none of them exist IIRC
[14:52] <nessita> hello 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:53] <nessita> I 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 pump
[14:59] <mgz> nessita: is there a bug against bzr-pipeline for creating the dirstate corruption in the first place?
[15:00] <mgz> if you can reliably reproduce it, I'd try to get as minimal a case as possible
[15:00] <nessita> mgz: makes sense, will try to do so
[15:04] <mgz> the 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 broken
[15:08] <nessita> mgz: 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:09] <mgz> bzr-pipeline
[15:12] <mgz> there'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 later
[15:13]  * mgz branches the source and looks at what pump actually does
[15:17] <mgz> ...various aarony magic, but basically switch/merge/commit repeated
[15:21] <nessita> mgz: bug filled at https://bugs.launchpad.net/bzr-pipeline/+bug/1030923
[15:21] <nessita> mgz: let me know if I can help debugging any further
[15:21] <nessita> mgz: shall I also attach the "/var/crash/bzr.1000.2012-07-30T15:07.crash" that the bzr st reported?
[15:47] <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:48] <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:52] <Dan_> I found it:  bzr pull . -r revid:blahblahblah
[16:14] <vila> Dan_: out of trouble ? Looks like you understood what happened and did what was needed :)
[16:34] <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:36] <vila> yeah, also, you could have done the pull earlier and just push
[16:37] <vila> with a valid use case for 'bzr revert --no-backup' (which I never recommend otherwise)
[16:38] <vila> and finally, I'm pretty sure 'bzr missing' would have ring a bell about the commits while unbound
[16:38] <vila> never heart to use bzr missing
[16:39] <vila> or 'bzr config' even
[17:28] <mnn> vila: 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:35] <mnn> vila: 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 unknown
[17:46]  * vila blinks at mnn 
[17:47] <vila> mnn: even if you quit/start explorer ?
[17:52] <mnn> vila: still the same
[17:52] <mnn> isn't this a bug? I mean bzr must be using bazaar\2.0\ignore because it works on my other repo/branch
[17:54] <mnn> bzr add obviously isn't helping (adds whole directory and its children)
[17:57] <vila> you can test your ignore file with 'bzr ignored
[17:57] <vila>  grrr
[17:57] <vila> you can test your ignore file with 'bzr ignored' and 'bzr add --dry-run'
[17:57] <mnn> yeah ... 'bzr ignored' returns nothing
[17:58] <mnn> bzr add --dry-run wants to add supposedly ignored folder
[18:00] <vila> I can't imagine why explorer differs... but if 'st'and 'add' agree, then there is something fishy there...
[18:00] <vila> dinner time here, file a bug giving as much context as you can
[18:01] <mnn> ok, thanks for the help in the meantime
[18:06] <mnn> I can't reproduce it :(
[18:07] <mnn> ... on a new, clean repo/branch
[18:13] <vila> already added files are not taken into account when dealing with ignored files, this matters only for 'bzr add'ing unversioned files
[18:14] <mnn> well... I removed the folder: 'bzr remove --keep folder'
[18:14] <mnn> I must have broken something here
[18:24] <mnn> > when dealing with ignored files, this matters only for 'bzr add'ing unversioned files
[18:24] <mnn> I believe that ignored files should be taken into account by 'bzr status' as well, right?
[18:42] <vila> mnn: right, but displayed as unknowns there *iff* they are unversioned
[18:45] <mnn> so basically there's no way to make bzr ignore these files without adding them to .bzrignore?
[18:45] <mnn> *this folder
[18:45] <tsdh> Hi.  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.
[19:21] <vila> mnn: err, the way to make nzr ignore these files *is* to add them to .bzrignore OR add the right regexps in ~/.bazaar/ignore
[19:21] <vila> s/nzr/bzr/
[19:23] <mnn> well they already are in %AppData%\bazaar\2.0\ignore (I'm using WinXP)... and the same ignores work for other repos/branches
[19:23] <mnn> the problem is that I removed the ignores from .bzrignore and added them to global ignores (in bazaar\2.0\ignores)
[19:24] <mnn> and now bzr is showing them as unknown (Bazaar Explorer doesn't show them)
[19:24] <vila> doesn't make sense, so I should be missing some info
[19:24] <vila> or there is a bug
[19:24] <vila> if you can't reproduce in  a clean branch, something is going on in your branch
[19:26] <mnn> wait I might just have reproduced it... need to try it again
[19:33] <mnn> vila: 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 up
[19:33] <mnn> but thanks for help anyway
[19:34] <vila> doh, then of course you don't find the right ignore file, no worries, thanks for giving the answer to this puzzle :)
[19:34] <mnn> yeah, I'm aware of that... just didn't notice it :(
[19:39] <DrDynamic2> Hey 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:46] <mgz> in mac ignorance, just reinstall it?
[19:46] <vila> DrDynamic2: 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 installed
[19:46] <vila> or rather was installed nor whether it's compatible with your installed python
[19:49] <DrDynamic2> vila: It's 2.7 that is provided, that seems to be the cause.
[19:49] <DrDynamic2> Alright I'll file a bug and reinstall :(
[20:05] <txomon|home> hi, is bazaar recommended to be a DAM ?
[20:06] <txomon|home> I 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:14] <lifeless> bzr has the same issue git does
[22:21] <mnn> could someone explain to me, when does iter_changes() returns (None, None) for kind?
[22:21] <mnn> because right now it seems that it does for delete directories... but I noticed that just now
[22:24] <mnn> also what are the exact meaning of versioned tuple? it's all fuzzy to me, what's written in InterTree.iter_changes()
[22:46] <mnn> really? nobody? oh, come on... :(
[22:51] <wgz> the two tuple from iter_changes?
[22:52] <wgz> it's like the others, first item is state in the old tree, second is state in the new tree
[22:52] <wgz> ah, you'd quit
[22:52] <mnn> yeah, it shut me down
[22:52] <mnn> did you wrote something?
[22:53] <wgz> by versioned tuple you mean the 2-tuple that's the fourth item in iter_changes results?
[22:53] <wgz> it's like the others, first item is state in the old tree, second is state in the new tree
[22:53] <mnn> yeah
[22:53] <mnn> ah
[22:53] <mnn> yes, thanks
[22:53] <wgz> but note aloo want_unversioned defaults to False
[22:55] <mnn> because 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:56] <mnn> also why is kind (None, None) - both for old tree and new tree?
[22:56] <wgz> it does seem a little suprising
[22:57] <mnn> could it be because it's a directory that's ignored?
[22:58] <wgz> I suspect it could happen if a file was added in this revision
[22:58] <wgz> but is then removed from disk
[22:58] <wgz> so, 'missing' state with no parent in the last revision
[23:01] <lifeless> yes, exactly that.
[23:26] <mnn> wgz: 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 above
[23:31] <wgz> I also put it up for another review at the same time :)
[23:31] <wgz> I should have added a text string as the review time to emphasise I've not actually thought about the logic in it yet
[23:31] <wgz> *review type
[23:32] <wgz> adding more failing test cases for things that break is a good way to proceed I'd say if you're still having issues
[23:34] <mnn> well first I need to wrap my head around whole iter_changes() and its return values for various tree states
[23:36] <wgz> maybe 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-eyed
[23:36] <mnn> I will go as well
[23:36] <mnn> thanks for help and guidance
[23:36] <mnn> good night
[23:38] <wgz> night!