[03:29] <Peng_> Hmm. bzrlib.plugins.search.index.index_url() should support possible_transports. cmd_index wastes a transport just to parse the URL.
[03:32] <Peng_> Or I guess index_url should just take a transport directly.
[06:30] <cammoblammo> `bzr ignored` seems to list the ignored file then the rule for identifying it. Is there any way the rule can be stripped from the output without resorting to awk or the like?
[06:36] <fullermd> Perhaps you want ls --ignored
[06:48] <cammoblammo> fullermd: Thanks! That's perfect.
[06:49] <adam> Hi
[06:50] <adam> can I set bzr to ignore .pyc on *all* newly created projects?
[06:51] <fullermd> Depends on what exactly you're asking.
[06:51] <fullermd> You can add .pyc to your personal ignores.  You could theoretically hack bzr to add .pyc system-wide.
[06:51] <fullermd> But there's no way to make a new projects spring into being with a .bzrignore handling .pyc's. no.
[06:52] <adam> ah, too bad.
[06:52] <adam> I was thinking about the ~/.subversion/config ignore settings.
[06:52] <adam> so I understand bzr doesn't have the equivalent.
[06:52] <fullermd> There's the list in ~/.bazaar/ignore that covers yourself
[06:52] <fullermd> (of course, it actually contains .pyc already...)
[06:52] <fullermd> But that doesn't do anything for other people, of course.
[06:54] <adam> fullermd: ah, awesome.
[06:54] <adam> so yeah, that would basically be the equivalent :)
[06:54] <adam> hm
[06:54] <adam> that list exists, and includes .py[co]
[06:54] <adam> yet for some reason, they aren't being ignored.
[06:55] <adam> fullermd: oh, I know what happened.
[06:55] <adam> I did `bzr add *`
[06:55] <fullermd> Ah, yeah, that would do it   :)
[06:56] <adam> fullermd: once you did `bzr init` at the root of a source tree you'd like to VC entirely, what would you do then?
[06:56] <adam> how would you add everything, every nested file and directly, except those in ~/.bazaar/ignore?
[06:56] <adam> *directory
[06:56] <fullermd> 'bzr add' by itself.
[06:56] <adam> ah, hah.
[06:57] <fullermd> 'add' with no args is what uses the ignore list.  'add' of specific files never does.
[06:57] <adam> fullermd: that's awesome.
[06:57] <adam> bzr is so convenient, I'm happy I chose it.
[06:57] <adam> thanks a bunch.
[06:58] <fullermd> np  :)
[06:58] <fullermd> (actually, I think that phrasing is a little off...)
[06:58] <fullermd> If specific files are named on the 'add' command line (e.g. "bzr add foo.pyc"), ignores have no power.
[06:59] <fullermd> If they're not ("bzr add", "bzr add somedir/"), then ignores determine which of the found files (add is recursive) get added.
[06:59]  * adam nods
[06:59] <fullermd> Guardrails without straitjackets.
[14:01] <evge> I have bzr branch on test server and want to force something like post commit hook to auto update this branch after each remote commit, so the server is serving up to date content ?
[14:04] <bob2> there's an update-after-push plugin
[14:04] <LeoNerd> .oO( Why is that a question? )
[14:04] <bob2> https://launchpad.net/bzr-push-and-update
[15:05] <mamatata_> arghh... big emergency here! did a 'bzr add' but wanted to go back to ignore some. without thinking much did a 'bzr revert' now all my changes (lots) are reverted :S anything i can do??
[15:06] <fullermd> They'll be around in backup files.
[15:07] <fullermd> whatever.~1~ or the like.
[15:08] <mamatata_> love you fuller!
[15:11] <mamatata_> is there a quick way to replace all 26 of them?
[15:12] <LarstiQ> not from bzr that I know, but with shell scripting, sure
[15:13] <mamatata_> hmm okay... gotta take a break before i erase all those with a wacky shell script...
[15:13] <LarstiQ> mamatata_: right, I suggest you cp -a your working tree before you do anything else :)
[15:14] <LarstiQ> or at the very least your backup files
[16:27] <olejorgenb> bzr ls simply lists the files in the directory?
[16:27] <olejorgenb> or have I somehow managed to add all the files
[16:28] <olejorgenb> if 1 is the case, how to I check what files are versioned? (without pulling to a empty location)
[16:30] <fullermd> ls --versioned shows which files are versioned.
[16:31] <olejorgenb> fullermd: thank. (guess that actually was pretty easy to find in the manpage. Sorry)
[16:32] <olejorgenb> what is the purpose of ls (without --versioned) though?
[16:35] <fullermd> Well, it lists the files in the tree.  With no options, it's probably not used much.
[16:35] <fullermd> It's usually used with one of the filters.
[17:17] <Lani78> I installed Loggerhead using "sudo python setup.py install". It seems to me that loggerhead want to have the loggerhead.conf in "/usr/bin". Is there anyway to have it look for the configuration file in "/etc"?
[17:19] <Lani78> It also seems that it wants to write a "loggerhead.pid" file in the /usr/bin folder. Is this really advisable? I would like to redirect that file to something like "/var/lib/loggerhead/loggerhead.pid", can that be done as well?
[17:30] <stefanlsd> does bzr have anything like  gitk ?
[17:31] <stefanlsd> bzr-gui?
[17:32] <beuno> stefanlsd, bzr-gtk
[17:32] <beuno> and qbzr
[17:32] <stefanlsd> beuno: which would u recommend?
[17:33] <beuno> stefanlsd, bzr-gtk has more features
[17:33] <beuno> so bzr-gtk  :)
[17:33] <stefanlsd> beuno: kk. thanks :)
[17:35] <nekohayo> hey, could anyone tell what went wrong? http://ecchi.ca:8000/1.png
[17:36] <beuno> nekohayo, the packs error?
[17:36] <beuno> it happens sometimes
[17:37] <nekohayo> beuno: yeah, why? and how do we fix that?
[17:37] <beuno> you just re-push and it gets fixed
[17:37] <nekohayo> beuno: are you sure? that error seems to have come up while issuing a "bzr push" command
[17:38] <beuno> nekohayo, yeap, I'm sure. It's happen to me a few times
[17:38] <beuno> we haven't quite managed to figure out what causes it
[17:38] <nekohayo> why does that happen? connection problems?
[17:38] <nekohayo> hm
[17:38] <beuno> lifeless, ^
[17:38] <nekohayo> (well, just curious)
[18:16] <zbrown> Is there a good way to bzr repo that you can push/pull from with users that don't actually have an account on the machine?
[18:32] <Lani78> zbrown: If you are still there: I created a bzr account on my server and then access it with ssh and added the users public key to the bzr account.
[18:32] <zbrown> oh I see
[18:33] <zbrown> Lani78: thats what I was thinking about doing, just wondered if anyone had other suggestions
[18:33] <Lani78> The drawback is that all users have the same access rights then.
[18:34] <Lani78> zbrown: thats the suggestion that I got some weeks back, but I'm fairly new to both linux and bzr, I'm learning bit by bit ;)
[18:34] <zbrown> hehe
[18:35] <zbrown> Lani78: ya, my main thing is I have one other collaborator on a project and am just looking for an easy way for us both to have access without giving out another account
[18:37] <Lani78> zbrown: I think that it would be easy to create an account for that project then, an account that doesn't have a password and that has no shell (/bin/false). And then ask your collaborator for his public ssh key so you can add both yours and his to that user account.
[18:39] <Lani78> This is manageable for small sites with few users and few projects. But I cannot use this at work, as it is to much administration. At least for me that doesn't know Linux. And access to projects changes daily. So I would love to see some nice administration tool where you easily could give read/write access to specific projects to single developers.
[18:40] <zbrown> ya
[18:40] <nekohayo> indeed, it seems that pushing again worked, beuno
[18:41] <Lani78> But I've understood that the bzr-team have tried to avoid any authentication code. They relay on the Linux or Apache for that.
[18:41] <zbrown> understandably
[18:41] <zbrown> I haven't entirely settled on bzr yet either... we'll see
[18:42] <zbrown> it could also end up as a git repo
[18:42] <Lani78> zbrown: That made me remember that someone also suggested that you could make your project available through Apache, and have Apache control the access. But I don't know how to do that.
[18:43] <Kosjer> hi there, i just wanted to ask about the mac osx 10.5 installer binary distribution  why there isnt a 1.6.1 version out yet like with the 10.4 installer version. its still at 1.5.0
[18:43] <zbrown> ya... I like to avoid apache when I can
[18:43] <zbrown> Kosjer: different maintainers and the 10.5 one probably hasn't gotten around ot it
[18:44] <Kosjer> ahhh oki doki
[18:44] <Kosjer> thx
[18:55] <uliwitness> Hi.
[18:55] <uliwitness> Is this the right place to ask about a weird message I'm getting trying to bzr push to a server?
[18:57] <uliwitness> I get a few "FTP temporary error: 451 (...) Append/Restart not permitted, try again. Retrying." and then "bzr: ERROR: Transport error: FTP temporary error during APPEND (...)" followed by the same 451 append/restart message.
[19:00] <uliwitness> It worked fine on my old FTP server, but it seems BZR's FTP and my new server don't see eye-to-eye. Is there a way I can diagnose this further?
[21:21] <ericvw> Am I able to change the committer information for previous revisions if someone's contact info changed?
[21:28] <Odd_Bloke> ericvw: No, revisions are immutable.
[21:31] <ericvw> I could do the most recent by uncommit though and then change the commiter name thought, right?
[21:32] <Odd_Bloke> Yes, provided no-one has branched from you.
[21:33] <Odd_Bloke> Because you'll be creating a new revision.
[21:43] <ericvw> Odd_Bloke: thank!
[21:47] <justdave> if I have a bzr checkout, and it's possibly been locally modified, and I want to update from the repo and overwrite whatever local changes I had, is there a way to do that with a checkout?
[21:48] <justdave> I had been doing it with "bzr pull --overwrite" before
[21:48] <lifeless> justdave: is this a valid rephrase: "I want to discard my changes and be up to date" ?
[21:48] <justdave> but when switching to a different branch at one point, blew away the checkout and checked out again
[21:48] <justdave> apparently the first one was a clone instead of a checkout and pull doesn't work on a checkout? :)
[21:48] <justdave> lifeless: yes, that's correct
[21:49] <lifeless> "bzr update; bzr revert"
[21:49] <justdave> ok, good enough. :)
[21:50] <lifeless> pull --overwrite doesn't discard uncommitted local edits, the above will
[21:50] <lifeless> which is why I rephrased for clarity
[21:51] <justdave> oh, I think I know what was going on...  because the original one was a clone, "bzr up" just updated locally and didn't actually pull anything from the upstream repo
[21:51] <justdave> --overwrite just makes pull to an update after updating the local repo doesn't it
[21:52] <justdave> so since this one is a direct checkout and not a clone, "bzr up" by itself would be equivalent to what I was doing before.
[21:52] <GaryvdM> Hi - Is it possible to split a file into 2, without losing annotate info?
[21:53] <lifeless> nearly equivalent
[21:53] <lifeless> justdave: bzr up will turn local commits into a pending merge, as part of its mission to preserve the svn/cvs 'up && commit' pattern
[21:53] <lifeless> justdave: which is why the revert command's discard of pending merges is needed to complete the reset
[21:54] <justdave> in theory there shouldn't be local edits anyway...  using it for a production website
[21:54] <lifeless> justdave: instead, using revert --forget-merges makes it equivalent to pull --overwrite
[21:54] <lifeless> GaryvdM: hi, no, not yet.
[21:54] <GaryvdM> ok
[21:54] <lifeless> justdave: cool
[21:55] <justdave> hmm, bzr update doesn't seem to take a tag/revision argument...
[21:55] <lifeless> there is a patch in the bug tracker
[21:55] <justdave> maybe that's why we did the pull thing, because it does
[21:56] <lifeless> if you want a branch that is conceptually able to differ from your trunk, use a branch not a checkout
[21:56] <justdave> the website always updates to the same tag, so we check in as needed then when it's tested and ready to go live, we move the tag and the website picks it up
[21:56] <lifeless> IMO anyhow, pull is clearer when managing a mirror
[21:56] <lifeless> justdave: ah; interesting
[21:56] <lifeless> justdave: checkouts mirror the branch; if you used a branch rather than a tag it would work
[21:57] <lifeless> one branch for dev, one for tested
[21:58] <justdave> I'll continue messing with this in a bit, need to travel, back online when I get there. :) (half hour or so)
[21:58] <justdave> thanks for the help :)
[21:59] <lifeless> np
[22:22] <GaryvdM> If I can see a way to make bzr faster, but it would require adding a parameter to and existing function
[22:23] <GaryvdM> and I could make the parameter optional
[22:24] <GaryvdM> would a patch be rejected because it changes an api?
[22:24] <lifeless> no; see HACKING for a dscription of our api management
[22:24] <lifeless> is this hypothetical, or do you have an actual case of this?
[22:24] <GaryvdM> I have a actual case
[22:24] <lifeless> care to elaborate ?
[22:25] <GaryvdM> Sure - just give me a sec
[22:28] <GaryvdM> Ok - in bzrlib/log.py
[22:29] <GaryvdM> in get_view_revisions and in _filter_revisions_touching_file_id
[22:29] <GaryvdM> we do parent_map = .... graph.iter_ancestry...
[22:29] <GaryvdM> This is slow
[22:30] <GaryvdM> I want to do it once in calculate_view_revisions
[22:30] <lifeless> ok
[22:30] <lifeless> a few news
[22:30] <lifeless> *notes*
[22:30] <GaryvdM> and pass it as a parameter to get_view_revisions and in _filter_revisions_touching_file_id
[22:30] <lifeless> firstly, log got a bit rearranged recently
[22:31] <lifeless> make sure you have the make_log_rev_iterator function in your log.py (if you have bzr.dev you're fine)
[22:31] <lifeless> hmm, are you saying that both get_view_revisions and _filter_revisions_touching_file_id both call the same underlying api ?
[22:31] <GaryvdM> I don't have make_log_rev_iterator in log.py
[22:32] <GaryvdM> Yes - in the versions I have
[22:33] <GaryvdM> I have revno 3695 of bzr.dev
[22:33] <lifeless> ok
[22:33] <lifeless> you should update :P
[22:34] <lifeless> anyhow, I've checked and ye, its still duplicated, on the same graph object no less
[22:34] <lifeless> I have
[22:34] <lifeless> def make_log_rev_iterator
[22:34] <lifeless> in my log.py
[22:35] <GaryvdM> I was pulling from lp. Let me pull from the bzr site.
[22:36] <lifeless> so
[22:36] <lifeless> looking at this
[22:36] <lifeless> I think this could be integrated into the filter stack better, but that is separate and not needed to prevent the duplicate work
[22:36] <lifeless> and I think that this is a good thing to do
[22:36] <lifeless> as the _filter function is private you don't need to make parameters optional - its not frozen in any way
[22:37] <GaryvdM> ok
[22:45] <GaryvdM> Sorry lifeless: where do I find HACKING ?
[22:45] <lifeless> doc/developers/
[22:45] <GaryvdM> thanks
[23:30] <mwhudson> so, what's the story with the transport api and url encoding?
[23:31] <lifeless> urls in urs out
[23:31] <lifeless> get_transport is magic
[23:31] <lifeless> local_abspath gets a local filename
[23:31] <lifeless> filenames are unicode
[23:31] <lifeless> urls are octets as per std66
[23:34] <mwhudson> ok
[23:34] <mwhudson> this doesn't seem to be covered by the transport_implementation tests
[23:34] <mwhudson> maybe
[23:34]  * mwhudson tries to think
[23:36] <lifeless> should be
[23:37] <lifeless> test_unicode_paths
[23:37] <lifeless> test_has
[23:37] <lifeless> test_list_dir_result_is_url_escaped
[23:37] <lifeless> etc
[23:37] <mwhudson> yeah
[23:38] <mwhudson> i think our transport is a bit funny when you give it unescaped paths
[23:38] <mwhudson> but actually dtrt when its inputs are properly escaped
[23:39]  * jml focuses on something else, despite how tempting this discussion is.
[23:39] <mwhudson> jml: you'll get your chance to think about this when you review the resulting branch :)
[23:57] <GaryvdM> lifeless: I tried making that change, but it made no difference to the speed. I the graph loading maybe cached?
[23:57] <GaryvdM> *i
[23:57] <GaryvdM> *Is
[23:59] <spiv> Good morning.