[00:06] <jelmer> chandlerc, do you use any fancy compiler flags on Gentoo?
[00:26] <ferringb> I'm getting a revision_id from a file w/in a branch that isn't in said branches revision_history()... I'm assuming this is a submerge of some sort, but how should I go about tracing it back to a rev in the branches revision_history?
[00:28] <chandlerc[g]> jelmer: not really
[00:29] <chandlerc[g]> jelmer: -O3 -fomit-frame-pointer.. i really only aim for inlining and reducing register pressure
[00:30] <chandlerc[g]> jelmer: and bzr-svn is compiled with nothing, and lots of debugging, i don't install it via gentoo tools
[00:42] <jelmer> chandlerc[g], what about the compile flags for python itself?
[00:47] <chandlerc[g]> i reproduced it with a hand built, debugging enabled python
[00:48] <chandlerc[g]> was still using the system installed subversion libs and bindings tho
[02:06] <teratorn> I repository A, which has been in use for a long time. Now recently I've created repository B to hold some related work, and I've committed many revisions to it. I would like to import repo B in to a sub-directory of repo A, including all revision history.. is this possible?
[02:06] <teratorn> *I have
[02:10] <bob2> sure
[02:12] <teratorn> bob2: OK, how? :)
[02:13] <bob2> cd A/somewhere ; for branch in `bzr branches ~/B` ; bzr branch ~/B/$branch $branch ; done
[02:13] <bob2> but that breaks for  branches in nested dirs - I think you'd need to use push --create-prefix
[02:15] <bob2> cd ~/b ; for branch in $(bzr branches) ; do (cd $branch ; echo bzr --create-prefix push ~/a/somewhere/$branch) ; done
[02:16] <teratorn> bob2: thanks, I'll experiment
[02:16] <bob2> repo-push would be ideal. but I don't think it can push into a subdir of a repository
[02:17] <fullermd> Well, I would read the question as asking rather about merge...
[02:37] <teratorn> bob2: "bzr branches" just prints a single newline when run on either of my repos
[02:38] <teratorn> bob2: and besides.. I don't wish to have a separate branch existing within a subdirectory of another branch... I wish to merge revisions from repo B in to A, except I want the files in repo B to appear inside a subdir of repo A
[02:39] <teratorn> I'm going to delete repo B once this is done
[02:39] <bob2> I think we're conflating branches and repositories
[02:39] <teratorn> ok, probably so :)
[02:41] <bob2> in bzr, repositories are just places where branches live and share storage.  you can not ever use a repository, and it'll only cost you some disk (and maybe bandwidth).
[02:42] <teratorn> ok
[02:42] <bob2> are A and B branches (ie contain files you've commited etc)?
[02:42] <teratorn> yes
[02:43] <teratorn> so yeah, I was using the wrong terminology
[02:45] <bob2> are A and B related at all (ie is one a branch of the other)?
[02:45] <teratorn> no
[02:45] <teratorn> but I've decided that the content is logically related, and so I've decided to merge the branches
[02:46] <teratorn> s/merge/combine/
[02:46] <teratorn> and I have no idea what that means in terms of BZR
[02:47] <bob2> I think the trick would be: (in B) "bzr mkdir subdirwhereyouwantthefilestoappearinA ; bzr mv * subdirwhereyouwantthefilestoappearinA" (in A) "bzr merge -r0..-1 ../b ; bzr commit -m 'merge in B.'"
[02:47] <bob2> er, commiting in B after the mv
[02:47] <bob2> fullermd: right?
[02:48] <teratorn> sounds like we're getting there... the thought that I would have to "mirror" the directory structure occured to me
[02:48] <bob2> (you could do the mv after the merge, but it'd be fiddler if any of the names collided)
[02:51] <fullermd> Pretty much, yeah.  With rich roots, 'bzr join' should be able to automate some of that.  Ditto for the 'merge-into' plugin.  But it's not that hard to do it manually.
[02:51] <fullermd> (don't forget to commit after the mv in B before you merge)
[02:53] <teratorn> bob2: OK, well yes what you suggested did work.
[02:53] <teratorn> looking at 'bzr log' in A it seems that all the revisions from B are now sub-revisions of the revision I committed to A after merging
[02:53] <teratorn> and I suppose when I push to SVN it will only go through as a single commit
[02:54] <teratorn> so Trac won't have my actual history...
[02:54] <teratorn> is this always how bzr merges work?
[02:55] <fullermd> Well, when you try and shove it into a round hole like SVN...  ;)
[13:36] <dereine> how can i rename files?
[13:39] <james_w> dereine: is "bzr mv" what you are after?
[13:43] <dereine> thx i tought mv would be do easy ^^
[23:02] <lifeless> spiv: call?
[23:02] <spiv> lifeless: sure.  I'm on skype if you want to use that.
[23:03] <lifeless> its trying ...
[23:07] <lifeless> fooding
[23:32] <poolie> lifeless, spiv, anyhow today i was going to finish setting up kerguelen to the point it can at least manually build correct packages
[23:32] <poolie> and then do 1.8final and 1.8rc1
[23:33] <arjenAU> poolie: morning! hey quick q... I did mv of a version controlled file (without bzr mv), then mistakenly did bzr commit but aborted it, renamed back, then bzr mv but then bzr says it's not under revision control. I think that something does get committed at least as far as the live state is concerned?
[23:33] <arjenAU> I can run through it in a fake repo to reproduce ... this is 1.7 I think
[23:34] <poolie> if you can write a reproduction script that would be good
[23:34] <arjenAU> on it. no worries.
[23:34] <lifeless> poolie: cool
[23:34] <poolie> when you say "aborted" do you mean you uncommitted, or you pressed ^C during the commit?
[23:34] <lifeless> poolie: I'm working on  fetching inventories faster
[23:35] <poolie> if the latter, it's possible that you caught it after the workingtree was updated but before the branch was updated
[23:35] <poolie> since it is not precisely atomic across those objects
[23:35] <poolie> lifeless: and doing something on usertest? writing more scripts?
[23:35] <poolie> lifeless: btw i looked yesterday and orcadas was still running the same job
[23:35] <arjenAU> and we have a hit. ok wraping up the script
[23:35] <poolie> since it runs bzr branch several times
[23:38] <poolie> you can reproduce it?
[23:41] <arjenAU> poolie: https://bugs.launchpad.net/bzr/+bug/282402
[23:41] <arjenAU> ye that ;-)
[23:41]  * arjenAU forgot about the bot
[23:41] <lifeless> poolie: no, I mentioned usertest to andrew in the context of 'usertest is still fetching'
[23:41] <poolie> is that meant to be an 'uncommit'?
[23:42] <arjenAU> nop
[23:42] <lifeless> poolie: it only clones the full repo once
[23:42] <poolie> arjenAU: ??
[23:42] <poolie> # abort the following commit, because we realise we should've done the rename through bzr
[23:42] <poolie> bzr commit
[23:42] <poolie> what does that mean?
[23:42] <arjenAU> poolie: exit out of the changelog editor without saving, so it does not commit
[23:43] <poolie> oh i see
[23:43] <arjenAU> except SOMETHING is stored anyway...
[23:43] <arjenAU> yea. and veyr common possibly, it's so easy for the fingers to type mv and late realise that it was wrong - you realise when you see the changelog in commit, so you back out, ....blahdiblah and there you are, a murdered history
[23:44] <arjenAU> I haven't tracked what is actually mucked up where, but since you guys will fix this I won't bother ;)
[23:44] <poolie> :)
[23:44] <lifeless> arjenAU: so you've done 'mv foo bar'
[23:45]  * arjenAU hugs all bzr devs - great work everybody, thanks! sooooo easy. kinda feels like bk when I first got to use it years ago
[23:45] <poolie> i answered it
[23:45] <lifeless> arjenAU: and "bzr commit -m ''" loses the fact foo existed
[23:45] <lifeless> ?
[23:45] <lifeless> I bet its the implicit delete code
[23:45] <poolie> yes, it is
[23:46] <lifeless> 6ok cool
[23:46] <arjenAU> never use -m
[23:46] <lifeless> -> repository code
[23:46] <poolie> lifeless: i remember you have an opinion about that but i can't remember which way it points :)
[23:46] <poolie> against or in favor of implicit delete?
[23:46] <lifeless> poolie: I want auto-add and auto-delete in commit, for symettry
[23:46] <lifeless> poolie: I wrote a patch to do auto-add in commit, it was .. contentious
[23:47] <poolie> ok
[23:47] <arjenAU> oh hmm... well commit doesn't auto-add things, so I don't want it to auto-rm things either
[23:47] <lifeless> but yeah, I'm fine with the functionality
[23:47] <poolie> i agree they should be symmetrical but i suspect it should default off
[23:47] <arjenAU> but it should be either or none
[23:47] <arjenAU> you know you could make it even more nifty
[23:47] <lifeless> poolie: the thread is there on the list :>
[23:48] <arjenAU> if a file vanishes, grab a hash of the alst revision and see if any of thenew files is the same?
[23:48] <arjenAU> suggesting a rename!
[23:48] <arjenAU> won't work if it was also edited, but...
[23:48] <poolie> i think there's a bzr-autorename plugin that does this?
[23:48] <arjenAU> plugins, plugins...
[23:50] <lifeless> poolie: I'm really quite happy with the behaviour of 'bzr rm' now
[23:50] <lifeless> poolie: I'm thinking of going back to it and removing some of the extra knobs
[23:51] <arjenAU> ok so anyway you guys have an angle on what's going on. that's good, then I can move on and see the update soon!
[23:52] <lifeless> arjenAU: you do know you can 'bzr revert foo' too, to restore bzr's tracking of it after it was renamed
[23:52] <arjenAU> lifeless: so it's kinda half committed?
[23:52] <arjenAU> lifeless: I'm just trying to get my head round what bzr is thinking there
[23:52] <lifeless> arjenAU: no; the commit is writing an update to the staging area
[23:53] <lifeless> arjenAU: there is a thing called dirstate that lists what is versioned in your current tree
[23:53] <arjenAU> ye, so autoremoves shouldn't be written there before the commi is confirmed, then eh?
[23:53] <lifeless> arjenAU: commit has two major tasks: to add a new revision to the repository, and to update the dirstate to record what was committed so it doesn't show as changed anymore
[23:54] <lifeless> arjenAU: and its just unlocking rather than rolling back the change to the dirstate
[23:54] <arjenAU> gotcha. so it's kinda half committed
[23:54] <lifeless> arjenAU: so its precisely equivalent to 'mv foo bar' && 'bzr rm'
[23:54] <arjenAU> ye ok. so with bzr revert I can undestroy my world. but you're going to fix it anyway ;-)
[23:55] <lifeless> arjenAU: to restore the data for 'foo', you can do 'bzr revert foo'  (which will restore the dirstate entry) and then 'mv bar foo'
[23:55] <arjenAU> foo bar. yea
[23:55] <lifeless> oh sure, its a bug, but its kinda cosmetic compared to some of the performance and functionality stuff
[23:55] <arjenAU> lifeless: dude this is serious, I keep tripping over it
[23:55] <lifeless> (no, bar foo, to put your copy of bar back)
[23:55] <MattCampbell> Does bzr work with Python 2.6 yet?
[23:55] <lifeless> MattCampbell: there is a patch, I don't know if its landed yet
[23:56] <poolie> MattCampbell: it is landed, it should work in 1.8rc1
[23:57] <poolie> bug reports welcome
[23:57] <jonoxer> Hi ppl! After all the assistance on Friday to reset the svn hard-wiring in my brain I'm back with another question. One that will make ArjenAU very happy
[23:58] <jonoxer> I've successfully switched a few svn repos to bzr by doing something like: "bzr branch file:///home/jon/temp/svn/blah blah" (with the bzr-svn plugin installed)
[23:58] <arjenAU> jonoxer: go for it, grasshopper. your world will be better
[23:58] <jonoxer> But it runs out of memory about 3 hours and 11,000 commits into converting a 21,000 commit, 4.4G repo
[23:58] <jonoxer> I get a traceback from bzr
[23:59] <jonoxer> This is on a machine with 2G RAM, 4G swap, and it doesn't ever fill the swap
[23:59] <lifeless> jonoxer: well, whats the traceback
[23:59] <jonoxer> Is there any recommended way to convert a large repo?
[23:59] <jonoxer> lifeless: I'll pastebin it, gimme a sec...