| === beuno_ is now known as beuno | ||
| txomon|home | thank you lifeless | 05:36 |
|---|---|---|
| txomon|home | but anyway, bzr can work in non-distributed mode? | 05:43 |
| txomon|home | I am talking about http://doc.bazaar.canonical.com/bzr.2.5/en/user-guide/bazaar_workflows.html?highlight=distributed#centralized-with-local-commits | 05:56 |
| txomon|home | is there any sharing of data between same elements in different branches? or is just like svn? | 06:02 |
| txomon|home | I mean when storing | 06:02 |
| bob2 | unclear what you mean | 06:07 |
| bob2 | do you mean "Do repositorities dedupe revisions common to multiple branches in that repo"? if so, yes | 06:07 |
| bob2 | ps bound branches are imvho a bad idea | 06:08 |
| === r0bby_ is now known as robbyoconnor | ||
| jelmer | moin | 08:03 |
| mgz | morning! | 08:04 |
| jam | mgz, vila, jelmer: morning | 08:07 |
| vila | morning | 08:07 |
| jam | care to join me in mumble? | 08:08 |
| vila | <shudder> bzrlib.tests.blackbox.test_serve.TestBzrServe.test_bzr_serve_supports_configurable_timeout hanging rings anyone's bell ? | 09:36 |
| vila | ha, never mind, there is a TODO in the test: TODO: Use something like signal.alarm() so that if the server doesn't | 09:37 |
| vila | # properly handle the timeout, we end up failing the test instead | 09:37 |
| vila | # of hanging forever. | 09:37 |
| vila | ...and using alarm() has been implemented indeed | 09:38 |
| mgz | alarm is dodgy | 09:40 |
| mgz | but so is our serve setup in general, so hey. | 09:41 |
| vila | the way we use it in features.TimeoutFixture should be ok though (at least on unix) | 09:43 |
| frathgeber | hi all | 09:44 |
| mgz | hi! | 09:44 |
| frathgeber | i'm (still) looking for a way to reliably interact with bzr branches through git | 09:45 |
| mgz | why? | 09:45 |
| frathgeber | because bzr doesn't have interactive rebasing | 09:45 |
| frathgeber | i know you'll hate me for that | 09:45 |
| mgz | sigh | 09:45 |
| mgz | I said that just for the rhyme | 09:45 |
| frathgeber | hehe. it's a bit heretic to come to #bzr and declare you want to use git on bzr branches, i appreciate that | 09:46 |
| mgz | well, tell us if you find a way that works for you. | 09:46 |
| vila | yeah :) Especially since what you're asking for as to be implemented in git :) | 09:47 |
| frathgeber | but maybe you can give me some advice whether my current plan could work | 09:47 |
| frathgeber | vila: yes, that's the problem | 09:47 |
| mgz | I'm curious, how often do you modify an n-2 commit vs just the n-1 commit? | 09:49 |
| tbf | what's bzr's version of "git add -p"? | 09:50 |
| frathgeber | i've given up on git-bzr-ng and all the other so-called git-bzr bridges because they use fast-im/export, which is a horribly bad idea | 09:52 |
| mgz | tbf: shelve and the 'e' option where needed, does the inverse | 09:52 |
| frathgeber | because you don't get a stable history | 09:52 |
| frathgeber | mgz: all the time. we have another project where the repo is in git and i've got so used to the workflow that i don't want to miss it when working with a bzr repo | 09:53 |
| tbf | mgz, hmm... seems my bzr is too old to have that option. | 09:53 |
| mgz | tbf: you need to have EDITOR set to something | 09:54 |
| mgz | or change_editor in bazaar.conf, see `bzr help shelve` | 09:54 |
| tbf | mzr: 2.5.1 really just says "bzr: ERROR: no such option: -e" | 09:56 |
| mgz | it's one of the things you can type during shelve, it's not a command line switch | 09:56 |
| tbf | ah! ok! | 09:56 |
| mgz | if you need to split a diff hunk into two parts, for instance | 09:57 |
| frathgeber | my current plan is as follows: 1) import the bzr branch into a git repo via fast-import 2) bzr branch the git repo so i get a bzr-git branch 3) work on the git repo 4) git push to the bzr-git branch 5) bzr push to the upstream bzr branch from the bzr-git branch | 09:57 |
| frathgeber | is that going to work? | 09:57 |
| mgz | frathgeber: ...I don't think so | 09:57 |
| frathgeber | is step 5) going to fail? | 09:58 |
| mgz | you're just making two git branches that share history, but are different to the bzr branch | 09:58 |
| frathgeber | because the fast-import will destroy the relationship, right? | 10:00 |
| mgz | right. isn't there a much simpler way? | 10:02 |
| mgz | hm... how do you tell bzr-git to create a local git branch from bzr... | 10:04 |
| tbf | how do i tell bzr to always print logs in --forward order? is there a list of all configuration options? | 10:06 |
| frathgeber | mgz: i'm not sure you can, but i'll have a look. unfortunately the docs on bzr-git are rather sparse, maybe jelmer can help | 10:16 |
| mgz | frathgeber: so, you can dpush to a branch created `bzr init --format git` | 10:29 |
| mgz | but you still have the problem that you're trying to work backwards | 10:29 |
| mgz | it would be easier for you to spend this time just making bzr-rebase do what you want. | 10:30 |
| frathgeber | you may be right | 10:30 |
| frathgeber | it just seems so silly it works fine in the one direction and not at all in the other | 10:31 |
| mgz | bzr is flexible, we can store extra stuff required for git interoperability | 10:31 |
| frathgeber | i guess the git community is to blame because they're not keen enough to interact with bzr branches | 10:32 |
| frathgeber | and launchpad | 10:32 |
| mgz | git is also flexible, but not in a way that's useful for storing extra stuff for bzr interoperability | 10:32 |
| frathgeber | yep | 10:32 |
| frathgeber | i just found another possible way: bzr serve --git (see https://bugs.launchpad.net/bzr-git/+bug/544776) | 10:39 |
| ubot5 | Ubuntu bug 544776 in Bazaar Git Plugin "no roundtripping support" [Wishlist,Triaged] | 10:39 |
| jelmer | frathgeber: bzr serve --git doesn't really work at the moment - it depends on roundtriping support | 10:49 |
| frathgeber | which is exactly what i'm looking for :) | 10:49 |
| frathgeber | so at the moment it's basically read-only? | 10:50 |
| jelmer | frathgeber: yes | 10:52 |
| frathgeber | are there any other ways to make it work? | 10:52 |
| frathgeber | i haven't found any yet. git-bzr-ng makes promises it cannot keep | 10:53 |
| jelmer | frathgeber: no, the roundtripping support is really required for this kind of thing. | 10:53 |
| frathgeber | jelmer: thanks, that was the answer i anticipated | 10:53 |
| frathgeber | does that require work in dulwich? bzr-git? both? | 10:54 |
| jelmer | frathgeber: bzr-git | 10:54 |
| jelmer | the work has mostly actually been done, but there are some smaller kinks to work out | 10:54 |
| frathgeber | anything i can beta test? | 10:54 |
| frathgeber | i'm happy to be a guinea pig | 10:55 |
| jelmer | frathgeber: see mapping.py line 457 | 10:55 |
| frathgeber | in bzr-git/trunk? | 10:55 |
| jelmer | frathgeber: yep | 10:55 |
| frathgeber | that's what your comment refers to in #544776 i guess? | 10:56 |
| jelmer | yeah | 10:57 |
| frathgeber | brilliant. i'll bash on it and report back if and when it breaks | 10:57 |
| frathgeber | what's the easiest way of experimenting with it then? via bzr serve --git? | 10:58 |
| frathgeber | or can i convert the bzr branch to a git repo via bzr-git in other ways? | 10:58 |
| mgz | you can just push into a fresh branch in git format | 10:58 |
| frathgeber | grand | 10:59 |
| mgz | followed by `bzr co` or `git reset --hard` to get a tree | 10:59 |
| mgz | (or pull, to avoid that, for that matter) | 11:00 |
| frathgeber | so getting back to the earlier conversation: will i then be able to push my changes back to the upstream bzr branch? | 11:00 |
| jelmer | frathgeber: you're welcome to report issues with the roundtripping code, but I don't think there is anybody actively working on it anymore | 11:01 |
| mgz | he's welcome to *fix* issues... :) | 11:02 |
| frathgeber | i guess via a detour of pulling into a bzr branch in bzr format and pushing upstream from there? | 11:02 |
| jelmer | frathgeber: bzr serve --git should allow pushing | 11:02 |
| frathgeber | ok | 11:02 |
| frathgeber | mgz: sure, i'll see what i can do (no promises at this point) | 11:02 |
| jelmer | frathgeber: but I doubt if that actually works | 11:02 |
| frathgeber | jelmer: i'll give it a try | 11:03 |
| frathgeber | it's not fast, so much i can already say ;) | 11:04 |
| frathgeber | should have started on a smaller repo | 11:04 |
| mgz | yeah, doesn't look hopeful: <http://pastebin.ubuntu.com/1121209/> | 11:07 |
| mgz | I might be missing a few fixes though, not sure what bzr-git version I'm running | 11:07 |
| mgz | better but no win: <http://pastebin.ubuntu.com/1121220/> | 11:15 |
| frathgeber | i've got this far: | 11:45 |
| frathgeber | http://paste.ubuntu.com/1121260/ | 11:45 |
| jelmer | frathgeber: are you running an old version of dulwich perhaps? | 11:46 |
| jelmer | another option is that this bitof bzr-git just isn't unit-tested well enough and wasn't updated | 11:46 |
| frathgeber | yep, i'm running on bzr-git trunk but dulwich 0.8.5-2 | 11:49 |
| frathgeber | will see if dulwich trunk does better | 11:49 |
| AfC | off topic, but perhaps you might know: why would pycrypto depend on a debug package (python-all-dbg in this case)? | 11:50 |
| jelmer | AfC: generally speaking, that seems like a bad idea | 11:51 |
| AfC | you would have thought so. | 11:51 |
| jelmer | AfC: this is a dependency in the binary package rather than a build-depends? | 11:51 |
| AfC | jelmer: I tried stripping it out, and sure enough the build broke. There's actually some command python-2.7-dbg or something the package tries to execute. | 11:51 |
| jelmer | AfC: if it's a build-dependency then it would make sense | 11:51 |
| AfC | jelmer: looks like a Build-Depends | 11:52 |
| jelmer | AfC: since it might want to install debug symbols in e.g. python-crypto-dbg, for those that want them | 11:52 |
| AfC | jelmer: [why does it make sense? Other languages use -dev packages for that sort of thing] | 11:52 |
| AfC | weird | 11:52 |
| AfC | anyway, thanks | 11:53 |
| jelmer | AfC: there are -dbg packages for C libraries too | 11:53 |
| AfC | sure, but you don't need them installed to build a package, no sir! | 11:53 |
| jelmer | AfC: you do need to install the dbg packages for their dependencies sometimes during build | 11:53 |
| AfC | anyway | 11:53 |
| AfC | never come across that before | 11:53 |
| AfC | </offtopic> | 11:54 |
| AfC | thanks | 11:54 |
| jelmer | AfC: sure | 11:54 |
| frathgeber | jelmer: with updated packages from the bzr nightly ppa the issue remains | 12:24 |
| jelmer | frathgeber: I guess it's just regressed :-/ I haven't touched that code in ages | 12:42 |
| frathgeber | yep. i might have a chance to look into it. but not now i'm afraid | 12:54 |
| mnn | wgz: question about RenameMap | 14:20 |
| mgz | hit me. | 14:21 |
| mnn | if user has an ignored directory in his repo, but decides to add it... but then decides to move that directory around, currently RenameMap ignores new location of that directory (even though it's that (ignored) directory that was added) | 14:22 |
| mnn | shouldn't RenameMap handle such situation and add such directory? | 14:25 |
| mgz | I'm not sure I follow, is the a commit involved too? | 14:26 |
| mgz | or is this all in pending changes? | 14:26 |
| mnn | well all without commit | 14:26 |
| mgz | but also without a state refresh? | 14:27 |
| mnn | because if there was a commit, such situation wouldn't exist | 14:27 |
| mgz | because with that, it all seems normal | 14:27 |
| mnn | well because if user manually adds such directory (bzr add --no-recurse dir) and then runs autorename, he gets "removed <old_dir>" and "added <new_dir>" | 14:28 |
| mnn | (+ renamed children of that directory) | 14:28 |
| mgz | ah, so not bzr mv, which works as intended: <http://pastebin.ubuntu.com/1121522/> | 14:29 |
| mgz | autorename isn't the most robust thing in the world | 14:29 |
| mnn | yeah... but I'm trying to make it at least a bit better :) because sometimes I move/rename things around and I'm just too lazy to do it with Bazaar (well I basically won't leave my IDE (Visual Studio) when doing this) | 14:31 |
| mgz | go for it. | 14:32 |
| mnn | or if I move/rename stuff I'm just used to use file manager rather than bazaar | 14:32 |
| mnn | *used to do it in file manager | 14:33 |
| mnn | I'm thinking of making RenameMap taking into account filenames - because I have some files that have exact contents but different filenames | 14:33 |
| mnn | and maybe make it optional | 14:34 |
| mnn | also: https://code.launchpad.net/~mnn282/bzr/sftp-unsupported-operation-more-info/+merge/116849/comments/252345 | 14:34 |
| mnn | I didn't understand this very well: | 14:34 |
| mnn | Including the path, and just using the operation name rather than the text form would work for everything but the symlink/rename case, which could just be an optional target_path param to the exception. | 14:34 |
| === joey2 is now known as nv0n | ||
| === nv0n is now known as joey | ||
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| mnn | mgz: I've adjusted RenameMap a bit to handle a bump from yesterday, however, I'm not sure about the whole old tree, new tree stuff from InterTree.iter_changes() | 16:22 |
| mnn | original code in RenameMap had this: | 16:22 |
| mnn | missing_parents.setdefault(parent[0], set()).add(file_id) | 16:22 |
| mnn | I | 16:22 |
| === AfC1 is now known as AfC|zzz | ||
| mnn | I'm not sure why would it check for parent in old tree... I changed it to parent[1] (new tree parent)... that fixed the bump from yesterday and didn't break any tests | 16:23 |
| mgz | mnn: haven't got any particular insight there, but I don't really like rename_map doing actions on the tree that change its state | 16:46 |
| === deryck is now known as deryck[lunch] | ||
| mnn | well, true but that's what dry_run is for, right? | 17:11 |
| mnn | mgz: don't you think? | 17:12 |
| mnn | and IMO it should change tree state - I mean it has to remap delete/missing files/directories to new ones (e.g. move/rename) | 17:14 |
| mgz | mnn: so, specifically I don't think _make_inventory_delta should be using tree.smart_add | 17:15 |
| mnn | well I don't like it either | 17:15 |
| mnn | but otherwise it can't create new entry correctly | 17:16 |
| mgz | it's fine that guess_renames fiddles with the tree, that's what it promises, and as you say is guarded by dry_run | 17:16 |
| mnn | because parent_id is None for new directories... that's why it has to add them | 17:16 |
| mnn | but that smart_add is not guarded by dry_run... I fixed it just now | 17:16 |
| mgz | it might mean making the logic in guess_renames two-pass | 17:16 |
| mgz | I'll think about it a bit and see if I come up with anything | 17:17 |
| mgz | no, I think one-pass is fine, you just need a level of parent indirection | 17:18 |
| mnn | hmm... that's little fuzzy to me... what do you mean by that? | 17:19 |
| mgz | the sticking point is you need a parent_id for the containing directory before you can create a delta for it's contents, right? | 17:21 |
| mnn | right | 17:21 |
| mnn | otherwise new_entry.parent_id becomes None and that causes real trouble | 17:22 |
| mgz | so, you create a delta adding the parent dir, then a pseudo-delta that refers to the parent so the add logic can lazily look up the parent id | 17:23 |
| mgz | I'd just refactor to defer entry creation till just before add | 17:24 |
| mgz | then provided you detect missing parents and insert them before children in the stream, you're all set. | 17:24 |
| mgz | so, don't put new_entry in the delta, put entry in and add a helper that does the copy and details fill in | 17:26 |
| mgz | follow me? | 17:26 |
| vila | mgz: you may not like the suggestion but this sounds like a tree transform job to ensure a safe result (as a bonus you get some sort of rollback protection) | 17:29 |
| mgz | feel free to guide mnn through doing that... | 17:29 |
| vila | yeah :-/ | 17:30 |
| vila | EOD here | 17:30 |
| vila | On the other hand, if this leads to dirstate/inventory bugs (which is what occurred when I didn't use tt for conflict resolution :-/)... | 17:31 |
| vila | tt should accept rename attempts by just feeding it with adjust_path() calls | 17:32 |
| vila | then tt.apply() should generate conflicts or a proper tree/dirstate | 17:33 |
| vila | this doesn't require ordering either | 17:34 |
| vila | oh, and there is a magic call to register trans_id... | 17:35 |
| vila | tt.trans_id_tree_path() or some variant | 17:36 |
| vila | mgz: i.e. renames are what PathConflict._resolve handle, here this may be even simpler | 17:37 |
| vila | mnn, mgz: I'll look into it tomorrow if there are some failing tests somewhere ;) | 17:40 |
| mgz | the mp is pretty simple, and includes a failing test. | 17:42 |
| mgz | see your inbox :) | 17:42 |
| mnn | mgz: I've been able to tackle that problem with adding new directory... however I can't handle this situation: | 18:18 |
| mnn | add directory (with files), move that directory under existing versioned directory | 18:18 |
| mnn | those files underneath the new directory get kind == (None, None) from InterTree.iter_changes() | 18:19 |
| mnn | and I don't think that's right - it should be kind == (None, 'file') right? | 18:19 |
| wgz | yeah, sounds more reasonable. | 18:27 |
| mnn | however this goes beyond me... that stuff is really complicated :( | 18:27 |
| mnn | could you take a look why it is returning (None, None) ? | 18:27 |
| wgz | mnn: I need to cook and stuff right now, but will poke try to have a look later on | 18:38 |
| mnn | no problem, thanks for help | 18:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!