[00:00] <james_w> awmcclain: you mean the packaged version?
[00:00] <james_w> awmcclain: you could also try your /var/cache/apt
[00:00] <awmcclain> james_w: i went from 1.0 to 1.2
[00:01] <james_w> ah, that wont work then.
[00:01] <awmcclain> james_w: I figured out some of the problem... seems like bzr-trac balks when used with a shared repo without working trees
[00:02] <james_w> awmcclain: ah, well caught.
[00:05] <awmcclain> ooh.. yesh
[00:05] <awmcclain> I'm getting bzr: ERROR: Repository KnitPackRepository('file:///shrepo/.bzr/repository/') is not compatible with repository SvnRepository('svn://localhost')
[00:05] <awmcclain> when i try to branch an svn directory into a shared repo with trees
[00:06] <fullermd> awmcclain: bzr-svn needs rick-root-packs format.
[00:06] <awmcclain> fullermd: Not sure I really understand. Is that an option i need to specify in bzr init-repo?
[00:06] <fullermd> Yah.
[00:06] <fullermd> --format=rich-root-packs
[00:07] <fullermd> Or maybe it's pack singular.  I'd have to check the help...
[00:07] <awmcclain> For bzr-svn?
[00:07] <awmcclain> or bzr init-repo
[00:07] <fullermd> For the init-repo
[00:07] <awmcclain> Is there a better (more native) way to convert from svn to bzr? I'm doing a one-way port
[00:07] <fullermd> There are one or two other converters around, but I think bzr-svn is the canonical one.
[00:08] <fullermd> I think the only other way that's gotten any work lately is whatever that thing is that igc's working on, and that's probably not near as production-ready.
[00:08] <awmcclain> Won't specifying a different file format hurt performance?
[00:08] <fullermd> Hurt performance relative to it not working at all?   ;)
[00:09] <awmcclain> Once i get the repo into bzr, can i convert from rick-root-packs to knit?
[00:09] <fullermd> No (you wouldn't want to go knit anyway; you'd want to go pack; but rich roots are a trapdoor)
[00:10] <awmcclain> Is there wiki page somewhere about all this?
[00:10] <fullermd> There's probably something in the bzr-svn docs about it, but I've never look at 'em.
[00:11] <awmcclain> So, bottom line is, if i'm converting a repo from svn, i'm stuck with an older file format.
[00:11] <fullermd> It's not older.
[00:11] <fullermd> In a sense, it's newer.
[00:12] <awmcclain> oh wait, i'm so confused.
[00:13] <awmcclain> The state-of-the-art is using packs, right?
[00:13] <fullermd> Correct.
[00:13] <fullermd> rich-root-pack is a variant of pack-0.92 that supports rich roots (much like rich-root is a variant of knits that supports rich roots)
[00:13] <awmcclain> But using bzr init-repo doesn't default to that? And bzr-svn is expeciting it.
[00:14] <awmcclain> Ah.
[00:14] <awmcclain> rich-root-pack is a superset of pack?
[00:14] <fullermd> Yah.
[00:14] <awmcclain> Ahhhh.
[00:14] <awmcclain> Is there a performance difference?
[00:15] <fullermd> Well, I would assume there has to be one, since it does more.  But that diff is almost certainly unmeasurable.
[00:15] <awmcclain> That's the magic word!
[00:16] <fullermd> It may miss some optimizations that exist in the straight format; I'm not sure how much of the code is shared.
[00:16] <fullermd> But I don't think it would be a large difference, if it's a meaningful one at all.
[00:44] <tgunr> Thought I would try out bzr on macosx, on 1st attempt to use it with the whoami command I get Unable to load plugin 'qbzr'
[00:44] <tgunr> :)
[00:45] <johnny> hmm..so.. do you guys talk about the bzrarchives proposal thingy here?
[00:46] <beuno> tgunr, so you installed the qbzr plugin and it's failing for some reason
[00:46] <beuno> you should remove it
[00:46] <beuno> and try again
[00:47] <beuno> Verterok, ^  :p
[00:47] <tgunr> just delete that folder?
[00:47] <tgunr> or plist or something?
[00:48] <Verterok> tgunr: the 10.4 installer?
[00:48] <tgunr> 10.5
[00:48] <Verterok> beuno: thanks :)
[00:49] <Verterok> tgunr: I don't have 10.5, but in 10.4 it's installed inside python site-packages
[00:50] <tgunr> CC
[00:51] <awmcclain> In a shared repository (with trees), is there anything different between mkdir foo; bzr add foo; bzr commit and bzr branch bar (where bar is an empty directory)?
[00:51] <Verterok> tgunr: I think it should be in: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages
[00:51]  * fullermd blinks.
[00:51] <fullermd> awmcclain: Either you're confused, or you confused me   :)
[00:52] <awmcclain> fullermd: I think both. :)
[00:52] <awmcclain> fullermd: Basically, is adding a directory using bzr the same as branching?
[00:53] <awmcclain> fullermd: I ask because I need to fiddle with my directory structure in my shared repository
[00:54] <fullermd> You can't "add a directory" in a repository.
[00:54] <fullermd> The concept has no meaning in bzr terms.
[00:54] <awmcclain> Using bzr add?
[00:54] <fullermd> Maybe you're thinking svnish?
[00:54] <awmcclain> Maybe i'm garbling the advice that lifeless gave me yesterday
[00:54] <fullermd> (Or maybe you mean 'branch' when you're saying 'repository', but branch'ing inside a branch doesn't make sense either)
[00:54] <awmcclain> I creating my shared respository
[00:55] <awmcclain> Well, there is that whole "nested branch layout" under http://bazaar-vcs.org/SharedRepositoryLayouts. ;)
[00:56] <awmcclain> I want my repo to look like: repo/trunk/src  repo/bobby/featureX/src repo/sally/featureY/src
[00:57] <awmcclain> "repo" in the sense of "shared repository"
[00:57] <awmcclain> The problem is that in my current SVN tree, I only have /src
[00:57] <awmcclain> So.
[00:58] <fullermd> I think you're mixing too many things around...
[00:58] <awmcclain> ??
[00:58] <fullermd> For one thing, 'add' is a command that deals with a working tree.  A working tree is only related to a branch; it doesn't have anything to do with repositories.
[00:59] <fullermd> It may be simpler to forget wholesale about the shared repo, at least mentally, for starters.
[00:59] <fullermd> The existence (or non-) of the repo doesn't change anything, relative to just having standalone branches.  It just saves space/time.
[00:59] <awmcclain> Ok.
[01:00] <awmcclain> So.
[01:00] <awmcclain> I should do bzr branch svn://src
[01:00] <awmcclain> which will give me a /src branch + working directory, correct?
[01:00] <awmcclain> I need to change my tree to look like /trunk/src
[01:01] <robey> since ppl are talking again: any word on bzr-git?
[01:01] <awmcclain> robey: just that bzr-svn is broken for 1.2 too.
[01:01]  * robey howls with pain
[01:01] <fullermd> robey: I believe somebody (lifeless?) looked at it recently, but I'm not aware of any real movement.
[01:02] <fullermd> (where 'recently' is the past month or three)
[01:02] <robey> i tried various branches from the launchpad project page for bzr-git, and they all failed in exactly the same way
[01:03] <robey> it sucks cuz i really dont want to use git, but some stuff here is stored in git repos
[01:03] <fullermd> I don't think bzr-git is sufficiently present at its best to be useful for doing real work.  So it being broken doesn't necessarily lose you much   :)
[01:03] <awmcclain> fullermd: I'm just trying to set up my mainline server so that we can share feature branches, and I want to do it in such a way that encourages branching.
[01:05] <awmcclain> I guess another question would be: How would you change the root directory of a branch?
[01:06] <fullermd> You mean the "move everything from / into /foo" thing?
[01:06] <robey> if it was good enough to make a bzr branch from a git one, that would've probably been enough
[01:06] <fullermd> I don't think it was ever that good.
[01:07] <robey> oh well, ok... thanks
[01:08] <awmcclain> if i have a branch /foo, i want to "reroot" it at /bar/foo
[01:09] <fullermd> awmcclain: Theoretically, with rich roots, one could pivot the root dir.  But there's no UI or other support for doing so.  So the real choice is pretty much as above; make a dir, and bzr mv everything into it.
[01:09] <awmcclain> fullermd: Exactly what I want to do.
[01:09] <fullermd> See, that phrasing is unclear, which makes it tough to answer.
[01:09] <awmcclain> My use of "reroot"
[01:09] <awmcclain> ?
[01:09] <fullermd> It could be read as "move the branch from /foo to /bar/foo", or it could be read as "move the contents of the branch which is located at /foo into the bar/ subdirectory inside the branch"
[01:10] <awmcclain> Ah. Sorry. #1
[01:10] <fullermd> (or alternately phrased; you could be talking about moving the _branch_, or you could be talking about moving stuff around _in the branch_.
[01:10] <fullermd> If you want to move the branch, you just mv it.
[01:11] <awmcclain> hrm
[01:11] <awmcclain> because it's a directory?
[01:11] <fullermd> Or tar, or zip, or whatever other random mechanism you use for moving filesystem trees around.
[01:11] <awmcclain> ah
[01:11] <awmcclain> but
[01:11] <fullermd> Yah.  If it's a standalone branch, everything it needs is inside itself, so you can throw it around however you like.
[01:11] <fullermd> (if it's in a shared repo, a little more care is needed, since it doesn't have the repo included, but that's another matter)
[01:11] <awmcclain> Well, it's a branch inside a shared repo.
[01:11] <awmcclain> =)
[01:11] <awmcclain> but
[01:12] <awmcclain> ideally, i want to be able to say
[01:12] <fullermd> If it's in a shared repo, as long as it stays under the repo, mv is still what you want.
[01:12] <awmcclain> ok
[01:12] <awmcclain> so
[01:12] <awmcclain> i could do
[01:13] <awmcclain> bzr-init --trees repo; mkdir repo/trunk; bzr branch SOURCE_URL repo/trunk/src
[01:13] <awmcclain> and then from the client, bzr branch repo/trunk?
[01:13] <fullermd> No.
[01:13] <awmcclain> OK. That's what I want to do.
[01:13] <fullermd> You can only branch a branch, which in this case would be "repo/trunk/src".  "repo/trunk" is nothing.
[01:14] <fullermd> (also, "bzr init-repo", not "bzr-init", but that's details)
[01:14] <awmcclain> (Sloppy typing sorry)
[01:14] <fullermd> 'src' is a bad name for a branch.  You probably want 'repo/trunk' to be the branch.
[01:14] <awmcclain> Exactly!
[01:14] <awmcclain> that's the problem
[01:14] <fullermd> Either that, or you want to have 'src' be a directory inside the branch.
[01:14] <fullermd> (possibly the only thing in the root of the branch)
[01:15] <awmcclain> The problem is that right now, i have many project in my svn /trunk directory
[01:15] <awmcclain> so, in order for me to split things up
[01:15] <awmcclain> i can only do bzr branch svn://.../trunk/sub_proj
[01:16] <fullermd> Mmm.  Let's assume proj1, proj2, and proj3.
[01:17] <awmcclain> But, in bzr, i want to make /trunk/sub_proj the branch
[01:17] <fullermd> And we'll ignore the presence (or absence) of a share repo for the moment.
[01:17] <awmcclain> well (/trunk)
[01:17] <awmcclain> ok
[01:17] <awmcclain> great
[01:17] <fullermd> You can arrange stuff two ways (an infinite number, of course, but 2 main ones)
[01:17] <fullermd> One is
[01:17] <fullermd> /proj1/trunk, /proj2/trunk, /proj3/trunk
[01:17] <fullermd> The other is /trunk/proj1, /trunk/proj2, /trunk/proj3
[01:18] <awmcclain> So, I want to have my bzr projects set up like choice A
[01:18] <awmcclain> But my SVN is set up like choice B
[01:18] <fullermd> In the former, other branches of each project would be under /projX, in the latter you'd have either /branchs/RANDOM, or /branches/proj1/RANDOM, /branched/proj2/RANDOM, etc.
[01:18] <fullermd> OK, that's no problem at all, since branches are independent.
[01:18] <fullermd> You'll bzr branch svn://... once for each project, and you'll end up with N bzr branches, one for each project.
[01:19] <fullermd> Then you can arrange them however you like.
[01:19] <fullermd> In svn, you're kinda stuck with them laid out however you did them initially.
[01:19] <fullermd> With bzr, you can rearrange at will, because there's nothing quite like a svn repo; there's no higher level thing they're all explicitly pieces of.
[01:20] <awmcclain> SVN looks like this: /pandasite/trunk/panda /pandasite/trunk/artwork pandasite/trunk/notify
[01:20] <awmcclain> I want bzr to look like:
[01:23] <awmcclain> ...
[01:24] <awmcclain>  /pandasite/trunk/panda
[01:25] <awmcclain>  /artwork/trunk
[01:25] <awmcclain>  notify/trunk
[01:25] <awmcclain> */notify/trunk
[01:25] <fullermd> Was that first meant to be /panda/trunk?
[01:25] <awmcclain> So, unfortunately, I can't branch the /pandasite/trunk into bzr, because that will give me two other projects
[01:25] <awmcclain> no
[01:26] <awmcclain> We could call it /pandasite/trunk/src /pandasite/trunk/artwork
[01:27] <awmcclain> I have some "nested" directories in SVN that I want to fix when I move to bzr
[01:27] <fullermd> OK, well, let's forget about that, because it twists my brain into probably somewhat irrelevant side paths, and stick with the other two   :)
[01:27] <awmcclain> That's the tricky one, though. :)
[01:27] <awmcclain> Im done witht eh other two
[01:27] <awmcclain> :)
[01:27] <fullermd> Well, crud.
[01:28] <awmcclain> Just say you're given a branch that is /src
[01:28] <awmcclain> And you need to convert to a branch that is /trunk with a subdirectory /src
[01:29] <fullermd> I think you're confusing me because you're mixing up the branch, and what's in the branch, which doesn't happen in bzr.
[01:29] <fullermd> The branch is /src.  It could as well be /, or /foo/bar/mybranch, or whatever?
[01:31] <fullermd> So what you really want to do is "move the files/dirs in the root of the branch into a subdir".  I keep feeling like you mean more than that, because the solution to that seems so simple.
[01:31] <awmcclain> Yes!
[01:31] <awmcclain> That's what I want to do!
[01:32] <fullermd> Well, you want to make a dir in the branch, and move everything into it.  You do that by making a dir in the branch (technically, your working copy of the branch), and moving everything into it   :)
[01:33] <awmcclain> using bzr mv
[01:33] <fullermd> Right.
[01:33] <awmcclain> do i need to bzr add the dir?
[01:33] <awmcclain> first?
[01:33] <fullermd> I don't think you can actually 'bzr mv *' like you can with straight 'mv', since I dunno if it'll notice you trying to move a dir into itself and DTRT, but...
[01:33] <fullermd> Yah.
[01:33] <awmcclain> i was confused because I was equating "the directory at the root of the tree" with the definiation of the branch
[01:34] <awmcclain> Does that make sense?
[01:34] <fullermd> Ah.  Yeah, that could be a source of confusion.
[01:34] <awmcclain> pehw
[01:34] <fullermd> There's a sharp line between "working on your project" (in which you essentially chroot into the root of the branch), and manipulating the branch from the outside.
[01:34] <awmcclain> right
[01:34] <fullermd> (in which case the branch is opaque)
[01:35] <awmcclain> and "working on your project" == "working within your working-tree"
[01:35] <fullermd> cd $BRANCH ; mkdir src ; bzr mv [A-Za-rt-z]* src ; {manually bzr mv s* files or dotfiles} ; bzr ci -m 'Move a bunch of crap'
[01:35] <fullermd> Right; your day to day "getting stuff done"
[01:36] <awmcclain> Ah ha!
[01:36] <fullermd> (whoops, I missed the 'bzr add src' before the mv)
[01:37]  * fullermd pours more coffee.
[01:37] <awmcclain> Ok. Would another approach be to create a new branch (call it trunk)
[01:37] <awmcclain> then somehow move the contents of $BRANCH2 into $TRUNK?
[01:37] <awmcclain> (without creating nested branches)
[01:38] <fullermd> Well, you could 'bzr branch src trunk' and do the work in trunk/ instead of src/ if you like.  No real reason to, though.
[01:38] <fullermd> Or just 'mv src trunk' (not 'bzr mv', since you're not working in a bzr tree).
[01:38] <awmcclain> but mv src trunk would create nested branches, right?
[01:38] <awmcclain> you have branch trunk
[01:39] <awmcclain> then branch src inside trunk
[01:39] <fullermd> I meant with 'trunk' not existing; just renaming the directory.
[01:39] <fullermd> Branches aren't "called something"; they're just "located somewhere", so changing the "name" is just mv'ing the branch.
[01:40] <awmcclain> right
[01:41] <awmcclain> So it wouldn't make senses to somehow move the working tree from branch src into a src directory in branch trunk
[01:41] <awmcclain> $SRC/*  ---> $TRUNK/src
[01:42] <fullermd> Not really.  Either way you have to move $BRANCH/* into $BRANCH/src/*.  It's just a question of whether you 'rename' the branch before or after, which affects nothing.
[01:43] <awmcclain> Oh, just to be clear, I'm talking about moving working trees from two _separate_ branches, but I'm guessing you can't do that
[01:44] <fullermd> Well, you can merge the trees, then mv all the new files before commit.
[01:45] <awmcclain> ok, let me just dive into this
[01:45] <awmcclain> If I do all this branch work outside my shared repository, can I just push my branch into my shared repo?
[01:46] <fullermd> Sure.
[01:46] <awmcclain> Can I just cp it in?
[01:46] <fullermd> Well, yes and no.
[01:46] <fullermd> You *can*.  But it'll still be a standalone branch, just one located inside a repo.
[01:46] <awmcclain> no, because it defaultst he purpsoe of the shared repo
[01:46] <awmcclain> defeats
[01:46] <awmcclain> :)
[01:46] <awmcclain> ok
[01:46] <fullermd> You should consider too at what level you want the repo; whether all this goes in one, or you want one for each project.
[01:47] <awmcclain> right
[01:47] <fullermd> Right   :)
[01:47] <awmcclain> it's going to be
[01:47] <awmcclain>  /repo (plain directory with a misleading name)
[01:47] <awmcclain>  /artwork (branch)
[01:47] <awmcclain>  /pandasite (shared repo)
[01:48] <awmcclain>  /pandasite/trunk (branch)
[01:48] <awmcclain>  /pandasite/andrew (dev branch)
[01:48] <awmcclain> etc
[01:48] <awmcclain> eeep
[01:48] <awmcclain>  everything from /artwork down lives in /repo
[01:48]  * fullermd nods.
[01:48] <awmcclain> (/repo/artwork/) etc
[01:48] <awmcclain> ok
[01:49] <fullermd> Don't need to handle multiple branches of artwork?
[01:49] <awmcclain> Nope
[01:49] <fullermd> What about notify?  Where does that fit?
[01:52] <awmcclain>  /repo/notify (shared repo)
[01:52] <awmcclain>  /repo/notify/trunk
[01:52] <awmcclain> So, the same thing needs to happen for that
[01:53] <awmcclain> oh, no
[01:53] <awmcclain> i'll just do
[01:54] <awmcclain> cd repo; bzr init-repo --trees --rich-root-pack notify; cd notify; bzr branch svn://pandasite/trunk/notify trunk
[01:55] <awmcclain> btw, thank you for taking the time to walk through this with me. As I've said before, the community and the docs are why I'm switching my team to bzr rather than hg.
[01:56] <fullermd> Sounds like something remarkably like a plan to me.
[01:59] <awmcclain> Ok, last thing... in order to push into the shared repo, I'll have to serve it on localhost, right?
[01:59] <fullermd> Well, on localhost, I'd just 'branch' instead of 'push'.  Comes out to the same thing, though.
[02:01] <awmcclain> So, say my directory-fiddled branch ends up at ~/good-branch
[02:02] <awmcclain> i can just say, bzr branch ~/good-branch /repos/pandasite/good-branch
[02:02] <awmcclain> oh of course
[02:02] <awmcclain> yes
[02:02] <fullermd> Yep.
[02:03] <fullermd> cd ~/good-branch ; bzr push /repos/pandasite/good-branch/ is _almost_ the same.  Either would work.  I'd just reflexively use 'branch'.
[02:04] <awmcclain> Ok. Great!
[05:56] <etteyafed> anyone know about a bzr plugin for netbeans?
[06:20] <Peng> Ouch.
[06:28] <jml> zoinks!
[06:28] <jml> $ bzr branch bzr+ssh://myserver/home/jml/a/branch
[06:28] <jml> bzr: ERROR: Generic bzr smart protocol error: bad protocol marker "error\x01Generic bzr smart protocol error: bad request 'bzr request 2'\n"
[06:28] <jml> that's not a fun error message
[08:28] <awmcclain> Ug. One MORE error.
[08:29] <awmcclain> I can't checkout my branch from my mainline! Repository KnitPackRepository('file:///Users/andrew/clownfish/panda-mirror/.bzr/repository/') is not compatible with repository RemoteRepository(bzr+ssh://bamboo.fluther.com/repos/pandasite/.bzr/)
[08:29] <awmcclain> I inited my remote shared repo with --format=rich-root-pack so that I could import SVN branches into it.
[08:29] <bob2> you'll need to do the same for your local repository
[08:30] <awmcclain> ah... I have to init a local repository in order to do a checkout from a shared repo?
[08:31] <bob2> what command gave you that error?
[08:31] <awmcclain> bzr checkout bzr+ssh://bamboo.fluther.com/repos/pandasite/trunk panda-mirror
[08:32] <awmcclain> I get no error if i do a branch
[08:32] <bob2> is clownfish or panda-mirror a repository root?
[08:33] <awmcclain> no
[08:33] <bob2> er, clownfish, that is
[08:33] <awmcclain> it is not
[08:33] <awmcclain> it is a vanillay directory
[08:34] <bob2> (and no, you don't need to init a local repository to do a checkout from a shared repo)
[08:34] <awmcclain> hrm
[08:34] <awmcclain> i don't get it then
[08:34]  * bob2 tries a bzr+ssh checkout of a rich-root-pack branch
[08:34] <bob2> hah, same error
[08:35] <awmcclain> !!
[08:35] <awmcclain> booo
[08:35] <awmcclain> Is there any way to convert to KnitPack?
[08:35] <awmcclain> I have no need to communicate to SVN anymore... I just needed to port over from SVN
[08:36] <bob2> [09:55] <mwhudson> there's a bug where initial branches over bzr+ssh always create local branches in the default format
[08:38] <bob2> awmcclain: if you use sftp instead of bzr+ssh, it should work
[08:39] <awmcclain> Aren't there weirdnesses with using sftp? Like losing some meta information or something?
[08:39] <awmcclain> Or... is there a way to convert rich-root-pack to knitpack?
[08:39] <bob2> awmcclain: the other workaround from http://irclogs.ubuntu.com/2007/12/13/%23launchpad.html is to use sftp for the first revision (-r1), then bzr up
[08:40] <bob2> I don't know of any weirdness from using sftp, aside from it maybe being slower
[08:40] <awmcclain> ug
[08:40] <awmcclain> what does bzr up do?
[08:41] <bob2> if it's on a lan, it shouldn't matter
[08:41] <awmcclain> it's not
[08:41] <awmcclain> and speed is important
[08:41] <bob2> ah
[08:41] <awmcclain> hrm
[08:43] <bob2> (bzr up would update you from rev1 to the current rev)
[08:43] <awmcclain> and in order to branch from SVN you _have_ to use rich-root-pack, right?
[08:43] <awmcclain> Right...makes sense
[08:44] <bob2> or rich-root, but the bug is that "co" always picks the current bzr default format, instead of the remote format
[08:47] <bob2> there is another confusing workaround
[08:48] <bob2> if you make a rich-root-pack repository on your local machine, then checkout into that, then it uses rich-root-pack for the check and thus works over bzr+ssh
[08:48] <bob2> thus making my intiial comment about not havbign to init a local repository quite wrong
[08:51] <awmcclain> And there's no command to remake the entire file repository, right?
[08:52] <bob2> hm?
[08:52] <awmcclain> bzr convert-file-format crappy-rich-root-format nice-knit-pack-format?
[08:52] <awmcclain> just guess on the syntax. ;)
[08:52] <awmcclain> s/guess/guessing
[08:53] <bob2> well, branches from svn require rich-root support, so no
[08:53] <awmcclain> right, but if i dont' need svn support anymore, can i convert them?
[08:54] <bob2> well, branches that didn't come from svn can be branched into a knit or pack repository
[08:55] <bob2> not sure if you mean "if I don't need to use branches that came from svn anymore" or "if I don't need my branches from svn to interact with svn anymore"
[08:57] <awmcclain> choice B
[08:58] <bob2> not afaik, but I know little about bzr-svn
[09:01] <awmcclain> sigh
[09:01] <awmcclain> ok
[09:01] <awmcclain> i'll try the workaround. thank you for your help!
[09:43] <awmcclain> bob2: still here?
[09:44] <awmcclain> Is there a better way of switching the source of my checkout from sftp:// to bzr+ssh:// than editing the branch.conf manually?
[09:48] <bob2> awmcclain: bzr switch bzr+ssh://...
[09:48] <awmcclain> great
[09:48] <awmcclain> that's from inside the checkout, right?
[09:49] <bob2> yes
[10:17] <rysiek|pl> guys, where does bzr keep revno in branch/repo?
[10:17] <luks_> nowhere, they are calculated
[10:18] <bob2> ("bzr revno" will figure it out)
[10:18] <rysiek|pl> hmmm... ok, so what files should I watch (say, with inotify) to get a heads-up when a revno changes?
[10:18] <rysiek|pl> bob2: yeah, I know, but I am trying to run something automagically when a revno changes
[10:19] <luks_> .bzr/branch/last-revision might work if you want only a single branch
[10:19] <bob2> surely a commit hook would be less hacky?
[10:20] <luks_> bob2: not if it's on a server and you want something like push hook
[10:20] <rysiek|pl> precisely
[10:20] <rysiek|pl> luks_: I don't have anything named "last-revision" in there
[10:21] <luks_> revision-history for old branches
[10:21] <luks_> but you should upgrade them :)
[10:21] <rysiek|pl> $ find ./ -iname last* -> ./checkout/last-revision
[10:21] <emilis_info> Can bzr checkout sourceforge svn on Ubuntu Gutsy? Fails on my machine.
[10:21] <luks_> oh, a checkout
[10:22] <rysiek|pl> emilis_info: bzr != svn
[10:22] <emilis_info> rysiek|pl, I know
[10:22] <bob2> rysiek|pl: bzr-svn!
[10:22] <emilis_info> I use the plugin
[10:22] <luks_> you said branch/repo, so I though you mean a branch
[10:22] <emilis_info> :)
[10:22] <rysiek|pl> ah
[10:22] <luks_> *thought
[10:22] <rysiek|pl> luks_: ell, it is a branch
[10:22] <rysiek|pl> *well
[10:22] <luks_> ls .bzr/branch
[10:22] <emilis_info>  bzr selftest svn gives some output but ends in error: bzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko
[10:23] <rysiek|pl> luks_: yup. revision-history is her
[10:23] <rysiek|pl> e
[10:23] <bob2> emilis_info: you can install python-paramik to fix that
[10:23] <bob2> emilis_info: but can't imagine how that would affect svn support
[10:23] <luks_> yep, upgrading it would be a good idea, unless you have a reason to use the old format
[10:24] <rysiek|pl> nope, just did a bzr upgrade (to 1.1) so it might be a good idea
[10:24] <emilis_info> bob2, I'll try now, thanks
[10:24] <rysiek|pl> hope it won't mess my 2000+ revisions branch... ;)
[10:25] <rysiek|pl> luks_: so, how can I upgrade a branch
[10:25] <rysiek|pl> aah
[10:25] <ubotu> New bug: #194675 in bzr "encoding problem with `bzr merge --preview | less`" [Undecided,New] https://launchpad.net/bugs/194675
[10:25] <rysiek|pl> bzr upgrade
[10:25]  * rysiek|pl is blind
[10:52] <emilis_info> doh... got it working finally... seems I had to use https://...sourceforge.net/... instead of svn+https://...
[11:18] <hsn_> why are .bzr directories hidden on windows? this is confusing
[11:18] <bob2> because they're hiddon on unix
[11:20] <hsn_> but most programs in unix stills shows them, on windows practicaly nothing shows them
[11:42] <AfC> Do we ever use UDP in our bzr:// communications?
[13:10] <ubotu> New bug: #194716 in bzr "bzr pull should support --local" [Undecided,New] https://launchpad.net/bugs/194716
[13:21] <VSpike> I'm trying to do a bzr push by sftp on a lan and the command just goes away and does not return
[13:21] <VSpike> How can I figure out what the problem is?
[13:21] <VSpike> I know I can ssh from one machine to the other succesfully, although it does normally require a password
[13:50] <Odd_Bloke> jelmer: Hey, you around ATM?
[13:54] <echo-are`> hello
[13:55] <echo-are`> was the format of the bzr.dev head updated again?
[13:55] <echo-are`> pulling remotely really takes long time again now
[13:55] <echo-are`> thanks
[13:57] <bob2> are you pulling into a rich root or knit repository?
[13:59] <echo-are`> how to see that?  sorry i'm a newbie
[14:00] <bob2> what command are you running, and where?
[14:01] <echo-are`> i'm running bzr pull
[14:01] <echo-are`> in the top level directory of my local version of bzr.dev
[14:02] <bob2> and that's just a branch you made, and not in a repository?
[14:02] <hsn_> is there simple way to convert checkout to lightweight checkout?
[14:02] <echo-are`> bob2: yes
[14:02] <bob2> hsn_: bzr reconfigure --lightweight-checkout should do it
[14:03]  * echo-are` thinks he should not delay reading the bzr manual by other things now
[14:06] <bob2> afaik the format hasn't changed in a couple of months, and the only other thing I could suggest is that pulling packs into other format repositories is slow
[14:07] <hsn_> bob2: thanks, it worked
[14:08] <echo-are`> bob2: ok.  i recall that on nov 2007 the format was changed, and i did update my local format.  so perhaps this is because of the poor network i have.  thank you
[14:08] <Odd_Bloke> echo-are`: Does the output of 'bzr info' include 'pack' anywhere?
[14:09] <bob2> echo-are`: you can compare the output of "bzr info" and "bzr info http://bazaar-vcs.org/bzr/bzr.dev/"
[14:09] <echo-are`> Odd_Bloke: yes, it says "format: pack-0.92"
[14:10] <Odd_Bloke> echo-are`: In that case it's likely to be network.
[14:11] <echo-are`> bob2: Odd_Bloke: thanks.  i'll read the bzr manual right now :)
[14:51] <echo-are`> bob2: when you mentioned "a repository", did you mean creating a repository with 'bzr init-repo' and executing 'bzr branch' etc in that repository?  thanks
[14:53] <bob2> yes, if you did that with a different repository format to that of bzr.dev, it could cause a slowdown
[15:22] <echo-are`> bob2: thanks :)
[15:35] <awilkins> Is there any way to get bzr diff to just emit a list of paths that changed?
[15:36] <awilkins> Bah, never mind, I think bzr status is what I want
[15:39] <james_w> I'm trying to checkout a branch from launchpad using the smart server and Repository.get_parent_map() is taking a huge amount of time.
[15:41] <awilkins> Ok, next question, whats the easiest way to determine the common base revision of two given revisions?
[15:45] <james_w> awilkins: "bzr find-merge-base" can do it for two branches.
[15:47] <awilkins> Would the algorithm there be something like "read back until they share a mainline revision id, then check all the merges to see which contiguos revisions they have in common"?
[15:47]  * awilkins is more and more wishing he could use bzr instead of svn for this project....
[15:48] <awilkins> Maybe I'll just try and use bzr-svn for it.
[15:48] <james_w> awilkins: I'm not sure what the algorithm is to be honest.
[15:48] <awilkins> Well, I was just trying to work it out, but I'm glad there's an implementation already
[15:49] <awilkins> IF I can't figure it out I'll have to do i9t for SVN (or integrate bzr-svn.... looking better and better....)
[15:49] <awilkins> If only the Eclipse plugins  for bzr were more mature./
[15:49] <db-keen> I have two bzr branches in a directory, can I just init-repo in that directory, or do I have to do something special?
[15:50] <awilkins> db-keen: init-repo another directory, and branch those two branches into it
[15:50] <db-keen> then delete the original and rename the new one to the old one?
[15:50] <awilkins> That should work
[15:51] <db-keen> thanks, I'll do that
[15:58] <awilkins> mylyn
[15:58] <awilkins> oops
[15:59] <Verterok> awilkins: I'm working on making bzr-eclipse better :)
[15:59] <awilkins> Verterok: Oh, much appreciated :-)
[15:59] <Verterok> awilkins: what are the key features you need in it?
[16:00] <Verterok> maaybe
[16:00] <awilkins> Verterok: Difficult to say, I'm working on a project for rather-non-technical users
[16:00] <Verterok> maybe I can push those first :)
[16:01] <awilkins> I'll communicate with you as I go ... I'd quite like the bzr / Java binding that underlies it too.
[16:01] <Verterok> I just merged a improved 'new project wizard' (going to release it soon)
[16:01] <awilkins> I thought the use of Jepp was prefereable to the "eats xml-output" approach, but that was mostly because xml-ouput was clashing with something at the time
[16:02] <awilkins> Verterok: I might have a look at the wizard, I need a branch creation wizard that I can subclass to add functionality to mny users.
[16:02] <Verterok> awilkins: great, I'm currently working in the bindings, updating to 1.x syntax and implementing switch, merge and reconfigure
[16:03] <awilkins> ATM my project plan says "Subversion", but given their heavy and scary merge requirements I might persuade them otherwise
[16:03] <Verterok> awilkins: jepp is quite dificult to distribute, and Jython guys are targeting 2.5 :-D
[16:03] <awilkins> One downside being that the issue tracker I've settled on so far is integrated to a Subversion plugin
[16:04]  * awilkins has no problems with Python 2.5, even though bzr officially targets 2.4
[16:04] <awilkins> The issue tracker is a file based one, it shares little XML files around using a SVN repo
[16:05] <Verterok> awilkins: jython only supports 2.3 syntax, with 2.5 we can use bzrlib from jython :) (I already have jython integrated in eclipse)
[16:05] <awilkins> I keep finding myself wanting a Mylyn tracker like that instead
[16:06] <Verterok> awilkins: did you look at bugs-everywhere? it's a similiar approach, but integrated with bzr
[16:06] <awilkins> Oooo.
[16:06] <awilkins> Can it do hook functions on workflow transitions?
[16:08] <Verterok> awilkins: sorry ¿hook functions?
[16:08] <awilkins> I used a few brain cycles thinking about branched issue management the other day, merge the "issue fixed" along with the issues :-)
[16:08] <awilkins> Yeah, things like "before I allow the issue to make this transision, check this function returns "true"
[16:08] <ltsampros> hello ppl
[16:08] <awilkins> Set field automatically, automatically commit + push on state transition, etc.
[16:09] <Verterok> i think, that can be done from a bzr hook and  bit of python glue
[16:09] <Verterok> awilkins: here is it: http://www.panoramicfeedback.com/opensource/index.html
[16:09] <awilkins> I was thinking the same mysself..... is it integrated with Eclipse?
[16:09]  * awilkins looks
[16:10] <Verterok> awilkins: I think is not
[16:10] <awilkins> But does it use dinky little XML files?
[16:11] <awilkins> I could always write some integration, if it's easier than breaking my current appraoch (which really hasn't had too much work donwe to it)
[16:11] <Verterok> awilkins: I think it uses plain text files
[16:11] <awilkins> Well, that's fine too
[16:12] <ltsampros> sorry for interrupting guys (i'm a very new user) , but let's say there is a repository like http://code.bitlbee.org/jelmer/win32/
[16:12] <Verterok> Hi ltsampros
[16:13] <ltsampros> according to the website, i'm told to create a local copy of the bitlbee-win32 branch using  bzr branch http://code.bitlbee.org/jelmer/win32 bitlbee-win32
[16:13] <ltsampros> which works of course
[16:13] <Verterok> awilkins: I'm sure abentley can help you with bug-everywhere integration with bazaar workflows
[16:13] <Verterok> ltsampros: yep
[16:13] <ltsampros> but let's say i want to get a list of all published branches in that repository. is there a way to do so. a half hour googling didn't reveal anything
[16:14] <Verterok> ltsampros: http://code.bitlbee.org/jelmer/win32 is one branch, not a repo in the svn/cvs-way
[16:14] <awilkins> If the web server lets you list the directory that'll workj :-)
[16:15] <ltsampros> i see. thanks for the info
[16:16] <Verterok> ltsampros: launchpad can help with that :) https://code.launchpad.net/bitlbee
[16:17] <ltsampros> thanks for that too.
[16:17] <ltsampros> integration with launchpad seems nice
[16:44] <awilkins> Integration with launchpad will be veen incer when the source opens :-)
[17:05] <ubotu> New bug: #194789 in bzr "Branches with symlinks can't be exported on Windows" [Undecided,New] https://launchpad.net/bugs/194789
[17:27] <jelmer> Odd_Bloke: hi!
[17:27] <jelmer> Odd_Bloke: still there?
[17:27] <jelmer> Odd_Bloke: Im in the debian room atm
[17:27] <Odd_Bloke> jelmer: Cool.
[17:28] <Odd_Bloke> I attempted to get to that talk, but was too late to fit in. :p
[17:30]  * jelmer is trying to get out atm, but I'm in the far back
[17:31] <jelmer> LarstiQ: ping
[17:38] <seba__> hi
[17:40] <seba__> i try to run bzr fast-import
[17:40] <seba__> and get http://pastie.caboo.se/156320
[17:40] <seba__> any idea ?
[17:40] <seba__> python version prolly
[17:45] <Verterok> seba__: it seems that fast-import is using python-2.5 syntax
[17:45] <Odd_Bloke> seba__: Yeah, that's syntax that changed between 2.4 and 2.5.
[17:45] <seba__> yeah saw that
[17:45] <seba__> http://www.python.org/doc/2.5/ref/try.html
[17:48] <seba__> got this now:
[17:48] <seba__> $ bzr fast-import /del/dvcs-test/hg
[17:48] <seba__> bzr: ERROR: [Errno 21] Is a directory
[17:48] <Odd_Bloke> seba__: I believe that 'fast-import' is designed to import from a specific format.
[17:49] <seba__> I want to import from hg
[17:49] <Odd_Bloke> To be able to import an hg branch, there needs to be Mercurial support for exporting to that format.
[17:49] <seba__> thing is i didn't really understand what is this front-end
[17:50] <seba__> ah ok
[17:50] <seba__> front-end | bzr fast-import -
[17:50] <seba__> I have to replace front-end by the one I chose
[17:58] <hsn_> can i upgrade remote repo to packs?
[17:58] <awilkins> Only via bzr+ssh, methinks
[18:00] <Odd_Bloke> jelmer: I'm in the hacking room in the main building, BTW.
[18:09] <seba__> it seems as if it's mission impossible to hg -> bzr
[18:10] <Odd_Bloke> seba__: Yeah, unless you go via something that they both have decent conversion tools for.
[18:11] <Odd_Bloke> jelmer: I'm being kicked out of the hacking room, so probably won't be on IRC for a while.
[18:17] <Verterok> seba__: maybe bzr-hg? http://bazaar-vcs.org/BzrForeignBranches/Mercurial
[18:20] <seba__> Verterok, I tried this one
[18:20] <seba__> it's slow as hell
[18:20] <awmcclain> If you have a local mirror branch with local feature branches, wouldn't it theoretically make branching faster to put them all in a local shared repository?
[18:21] <Verterok> seba__: the last option I'm aware is tailor, but never used it
[18:22]  * Verterok lunch, bbl
[18:22] <seba__> Verterok, in fact i didn't try bzr-hg but http://bazaar.launchpad.net/~luks/+junk/bzr-hgimport
[18:22] <seba__> which was the slow one
[18:22] <seba__> but bzr-hg only allow mirroring
[18:22] <seba__> not direct export <-> import
[18:23] <seba__> and concerning tailor it was ~as slow as bzr-hgimport
[18:23] <johnny> slow is a problem?
[18:24] <johnny> it'll finish and you won't have to do it again?
[18:24] <seba__> yeah sure
[18:24] <seba__> i agree
[18:24] <seba__> but you know ppl are impatient :)
[18:24] <johnny> calling it mission impossible is a big overstatement then
[18:24] <johnny> unless it fails..
[18:25] <seba__> hg -> git was ~5h while hg -> bzr with bzr-hgimport would be 37h and with fast-import fails
[18:25] <johnny> git is surely faster
[18:26] <seba__> and 37h when it doesn't fail in the middle for unknown reason...
[18:26] <johnny> git makes more compromises tho in design
[18:26] <seba__> like ?
[18:26] <johnny> compare monotone to git and you'll see
[18:27] <seba__> it's already hard job comparing hg, git, bzr
[18:27] <bob2> awmcclain: yes branching within a repository might be faster than not
[18:27]  * awmcclain tests
[18:28] <johnny> hg is out of the running for me, mainly due to the fact i think bzr will getmore use than hg
[18:28] <johnny> and go farther, mostly due to launchpad if nothing else
[18:28] <johnny> and git is still too cryptic to use
[18:28] <johnny> especially for vcs n00bs
[18:29] <seba__> hehe
[18:29] <johnny> so for me, it is monotone vs bzr
[18:30] <seba__> fact is apart of Canonical partners bzr wasn't chosen by any big name so far...
[18:31] <johnny> that's a big enough name, especially since launchpad mirrors so many repositories
[18:31] <seba__> and monotone isn't as popular as the 3 others
[18:31] <johnny> but the design is amazing
[18:31] <awmcclain> seba__: I've used hg and bzr. I ended up choosing bzr for our team because a) the centralized features made sense for our webapp 2) the docs are much better IMHO 3) the eclipse plugin is _much_ better (and we're a partial eclipse shop
[18:32] <johnny> seba__, you do know git got it's best ideas from monotone right?
[18:32] <seba__> what prevented you from having a central peer with hg ?
[18:33] <seba__> johnny, i do think it just got its ideas from BitKeeper instead...
[18:33] <johnny> no
[18:33] <johnny> i'm sure they got some of the ideas
[18:33] <johnny> but if you go back and read, you'll see that if mtn would have been faster at the time
[18:33] <seba__> lol
[18:33] <johnny> we might not even know what a "git" is
[18:33] <seba__> sure man
[18:33] <awmcclain> seba__: There aren't as many features to faciliate centralized workflows (i.e. checkouts to force lockstep development).
[18:33] <seba__> but that's the game...
[18:34] <johnny> seba__, i was using bitkeeper around the time
[18:34] <johnny> so i know about that whole situation, we had to switch too
[18:34] <johnny> we were #3 on the bitkeeper list
[18:34] <johnny> right behind the linux kernel and mysql
[18:34] <seba__> bzr lost many battle because of its crappy performance of the beginning
[18:34] <seba__> it's hard going back after such
[18:35] <johnny> when we chose, we didn't have a git to choose from :) and bzr barely exited
[18:35] <johnny> existed*
[18:35] <awmcclain> Yup. I still think hg is a tad faster... but if you follow a workflow where you have local mirrors (which i think bzr does a better job promoting), then it's not really an issue
[18:35] <johnny> oh..and when git did start.. there was definitely no win32 support
[18:36] <awmcclain> Woah! Big peedup!
[18:36] <awmcclain> *speedup!
[18:36] <awmcclain> Average time branching without a shared repo... ~20sec
[18:37] <awmcclain> Average time branching with a shared repo... ~3 sec
[18:37] <awmcclain> Plus, using a shared repo I can get around that rich-root-pack bug!
[18:37]  * awmcclain cheers
[18:53] <awmcclain> One question about http://bazaar-vcs.org/SharedRepositoryLayouts#simple-developer-naming-project-joe-foo-project-barry-bar
[18:54] <awmcclain> Are the developer names just folders in the repository? With branches inside them?
[19:04] <abentley> awmcclain: yes
[19:11] <ubotu> New bug: #177683 in trac-bzr "All revisions and changesets starts with a comma sign" [Low,Triaged] https://launchpad.net/bugs/177683
[19:21] <ubotu> New bug: #194831 in trac-bzr "Non-urlsafe characters are escaped in branch names" [Undecided,New] https://launchpad.net/bugs/194831
[20:38] <db-keen> I'm having trouble pulling an svn repo to branch into a repository
[20:38] <db-keen> bzr: ERROR: Repository KnitPackRepository('file:///[...]/.bzr/repository/') is not compatible with repository SvnRepository('http://[some_site]')
[20:39] <db-keen> it works fine if I branch outside the repository
[20:41] <db-keen> can I just bzr branch $SVNREPO $BRANCH;mv $BRANCH $LOCAL_BZR_REPO/
[20:41] <james_w> db-keen: yes, bzr-svn requires something called 'rich-roots'. The default format does not support them.
[20:42] <james_w> You can either create a "rich-root-pack" repository (bzr init-repo --rich-root-pack) for working with bzr-svn, or force bzr-svn to not use that repository, by using the workaround you suggest.
[20:43] <james_w> *providing that $BRANCH is not inside another shared repository*
[20:44] <db-keen> is there some reason I wouldn't use rich-roots?
[20:45] <db-keen> Can I convert an existing repo to use rich roots?
[20:55] <james_w> db-keen: they are a watershed conversion, so once you switch to it all branches of that code you interact with must use it also.
[20:56] <james_w> This is fine for bzr-svn based stuff, but for existing bzr projects it is harder.
[20:56] <james_w> For new bzr projects then I suggest you use it.
[20:56] <db-keen> why is it harder?
[20:56] <db-keen> is it compatible with Launchpad?
[20:58] <db-keen> if I should use it for new projects and it works with svn when other formats don't, why isn't it the default?
[20:58] <james_w> yes, it is.
[20:58] <james_w> I'm not sure what the exact reason is really, but we want to transition soon.
[20:59] <james_w> one reason is that "bzr init-repo" would do the wrong thing to branch an existing project.
[21:00] <db-keen> I'm still not sure what you meant by "for existing bzr projects it is harder"
[21:20] <awmcclain> db-keen: I *just* ran into this today
[21:21] <awmcclain> Also note that as of 1.2.0, if' your client is using bzr+ssh:// you have to do a work around to check out SVN-based bzr branches as well.
[21:22] <awmcclain> Since the "smart server" transports create branches on the local machine in the default format, not the remote format
[21:22] <db-keen> what exactly do you mean svn-based?
[21:23] <db-keen> I'm still running bzr 1.1.0
[21:24] <awmcclain> bzr branches that you import from SVN. I set up our machines to have a mainline on a central server (and I ported over our codebase from SVN), so when i made my shared repo i had to init with --format=rich-root-pack.
[21:24] <awmcclain> (in order to prevent that error that you're talking about)
[21:25] <awmcclain> Then, on my dev box, when I went to bzr co bzr+ssh://mainline local-mirror, it gives another error
[21:25] <awmcclain> If you're not using a "smart" transport (bzr+ssh://, bzr://), you don't have to worry about that second bug.
[21:27] <awmcclain> db-keen: Is the repository you're branching into on your local machine or a remote one?
[21:28] <db-keen> awmcclain: I'm trying to branch an svn repo on a remote machine into a bzr repo on the local machine
[21:28] <awmcclain> And you already have other, non-svn branches in your repo?
[21:28] <db-keen> yes
[21:28] <awmcclain> :(
[21:29] <db-keen> I've been working with bzr without using repositories
[21:29] <db-keen> I'm still entirely sure what the advantage is, but people make it sound like a good idea for some reason...
[21:30] <db-keen> still *not* entirely sure
[21:30] <awmcclain> Are your existing branches the same codebase as the svn branch?
[21:31] <db-keen> they're related, I'm trying to merge code from another project (the svn) into my existing bzr project
[21:32] <awmcclain> Here's what I would do...
[21:32] <johnny> i'm still trying to merge my understanding of what i'm used to working with. with bzr..
[21:33] <johnny> thus i have trouble with understanding the repository thing too
[21:33] <awmcclain> Here's how I think of bzr shared repositories
[21:33] <awmcclain> (as someone who just spent the last 3 days moving from SVN to bzr)
[21:34] <johnny> well moving from svn to anything would be an improvement (except cvs)
[21:34] <johnny> i avoided svn from the start.. so i dont'really have experience with that
[21:35] <awmcclain> Normally, when you make a self-contained branch, you have ALL of your version history in that branch, along with your working tree-- the "checkout" of that branch (to use SVN terms)
[21:36] <awmcclain> meaning, the entire log is tucked away inside that directory
[21:36] <johnny> the entire change graph
[21:36] <awmcclain> shared repositorities are basically special folders that hold the common histories of the branches inside them
[21:36] <awmcclain> johnny: ye
[21:36] <awmcclain> s
[21:36] <johnny> aha..
[21:37] <db-keen> awmcclain: that seems like what I'm trying to do
[21:37] <johnny> see.. i'm used to working with monotone, where that already happens by default
[21:37] <awmcclain> For example:
[21:37] <johnny> as long as you put your code in the same db
[21:37] <awmcclain> I have a mainline server
[21:37] <awmcclain> And I have a mirror on my local machine, and from that mirror i'll be making lots of little feature branches
[21:38] <awmcclain> Without a shared repository (on my local machine), each time i branch i copy the ENTIRE history
[21:38] <awmcclain> (the entire graph)
[21:38] <awmcclain> but, if my mirror and all my branches are in a repository
[21:38] <awmcclain> when I branch, I'm copying over (i think) just my working tree
[21:38] <awmcclain> difference of 20 secs to branch vs 3 sec to branch
[21:39] <awmcclain> plus less disk space
[21:39] <db-keen> awmcclain: I keep all my projects in a single directory (~/Projects), should I just turn that directory into a repo?
[21:39] <johnny> hmm. why do i feel that bzr is more complicated ..
[21:39] <johnny> db-keen, not if they are unrelated it seems
[21:39] <awmcclain> exactly
[21:39] <johnny> ~/projects/foo/ would be one
[21:39] <db-keen> they are unrelated, but at the same time, I just might share code between them
[21:39] <johnny> ~/projects/bar would be another
[21:39] <awmcclain> because you only really get a benefit of a shared repository when you have a signifcant common history
[21:40] <johnny> then how are they related?
[21:40] <johnny> db-keen, use case?
[21:40] <awmcclain> db-keen: I'd say, if you're just cherry picking some change between them, don't worry about putting them all in a shared repo
[21:41] <db-keen> that's what I thought, I just had to ask
[21:41] <awmcclain> db-keen: Are projects/foo and projects/bar two different branches or two different projects?
[21:42] <johnny> i meant projects when i used it as an example
[21:43] <db-keen> the way I have it right now, subdirs of ~/projects are mostly branches, but I've been converting the larger ones into repos with nested branches
[21:43] <awmcclain> db-keen: Can you give an example of the one of your repos?
[21:44] <awmcclain> s/the//
[21:45] <johnny> you should go with ~/projects/random for random unassociated branches
[21:45] <johnny> or something
[21:45] <johnny> and then ~/projects/projectfoo for repos
[21:45] <johnny> for all branches of projectfood
[21:45] <johnny> err foo*
[21:46] <lifeless> johnny: unrelated projects work fine in a reop
[21:46] <lifeless> johnny: repos are _just_ storage optimisation.
[21:46] <johnny> either way... the actual shared ones can go together
[21:46] <johnny> or should
[21:47] <db-keen> I have to go, but thanks for your help
[21:47] <awmcclain> welcome
[21:47] <db-keen> I might be back later...
[22:30] <awmcclain> What's the bzr command to show me what files have changed in a branch?
[22:31] <luks> bzr st?
[22:32] <awmcclain> That's not recursive, though, right?
[22:32] <luks> it is
[22:32] <luks> it displays files for the whole branch by default
[22:33] <awmcclain> ok
[22:34] <awmcclain> Sorry, i was looking in the wrong branch. You're totally right. :)
[23:25] <awilkins> The bit about bzr I find more complicated is the multiple repo formats, and the no-fixed-central-point thing.
[23:25] <johnny> the no fixed central point is at least par for the course among all the systems :)
[23:25] <johnny> except svn and cvs that is
[23:26] <johnny> the multiple repo formats is certainly an annoyance in bzr atm
[23:26] <awilkins> And a lack of mature integrated GUI tools... I'm too used to being able to r-click on a file and get a diff in my favourite diff tool
[23:26] <johnny> something to deal with at some point
[23:26] <johnny> once again.. par for the course :)
[23:27] <johnny> there are some tortoise type things iirc
[23:27] <johnny> for other systems
[23:27] <awilkins> Handling win32 file locking semantics is another thing
[23:27] <johnny> does any system handle that well?
[23:27] <johnny> it's been awhile since i've used anything on windows
[23:28] <awilkins> TortoiseSVN is of course very good at it :-)
[23:28] <johnny> nasty windows
[23:28] <awilkins> swings/roundabouts
[23:28] <johnny> i'm glad i only have to make small glances at worry about support with
[23:28] <awilkins> In some ways, I don't really trust the whole laxy unlinking thing
[23:29] <johnny> with windows*
[23:29] <johnny> windows file locking sucks.. i'm so glad i don't have to worry about..
[23:31] <Peng> The one good thing about the multiple formats is that at least it's handled pretty smoothly.
[23:31]  * awilkins could name several bugs that contradict that theory
[23:32] <Peng> "pretty". :P
[23:35] <johnny> i bet they relate to svn crap :)
[23:36] <awilkins> Translating between pack-092 and rich-root-pack are the ones I've bumped into :-)
[23:36] <Peng> Ah, yeah.
[23:37] <Peng> Incompatible formats seem to be the main rough spot at the moment. :\
[23:49] <lifeless> awilkins: you can use a fixed central location i fyou want, by using 'checkout and commit' rather than 'branch and push'