[00:02] <eric_programmer> lifeless: I am just a user. So when you say unpolished do you mean it is not really supported yet or do you mean it just is a little more pain than it will eventually be?
[00:04] <lifeless> eric_programmer: I mean lots of rough edges; possible bugs. I wouldn't use it unless you plan on helping finish it off :(
[00:04] <lifeless> eric_programmer: sorry :(
[00:06] <eric_programmer> lifeless: No problem. Is there any alternatives. I looked at the config-manager but didn't quite understand how it fit into things. I am coming from SVN + Piston so am looking for somewhat of an equivalent.
[00:08] <lifeless> I don't know what piston does
[00:10] <eric_programmer> lifeless: Basically is a add-on for SVN. Works a little like svn:externals but actually puts the source of the vendor code in your own tree. This way you can make changes and track those changes. But then later do a piston update vendor/some_lib and it will pull in the latest from that project merged in with your changes. This way you can make local changes and control when updates come in from vendors.
[00:12] <lifeless> eric_programmer: config-manager can do that' basically you record all your externals in a flat text file
[00:13] <eric_programmer> lifeless: OK, I'll have to check that out more carefully then. Sounds like it may be what I am looking for until Bazaar get's full support. Thanks!
[00:13] <lifeless> eric_programmer: you want the python codebase
[00:25] <awmcclain> Is it possible to have more than one (non-nested) tree in a branch?
[00:25] <awmcclain> I'm still trying to wrap my brain around this.
[00:26] <lifeless> awmcclain: no; a branch is a pointer to a revision-tree
[00:27] <lifeless> when you commit the pointer is changed
[00:28] <awmcclain> I see. So when you you run bzr branch inside a shared repo, what happens in terms of "branches" and "trees"
[00:28] <awmcclain> ?
[00:28] <awmcclain> is "working-tree" the same as "tree"?
[00:28] <awmcclain> no, right?
[00:28] <lifeless> working tree is a tree that can be edited; when referring to whats on disk they are often used interchangably
[00:29] <lifeless> bzr branch creates a new branch using the revision pointer from another branch; then creates a working tree at the same location with the contents of that revision
[00:30] <awmcclain> unless invoked in a shared repo with --no-working-trees
[00:30] <lifeless> right; in that case the second step is skipped
[00:30] <awmcclain> ah ha! I learned something!
[00:31] <lifeless> are you new to bzr?
[00:31] <awmcclain> Yes.
[00:31] <lifeless> you may find it easier to completely ignore repositories for a while
[00:31] <lifeless> they are nothing more than a space optimisation
[00:34] <awmcclain> Well, I'm doing enough nitty-gritty work (between stripping out SVN revisions and writing a plugin to interface with bzr-eclipse deal with our eclipse workflow) that it doesn't really bother me. I just want to make sure I'm understanding the concepts.
[00:35] <awmcclain> My primary goal is to make branching fast and easy easy easy.
[00:35] <lifeless> awmcclain: ok :).
[00:35] <awmcclain> And along the way I need to deal with some architectural issues with the way our VCS was set up.
[00:48] <Verterok> moin
[00:48] <awmcclain> If you have a nested branch structure (like in http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch), and you branch the mainline, do you get revisionn histories from everyone's feature branches?
[00:50] <bob2> outside the repository? no.
[00:53] <awmcclain> bob2: So if you do bzr branch mainline, you just get the mainline change history, not bob/feature-foo as well
[00:53] <lifeless> right, branches are separate
[00:54] <lifeless> this is why I said ignore repositories:) they don't change any semantic behaviour
[00:55] <awmcclain> lifeless: Ahhhh. Of course. Ok, now it makes sense what you were saying. I was thinking of them in an SVN sense.
[00:56] <awmcclain> Hierarchy in the filesystem (branch B is in a folder of branch A) is separate than the tree hierarchy
[00:56] <awmcclain> s/than/from
[00:56] <awmcclain> Ok. Last question, I swear:
[01:03] <awmcclain> In http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style, under "backing up" it mentions "You may even wish to bind local task branches to remote ones established on a backup server just for this purpose.". How would that work? bzr branch local-mirror local-feature-branch. bzr <branch create command> remote-branch. bzr bind local-feature-branch remote-branch?
[01:06] <lifeless> awmcclain: what it means is 'work like you do with svn' - so that the remote server that is backed up has every branch
[01:06] <lifeless> awmcclain: and when you commit those branches get the commits
[01:06] <lifeless> awmcclain: I don't think backing up is a reason do to this; workflow and team coherence is a much better reason to do this.
[01:07] <awmcclain> lifeless: Very good point. The only thing I want to mitigate is the remote possibility that someone's machine goes down with their local feature on it.
[01:08] <lifeless> awmcclain: then have them make sure its published in some fashion somewhere :)
[01:11] <awmcclain> lifeless: Is the main reason to have nested branches (or just developer branches published) on the mainline server to facilitate corroboration on feature branches? Because it's easier to just both pull from the central location vs push pulling between devs?
[01:12] <lifeless> awmcclain: uhm, nested branches is not what you mean I think
[01:12] <awmcclain> I mean a shared repository structure like: http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch
[01:13] <awmcclain> or even http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar
[01:13] <lifeless> awmcclain: anyhow, if you have two developers working on a single feature, it can be advantageous to have a single branch they both commit too
[01:15] <lifeless> I have to go catch a train
[01:16] <lifeless> awmcclain: man that wiki page is confusing
[01:16] <awmcclain> Tell em about it. :)
[01:17] <lifeless> did you try the user guide? it may have something better
[01:19] <awmcclain> it's the same thing verbatim
[01:19] <awmcclain> :)
[01:38] <Odd_Bloke> So, anyone here intending to be at FOSDEM?
[01:52] <lifeless> igc: ^ see comments re shared repo stuff
[01:52] <jelmer> Odd_Bloke: yep, I will
[01:53] <igc> shall do
[01:54] <jelmer> Odd_Bloke: I'll be wandering around and hopefully be on IRC (if they managed to get the WiFi working this year)
[01:54] <jelmer> Odd_Bloke: are you speaking / manning a booth?
[01:54] <lifeless> jelmer: how is wouter?
[01:55] <jelmer> lifeless: ok but busy with uni last time I spoke to him
[01:56] <igc> awmcclain: wrt the 'using a backup server', what I meant was something like this ...
[01:57] <igc> bzr push sftp://our-backup-server/me/work-for-X
[01:57] <igc> then use bind to bind to it while in the office
[01:57] <igc> as lifeless said, commits will implicitly go there as well
[01:57] <awmcclain> igc: our-back-server being different than our-mainline-server?
[01:57] <igc> when out of the office, unbind and work locally
[01:58] <igc> it can be - it's up to you
[01:58] <jelmer> he was actually on the channel a couple of days ago
[01:58] <igc> if the motivation is "let's not lose work when a laptop disk crashes", then ...
[01:58] <awmcclain> Exactly
[01:58] <igc> it doesn't need to be the main repo - it can be anywhere central that's backed up
[01:58] <awmcclain> also the motivation being "let's make this whole thing as easy as possible"
[01:58] <awmcclain> =)
[01:59] <lifeless> igc: I strongly suggest not using 'bind' for 'backup'. Its a) confusing and b) will /conflict/ with folk that use checkouts for workflow.
[01:59] <igc> well it's one option
[01:59] <igc> another is being in the habit of doing a regular push to a cental server as well
[02:00] <lifeless> igc: its an abuse of a workflow feature; as seen above it just confuses people.
[02:00] <igc> lifeless: yes and no
[02:00] <lifeless> igc: another is to run a backup tool. Or do push-multi before signing off.
[02:00] <bob2> clearly you need multi-bind, so you commit to your 17 redundant data centres
[02:00] <awmcclain> Also, is there any to use http://bazaar-vcs.org/SharedRepositoryLayouts#nested-style-project-branch-sub-branch over http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar? To me the only real difference is that your mainline trunk is either a parent or sibling... and nested branches don't work in trac-bzr. Is there a performance increase?
[02:00] <lifeless> bob2: exactly.
[02:01] <lifeless> awmcclain: I would never arrange branch A under branch B, because when we get real nestd branches working that will cause all sorts of errors.
[02:01] <bob2> hm, I was being fascetious, but it would be neat to commit to local and remote repository
[02:01] <awmcclain> lifeless: 'Nuff said.
[02:01] <igc> keep in mind that some teams are sticking with central VCS solely for the 'we like central backups' all the time side effect
[02:01] <lifeless> awmcclain: *unless* you know you won't be using tested trees.
[02:02] <lifeless> igc: in which case, they should just use 'bzr checkout' all the time, which will do the same thing. When offline they use bzr commit --local.
[02:02] <lifeless> igc: what I'm getting at here is the following:
[02:02] <lifeless> new users see repository layout as something to get right, because they assume a high cost to change (because svn is bad, mmkay).
[02:03] <lifeless> and to understand that page they need to know all about repositories, bind, namespaces, difference between branches with trees and without trees.
[02:03] <lifeless> which is a huge learning curve that new users should not need to know.
[02:03] <awmcclain> !!!" new users see repository layout as something to get right"
[02:03] <igc> agreed, but I didn't write that page :-)
[02:03] <bob2> (and because svn offers some advantages to some layouts (e.g. checkout trunk to get trunk/{project1,project2}))
[02:04] <awmcclain> i just uttered that not more than 5 minutes ago
[02:04] <lifeless> bob2: our nested trees will do that correctly when polished.
[02:04] <igc> my point is that in a central system, commit = checkpoint + publish + backup
[02:04] <lifeless> awmcclain: you're not the first I've seen having this problem
[02:04] <lifeless> igc: I'm not blaming you for the page; but you are defending some of the content at least.
[02:05] <johnny> hmm.. i think even monotone made it easier to understand, as they avoid the trees vs no tree repositories.. since trees are always stored in sqlite, and only working copies make files
[02:05] <igc> in Bazaar, you have the flexibility to make it mean any one, or two, of those
[02:05] <igc> lifeless: I did write the bit about pushing to a backup server
[02:05] <lifeless> igc: I posted to the list a while back that we're making the curve harder than it has to be.
[02:06] <igc> I'd agree with that ...
[02:06] <igc> I'm far from finished with the docs fwiw
[02:06] <lifeless> igc: I think that that page needs to let new users be much more agile; there are multiple answers but we don't have to provide a concordance in the introductory information.
[02:06] <awmcclain> If I may, as a new user, chime in.... the whole page on distributed workflow is really really great.... except for that one paragraph on backing up the server. (Since that was exactly my worry coming from a central VCS). It just wasn't informative enough.
[02:06] <awmcclain> (sorry igc)
[02:07] <igc> feedback is great - thanks
[02:07] <igc> is it clearer now?
[02:07] <lifeless> igc: anyhow, I would rather we provide a flowchart 'if you want to achieve X' system for this, rather than a huge list of choices
[02:08] <awmcclain> On the whole, though, the docs on bazaar have been really great for me to wrap my mind around the big problems... 1 How is DVCS better? 2. How can I adjust our existing workflow to best suite that?
[02:08] <lifeless> igc: with the first option being 'are you a single user with a small tree' -> no repository, kthxbye
[02:08] <igc> bbiab
[02:08] <awmcclain> let me see
[02:08] <lifeless> igc: I'm heading to Martins now.
[02:09] <awmcclain> igc: looking at http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#team-collaboration-distributed-style. Did you change it?
[02:09] <igc> lifeless: np - thanks for the ping
[02:09] <igc> awmcclaim: I wrote it if that's what you mean
[02:10] <awmcclain> ohhh... is it clearer now, yes, after irc? yes
[02:10] <awmcclain> i thought you meant that you changed the docs
[02:11] <igc> No, what I meant was I didn't write the section on NestedTreeLayout
[02:11] <igc> I wrote a large amount of the rest though
[02:11] <igc> (and after irc)
[02:13] <awmcclain> Ah yes. Is "NestedTreeSupport" different than 8.2.2 Nested Style repository layout?
[02:13] <awmcclain> Overall, i just want to say that the docs were the main reason I chose bzr over hg.
[02:14] <lifeless> awmcclain: cool
[02:14] <lifeless> awmcclain: and yes it is different
[02:14] <awmcclain> Ok, good.
[02:15] <awmcclain> I don't want to think about it then. :)
[02:17] <Odd_Bloke> jelmer: Nope, will be a spectator again this year.
[02:17] <igc> awmcclain: ah yes, I meant Nested Style repo layout (or whatever the really long section like that is called)
[02:18] <awmcclain> hehh
[02:18] <igc> awmcclain: and I'm wrapper you like the docs - that's great news
[02:18] <igc> s/wrapper/wrapped/
[02:20] <Odd_Bloke> jelmer: Are you manning/speaking?
[02:22] <jelmer> Odd_Bloke: nope, not this year
[02:23] <jelmer> Odd_Bloke: Interested in meeting up during FOSDEM? We could get some people involved in Bazaar development together
[02:23] <jelmer> I know at least LarstiQ is going to be there as well as some users
[02:24] <Odd_Bloke> jelmer: Yeah, I'd be up for that.
[02:25] <jelmer> Odd_Bloke: are you going to be on IRC during the weekend?
[02:26] <jelmer> Hopefully the network is going to be working correctly again this year
[02:28] <jelmer> anyhow, sleep first
[02:29] <Odd_Bloke> Night!
[02:29]  * Odd_Bloke intends to stay up so he doesn't miss his train and then nap liberally.
[02:34]  * igc food
[02:37] <awmcclain> Anyone here familiar with bzr-svn?
[02:56] <Odd_Bloke> awmcclain: A number of people are.  If you have a question, just asking it is the best way to get a response. :)
[03:07] <poolie> Odd_Bloke, are you coming to London to see us?
[03:25] <Odd_Bloke> poolie: Yeah, I'd like to.
[03:34] <awmcclain> Here's a strange thing: I'm getting an error in trac svn: PermissionDenied: Permission denied: "/repos/pandasite/.bzr/branch-format": [Errno 13] Permission denied: u'/repos/pandasite/.bzr/branch-format'
[03:35] <awmcclain> Even though my /repos/pandasite is world readable
[03:35] <awmcclain> does it need to be writable as well?
[03:35] <awmcclain> s/trac svn/trac+bzr/
[03:42] <lifeless> awmcclain: I don't know why trac+bzr would try to write
[03:43] <awmcclain> looking at the python it's just trying to "get" using a local bzr transport at file:///repos/pandasite/
[03:44] <awmcclain> ls -al /repos/pandasite
[03:44] <awmcclain> total 16
[03:44] <awmcclain> drwxr-sr-x 4 clownfish dev 4096 Feb 22 02:41 .
[03:44] <awmcclain> drwxrws--- 6 root      dev 4096 Feb 22 01:37 ..
[03:44] <awmcclain> drwxr-sr-x 6 clownfish dev 4096 Feb 22 01:36 .bzr
[03:44] <awmcclain> drwxr-sr-x 9 clownfish dev 4096 Feb 22 02:44 panda
[03:44] <lifeless> then for whatever reason its failing to read; are the directory above rx for this user ?
[03:45] <lifeless> drwxrws--- 6 root      dev 4096 Feb 22 01:37 ..
[03:45] <awmcclain> ahhh!
[03:45] <awmcclain> the sticky bit!
[03:45] <awmcclain> sigh
[03:45]  * awmcclain shudders off into corner
[03:45] <lifeless> a good way to test these things is to su to the user doing the access
[03:46] <lifeless> and explore in shell
[03:46] <lifeless> jml: when are thou arriving?
[03:46] <lifeless> spiv: ottid
[03:46] <jml> lifeless: I've pinged poolie confirming if it's ok to leave now. no response yet.
[03:47] <awmcclain> Can't su as ww-data because i've removed the shell. :)
[03:47] <awmcclain> www-data that is
[03:47] <lifeless> jml: I'mm here :)
[03:47] <awmcclain> So, the instructions on http://bazaar-vcs.org/SharedRepositoryTutorial (set the perms of your repo directory to 02770) don't work for trac+bzr.
[03:47] <lifeless> jml: he says its ok to come now
[03:47] <jml> ok.
[03:48]  * jml tidies up some stuff
[03:48] <lifeless> awmcclain: su -s /usr/bin/bash www-data
[03:49] <lifeless> awmcclain: as root; so sudo su -s ...
[03:54] <spiv> lifeless: "ottid"
[03:54] <spiv> ?
[03:54] <lifeless> ditto :)
[03:54] <spiv> Oh, right
[03:54] <spiv> I forget to use the xrandr option to flip my screen :P
[03:54] <poolie> Odd_Bloke: did you tell Claire so?  i don't remember seeing a response from you?
[03:55] <lifeless> that wouldn't work either :)
[03:55] <Odd_Bloke> poolie: I haven't responded yet, because I completely forgot to do so.
[03:55] <lifeless> do now :)
[03:56] <awmcclain> Oh, so close... now: "No node at revision current%3A"
[03:57] <spiv> lifeless, poolie: I'll probably head off in about an hour
[03:58] <poolie> rightyo
[03:58] <Odd_Bloke> poolie: Who is Claire and how do I tell her so? :p
[04:00] <poolie> see my mail
[04:02] <Odd_Bloke> poolie: The only mail I can find (and recall getting) doesn't mention a Claire (http://paste.pocoo.org/show/29283/).
[04:02] <poolie> do you see my private msg?
[04:05] <Odd_Bloke> poolie: I don't.
[04:05] <Odd_Bloke> You would appear not to be identified with NickServ...
[04:07] <poolie> now?
[04:48] <kumi> hmm... if I have a path with hundreds of files and folders, and I want to ignore _all but a few_ files, how would I do that in .bzrignore?
[04:49] <poolie> kumi: probably easiest to ignore everything, then add the ones you want to keep
[04:49] <poolie> you can add ignored files
[04:49] <poolie> this is assuming there's no easy expression that will match
[04:49] <kumi> Oh, that's surprisingly simple
[04:49] <kumi> let's see
[04:51] <poolie> we try to be pleasantly simple
[04:52] <kumi> Worked like a charm, thanks
[05:07] <awmcclain> Ug. I can't figure this out. I've branched a directory from SVN into a shared repo, but when I point bzr+trac to the repo, I get "no node at current:", and if i point it one level in (to the branch) i get "can't compare datetime.datetime to float"
[05:11] <ubotu> New bug: #194251 in bzr-dbus "bzr-dbus should not require a separate daemon to broadcast notifications" [Undecided,New] https://launchpad.net/bugs/194251
[05:16] <jamesh> lifeless: ^^^ the above bug contains my thoughts about how to improve bzr-dbus
[05:21] <lifeless> jamesh: ok; we should talk about this daemon presence/absence thing; I'm really not sure that we can do without it, and I don't understand why doing without it is a feature
[05:21] <lifeless> jamesh: specifically getting the mappings right seems to require state to me
[05:22] <jamesh> lifeless: I don't think that is a problem provided that the servers providing the mappings are able to readvertise themselves on demand
[05:22] <jamesh> (which I cover in that bug)
[05:23] <lifeless> jamesh: ah; won't that require event driven servers though?
[05:24] <jamesh> lifeless: for bzr-avahi, I just run an event loop in a daemon thread
[05:24] <jamesh> works great
[05:25] <lifeless> jamesh: ok, I shall read the bug.
[05:25] <lifeless> jamesh: I still don't get the objection :)
[05:25] <jamesh> lifeless: other than the daemon being unnecessary and the cause of pretty much all the other bzr-dbus bugs? :)
[05:28] <lifeless> well, its not being fully utilised today; but besides that - it is the cause of bugs ?
[05:29] <jamesh> the big improvement is changing things to use signals instead of method calls
[05:30] <jamesh> with current bzr-dbus, "bzr commit" will needs to send a DBus message to the daemon and wait for a response
[05:31] <jamesh> by instead sending it as a signal, it need not block on a response
[05:31] <jamesh> and if you're sending a signal, you may as well send it to everyone who has expressed interest
[05:37] <lifeless> current bzr-dbus does send a signal
[05:37] <lifeless> the service is the one that waits
[05:39] <jamesh> the set_rh hook calls Activity.advertise_branch()  That in turn performs a DBus method call to the broadcast daemon
[05:39] <jamesh> a method call is two messages (one in each direction)
[05:40] <lifeless> oh hmmm
[05:40] <lifeless> so youre right.
[05:40] <abentley> lifeless: I don't expect "nested-style" layout to interact poorly with nested trees.
[05:41] <lifeless> abentley: when the user has a tree in the repo I expect it too
[05:41] <lifeless> abentley: tree-less repos - sure.
[05:41] <jamesh> a signal is basically a "one way" method call that can optionally be broadcast (as opposed to being sent to a single DBus name)
[05:41] <lifeless> jamesh: ok; in principle I'm for this, but I want to think around the mapping implications.
[05:41] <lifeless> jamesh: also, are you volunteering ;)
[05:42] <jamesh> lifeless: sure, although I may not be timely in sending patches :)
[05:42] <abentley> lifeless: The plan for nested trees was to allow arbitrary locations to be used.
[05:42] <lifeless> jamesh: (I do know the difference between signals and calls on dbus :))
[05:43] <jamesh> lifeless: one of my ulterior motives for running an event loop on "bzr serve" is that I need one for bzr-avahi anyway
[05:44] <jamesh> lifeless: if bzr-dbus requires effectively no setup and has low overhead with no listeners, I may as well make bzr-avahi depend on it
[06:00] <lifeless> jamesh: ok; I'm keen to reduce overhead.
[06:26] <lifeless> tree = bzrlib.workingtree.WorkingTree.open('.')
[06:26] <lifeless> state = tree.branch.get_loom_state()
[06:27] <lifeless> tree.branch.remove_thread('string_here')
[06:27] <lifeless> tree.branch.nick = 'rf'
[07:13] <awmcclain> Anyone up? Trying to upgrade bazaar on ubuntu... but I can't figure out how to add the entry to my sources.list. It keeps telling me the 1.0.0 i have installed is current
[07:15] <bob2> https://launchpad.net/~bzr/+archive has the correct sources.list lines
[07:15] <bob2> maybe you forgot to "sudo apt-get update" or similar?
[07:15] <awmcclain> oh, man. i'm too tired. I totally misse dthat
[07:16] <awmcclain> thank you
[07:16] <bob2> np
[07:17] <awmcclain> hrm
[07:18] <awmcclain> it's removing bzr-svn... was that merged into bzrtools?
[07:18] <bob2> no
[07:18] <bob2> bzr-svn (maybe) isn't updated to work the latest version of bzr
[07:19] <awmcclain> :(
[07:19] <awmcclain> well
[07:19] <awmcclain> this stinks
[07:25] <poolie> good night all
[07:25] <ubotu> New bug: #194274 in bzr-loom "Removing the bottom thread should be possible." [Medium,Triaged] https://launchpad.net/bugs/194274
[07:26] <poolie> awmcclain: i'll check about bzr-svn, but i have to go now
[07:26] <poolie> for now i suggest you stay on 1.1
[07:26] <awmcclain> okee doke
[07:28] <poolie> awmcclain: i think that bug is the indirect cause of your problem
[07:29] <awmcclain> 194274?
[07:46] <ubotu> New bug: #194277 in trac-bzr "Trying to view diffs between revisions on a single file shows revision on ALL files" [Undecided,New] https://launchpad.net/bugs/194277
[07:57] <igc> night all
[08:01] <ubotu> New bug: #194282 in trac-bzr "Pointing trac to a shared repository with a single branch yields an error" [Undecided,New] https://launchpad.net/bugs/194282
[08:01] <lifeless> later all
[08:01] <awmcclain> night
[08:01] <awmcclain> well
[08:01] <awmcclain> this has been a long day. I'm signing off as well. Too bad I couldn't get the trac stuff to wrok. :-\
[08:02] <awmcclain> thanks lifeless, for all your help
[10:33] <AnMaster> hm something is odd here: bzr check says "429 revisions", yet bzr up says "Tree is up to date at revision 390.". No I haven't merged anything from anyone, nor branched it.
[10:34] <AnMaster> any idea? would bzr uncommit cause it? I used it a few times
[10:35] <dato> yes
[10:36] <AnMaster> ah
[10:36] <AnMaster> dato, how do I get rid of those "orphand" revisions?
[10:36] <dato> at the moment, you only can by branching your current branch to a new branch, and use that one from now on
[10:37] <dato> b get foo foo.new
[10:37] <dato> mv foo foo.old
[10:37] <dato> mv foo.new foo
[10:37] <dato> :)
[10:37] <AnMaster> dato, hm I store it in a shared repo (in case I later want to branch), so a bit more complex
[10:37] <AnMaster> but I see
[10:37] <dato> oh, it indeed is a bit more hairy in a shared repo
[10:38] <AnMaster> dato, hariy? hm?
[10:38] <AnMaster> how would one do in a shared repo then
[10:38] <dato> but only a bit
[10:38] <dato> cd ..
[10:38] <AnMaster> ah right
[10:38] <dato> b init repo.new
[10:38] <dato> er
[10:38] <dato> init-repo
[10:38] <AnMaster> and then branch each over to new repo right
[10:38] <dato> b get repo/foo repo.new/foo
[10:38] <dato> yes
[10:38] <dato> etc
[10:38] <AnMaster> hrrm
[10:39] <AnMaster> dato, would be nice with a command to get rid of such orphand revisions
[10:39] <dato> unless you committed some really big (or confidential) revisions by mistake
[10:39] <dato> you normally don't care
[10:39] <AnMaster> dato, really big indeed
[10:39] <dato> AnMaster: yes, there's been talk about it for ages
[10:39] <AnMaster> and saw a typo in commit message. uncommited, recommited
[10:39]  * AnMaster wonders if bzr uncommit works after bzr sign-my-commits
[10:40] <quicksilver> I've sometimes wondered about accidental committing of privileged data
[10:40] <quicksilver> never done it, thank god.
[10:40] <quicksilver> but it is an interesting issue.
[10:40] <quicksilver> I guess if the privileged data is in revision N and you do a bzr branch on (N-1) that gives you a clean copy?
[10:41] <dato> yes
[10:41] <dato> barring the shared repo issue mentioned above
[10:41] <AnMaster> I assume it doesn't push orphand revisions
[10:41] <AnMaster> on bzr push
[10:41]  * quicksilver nods
[10:41] <AnMaster> so the data would just be locally
[10:42] <AnMaster> btw anything interesting new in bzr 1.2?
[10:50] <jelmer> there is the bzr remove-revisions plugin
[10:50] <jelmer> which will removed orphaned revisions
[10:50] <jelmer> but it's slow as hell, because it can optionally rewrite the whole history of the repository
[12:02] <dato> jelmer: it seems that pushing to svn from bzr shell leaves the database locked
[12:21] <alfborg1> Can anyone tell me about Visual
[12:21] <alfborg1> Studio integration?
[12:22] <alfborg1> I find the SOC-project, but nothing about it actually being successful or not.  As in production quality.
[12:24] <jelmer> dato: I'm not doing anything fancy to the database
[12:26] <dato> jelmer: well, all I know is that if I `bzr shell`, and push to svn from there, and leave the shell open, I can't push from another terminal.
[12:26] <dato> not that is something critical, but just I thought you'd like to know.
[12:26] <dato> (btw the "db is locked" error spits  a traceback)
[12:44] <alfborg1> Nobody knows about Visual Studio support for bzr?
[16:02] <radix> is there a known bug about the bzrtools 1.2.0-1ubuntu2 package being broken?
[16:02] <radix> the postinst is failing for me because none of the .py files that it's looking for are there
[16:06] <luris> Hi. Getting the following when committing: bzr: ERROR: exceptions.AttributeError: children
[16:07] <luris> Full traceback: http://dpaste.com/36405/
[16:49] <MeLanKoLia> WhAlBeRg
[16:49] <MeLanKoLia> NeRdEsInNnN
[17:00] <MeLanKoLia> asf
[17:14] <Lo-lan-do> Hi there
[17:14] <Lo-lan-do> Can I update a lightweight checkout of a branch to an older revision?
[17:14] <beuno> Lo-lan-do, you mean revert it to an older revision?
[17:15] <Lo-lan-do> Yes
[17:15] <beuno> Lo-lan-do, bzr revert -r revision_number
[17:15] <beuno> will revert the tree to the state it was at a specific revision
[17:15] <beuno> you can also create a new branch from that revision
[17:16] <Lo-lan-do> Hm.  But I'll have locally modified files then :-/
[17:18] <beuno> Lo-lan-do, I don't understand what you want very well than. Can you explain a bit more?
[17:18] <beuno> you have a remote branch, and a local lightweight checkout, right?
[17:19] <Lo-lan-do> Right.
[17:19] <Lo-lan-do> And I'd like to change the contents of the files I have locally.  So bzr revert -r foo works.
[17:20] <Lo-lan-do> But when I do that, bzr status tells me the files are added/modified/deleted/whatever
[17:20] <beuno> Lo-lan-do, yeap. Then you'll have to commit them, fo course
[17:20] <Lo-lan-do> I don't want to commit, I just want to navigate the past.
[17:21] <beuno> Lo-lan-do, then just re-branch at that revision
[17:21] <beuno> it it's just to look through
[17:22] <beuno> then just delete ir when you're done
[17:22] <Lo-lan-do> That sounds a big suboptimal, especially if I want to poke at several past revisions.
[17:22] <Lo-lan-do> s/big/bit/
[17:23] <beuno> ah, well, I'm not sure what tool let's you navigate revisions better, but I do think it would be a plugin
[17:24] <Lo-lan-do> Basically, I've tried the bisect plugin, and I'm trying to go a bit past that.
[17:24] <Lo-lan-do> See what happens if I poke files around.
[17:25] <beuno> Lo-lan-do, maybe the list will be more helpful
[18:36] <exarkun> Did I get this message - `bzr: ERROR: Cannot lock: transport is read only: <bzrlib.transport.http._urllib.HttpTransport_urllib url=http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk/.bzr/branch/>´ - because I used `bzr checkout´ instead of `bzr branch´?
[18:37] <james_w> exarkun: yes, are you doing a commit?
[18:37] <exarkun> No, it happened during checkout
[18:37] <james_w> exarkun: ah, that's a bug.
[18:38] <james_w> exarkun: you can probably branch and the "bzr bind", or checkout using "bzr+ssh://"
[18:38] <exarkun> maybe
[18:39] <exarkun> actually it happened as part of an automated process which is difficult to alter :/
[18:40] <james_w> exarkun: :/
[18:40] <jdong> james_w / exarkun : just yesterday I did a light checkout over http and it worked
[18:40] <jdong> of course not for committing but the checkotu didn't error
[18:40] <exarkun> hm
[18:41] <exarkun> lemmie make sure I actually completely understand what's going on...
[18:41] <james_w> jdong: yeah, it only seems to be some branches that cause it.
[18:41] <james_w> exarkun: are you using checkout --lightweight?
[18:41] <exarkun> doesn't look like it.  this is the full command - '/usr/bin/bzr checkout http://bazaar.launchpad.net/~exarkun/pyopenssl/trunk build'
[18:42] <exarkun> there's a comment in this code about how --lightweight causes a cannot-lock error ;p
[18:42] <james_w> yeah, that's a heavyweight one.
[18:42] <james_w> oh dear.
[18:44] <jdong> lol
[18:44] <exarkun> oh hm
[18:44] <jdong> why would you do an entire heavyweight checkout for a  build though?
[18:44] <exarkun> maybe this is using an old version of bzr
[18:45] <jdong> (my tests were with bzr 1.1 or 1.2, forgot which)
[18:45] <exarkun> this host seems to have bzr 0.8.2
[18:45] <exarkun> maybe I will upgrade it
[18:45] <fullermd> Holy crap.
[18:45] <jdong> a tiny bit outdated
[18:51] <exarkun> ah, cool, that fixed it
[18:52]  * james_w cheers for progress
[18:52] <james_w> we finally know that we have improved on 0.8.2
[18:52] <exarkun> :P
[18:52] <fullermd> True.  I haven't even considered the question since, like, 0.9   :p
[18:54] <distatica> Hey folks, when I try to add a directory with bzr add, it says "Ignored 27 file(s) if you wish to add some of these files, please add them by name" is there any way to override that so I don't have to manually go through and find those files?
[18:54] <distatica> not that I'm even sure where this listing of 27 files would be.
[18:54] <fullermd> 'bzr ignored'
[18:55] <distatica> oh sweet, it's just ignoring vim's extra files. thank you.
[18:56] <fullermd> We try to only ignore ignorable things   :)
[19:04] <distatica> I wasn't sure, but that's good, vim swap files annoy me. (especially on windows with "show hidden files" true.
[19:04] <distatica> glad they're not in my repo now too.
[19:06] <ubotu> New bug: #194450 in bzr "commit doesn't supports wildcards in windows" [Undecided,New] https://launchpad.net/bugs/194450
[19:56] <EdwinGrubbs> hello, I have some questions concerning looms
[21:15] <championdusk> anyone know of a good WORKING guide to getting bzr + the svn plugin working on leopard?
[21:25] <awmcclain> championdusk: I just got it working on ubuntu yesterday, and I'm installing on leopard today... what's going on?
[21:44] <james_w> EdwinGrubbs: please ask your question.
[21:44] <james_w> the developer isn't around at the moment, but I have seen a few people trying to use it.
[21:45] <EdwinGrubbs> james_w: I don't see what effect "bzr record" has for looms
[21:46] <eric_programmer> I have a question I recently asked on the bzr-svn plugin project but thought I might also ask it here in hopes of getting an answer. Rather than repeating everything I figure I will just point a link to my previous question: https://answers.launchpad.net/bzr-svn/+question/25353
[21:48] <james_w> eric_programmer: so you don't have any trunk/ branches/ tags/ type organisation on that repo?
[21:49] <james_w> EdwinGrubbs: have you read about it in README?
[21:49] <james_w> EdwinGrubbs: also there is a mention in HOWTO
[21:50] <EdwinGrubbs> james_w: I read the description in the README and HOWTO, but it doesn't seem to be necessary to use record, since it appears that the changes are available to be pulled after doing a commit.
[21:51] <awmcclain> EdwinGrubbs: Try removing the svn branching schema file from your ~/.bazaar directory
[21:51] <eric_programmer> james_w: No my repository. Just trying to use the code. Yes it looks like for the most part each project just has one main line of development. There is a branches and tags but they are effectively not used in a normal style and we can ignore them for the most part.
[21:52] <eric_programmer> james_w: s/No/Not/
[21:52] <EdwinGrubbs> james_w: I also cannot figure out where the comment passed into "record" is viewable.
[21:52] <james_w> EdwinGrubbs: so it seems that there is another "branch" that records activity in the .bzr/loom dir or wherever, and the record is actually commit in that branch. I don't know what effect that will have though.
[21:54] <awmcclain> oops, sent that to the wrong person
[21:55] <awmcclain> eric_programmer: Try removing the svn branching schema file from your ~/.bazaar directory
[21:55] <abentley> EdwinGrubbs: It will make all your threads be updated properly, not just the active thread.  It will cause any threads you have deleted to be deleted in the other, add any threads you have added, etc.
[21:56] <eric_programmer> The entire file or just the entry for that repository?
[21:57] <EdwinGrubbs> abentley: thanks
[21:57] <eric_programmer> awmcckain: I have already tried just that entry and no luck. Let me try the entire file just in case. :)
[21:57] <awmcclain> eric_programmer: I'd try for just that entry first. I had the same problem yesterday; removing the file fixed it, (but i only had one svn repository)
[22:00] <eric_programmer> awmcclain: Same deal when removing the entire file:
[22:00] <eric_programmer> eric@sleek:~$ rm .bazaar/subversion.conf
[22:00] <eric_programmer> eric@sleek:~$ rm -rf .bazaar/svn-cache/
[22:00] <eric_programmer> eric@sleek:~$ bzr branch http://svn.viney.net.nz/things/rails/plugins/acts_as_modified
[22:00] <eric_programmer> Initialising Subversion metadata cache in /home/eric/.bazaar/svn-cache/20afb1e0-9c0e-0410-9884-91ed27886737/cache-v3
[22:00] <eric_programmer> bzr: ERROR: trunk/rails_plugins/acts_as_modified/README is not a valid Subversion branch path in the current
[22:00] <eric_programmer> branching scheme. See 'bzr help svn-branching schemes' for details.
[22:01] <awmcclain> hrm
[22:01] <awmcclain> :(
[22:02] <awmcclain> did you try backing up your svn-cache directory and removing it?
[22:02] <awmcclain> oh
[22:02] <awmcclain> yes
[22:02] <awmcclain> you did
[22:06] <awmcclain> Does bzr-svn not work with bzr 1.2.0?
[22:07] <james_w> eric_programmer: have you read 'bzr help svn-branching schemes'?
[22:07] <james_w> eric_programmer: it suggests that "none" should be what you want, but also that it should be autodetected.
[22:11] <eric_programmer> james_w: Yes and I have tried editing the schemes but no luck (by the way that is a typo, it should be svn-branching-schemes). Even when I set it to none it doesn't work because it seems to reset it when I try to create the branch again. I think I may know what happened though. It looks like around revision 295 the developer renamed trunk/rails_plugins to rails/plugins. So basically his scheme changed confusing bzr. So when it tires 
[22:12] <awmcclain> eric_programmer: If that IS the case, you COULD do something super convoluted like make an svnadmin dump 296:N (where N is the head revision), svnadmin load that into a local svn repo, then branch from there
[22:14] <eric_programmer> The only problem with that is I then cannot track changes from the upstream vendor repository. Basically I want to be able to occasionally "pull" to get the latest source to merge in with my copy.
[22:14] <awmcclain> Mmm.
[22:15] <james_w> eric_programmer: typo fix sent to jelmer, thanks.
[22:16] <james_w> eric_programmer: ah, that's probably the problem then.
[22:17] <theuiguy> If I want to call multiple bzr commands in a plugin, how can I avoid multiple password prompts (due to the need to authenticate the remote server)?
[22:18] <theuiguy> Is there some way to hold on to the transport so it doesn't have to re-auth each time? I'm using SFTP in this case
[22:18] <james_w> theuiguy: there's a way to reuse transports which should avoid that.
[22:19] <james_w> theuiguy: possible_transports=list in the arguments to a method.
[22:19] <theuiguy> james_w: do you know if I can use that with the cmds directly?
[22:20] <theuiguy> specifically I'm trying to do branch, pull, and push...
[22:20] <james_w> theuiguy: you are actually calling cmd.run()?
[22:20] <theuiguy> yes
[22:20] <awmcclain> I'm confused... does the smart server exist or not exist?
[22:21] <james_w> awmcclain: it exists, but only if you don't look directly at it.
[22:22] <awmcclain> james_w: Ah. The watched pot never boils, eh?
[22:22] <james_w> sorry, I mean yes, it exists, bzr+ssh:// is one of them.
[22:23] <james_w> theuiguy: that is generally not that popular, but it can be convenient. If you don't need all the cases that the commands handle then it is probably as easy to actually work on the objects.
[22:24] <james_w> theuiguy: that would then give you access to these facilities.
[22:24] <awmcclain> eric_programmer: What version of bzr are you running?
[22:25] <james_w> unfortunately some of the commands have a little too much knowledge in the command class, which you have to reimplement with that approach.
[22:25] <eric_programmer> awmcclain: Bazaar (bzr) 1.0.0
[22:25] <theuiguy> james_w: That's what I was going to ask. I'm (sadly) trying to learn how to hack python while updating a plugin for bzr
[22:26] <theuiguy> james_w: Sadly in that it would probably be easy if I knew more python...
[22:26] <awmcclain> eric_programmer: You *might* try getting bzr-svn 0.5.0 from his trunk at http://people.samba.org/bzr/jelmer/bzr-svn/trunk
[22:26] <awmcclain> eric_programmer: Since it's just a python file, it' fairly trivial to install
[22:26] <theuiguy> james_w: Is there somewhere I can find a mapping between cmds and their objects?
[22:26] <awmcclain> file(s)
[22:27] <james_w> theuiguy: well a command usually operates on more than one object, but if you tell me a command I can try and tell you what the essence of this is.
[22:27] <james_w> theuiguy: is this a plugin that is available, or just something local?
[22:28] <theuiguy> james_w: It used to be known as ezbzr, but it's no longer available at it's old location
[22:29] <theuiguy> james_w: eventually we want to put it somewhere, perhaps launchpad?
[22:29] <eric_programmer> awmcclain: I'll give a newer version a try. Maybe it will work for me
[22:29] <james_w> theuiguy: launchpad would be ok, there's quite a few plugins there.
[22:29] <awmcclain> eric_programmer: Good luck. I'm stuck in bzr-svn troubles myself. :)
[22:29] <james_w> theuiguy: I've heard of it, but never tried it, what does it provide over bzr itself?
[22:30] <theuiguy> james_w: good deal.
[22:31] <theuiguy> james_w: ezbzr has three major commands, foreach which does executes a command for every revision with an option to use just the latest
[22:31] <theuiguy> james_w: diffstatus which is a trivial thing that combines both diff and status into one command
[22:31] <awmcclain> Can anyone here help me with https://bugs.launchpad.net/trac-bzr/+bug/194282?
[22:31] <ubotu> Launchpad bug 194282 in trac-bzr "Pointing trac to a shared repository with a single branch yields an error" [Undecided,New]
[22:32] <james_w> ah, so it's not providing a wrapper on the bzr interface, but extra commands. I though it maybe provided a more "easy" UI.
[22:32] <theuiguy> james_w:  and the one that's causing problems is release, which tries to cleanly release to another branch without polluting it
[22:32] <james_w> what do you mean by release?
[22:32] <theuiguy> james_w: no, just more commands
[22:33] <theuiguy> james_w: in our environment we're using bzr to manage code on multiple servers (production, dev, testing, etc.)
[22:34] <theuiguy> james_w:  Release helps us update the code on other servers while not overwriting other people's changes
[22:35] <foom> eric_programmer: you can probably do what you want with bzr svn-branching-scheme but it's not documented anywhere afaik
[22:35] <theuiguy> james_w: essentially it creates a temp branch from target server, merges your code changes, lets you conditionally commit them, and then push
[22:36] <james_w> eric_programmer: one idea might be bzr branch -r last_revision_before_move
[22:36] <james_w> then change the branching scheme and pull.
[22:36] <foom> eric_programmer: just put two lines in:  trunk/rails_plugins and rails/plugins
[22:36] <foom> then it will know both those as branches and should work
[22:37] <eric_programmer> foom: It's funny you mentioned that. I had just put this in as a list using the --set option and am giving a try now... hopefully it will work. I know my lack of knowledge on Subversion schemas is what is preventing me from working.
[22:37] <theuiguy> james_w: does that make sense?
[22:38] <james_w> theuiguy: hmm, sounds like using the objects might be a little work, but it's hard to tell.
[22:38] <foom> what prevented me from understanding is that the ability to list branches directly is apparently undocumented. :)
[22:39] <theuiguy> james_w: I know that one of the things the plugin does is a local branch and then a pull with overwrite from the remote server
[22:39] <james_w> awmcclain: are you using Aaron's multi branch version of trac-bzr?
[22:39] <eric_programmer> foom: Well after I read what documentation does exist and read the source code I think I am finally understanding schemas a bit. The imports seems much slower this time but as long as it works I am happy. Hopefully I will know soon.
[22:40] <james_w> theuiguy: the branch that you are currently in?
[22:40] <theuiguy> james_w: I'm guessing this was for speed... but this was written for bzr 0.15 or so... so this may be unnecessary now
[22:40] <theuiguy> james_w: yes
[22:40] <james_w> theuiguy: it's probably still worth doing
[22:40] <awmcclain> james_w: I'm using the bmonty-devel branch for trac 0.11 support
[22:40] <james_w> awmcclain: then that can only serve a single branch I think.
[22:40] <awmcclain> Though I HAVE the multi-branch branched out as well
[22:41] <theuiguy> james_w: I'm wondering whether there's any better/faster way to construct the temp branch from the target server.
[22:41] <awmcclain> Ah ha!
[22:41] <james_w> http://cmcsforge.epfl.ch:6789/cgi-bin/dwww/usr/share/doc/trac-bzr/README
[22:41] <james_w> awmcclain: ^
[22:41] <james_w> theuiguy: well the local copy is probably quicker to branch.
[22:42] <james_w> tree = WorkingTree.open_containing('.')[0]
[22:42] <james_w> branch = tree.branch
[22:42] <awmcclain> james_w: There's no multi-repository support yet, right?
[22:42] <james_w> branch.sprout(tempdir)
[22:42] <james_w> new_branch = Branch.open(tempdir)
[22:43] <theuiguy> james_w: does that replace this: builtins.cmd_branch().run(from_location=branch_base, to_location=localcache)
[22:43] <james_w> or perhaps sprout returns the new branch object, I can't remember.
[22:43] <james_w> theuiguy: pretty much I think, this is all just guess programming though, so the exact methods will need to be checked.
[22:43] <theuiguy> james_w: gotcha
[22:44] <theuiguy> james_w:  what's the branch.sprout(tempdir) do? I haven't seen that method.
[22:44] <james_w> but you probably want to create a tree rather than branch, and I don't know if you use tree.sprout() or branch.sprout() has an argument.
[22:45] <james_w> theuiguy: also look for accelerator_tree or something like that, as you have a local tree it can use that to make building the temp one quicker.
[22:45] <james_w> awmcclain: I think Aaron's branch does
[22:45] <awmcclain> james_w: !!
[22:46] <james_w> theuiguy: Then you need to get the server transport so you can reuse it. I can't remember the transport API though.
[22:46] <awmcclain> Silly that his branch isn't on launchpad
[22:46] <theuiguy> james_w: ok. Once I have a tree, how could I do a pull overwrite... I'm guessing that's where it needs a transport.
[22:47] <james_w> theuiguy: but the pull --overwrite is easy, tree.pull(othertree, overwrite=True) or something.
[22:47] <theuiguy> cool
[22:47] <james_w> You can pass in possible_transports as well I assume.
[22:47] <awmcclain> james_w: Hrm. Same problem. "No node at current"
[22:47] <awmcclain> I wonder if it has to do with the way in which i set up the repository? And made the brach from bzr-svn?
[22:47] <james_w> theuiguy: I'm just guessing at all of this, but you should be able to work it out from the command in bzrlib/builtins.py
[22:48] <james_w> theuiguy: though if you are still learning python there might be a lot going on in there to distract you. However it usually boils down to
[22:48] <james_w> 20-50 lines of setup and checking
[22:49] <theuiguy> james_w: I think I'm getting it. Thanks for the pointers.
[22:49] <james_w> call method to do the work, with obvious parameters.
[22:49] <eric_programmer> james_w, foom and awmcclain: You guys rock. I was able to finally get it working. The secret sauce was to do "bzr svn-branching-scheme http://svn.viney.net.nz/things/ --set". Then when my editor popped up put in "rails/plugins/*" and "trunk/rails_plugins/*" as separate lines. After that everything worked great. Thanks for your help guys.
[22:49] <james_w> theuiguy: no problem.
[22:49] <james_w> awmcclain: did you read the link I posted? You have to set some extra config options.
[22:50] <james_w> eric_programmer: wow, I can't believe it worked, congratulations.
[22:50] <james_w> I should never have doubted jelmer.
[22:50] <theuiguy> james_w: I'll have to look at this over the weekend, but it seems like it should similar.
[22:51] <theuiguy> james_w: er... should be similar to using the cmds directly.
[22:51] <awmcclain> james_w: Ah. Yes. It's the same README as in the branch. I've set repository_dir
[22:51] <awmcclain> And all the rest of the configuration
[22:51] <james_w> theuiguy: yeah, I've done similar things to this, and just poking around in the bzrlib code normally make things clear soon enough, ask again if you need some more pointers.
[22:51] <awmcclain> I wonder if it's because the "directory containing the branches" IS a repository.
[22:51] <theuiguy> james_w: do you know of any code that uses multiple commands while sharing the transport? I was looking for some sample code somewhere.
[22:52] <theuiguy> james_w: might some of the test code do this?
[22:53] <fullermd> I doubt it.  The test suit either calls functions directly, or exec's out bzr.
[22:53] <james_w> theuiguy: that's another good place to look. The sharing of transports should be tested somehow, but I don't know if it will look like what you want.
[22:53] <fullermd> I don't think anything calls command frontends except the commands in bzr proper.
[22:53] <fullermd> The cmd_'s aren't really made to be called by other code, I don't think.
[22:54] <james_w> theuiguy: the transport sharing should be easy for you I expect, just pass a list containing the transport you have to every method that accepts it.
[22:54] <theuiguy> fullermd: it's pretty convenient when you're just grouping some commands
[22:54] <james_w> awilkins: I don't think that should have an effect.
[22:54] <fullermd> theuiguy: Well, I do that with my shell   :)
[22:54] <theuiguy> unfortunately, some bzr internals change made it so the cmds now prompt for password each time
[22:55] <theuiguy> Since this worked in some earlier versions (admittedly pre-1.0) of bzr
[22:58] <theuiguy> james_w: thanks again, I really appreciate the pointers. Hopefully you'll see the plugin more publicly available sometime soon.
[23:03] <awmcclain> Is there a way to apt-get bzr version 1.1 somewhere?
[23:05] <radix> awmcclain: you mean, as opposed to bzr 1.2?
[23:09] <awmcclain> radix: Exactly.
[23:12] <radix> awmcclain: I think the PPA archive keeps the old .debs around, but you'd have to download them manually
[23:12] <radix> I think?
[23:13] <awmcclain> radix: Any idea where they might live? I can't find them anywhere. :(
[23:15] <radix> awmcclain: hmm. guess not.
[23:15] <radix> I assumed it would be at http://ppa.launchpad.net/bzr/ubuntu/pool/main/b/bzr/ , but it's not.
[23:15] <awmcclain> Ah well. What a bother that bzr-svn doesn't work with 1.2 yet
[23:17] <foom> if you were using debian you could use snapshot.debian.net
[23:17] <foom> dunno about ubuntu
[23:23] <robey> is there a working version of the bzr-git plugin?
[23:23] <robey> (bzr-git trunk appears to be broken against bzr 1.2)