| === wgrant_ is now known as wgrant | ||
| === BasicPRO is now known as BasicOSX | ||
| jonnydee | hi, I'm just investigating the bzr-svn plugin features and associated worklflows... | 01:01 |
|---|---|---|
| jonnydee | now I wonder how the workflow for dealing with svn branches is like...? | 01:02 |
| jonnydee | I've seen blog posts telling to branch the 'trunk', then branch from the local 'trunk' branch, commit to the latter, and finally merge to the former | 01:03 |
| jonnydee | But how can I deal with branches tracked within svn? Will it be possible to work on a svn branch using bzr-svn, and finally merging that svn branch to trunk? will it look like I did a merge from a branch to trunk using svn? | 01:05 |
| jelmer | jonnydee: hi | 01:06 |
| jonnydee | hi jelmer :) | 01:07 |
| jelmer | jonnydee: they're much like "normal" bazaar branches, and you can pull from them merge into them and push into them as you would expect to with a regular bzr branch | 01:07 |
| jonnydee | so it should be possible to emulate a branch-merge workflow of users using svn only? | 01:09 |
| jonnydee | I'm asking because we have svn, but I would like to use Bazaar and this should completely be transparent to the other svn users | 01:10 |
| jelmer | jonnydee: yes, although bzr-svn does add revision properties with bzr metadata that can't be represented in svn natively | 01:11 |
| jonnydee | jelmer: I think that shouldn't be an issue... So I would co "trunk" using bzr, do my commits to a local branch of it, then I push to svn using an svn-url pointing to ../branches/my-branch | 01:13 |
| jonnydee | then I merge my local my-branch into my local "trunk" checkout and push to svn "trunk"? | 01:14 |
| jelmer | jonnydee: there's no need for the local mirrors | 01:15 |
| jonnydee | svn users will then see my branch commits for ../branches/my-branch, and they will realize that I merged that branch into "trunk"? | 01:15 |
| jonnydee | no need for local mirrors? | 01:16 |
| jelmer | jonnydee: You'll have to push that branch into /branches/my-branch in svn manually | 01:16 |
| jelmer | jonnydee: otherwise it won't show up there in svn | 01:16 |
| jelmer | there is an option in bzr-svn to do that for you, but it's experimental | 01:17 |
| jonnydee | ok, that's what I assumed, but will they somehow realize that I finally did a merge from /branches/my-branch to /trunk ? | 01:17 |
| jelmer | not anymore than they currently will | 01:18 |
| jonnydee | AFAIK svn >1.5 does merge-tracking and I wonder if this information will be propagated when I push my merge to the svn /trunk | 01:18 |
| jelmer | bzr-svn does set svn:merge-info, but it won't use it for the bzr revision graph | 01:20 |
| jonnydee | ok, so that's good news. It means that svn users will be able to see, that I merged /branches/my-branch to /trunk, right? | 01:21 |
| maxb | yes, the metadata will be there if they care to look for it | 01:22 |
| jonnydee | jelmer,maxb: thank your very much for your fast and helpful feedback :) | 01:22 |
| maxb | I am toying with trying to get bzr-svn to build a bzr revision graph based on svn:mergeinfo | 01:26 |
| maxb | I don't think it'll ever be roundtrippable, but it would be a boon for people doing a one-time convert out of svn | 01:26 |
| jonnydee | maxb: I think that would be really helpful in such cases | 01:27 |
| jonnydee | I wish you good progress | 01:27 |
| jonnydee | it's been a pleasure to talk to you! bye, and thanks once more for your attention :) | 01:28 |
| maxb | Why does bzrlib.tag._merge_tags_if_possible exist? | 01:54 |
| maxb | I'm trying to see what functionality it provides over tags1.merge_to(tags2), and there doesn't seem to be any | 01:54 |
| spiv | maxb: it does wha tthe comment says | 01:58 |
| spiv | maxb: if you want to pass the ignore_master=True arg, but aren't sure the tags implementation supports that API (new in 2.3), then it will try pass the flag, but if it can't it emits a warning and just give the pre-2.3 behaviour (by not passing the flag). | 02:00 |
| spiv | maxb: it's backwards-compat paranoia, basically | 02:00 |
| maxb | spiv: ok..... but I know it existed before ignore_master did .... so why? Prescience? :-) | 02:01 |
| spiv | maxb: when I added the ignore_master param as part of a bug fix I added that function so that cmd_merge (and possibly other bits of bzrlib?) can use it to avoid breaking with e.g. bzr-svn branches if the user is running with an un-updated plugin. | 02:01 |
| spiv | Are you sure? | 02:01 |
| maxb | Yes, because I remember looking at its pre-ignore_master implementation, which was more obviously mystifyingly pointless | 02:02 |
| spiv | I'm pretty sure I remember adding it :) | 02:02 |
| maxb | hm :-) | 02:02 |
| spiv | Or, perhaps, updating it to be its current useful form ;) | 02:02 |
| maxb | right | 02:03 |
| spiv | But I think I added it. | 02:03 |
| * spiv looks | 02:04 | |
| maxb | no, it's existed since poolie first implemented tags in branches in 2007 :-) | 02:05 |
| spiv | Ah, well, probably a hangover from an early implementation of tags. | 02:05 |
| spiv | I'm guessing it predates the merge_to method. | 02:05 |
| spiv | Anyway, it serves a useful purpose in 2.3 :) | 02:06 |
| maxb | Now that's planning ahead :-) | 02:08 |
| chx | to roll bzr patches i am using diff --diff-options -up so that i get @@ -136,6 +136,10 @@ function user_pass_reset($form, &$form_s now this is good but now I need patches suitable for patch -p1 and this created patch -p0 patches | 02:51 |
| chx | bzr diff -p1 gives me a patch -p1 but that does not do what diff -p does (--show-c-function) | 02:56 |
| chx | there is a largely undocumented option to bzr diff: --format | 02:59 |
| fullermd | I think that's used by plugins. | 03:00 |
| chx | fullermd: hi. any solution? I am happy to hack a plugin if necessary :) just dont know where | 03:04 |
| fullermd | Well, my solution has been to point and laugh at people screaming for -p1 patches. Not sure that helps you ;) | 03:04 |
| fullermd | Does bzr's -p take effect before --using? That sounds like it would be possible... | 03:05 |
| fullermd | If possible, it probably should, and would be a bug if it didn't. And surely it's possible; where else is an external diff getting filenames but from trusting what bzr says? | 03:05 |
| chx | i am reading diff.py and external_diff has http://paste.pocoo.org/show/343131/ in it | 03:07 |
| chx | this makes me suspect that the prefix is not taken into account | 03:07 |
| fullermd | As if showing python code to me is gonna do anything :p | 03:09 |
| fullermd | I woulda approached it by just trying it to see... | 03:09 |
| spiv | You could try passing the diff throught filterdiff | 03:09 |
| spiv | It's got a --addprefix option | 03:09 |
| chx | spiv: <3 you. | 03:10 |
| chx | spiv: now, how can i tell bzr that bzr diff is alias for bzr diff --options -up | filterdiff --addprefix a/ | 03:11 |
| chx | (or more elegantly --addoldprefix a/ --addnewprefix b/ ) | 03:11 |
| spiv | chx: for that I think you need a shell alias :) | 03:11 |
| chx | spiv: sniff i need to figure out bash code that on bzr foo runs bzr foo but on bzr diff runs the aforementioned ugliness. | 03:12 |
| fullermd | Nah, just make a 'bzrdiff' alias. | 03:13 |
| chx | Aliases don't allow for control-flow, command line arguments, or additional trickery that makes the command line so useful. | 03:13 |
| spiv | Personally I'd go with fullermd's suggestion | 03:13 |
| chx | fullermd: i guess. | 03:13 |
| * fullermd still says that -p should affect external diff... | 03:14 | |
| mwhudson | bzr () { if [ "$1" = "diff" ]; then shift; command bzr diff "$@" | diffstat; else command bzr "$@"; fi; } | 03:14 |
| spiv | Because as you say making bash treat 'bzr diff' differently to 'bzr foo' is going to be fiddly, and I'm fairly lazy. | 03:14 |
| * mwhudson has been doing too much shell lately | 03:15 | |
| spiv | Or, just hang out for 3 minutes, either way. | 03:15 |
| spiv | :) | 03:15 |
| * fullermd huddles mwhudson up in the corner with a blanket and a bowl of hot soup. | 03:15 | |
| chx | thanks | 03:15 |
| mwhudson | fullermd: thanks | 03:15 |
| chx | mwhudson: good god | 03:16 |
| chx | mwhudson: thanks | 03:16 |
| chx | off to the gym | 03:16 |
| === chx is now known as chx_afk | ||
| === chx_afk is now known as chx | ||
| === chx is now known as chx_afk | ||
| === chx_afk is now known as chx_sleep | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| montywi | vila: bzr check still running (laptop with 2 cores + flash disk).... | 09:08 |
| vila | montywi: single core used, lots of CPU needed, did it output some progress (even flaky) ? | 09:09 |
| vila | montywi: or something in .bzr.log (more likely) | 09:09 |
| montywi | yes, its progressing | 09:09 |
| vila | ha good, damn, I just realized I didn't recommend -'v' :-( /me bangs head | 09:10 |
| vila | stupid stupid stupid | 09:10 |
| montywi | it's now in 'checking graphs 42000/85000 | 09:10 |
| montywi | this is increasing with 1 per 3 seconds | 09:11 |
| vila | hmm, I don't remember the order in which the checks are performed :-/ | 09:11 |
| vila | 1 out of the 85 000 ? O_o | 09:11 |
| vila | 85.000 more or less correspond to the number of revisions ? | 09:12 |
| vila | (not the mainline revs, all the revisions I mean) | 09:12 |
| montywi | i think so | 09:17 |
| montywi | so if it continues like now, it will take 43000*3 seconds more to do the check | 09:17 |
| montywi | or 1.5 days | 09:17 |
| montywi | (for this stage) | 09:17 |
| vila | yeah, for this stage :-/ | 09:18 |
| vila | on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ? | 09:19 |
| vila | montywi: the format used is 2a right ? | 09:20 |
| montywi | yes | 09:23 |
| vila | on both counts ? | 09:23 |
| montywi | both counts ? | 09:23 |
| vila | on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ? | 09:23 |
| montywi | no problem found with repro during the last 2 days | 09:24 |
| vila | k | 09:24 |
| montywi | but i will continue to do rsync backups to be able to repeat any problems that is found | 09:24 |
| vila | of course 2 days (or even 3) is ridiculously too long for a check... | 09:24 |
| vila | thanks | 09:24 |
| vila | montywi: before I forget and in case you need to re-run a check (cough, hopefully not) use BZR_LOG=<different-one> bzr check -v | 09:26 |
| montywi | ok and thanks for tip | 09:26 |
| vila | montywi: so we get a clean log with all collected data (-v shouldn't make it really slower ;-/) | 09:26 |
| montywi | i would like to use the laptop after 2 weeks... | 09:27 |
| vila | oh good, Apple will be announcing some new models tomorrow, you'll be able to buy a new one, no problem :-} | 09:28 |
| vila | <desperate sarcasm/> | 09:28 |
| montywi | Apple? Why on earth would I want to buy an Apple? I am using *real* machines ;) | 09:35 |
| montywi | (Machines which software I can use, modify and extend without having to talk with lawyers) | 09:36 |
| vila | oh, but you can install Ubuntu on them :D | 09:36 |
| Tak | actually, ubuntu is really nice on my macbook pro | 10:45 |
| vila | jelmer: make sure you always mentions bug numbers in news entries (how a veteran packager can miss that is beyond my understanding ;-D) | 11:54 |
| * vila lunch | 11:54 | |
| jelmer | vila: *nod* | 11:55 |
| jelmer | vila: did I miss one somewhere? | 11:55 |
| vila | jelmer: hmm, yes, but... I can't remember where right now :-( if you don't find it, don't worry, I'll fix it at release time anyway | 11:56 |
| vila | I noticed it yesterday if that helps, may be already landed, not sure | 11:56 |
| * vila really out :) | 11:57 | |
| jelmer | bon appetit :) | 11:59 |
| shakaran | Hi, Where I can delete the config for bazaar explorer with Windows XP? | 12:16 |
| shakaran | bzr: ERROR: bzrlib.util.configobj.configobj.ParseError: Invalid line at line "1" with bzr 2.3.0 and I need delete de .conf file or whatever file that store the corrupt file | 12:19 |
| shakaran | somebody? | 12:21 |
| jelmer | shakaran: hi | 12:22 |
| jelmer | shakaran: it's either the .bzr/branch/branch.conf file or the locations.conf or bazaar.conf in your bzr home directory | 12:22 |
| shakaran | I have a C:\Archivos de programa\Bazaar for bzr home directory | 12:25 |
| shakaran | I search *.conf files but it dont found any file with conf | 12:25 |
| shakaran | Archivos de programas = Program files (sorry for the spanish) | 12:26 |
| shakaran | I have all my local branch's with Eclipse on C:\workspace If I search .conf file there I get: | 12:27 |
| shakaran | a branch.conf with: | 12:27 |
| shakaran | parent_location = ../../Earth%20Wars/ | 12:28 |
| shakaran | push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/ | 12:28 |
| shakaran | submit_branch = file:///C:/workspace/Earth%20Wars/ | 12:28 |
| shakaran | [commit_data] | 12:28 |
| jelmer | hmm, that all looks reasonable | 12:29 |
| shakaran | I have other 3 files with branch.conf | 12:29 |
| shakaran | parent_location = ../../Earth%20Wars/ | 12:29 |
| shakaran | push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/ | 12:29 |
| shakaran | [commit_data] | 12:29 |
| === Ursinha-afk is now known as U | ||
| shakaran | third file: | 12:30 |
| === U is now known as Ursinha | ||
| shakaran | bound_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/ | 12:30 |
| shakaran | bound = True | 12:30 |
| shakaran | parent_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/ | 12:30 |
| shakaran | submit_branch = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/ | 12:30 |
| shakaran | [commit_data] | 12:30 |
| shakaran | last file: | 12:30 |
| shakaran | bound_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/ | 12:30 |
| shakaran | bound = True | 12:30 |
| shakaran | (sorry about the flooding) | 12:30 |
| jelmer | shakaran: only the file in the branch you were working in should be relevant | 12:31 |
| shakaran | I dont see the problems on line 1 for the files. The problem is that bzr-explorer fails on start with a bug | 12:32 |
| shakaran | http://pastebin.com/azDjMfjm | 12:33 |
| shakaran | it dont show the invalid file, so I dont know what file is it bad parsed | 12:33 |
| jelmer | shakaran: one sec, I'll look at the source | 12:41 |
| jelmer | shakaran: do you have a qbzr.conf file anywhere? | 12:42 |
| shakaran | on whick folder should be? on bzr home? | 12:44 |
| shakaran | I report the bug too https://bugs.launchpad.net/bzr/+bug/723691 | 12:44 |
| shakaran | not found a qbzr.conf (on all system) | 12:45 |
| jelmer | shakaran: It seems like a qbzr issue, hopefully one of the qbzr folks can help out | 12:48 |
| shakaran | jelmer: I report the bug, I wait then, thanks for your great help | 13:08 |
| vila | jelmer: that one: https://code.launchpad.net/~jelmer/bzr/multiprocessing-cpu_count/+merge/50812 | 13:47 |
| jelmer | vila: Will fix - thanks for the reminder :) | 13:48 |
| vila | np ;) | 13:52 |
| === chx_sleep is now known as chx | ||
| jml | how can you tell what commands a plugin provides? | 13:59 |
| jelmer | jml: bzr help commands | grep plugin-name | 14:01 |
| jelmer | jml: I don't think we have anything fancier than that to discover it | 14:02 |
| jml | jelmer: thanks. | 14:02 |
| jml | jelmer: I have just discovered how awesome bzr-stats is. | 14:03 |
| jelmer | jml: :) | 14:06 |
| jelmer | it could be a lot more awesome though | 14:06 |
| jml | Yeah, agreed. | 14:06 |
| jml | I was just thinking, wouldn't it be nice if I could run a command and have it tell me how actively developed this project is | 14:07 |
| jelmer | jml: Ohloh-style, e.g.: | 14:07 |
| jelmer | "Decreasing year-over-year activity." / "Large development team" / ... ? | 14:08 |
| jml | yeah, maybe | 14:09 |
| jml | well, actually that would be pretty cool | 14:09 |
| jml | but also something like "6 commits to trunk in the last month" | 14:09 |
| jml | or maybe a little ascii art graph of num commits per chunk of time | 14:10 |
| jelmer | ah, hmm | 14:10 |
| jelmer | I quite like the (new?) blurb on the code.launchpad.net/PROJECT pages with that data | 14:10 |
| jml | yeah | 14:12 |
| jml | it's not that new, I think. | 14:12 |
| jelmer | jml: didn't launchpad also have tiny graphs with the branch activity for a while? | 14:13 |
| jml | jelmer: it did. | 14:13 |
| jelmer | jml: Do you know why that was removed? | 14:13 |
| jml | jelmer: we removed them because showing them on a branch listing for a project is generally uninteresting | 14:14 |
| jml | and that's where they were shown | 14:14 |
| jml | e.g. all of the branches for bzr will have almost exactly the same graph | 14:14 |
| jml | because they are all short-lived branches of trunk. | 14:14 |
| jml | jelmer: and so rather than rehabilitate the feature, we killed it. | 14:14 |
| jelmer | ah, ok | 14:15 |
| vila | jml: any feedback about bzrlib.transform.orphan_policy=move ? | 14:17 |
| jml | jelmer: do you know how to tell bzr-stats that two people are the same? | 14:17 |
| jml | vila: no. I'm a loser. | 14:17 |
| jml | vila: do I just add that line to my bazaar.conf? | 14:18 |
| vila | jml: yup | 14:18 |
| vila | bzr.transform.orphan_policy=move | 14:18 |
| vila | grr don't paste ! | 14:18 |
| jelmer | jml: it looks for similar email addresses/fullnames | 14:18 |
| vila | :) | 14:18 |
| jml | vila: thanks. added, will let you know how it goes. (I have a couple of branches up that delete directories) | 14:19 |
| jelmer | jml: it doesn't support a rename map of any sort (yet) | 14:19 |
| jml | jelmer: ahh ok. | 14:19 |
| vila | jml: cool, will fix any related bug | 14:19 |
| vila | jml: especially the ones with reproducing recipes ;) | 14:20 |
| jml | vila: heh. will do. :) | 14:20 |
| jml | jelmer: I have now filed many bugs on bzr-stats. I might actually try to fix them, but, you know how it is. | 14:22 |
| === Vorpal_ is now known as Vorpal | ||
| jelmer | jml: :) | 14:30 |
| jml | jelmer: I also just filed a bug asking for reviewer stats. I think that's kind of a tough one that might require some kind of hook thing. | 14:30 |
| jelmer | jml: with regard to reviewers, I think it would be really nice if we can start sticking them in a revision property | 14:30 |
| jml | +1 | 14:30 |
| jelmer | jml: https://bugs.launchpad.net/bzr/+bug/723740 | 14:37 |
| chx | jelmer: hi. Am I having the honor to talk to the author of bzr-git :) ? If yes, then https://bugs.launchpad.net/bzr-git/+bug/719238 what does this... mean? there is support for push now but it's experimental and shouldnt be...? | 14:38 |
| jelmer | chx: hi :) | 14:43 |
| jelmer | chx: looking.. | 14:47 |
| jelmer | chx: so, there has been some initial work on proper push (as opposed to dpush) but it's not ready for prime time use yet | 14:48 |
| jelmer | chx: it should by default be disabled but doesn't appear to be | 14:48 |
| chx | ah i see | 14:49 |
| chx | next question, when i use bzr git-import http://git-testing.drupal.org/project/drupal.git it creates an empty directory with .bzr in it | 14:50 |
| chx | oh it created a repo? | 14:50 |
| jhunt | Hi - can someone help me out with bug 723735? It's blocking me from submitting code prior to todays feature freeze. | 14:53 |
| ubot5 | Bug 723735 on http://launchpad.net/bugs/723735 is private | 14:53 |
| chx | jelmer: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study.html from reading this i am under the impression that bzr git-import http://git-testing.drupal.org/project/drupal.git should actually download something but it dosnt. | 14:54 |
| jelmer | jhunt: I can't see that bug because it's private. | 14:55 |
| jelmer | chx: It should, but that URL is a bit strange (it gives me a 404) | 14:55 |
| chx | jelmer: weird. git clone works with it unless i am blind. | 14:55 |
| chx | jelmer: yeah it does | 14:56 |
| chx | AH ha! | 14:56 |
| chx | jelmer: that's a git:// url | 14:56 |
| chx | jelmer: it's just that git ... works with http | 14:57 |
| chx | bzr git-import git://git-testing.drupal.org/project/drupal.git is downloading. | 14:57 |
| jelmer | chx: can you file a bug against bzr-git? | 14:57 |
| chx | jelmer: https://bugs.launchpad.net/bzr-git/+bug/723751 | 14:58 |
| jelmer | ah, I think I see what's happening | 15:02 |
| jhunt | jelmer: yes - the bug was created as private by default, but I am unclear as to why. | 15:02 |
| jelmer | jhunt: can you make it public or pastebin the information you can make public? | 15:08 |
| === Ursinha is now known as Ursinha-lunch | ||
| vila | jhunt: I often see bug created private when apport is involved... | 15:09 |
| === chx is now known as chx_afk | ||
| jhunt | jelmer: bug 723735 is now public | 15:18 |
| ubot5 | Launchpad bug 723735 in bzr (Ubuntu) "bzr crashed with NoSuchRevision in _translate_error()" [Undecided,New] https://launchpad.net/bugs/723735 | 15:18 |
| === marienz_ is now known as marienz | ||
| jelmer | jhunt: so, it seems like the "-v" is the bit that breaks | 15:26 |
| jelmer | jhunt: does it still break if you run without -v ? | 15:26 |
| jhunt | jelmer: well, I just pushed the same branch using "bzr push -v lp:~jamesodhunt/+junk/foo" and that was fine ? | 15:35 |
| vila | jhunt: no stacking involved in +junk | 15:36 |
| jelmer | jhunt: I guess it's stacking related. | 15:36 |
| jelmer | hmm, gmta :) | 15:36 |
| jelmer | jhunt: can you perhaps try with the latest bzr (2.3.0) ? | 15:37 |
| === deryck is now known as deryck[lunch] | ||
| vila | jelmer: You haven't (yet) used the lazy registration of branch formats in the foreign plugins right ? | 15:56 |
| vila | jelmer: argh, gmta again, loom trunk: branches have diverged :D | 15:57 |
| vila | jelmer: additional tweak pushed | 16:01 |
| jelmer | vila: I have, bzr-{hg,svn,git} use it | 16:01 |
| jelmer | vila: it's not in any releases yet though, so changing things should be possible | 16:02 |
| vila | jelmer: while you're warmed up, care to use it for looms too ? | 16:02 |
| vila | jelmer: do you remember if jam is already moving today ? | 16:03 |
| === Ursinha-lunch is now known as Ursinha | ||
| jelmer | vila: sure, I'd be happy to | 16:08 |
| jelmer | vila: I'm not sure | 16:08 |
| bialix | heya all | 16:08 |
| vila | heya bialix | 16:09 |
| jelmer | hey bialix, how's your day? | 16:09 |
| bialix | jelmer: I wish something better | 16:09 |
| vila | jelmer: could you give your input on https://code.launchpad.net/~vila/bzr/config-expand-options/+merge/50355 ? | 16:09 |
| bialix | vila: if you have a minute to talk about configs and qbxt | 16:09 |
| bialix | qbzr | 16:09 |
| vila | don't ask to ask :) | 16:10 |
| vila | Pushed up to revision 404. | 16:11 |
| vila | Huh ? What do you mean file not found ? | 16:11 |
| vila | errr | 16:11 |
| vila | :) | 16:11 |
| bialix | vila: currently qbzr/lib/util.py has its own Config object which is kinda caching object | 16:11 |
| bialix | it does not try to re-read the real config every time | 16:11 |
| bialix | *Config class | 16:12 |
| bialix | it's used to work with qbzr.conf | 16:12 |
| bialix | this class is using to work with qbzr.conf | 16:12 |
| jelmer | vila: sure | 16:12 |
| bialix | vila: what I need to switch to using bzrlib.config instead | 16:13 |
| vila | bialix: looking at it, it seems to have anticipated bzrlib.config.LockableConfig... except save is explicit | 16:13 |
| vila | hmm, and {set|get}_option here is {set|get}_user_option there :-/ | 16:14 |
| vila | wow, and BOOKMARKS | 16:14 |
| vila | bialix: forget it, too early to migrate | 16:15 |
| === beuno is now known as beuno-lunch | ||
| bialix | vila: forget what? | 16:24 |
| bialix | sorry, I had a call | 16:24 |
| vila | bialix: qbzr needs to save only once, this is not yet available (unless you don't want atomicity anymore) | 16:25 |
| vila | so you can't migrate yet... unless | 16:25 |
| bialix | vila: I don't think it's the main goal | 16:25 |
| vila | ha, ok | 16:25 |
| bialix | it saves data here and there all the time | 16:25 |
| bialix | no atomicity, as I can see | 16:25 |
| vila | another point to consider: | 16:26 |
| bialix | I need to dig through the history of that code to understand why it written in the way it's written | 16:26 |
| vila | instead of using a separate config file, you may want to prefix your options with 'qbzr.' | 16:26 |
| bialix | :-/ | 16:27 |
| vila | and use bazaar.conf or branch.conf | 16:27 |
| bialix | that'd be bad | 16:27 |
| bialix | maxb recently said against this | 16:27 |
| jelmer | vila: I'll have a look at the expand options branch and your udd MPs when I get back | 16:27 |
| vila | that would mean that in the future, some options may be defined in branch.conf, locations.conf, bazaar.conf | 16:27 |
| bialix | actually I don't like how it's designed today | 16:27 |
| vila | bialix: not for all variables | 16:27 |
| vila | jelmer: great | 16:27 |
| bialix | we have a lot of runtime variables which is not user editable | 16:28 |
| vila | jelmer: err, back from what ? :D | 16:28 |
| jelmer | vila: need to run some errands | 16:28 |
| vila | jelmer: np was kidding :) | 16:28 |
| maxb | The thing I objected to was 'bzr viz' storing window sizes in pixels in bazaar.conf, thus making it impractical to version-control my bazaar.conf | 16:28 |
| vila | maxb: yup, I understood that | 16:28 |
| bialix | maxb: exactly | 16:28 |
| bialix | vila: ^ see | 16:28 |
| vila | bialix: see ^ :D | 16:29 |
| bialix | vila: I don't like how we store our data in qbzr.conf | 16:29 |
| vila | that doesn't mean it applies to *all* qbzr config options ;) | 16:29 |
| bialix | yes, of course | 16:29 |
| bialix | there are about 5-10 options which are not pixels | 16:29 |
| maxb | I think it's fine for plugins to rewrite bazaar.conf so long as they only do it in response to the user actually reconfiguring sometime | 16:29 |
| maxb | *something | 16:29 |
| vila | yeah, I'll go as far as saying that 'bzr config' should be almost the only one to modify config options | 16:30 |
| bialix | if we start talking about bzr-explorer then it has a ton of options grouped into subdir | 16:30 |
| vila | the execptions being --remember, window sizes, bookmarks, aliases, but even bookmarks and aliases should be defined with 'bzr config' and just use special names | 16:31 |
| vila | bialix: I discovered that a couple of days ago, but most of them are in xml files | 16:31 |
| vila | there is one horror there still, file extensions are associated with executables by using the list of extensions as the key and the application as the value... | 16:32 |
| bialix | vila: I'm very dislike code like that in the qbzr: | 16:32 |
| vila | I wonder why it's not the reverse... | 16:32 |
| bialix | config.set_option(name + "_window_size", "%dx%d" % size) | 16:33 |
| bialix | config.set_option(name + "_window_maximized", is_maximized) | 16:33 |
| bialix | size = config.get_option(name + "_window_size") | 16:33 |
| bialix | those concatenations make me feel bad | 16:33 |
| vila | bialix: use helpers | 16:34 |
| vila | and dots instead of _ | 16:34 |
| bialix | no, I'm trying to say: why we haven't put them into subsections | 16:34 |
| vila | if you start thinking about option names as python identifiers | 16:35 |
| bialix | or even into database | 16:35 |
| bialix | registry | 16:35 |
| vila | eeerk | 16:35 |
| bialix | and so on | 16:35 |
| vila | no subsections please | 16:35 |
| bialix | that's bad | 16:35 |
| vila | I don't think we need more than python identifiers here | 16:35 |
| bialix | I can't agree | 16:35 |
| vila | that's far more user friendly than subsections with [[[[[very embbeded section]]]]]] | 16:36 |
| bialix | bzrlib.config has hidden ConfigObj too deeply | 16:36 |
| vila | not enough obviously | 16:36 |
| bialix | I need only one layer down | 16:36 |
| bialix | every q-window should have dedicated section | 16:36 |
| bialix | for their pixel settings | 16:37 |
| vila | qbzr.<window_name>.size | 16:37 |
| bialix | great! can I have one of this? | 16:37 |
| vila | just do it ! | 16:37 |
| vila | it works today ! | 16:37 |
| bialix | really? | 16:37 |
| bialix | in 2.3? | 16:37 |
| vila | in 2.0 even | 16:37 |
| bialix | ??? | 16:37 |
| vila | '.' has always been valid in an option name | 16:38 |
| bialix | I never seen it | 16:38 |
| bialix | ha | 16:38 |
| bialix | you again put me bacj | 16:38 |
| bialix | back | 16:38 |
| vila | ? | 16:38 |
| bialix | one sec, I'm pastebining | 16:38 |
| bialix | vila: http://pastebin.com/XQ9PiW7P | 16:39 |
| bialix | do you like it? | 16:40 |
| bialix | I'm NOT | 16:40 |
| bialix | that's a mess | 16:40 |
| bialix | sorry for my french | 16:40 |
| vila | :) | 16:40 |
| vila | Yeah and the user has no idea who is spamming his config file... | 16:41 |
| vila | subsections won't make it less spammy | 16:41 |
| bialix | the syntax you have shown "qbzr.<window_name>.size" recalls me about git configs | 16:41 |
| vila | just because it's like git doesn't mean it's bad | 16:41 |
| bialix | dot syntax is using to navigate through sections, IIRC | 16:41 |
| vila | no, sections are used for something else ! | 16:42 |
| vila | that's the whole point | 16:42 |
| bialix | I thought you said we can navigate through our sections as well | 16:42 |
| vila | if you use sections to define the name space you can't reuse it to define values for more specific cases | 16:42 |
| bialix | let's draw a line: I want those automatic pixel settings to be stored separately of user options | 16:42 |
| vila | 'specific' can be a path, a user name, an url, whatever | 16:42 |
| bialix | vila: so I need [GEOMETRY] section and q-window names as subsections | 16:43 |
| vila | bialix: right, put them in a qbzr.windows.conf file then | 16:43 |
| vila | haaa | 16:43 |
| vila | scratch above | 16:43 |
| bialix | qbzr.internals.pixels.settings.dont.edit.it.please.and.even.dont.look.inside.conf | 16:43 |
| maxb | What do we use sections for at the moment, other than locations.conf ? | 16:43 |
| vila | a qbzr.windows.conf with window names as sections then | 16:43 |
| vila | maxb: nothing, exactly my point ;) | 16:44 |
| maxb | oh, and branch.conf [commit_data] | 16:44 |
| bialix | yep, famous commit_data | 16:44 |
| vila | maxb: kill that one, I don't even want to know it has ever existed :) | 16:44 |
| bialix | (palm face) | 16:44 |
| vila | bialix: windows size are user specific right ? It's a bit sad it can't be project or even branch specific no ? | 16:45 |
| * bialix wonders where is the Gary. maybe in the long and sunny vacation on Taiti | 16:45 | |
| bialix | vila: yep | 16:45 |
| vila | nahhh, in a basement with someone whipping him | 16:46 |
| bialix | nm | 16:46 |
| vila | hmm | 16:46 |
| vila | then no sections for window names :) | 16:47 |
| vila | you can do as locations.conf and use path as section names instead | 16:47 |
| vila | one planned feature for configs is that the sections (from path) would be allowed in bazaar.conf to act as default values (as opposed to overriding values in locations.conf) | 16:48 |
| bialix | vila: so far nobody compains about pixels settings to be non-project adjustable | 16:48 |
| * vila nods | 16:49 | |
| bialix | vila: I want to extract pixel settings out of qbzr.conf, that's my long standing desire | 16:50 |
| bialix | I'm not sure I need conf file for them even | 16:51 |
| vila | config files are for text values that a user may want to edit, ... yeah | 16:51 |
| bialix | yep | 16:52 |
| vila | but you need some sort of persistence | 16:52 |
| bialix | of course | 16:52 |
| vila | so putting them in a different file with a comment: '# Sorry guys, not for you to edit' could work | 16:53 |
| bialix | so COnfigObj with subsections provides me a good hierarchy store | 16:53 |
| bialix | I'm not very good in sqlite | 16:53 |
| vila | why would you care about how it's represented in the file if you don't intend to edit it ? | 16:53 |
| bialix | sometimes I need to edit it | 16:54 |
| === deryck[lunch] is now known as deryck | ||
| bialix | maybe to test something or to workaround something | 16:54 |
| vila | the dotted notation works quite well for python modules why not for you ? | 16:54 |
| bialix | the paste I've shown | 16:54 |
| bialix | the options are not grouped toghethre | 16:54 |
| bialix | so it's harder to read and analyze | 16:55 |
| bialix | for me as qzbr dev | 16:55 |
| vila | sorry ? you mean you want them sorted by what criteria ? | 16:55 |
| bialix | by window name of course | 16:55 |
| bialix | they're essentially grouped | 16:56 |
| bialix | but not in the file | 16:56 |
| vila | err, the file you pasted is grouped by window name... | 16:56 |
| bialix | 'cause config preserves the order | 16:56 |
| bialix | no, it's not | 16:57 |
| bialix | look for explorer_ | 16:57 |
| bialix | they're spread | 16:57 |
| bialix | they're spread across the lines | 16:58 |
| bialix | ditto re log | 16:58 |
| bialix | and I think diff as well | 16:58 |
| bialix | sometimes I edit it to test something | 16:58 |
| bialix | sometimes it's for different reason | 16:58 |
| bialix | but my point: there are 75 lines of different settings | 16:59 |
| vila | well, that's your file :) | 16:59 |
| bialix | yeah, why not | 16:59 |
| vila | I meant, you're free to organize it as you see fit, we already agree it's not really user oriented | 17:00 |
| bialix | qbzr.conf is twofold today | 17:01 |
| bialix | there are user settings as well. I simply omit them when pasting | 17:01 |
| bialix | while pasting | 17:01 |
| bialix | vila: I raise this question because of new patch submission: https://code.launchpad.net/~nick-sonneveld/qbzr/fix-258926/+merge/50862 | 17:02 |
| bialix | it touches the same grey area | 17:02 |
| bialix | some qbzr options are about appearance, some about behavior | 17:03 |
| vila | well, the in (True, 1) is a subset of get_user_option_as_bool | 17:03 |
| bialix | yep | 17:03 |
| bialix | reinventing the wheel for fun and profit | 17:03 |
| bialix | ok, | 17:04 |
| bialix | I need to go home now, I'd like to continue this rant later | 17:04 |
| vila | but yeah, the behavior is a good candidate for branch.conf and this route is via qbzr.<window name?>.versioned_files.show | 17:04 |
| bialix | I need to think more | 17:04 |
| * bialix disappears | 17:05 | |
| vila | except you'll need to find a way for the user to decide in which conf file the changes are recorded | 17:05 |
| vila | too lat :) | 17:05 |
| vila | e | 17:05 |
| === beuno-lunch is now known as beuno | ||
| === chx_afk is now known as chx | ||
| CoffeeIV | Is there a general way I can undo a "bzr up" if I need to ? The situation is a live web site maintained under bzr version control. I think "bzr revert" would un-do edits I made, but if I note a revision number, is there a quick way to back out of a "bzr up" if I need to ? | 18:38 |
| chx | CoffeeIV: you can bzr up -r somepreviousrev | 18:42 |
| chx | CoffeeIV: i recommend setting a tag before upping and hten it's easy to back down | 18:42 |
| CoffeeIV | chx: ok, I will figure out how to do the tag. Thanks ! | 18:42 |
| chx | CoffeeIV: bzr tag whatever :) and then bzr up -r tag:whatever | 18:43 |
| chx | CoffeeIV: this is bzr, everything is trivial (until you do something as silly as i did two days ago and even that it was two commands to fix it, lol) | 18:43 |
| Tak | that's what I love about bzr | 18:44 |
| Tak | none of this 10 commands, each with 3 optional arguments and nondeterministic side effects, to accomplish a straightforward task | 18:45 |
| chx | yessss | 18:46 |
| beuno | http://git-annex.branchable.com/ | 19:40 |
| beuno | that looks interesting | 19:40 |
| Tak | looks similar to mercurial's bfiles extension | 19:42 |
| jaypipes | anybody know how to find out who removed or renamed a file that was at one time under bzr source control? | 20:09 |
| vila | beuno: damn it | 20:21 |
| vila | beuno: that's on my TODO list for months, far low unfortunately | 20:23 |
| beuno | vila, WORK FASTER | 20:23 |
| beuno | :) | 20:23 |
| vila | :-} | 20:25 |
| === Ursinha` is now known as Ursinha-afk | ||
| === BasicPRO is now known as BasicOSX | ||
| === fredp_ is now known as fredp | ||
| === joey` is now known as joey-tosh | ||
| === beuno is now known as 84XAAAATU | ||
| === Ursinha-afk is now known as Guest72054 | ||
| thumper | $ bzr revno :push | 23:29 |
| thumper | bzr: ERROR: Unsupported protocol for url "lp:~thumper/launchpad/lp-client-cache-move" | 23:29 |
| thumper | expected? | 23:29 |
| thumper | wasn't to me | 23:29 |
| thumper | $ bzr revno lp:~thumper/launchpad/lp-client-cache-move | 23:30 |
| thumper | 12445 | 23:30 |
| bob2 | is it a "lp: urls when you're not logged in are http://" issue? | 23:30 |
| thumper | nope | 23:30 |
| thumper | it seems that if you try to use a branch alias, it isn't expanding the branch | 23:30 |
| === chx is now known as chx_sleep | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!