[01:01] <jonnydee> hi, I'm just investigating the bzr-svn plugin features and associated worklflows...
[01:02] <jonnydee> now I wonder how the workflow for dealing with svn branches is like...?
[01:03] <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:05] <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:06] <jelmer> jonnydee: hi
[01:07] <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:09] <jonnydee> so it should be possible to emulate a branch-merge workflow of users using svn only?
[01:10] <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:11] <jelmer> jonnydee: yes, although bzr-svn does add revision properties with bzr metadata that can't be represented in svn natively
[01:13] <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:14] <jonnydee> then I merge my local my-branch into my local "trunk" checkout and push to svn "trunk"?
[01:15] <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:16] <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:17] <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:18] <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:20] <jelmer> bzr-svn does set svn:merge-info, but it won't use it for the bzr revision graph
[01:21] <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:22] <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:26] <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:27] <jonnydee> maxb: I think that would be really helpful in such cases
[01:27] <jonnydee> I wish you good progress
[01:28] <jonnydee> it's been a pleasure to talk to you! bye, and thanks once more for your attention :)
[01:54] <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:58] <spiv> maxb: it does wha tthe comment says
[02:00] <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:01] <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:02] <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:03] <maxb> right
[02:03] <spiv> But I think I added it.
[02:04]  * spiv looks
[02:05] <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:06] <spiv> Anyway, it serves a useful purpose in 2.3 :)
[02:08] <maxb> Now that's planning ahead :-)
[02:51] <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:56] <chx> bzr diff -p1 gives me a patch -p1 but that does not do what diff -p does (--show-c-function)
[02:59] <chx> there is a largely undocumented option to bzr diff: --format
[03:00] <fullermd> I think that's used by plugins.
[03:04] <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:05] <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:07] <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:09] <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:10] <chx> spiv: <3 you.
[03:11] <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:12] <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:13] <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:14]  * 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:15]  * 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:16] <chx> mwhudson: good god
[03:16] <chx> mwhudson: thanks
[03:16] <chx> off to the gym
[09:08] <montywi> vila: bzr check still running (laptop with 2 cores + flash disk)....
[09:09] <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:10] <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:11] <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:12] <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:17] <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:18] <vila> yeah, for this stage :-/
[09:19] <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:20] <vila> montywi: the format used is 2a right ?
[09:23] <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:24] <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:26] <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:27] <montywi> i would like to use the laptop after 2 weeks...
[09:28] <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:35] <montywi> Apple? Why on earth would I want to buy an Apple?  I am using *real* machines ;)
[09:36] <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
[10:45] <Tak> actually, ubuntu is really nice on my macbook pro
[11:54] <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:55] <jelmer> vila: *nod*
[11:55] <jelmer> vila: did I miss one somewhere?
[11:56] <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:57]  * vila really out :)
[11:59] <jelmer> bon appetit :)
[12:16] <shakaran> Hi, Where I can delete the config for bazaar explorer with Windows XP?
[12:19] <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:21] <shakaran> somebody?
[12:22] <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:25] <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:26] <shakaran> Archivos de programas = Program files (sorry for the spanish)
[12:27] <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:28] <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:29] <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:30] <shakaran> third file:
[12:30] <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:31] <jelmer> shakaran: only the file in the branch you were working in should be relevant
[12:32] <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:33] <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:41] <jelmer> shakaran: one sec, I'll look at the source
[12:42] <jelmer> shakaran: do you have a qbzr.conf file anywhere?
[12:44] <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:45] <shakaran> not found a qbzr.conf (on all system)
[12:48] <jelmer> shakaran: It seems like a qbzr issue, hopefully one of the qbzr folks can help out
[13:08] <shakaran> jelmer: I report the bug, I wait then, thanks for your great help
[13:47] <vila> jelmer: that one: https://code.launchpad.net/~jelmer/bzr/multiprocessing-cpu_count/+merge/50812
[13:48] <jelmer> vila: Will fix - thanks for the reminder :)
[13:52] <vila> np ;)
[13:59] <jml> how can you tell what commands a plugin provides?
[14:01] <jelmer> jml: bzr help commands | grep plugin-name
[14:02] <jelmer> jml: I don't think we have anything fancier than that to discover it
[14:02] <jml> jelmer: thanks.
[14:03] <jml> jelmer: I have just discovered how awesome bzr-stats is.
[14:06] <jelmer> jml: :)
[14:06] <jelmer> it could be a lot more awesome though
[14:06] <jml> Yeah, agreed.
[14:07] <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:08] <jelmer> "Decreasing year-over-year activity." / "Large development team" / ... ?
[14:09] <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:10] <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:12] <jml> yeah
[14:12] <jml> it's not that new, I think.
[14:13] <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:14] <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:15] <jelmer> ah, ok
[14:17] <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:18] <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:19] <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:20] <vila> jml: especially the ones with reproducing recipes ;)
[14:20] <jml> vila: heh. will do. :)
[14:22] <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:30] <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:37] <jelmer> jml: https://bugs.launchpad.net/bzr/+bug/723740
[14:38] <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:43] <jelmer> chx: hi :)
[14:47] <jelmer> chx: looking..
[14:48] <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:49] <chx> ah i see
[14:50] <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:53] <jhunt> Hi - can someone help me out with bug 723735? It's blocking me from submitting code prior to todays feature freeze.
[14:54] <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:55] <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:56] <chx> jelmer: yeah it does
[14:56] <chx> AH ha!
[14:56] <chx> jelmer: that's a git:// url
[14:57] <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:58] <chx> jelmer: https://bugs.launchpad.net/bzr-git/+bug/723751
[15:02] <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:08] <jelmer> jhunt: can you make it public or pastebin the information you can make public?
[15:09] <vila> jhunt: I often see bug created private when apport is involved...
[15:18] <jhunt> jelmer: bug 723735 is now public
[15:26] <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:35] <jhunt> jelmer: well, I just pushed the same branch using "bzr push -v lp:~jamesodhunt/+junk/foo" and that was fine ?
[15:36] <vila> jhunt: no stacking involved in +junk
[15:36] <jelmer> jhunt: I guess it's stacking related.
[15:36] <jelmer> hmm, gmta :)
[15:37] <jelmer> jhunt: can you perhaps try with the latest bzr (2.3.0) ?
[15:56] <vila> jelmer: You haven't (yet) used the lazy registration of branch formats in the foreign plugins right ?
[15:57] <vila> jelmer: argh, gmta again, loom trunk: branches have diverged :D
[16:01] <vila> jelmer: additional tweak pushed
[16:01] <jelmer> vila: I have, bzr-{hg,svn,git} use it
[16:02] <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:03] <vila> jelmer: do you remember if jam is already moving today ?
[16:08] <jelmer> vila: sure, I'd be happy to
[16:08] <jelmer> vila: I'm not sure
[16:08] <bialix> heya all
[16:09] <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:10] <vila> don't ask to ask :)
[16:11] <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:12] <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:13] <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:14] <vila> hmm, and {set|get}_option here is {set|get}_user_option there :-/
[16:14] <vila> wow, and BOOKMARKS
[16:15] <vila> bialix: forget it, too early to migrate
[16:24] <bialix> vila: forget what?
[16:24] <bialix> sorry, I had a call
[16:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <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:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <bialix> vila: http://pastebin.com/XQ9PiW7P
[16:40] <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:41] <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:42] <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:43] <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:44] <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:45] <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:46] <vila> nahhh, in a basement with someone whipping him
[16:46] <bialix> nm
[16:46] <vila> hmm
[16:47] <vila> then no sections for window names :)
[16:47] <vila> you can do as locations.conf and use path as section names instead
[16:48] <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:49]  * vila nods
[16:50] <bialix> vila: I want to extract pixel settings out of qbzr.conf, that's my long standing desire
[16:51] <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:52] <bialix> yep
[16:52] <vila> but you need some sort of persistence
[16:52] <bialix> of course
[16:53] <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:54] <bialix> sometimes I need to edit it
[16:54] <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:55] <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:56] <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:57] <bialix> no, it's not
[16:57] <bialix> look for explorer_
[16:57] <bialix> they're spread
[16:58] <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:59] <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
[17:00] <vila> I meant, you're free to organize it as you see fit, we already agree it's not really user oriented
[17:01] <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:02] <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:03] <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:04] <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:05]  * 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
[18:38] <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:42] <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:43] <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:44] <Tak> that's what I love about bzr
[18:45] <Tak> none of this 10 commands, each with 3 optional arguments and nondeterministic side effects, to accomplish a straightforward task
[18:46] <chx> yessss
[19:40] <beuno> http://git-annex.branchable.com/
[19:40] <beuno> that looks interesting
[19:42] <Tak> looks similar to mercurial's bfiles extension
[20:09] <jaypipes> anybody know how to find out who removed or renamed a file that was at one time under bzr source control?
[20:21] <vila> beuno: damn it
[20:23] <vila> beuno: that's on my TODO list for months, far low unfortunately
[20:23] <beuno> vila, WORK FASTER
[20:23] <beuno> :)
[20:25] <vila> :-}
[23:29] <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:30] <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