=== jam1 is now known as jam | ||
jelmer | moin | 07:32 |
---|---|---|
mgz | morning! | 08:12 |
jelmer | sup mgz! | 08:12 |
vila | hi all ! | 08:13 |
mgz | jam around yet today? | 08:17 |
jelmer | he was around in #-kitchen earlier | 08:17 |
mgz | ace. | 08:20 |
jam | mgz: /wave | 08:21 |
jelmer | mgz: do you still happen to have the PQM output for merge-grep? | 08:44 |
mgz | forwarded | 08:48 |
mgz | and you have too many email addresses with no obvious pattern for when you use which ones :) | 08:48 |
jelmer | mgz: gracias :) | 08:50 |
Peng | Solution: CC all? | 08:51 |
Peng | :) | 08:51 |
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:05 |
jelmer | I'm running with spanish here - it at least appears to have enough things translated | 09:06 |
mgz | you're learning spanish? | 09:06 |
jelmer | mgz: different computer :) | 09:07 |
jelmer | laptop is German, desktop is Spanish | 09:07 |
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:16 |
* jelmer chuckles thinking of vila being confused by French | 09:17 | |
vila | yup, same here ;) | 09:18 |
vila | truth is, to clear confusion, the best way for me is often to translate back to english... | 09:19 |
jelmer | vila: do you "think" in English when you speak it, or do you translate back to French mentally? | 09:20 |
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:21 |
vila | so, for technical matters, I often don't know how to translate idiomatically | 09:22 |
vila | but people around me are helpful ;) | 09:22 |
jelmer | heh | 09:27 |
vila | mgz: ping me when you're ready to discuss some resolve proposals of yours | 09:52 |
mgz | ping! | 09:52 |
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:55 |
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:56 |
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:57 |
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:58 |
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 | 09:59 |
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:00 |
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:01 |
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:02 |
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 '=======' in it" case | 10:03 |
vila | and preferably the action comes in two flavors: favor this or favor other | 10:03 |
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:04 |
vila | still sounds like a variation of --done rather than a different action | 10:05 |
mgz | --done is by definition not safe | 10:05 |
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:06 |
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:07 |
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:08 |
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 |
=== zyga is now known as zyga-afk | ||
mgz | right, the whole point is to change `bzr resolve FILE` to be 'safe' | 10:09 |
mgz | but then go back around and make `bzr resolve FILE` still do the right thing | 10:10 |
mgz | (by making auto smarter) | 10:10 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
vila | urgh | 10:19 |
vila | err, are you sure you don't just need to register a trans_id ? | 10:20 |
mgz | no, not sure, I didn't try using a tree transform. | 10:21 |
vila | right, then that's an example of why tt should be used ;) | 10:22 |
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:24 |
mgz | <http://pastebin.ubuntu.com/1119180/> | 10:24 |
vila | with a pristine bzr.dev ? | 10:25 |
mgz | yup. | 10:26 |
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:27 |
vila | great :-} | 10:29 |
vila | worth fixing | 10:29 |
* vila still paging in context | 10:30 | |
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:32 |
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:33 |
mgz | otherwise we peek at the bytes on disk looking for conflict markers, if they're gone, it's resolved | 10:34 |
mgz | otherwise we should raise ConflictUnresolved or whatever we go for over NotImplementedError | 10:35 |
mgz | ideally with contenxt like line number | 10:35 |
vila | "not text anymore" and we never try to keep the file-id when the kind changes, it makes no sense | 10:37 |
* vila agree with ConflictUnresolved of StillThere or whatever | 10:38 | |
vila | coming back to the internal 'auto' action" | 10:38 |
vila | s/"/:/ | 10:38 |
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:39 |
vila | which is also part of my reluctance to accept --auto as an action from the user pov | 10:41 |
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:42 |
vila | another way to look at it is that if --done cannot clean up safely, the user still have to do something. | 10:43 |
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:44 |
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:45 |
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:46 |
mgz | okay, I agree there's a lot of mess in resolve currently | 10:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
vila | so you still agree with turning auto_resolve into conflict.action_auto kind of refactor ? | 10:54 |
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:55 |
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. | 10:56 |
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:03 |
jelmer | mgz: those were other bzr tests | 11:19 |
mgz | okay, will do a full test run over lunch | 11:25 |
vila | mgz: back, indeed, I do want to pursue the efforts in conflicts.py | 11:28 |
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:30 |
vila | a way to force english messages (as expected by tests) sounds like a useful resource | 11:31 |
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:32 |
jam | jelmer: is it ok if we push back our call by a couple of minutes? | 11:33 |
jam | like 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 |
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:35 |
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:36 |
jam | jelmer: anyway, I'm going to go for a quick run, I'll check back in when I get back. | 11:38 |
jelmer | jam: sure, that's okay for me | 11:43 |
vila | mgz: damn, according to bug #688506 I've changed my mind... | 11:46 |
ubot5 | Launchpad bug 688506 in Bazaar ""bzr help conflict-types" suggests incorrect "bzr resolve --auto" command line" [Undecided,Confirmed] https://launchpad.net/bugs/688506 | 11:46 |
* 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:47 |
mgz | but yes, you wrote all the code to make this easy. | 11:48 |
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:49 |
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:51 |
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:53 |
=== zyga-afk is now known as zyga | ||
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:54 |
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:55 |
vila | mgz: are we still in agreement ? | 11:56 |
mgz | vila: so, mulling over that while I had much lunch | 13:00 |
mgz | I think we basically agree on the implementation? | 13:00 |
vila | that's my feeling as well | 13:01 |
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:02 |
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:03 |
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:04 |
vila | because --done is already an alien and adding another one makes this even more confusin | 13:18 |
vila | g | 13:18 |
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:20 |
vila | because as you argue, `bzr resolve` will clean up what it can | 13:21 |
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:23 |
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:24 |
mgz | vila: because bzr is not a daemon | 13:25 |
vila | fewer cases | 13:25 |
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:26 |
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:27 |
vila | which default switch ? | 13:28 |
mgz | `bzr resolve --auto` as a new alias for `bzr resolve` | 13:28 |
vila | huh ? This didn't land right ? | 13:29 |
mgz | sorry, confusing you with tenses | 13:29 |
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:30 |
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:31 |
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:32 |
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:34 |
mgz | magic is bad, but refusing to name it doesn't make it any better | 13:36 |
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:38 |
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:39 |
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:40 |
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:43 |
vila | 'resolved --auto' makes sense 'resolve --auto' implies that bzr will magically resolve the conflict, that's the part that I dislike | 13:45 |
vila | 'resolved --done' makes sense, 'resolve --done', well, is acceptable | 13:47 |
mgz | check doesn't seem bad | 13:52 |
mgz | any other suitable names? | 13:52 |
vila | cleanup ( less good IMHO) | 13:53 |
vila | --refresh ? | 14:04 |
mgz | have we got a less lame way of creating a branch in memory than bzrlib.branchbuilder? | 14:28 |
vila | no | 14:33 |
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:34 |
vila | mgz: and keep in mind you are starting a new kind: action between merge and resolve, none of them exist IIRC | 14:35 |
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:52 |
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:53 |
mgz | nessita: is there a bug against bzr-pipeline for creating the dirstate corruption in the first place? | 14:59 |
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:00 |
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:04 |
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:08 |
mgz | bzr-pipeline | 15:09 |
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:12 |
* mgz branches the source and looks at what pump actually does | 15:13 | |
mgz | ...various aarony magic, but basically switch/merge/commit repeated | 15:17 |
nessita | mgz: bug filled at https://bugs.launchpad.net/bzr-pipeline/+bug/1030923 | 15:21 |
ubot5 | Ubuntu 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 |
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: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:blahblahblah | 15:52 |
vila | Dan_: 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 |
vila | yeah, also, you could have done the pull earlier and just push | 16:36 |
vila | with a valid use case for 'bzr revert --no-backup' (which I never recommend otherwise) | 16:37 |
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:38 |
vila | or 'bzr config' even | 16:39 |
=== deryck is now known as deryck[lunch] | ||
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:28 |
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:35 |
* vila blinks at mnn | 17:46 | |
vila | mnn: even if you quit/start explorer ? | 17:47 |
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:52 |
=== deryck[lunch] is now known as deryck | ||
mnn | bzr add obviously isn't helping (adds whole directory and its children) | 17:54 |
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:57 |
mnn | bzr add --dry-run wants to add supposedly ignored folder | 17:58 |
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:00 |
mnn | ok, thanks for the help in the meantime | 18:01 |
mnn | I can't reproduce it :( | 18:06 |
mnn | ... on a new, clean repo/branch | 18:07 |
vila | already added files are not taken into account when dealing with ignored files, this matters only for 'bzr add'ing unversioned files | 18:13 |
mnn | well... I removed the folder: 'bzr remove --keep folder' | 18:14 |
mnn | I must have broken something here | 18:14 |
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:24 |
vila | mnn: right, but displayed as unknowns there *iff* they are unversioned | 18:42 |
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. | 18:45 |
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:21 |
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:23 |
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:24 |
mnn | wait I might just have reproduced it... need to try it again | 19:26 |
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:33 |
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:34 |
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:39 |
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:46 |
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 :( | 19:49 |
txomon|home | hi, is bazaar recommended to be a DAM ? | 20:05 |
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:06 |
lifeless | bzr has the same issue git does | 20:14 |
=== iBasic is now known as BasicOSX | ||
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:21 |
mnn | also what are the exact meaning of versioned tuple? it's all fuzzy to me, what's written in InterTree.iter_changes() | 22:24 |
mnn | really? nobody? oh, come on... :( | 22:46 |
wgz | the two tuple from iter_changes? | 22:51 |
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:52 |
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:53 |
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:55 |
mnn | also why is kind (None, None) - both for old tree and new tree? | 22:56 |
wgz | it does seem a little suprising | 22:56 |
mnn | could it be because it's a directory that's ignored? | 22:57 |
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 | 22:58 |
lifeless | yes, exactly that. | 23:01 |
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:26 |
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:31 |
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:32 |
mnn | well first I need to wrap my head around whole iter_changes() and its return values for various tree states | 23:34 |
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:36 |
wgz | night! | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!