[12:21] <et_> Running 0.18.0. Have checkout. Tried to commit. Got "ERROR: parent_id ... not in inventory". Have no clue what caused this happen, or how to correct it.
[12:27] <et_> Looks like if you bzr moved a file, and try to commit another file without first commiting the move, you get this error message. The work around is to commit the move first.
[02:29] <vila> 4. he's got a *first* baby :)
[03:50] <lapthrick> can you uncommit a revision from the middle of the history?
[03:51] <lapthrick> like, if the current revision is, say, 3000, can I uncommit rev 2900 only?
[06:45] <lifeless> lapthrick: no, uncommit just pops the top off the branch, recursively
[02:32] <cory> I'm confused that adding identical files is a conflict.
[02:34] <dato> cory: when you `bzr add` the same file in two different branches, each of them gets assigned a different file-id, which is the id bzr uses to know if they're the same file or not
[02:49] <cory> I understand.  I guess my gut expectation though is that it clobber files with the same name so that I can do a bzr status to see if they've actually changed, myself.
[02:52] <cory> Also, if, say, I accidentally reverted that part of a merge and kept the files different, I have no idea how to cause them to merge again.
[02:54] <cory> It's unfortunately guaranteed to happen the way I'm trying to round-trip changes with p4. :P
[08:34] <lapthrick> jelmer: poke?
[08:51] <lifeless> moin
[08:51] <lifeless> cory: ping
[09:29] <cory> lifeless: Hiya.
[09:29] <lifeless> hi
[09:30] <lifeless> you're working on a p4 round-tripper ?
[09:30] <cory> pong?
[09:32] <cory> I just have some sketchy scripts I threw together.  One to automate bringing changes from p4 to bzr, and one that just opens files for edit / add / whatever by comparing the current working tree and p4 branch in bzr.
[09:33] <lifeless> ok
[09:33] <cory> The first should really just be tailor, but fixing that was more daunting than making something that would work for now.
[09:33] <lifeless> so a couple of notes about the guts that may help you
[09:33] <lifeless> tailor is, IMO, broken by design
[09:33] <lifeless> because its a lowest common denominator approach
[09:34] <cory> Sure.
[09:34] <lifeless> I prefer high fidelity myself
[09:34] <lifeless> anyhow, bzr has an inode concept
[09:34] <lifeless> files are accessible by path, but identified by 'inode', which we call 'file-id'
[09:36] <cory> How would I take advantage of that?
[09:36] <lifeless> we have some sketches for recording copying and merging of file-ids. When we have that it will be possible, and occasionally sensible, for merges that end up with a file with mostly the same content, at the same place, to be merged rather than placed alongside each other
[09:36] <cory> Ah, neat.
[09:36] <lifeless> but until those sketches are turned into reality you have a bit of a problem :)
[09:37] <lifeless> there are a few ways around the issue
[09:37] <lifeless> bzr-svn, which has the same issue, tackles it by assigning deterministically unique file-ids
[09:38] <lifeless> which gives e.g. README in all branches of the same project on the same svn server the same fileid
[09:38] <lapthrick> http://pastebin.com/m63022805 <-- more bzr-svn fun
[09:38] <lifeless> but unique across all other svn servers
[09:38] <cory> Hrrrrm.
[09:38] <lapthrick> apparently you can't merge-into from an SVN repo, it goes wrong at some point
[09:39] <lifeless> lapthrick: merge-into is a plugin command, it possibly uses the bzrlib api in ways that the bzr-svn author hasn't accomodatd.
[09:39] <cory> How do files get added to a branch from the bzr side when you're working with bzr-svn?
[09:39] <lifeless> lapthrick: I would file a question on bzr-svn about that
[09:39] <lifeless> cory: bzr add :)
[09:40] <lapthrick> lifeless: you mean a question and not a bug now?
[09:40] <cory> Does bzr-svn get involved and make sure the file has a proper file-id?
[09:40] <lifeless> lapthrick: I suggest you work with 'bzr checkout svn:// && bzr merge && bzr commit' because that will preserve the history the same as merge-into, with the advantage of working.
[09:40] <lifeless> lapthrick: yes, its not clear where the bug is.
[09:40] <lifeless> lapthrick: so ask for help :)
[09:41] <lifeless> cory: perhaps I misunderstood your question. I thought you meant 'bzr branch svn:///  foo && cd foo && touch BAR && bzr add BAR && bzr commit && bzr svn-push svn:////'
[09:41] <cory> Oh, or is the original file-id stored in an svn property?
[09:41] <lifeless> cory: yes, bzr svn-push (it will be integrated with bzr push sometime) annotates the svn repository
[09:42] <lapthrick> lifeless: but plain merge won't result in having a branch in a subdir, I do have it working with a branch made out of SVN, I just wanted to reduce the number of intermediate steps between upstream SVN and my branch-in-subdir
[09:42] <lifeless> lapthrick: I don't understand what you mean
[09:42] <lapthrick> lifeless: well, I don't understand what I'm supposed to merge
[09:43] <lifeless> lapthrick: what are you trying to do then?
[09:44] <lifeless> cory: so if you don't want to annotate p4, you can just do a one-way solution, as long as the ids in different branches for the same file are the same bzr will be happy
[09:44] <lifeless> cory: when you add a file on the bzr side, you will have a history disconnect after you get it coming back at you from p4, just take the p4 version always
[09:45] <lapthrick> lifeless: the same as I was doing yesterday (have a branch of an upstream SVN repo inside a subdir of my own repo), but pulled directly from SVN, instead from my-branch-of-upstream-SVN that serves no other purpose than to mediate between upstream SVN and my branch-in-a-subdir
[09:45] <cory> lifeless: Yeah, that sounds sensible.
[09:45] <lifeless> cory: and do a manual merge (patch foo < diff foo.ORIG foo.THIS)
[09:45] <lifeless> lapthrick: do you mean 'repo' or 'tree' ?
[09:46] <lapthrick> lifeless: tree
[09:46] <lifeless> lapthrick: the terms are not interchangable for bzr.
[09:46] <lapthrick> yeah, I guess
[09:46] <lifeless> lapthrick: so, you have tree-root/upstream
[09:46] <lifeless> where tree-root is a bzr tree
[09:46] <lifeless> and upstream is a svn checkout ?, or a bzr-svn branch from svn ?
[09:49] <lapthrick> lifeless: http://pastebin.com/m1a7e323
[09:49] <lapthrick> is it more clear?
[09:51] <cory> Random thought...or there could be something like patch queue manager performing the actual p4 submits. :)
[09:52] <lapthrick> what's p4?
[09:54] <lifeless> lapthrick: I don't have a browser here
[09:54] <cory> lapthrick: perforce
[09:54] <lifeless> lapthrick: perforce, a vcs
[09:54] <lapthrick> lifeless: sec, I'll paste it in private
[09:54] <lifeless> k'
[09:54] <lapthrick> cory: so you're writing p4 integration?
[09:55] <lifeless> adhoc version I think
[09:55] <lifeless> rather than e.g. bzr-p4
[09:55] <cory> Just hacking enough together to get by. :P
[09:55] <lapthrick> ah, so just a single project that's somehow dependent on p4?
[09:56] <lifeless> lapthrick: I'm still confused; what is the relationship between mytree and myupstream; did you bzr join? or are you using the alpha-quality nested trees support?
[09:57] <lifeless> lapthrick: its hard for me to understand what you mean, as your commands used paths that did not exist (you branch to myupstream, then cd to mytree; I can't tell what mytree is meant to be there)
[09:58] <lapthrick> lifeless: mytree is a pre-existing tree I want to have upstream as a part of. I want to get the same effect as bzr join would have, but I'm using merge-into for that
[09:58] <lapthrick> not nested trees
[09:58] <lifeless> I don't understand why you use merge-into, rather than cd + bzr pull
[09:59] <lifeless> merge-into is for doing *merges*, and if you are not changing the upstream, and its just a separate tree that happens to be positioned one dir down, then pull should work fine
[09:59] <lapthrick> lifeless: because I want to have upstream/ be seen as a part of mytree. Mytree is actually backed by an SVN repo, so when I push into it, I want upstream/ be uploaded as well
[10:00] <lapthrick> I'm essentially using bzr to manage SVN for me
[10:00] <lifeless> ok
[10:00] <lifeless> so if you want the content to be added and managed, you need to combine the trees.
[10:00] <lifeless> that means 'bzr join myupstream'
[10:00] <lapthrick> but that's really experimental, right?
[10:01] <lapthrick> merge-into does the same, except without real nested trees support
[10:01] <lapthrick> (and with slight caveats because of that)
[10:03] <lapthrick> lifeless: will I get burnt badly if I use bzr join?
[10:04] <lifeless> merge-into does an implicit join
[10:04] <lifeless> you've already joined
[10:04] <lifeless> after that you should just use regular merge
[10:04] <lapthrick> yes, I know
[10:05] <lapthrick> lifeless: it works, as long as I don't try to merge-into directly from svn://
[10:05] <lapthrick> if I have that intermediate bzr-svn branch, it works like a charm
[10:05] <lifeless> lapthrick: but why are you running merge-into more than once
[10:05] <lifeless> lapthrick: I don't see why the intermediate branch is a problem as you only need it once
[10:05] <lapthrick> lifeless: I'm not, those were two different cases. First is what I did (and what worked), second was what I'd like to do
[10:06] <lifeless> so, I'd definately record this somewhere
[10:06] <lapthrick> lifeless: oh, so I can merge with svn:// later on?
[10:06] <lapthrick> if so, it's even better
[10:06] <lifeless> so that jelmer/john can look at the error
[10:06] <lifeless> but merge-into is used to perform the join
[10:06] <lapthrick> yah, will do
[10:06] <lifeless> you should not keep using merge-into
[10:06] <lapthrick> I'm not, I used it only once
[10:07] <lifeless> righto. So now you use bzr merge svn:// and that should work
[10:09] <lapthrick> apparently it does, missing --other reports nothing
[10:09] <lapthrick> lifeless: thanks, I didn't realise I could do that
[10:10] <lifeless> thats something John should add to the plugin docs
[10:11] <lapthrick> now I just need to figure out how to prod bzr-svn into making an actual SVN branch (ie. one that will result in a branch being created in the SVN repo)
[10:11] <lifeless> bzr svn-push ?
[10:11] <lapthrick> hmm, or I can do it by hand and then rebind
[10:12] <lapthrick> lifeless: will it have the same effect as doing cd svncheckout && svn cp trunk branches/mybranch && svn commit ?
[10:13] <lifeless> I don't know
[10:13] <lapthrick> ah, right, that's what it should do I guess
[10:13] <Lo-lan-do> Anyone knows whether jelmer works freelance?
[10:13] <lapthrick> let's test it on something that's not my job repo though :)
[10:14] <lifeless> Lo-lan-do: he's at uni still AFAIK
[10:14] <lifeless> hi keir
[10:14] <Lo-lan-do> Hmm.
[10:15] <keir> lifeless, hey
[10:15] <keir> lifeless, RL has been giving me the smackdown lately
[10:15] <lifeless> I know the feeling
[10:15] <keir> lifeless, so i haven't touched the indexing backend in awhile
[10:15] <lifeless> I only made incremental partial commit 40% faster last week  :()
[10:16] <keir> that's sweeeet!
[10:16] <lifeless> index reading is 14% of the remaining overhead !
[10:16] <keir> lifeless, cool
[10:18] <keir> lifeless, is that because it has to read the entire index?
[10:19] <lifeless> yes
[10:20] <lapthrick> awesome, it works
[10:22] <keir> lifeless, when do you expect to merge packs?
[10:24] <lifeless> keir: I'm hoping this week to have the code in bzr.dev
[10:24] <lapthrick> is there a way to retroactively change the committer on revisions? I have some revisions committed with the wrong name and would like to avoid mucking around with shelve if possible
[10:24] <keir> lifeless, neat!
[10:24] <lifeless> format freeze will be once the index read issue is fixed
[10:25] <keir> lifeless, have you looked at all at my code?
[10:25] <lifeless> keir: at some yes
[10:25] <lifeless> not at all
[10:25] <keir> lifeless, i won't be able to touch it until tuesday
[10:26] <lifeless> thats fine
[10:26] <keir> lifeless, i feel like the code has become too complicated, and i'd like a second opinion
[10:32] <lapthrick> so what about changing the committer? Is that possible?
[10:34] <keir> lapthrick, uncommit and re-commit?
[10:34] <lifeless> lapthrick: bzr does not support altering or annotating existing revisions
[10:34] <lapthrick> keir: I wanted to avoid doing that
[10:34] <lapthrick> hmm, okay
[10:34] <lifeless> lapthrick: we currently feel that this is too much complexity for too little return
[10:34] <keir> lifeless, what about the 'nuclear launch codes' problem?
[10:34] <lifeless> keir: uncommit and garbage collect
[10:34] <keir> lifeless, i've personally run into that and had to hex edit a svn repo
[10:35] <lifeless> there are plugins that can create new revisions from existing, preserving the deltas etc
[10:35] <keir> lifeless, aah, ok. in my case it was several revs behind
[10:35] <lifeless> but the *meaning* of the revision changes when you remove a file from it
[10:35] <lifeless> or change its content
[10:35] <lifeless> its hash changes
[10:36] <lapthrick> okay, so what will be the easiest change to pop a series of commits, then recommit them, just with a different name? If I could avoid typing in commits messages anew, it'd be helpful
[10:36] <lapthrick> s/easiest change/easiest way/
[10:36] <lifeless> lapthrick: check the rebase plugin out; AIUI it will do what you want
[10:36] <lifeless> of course, it may not ;)
[10:37] <lapthrick> ah, right
[10:37] <lapthrick> I wonder how experimental it is
[10:47] <lapthrick> bzr bzr-pokerolymp:2085/> log -r ancestor:svn+https://beta.aimido.de/svn/src2/trunk
[10:47] <lapthrick> Unhandled error:
[10:47] <lapthrick> 'NoneType' object has no attribute 'base'
[10:47] <lapthrick> interesting
[10:49] <lifeless> bug filin' time  :)
[10:49] <lapthrick> bzr bzr-pokerolymp:2085/> log -r branch:svn+https://beta.aimido.de/svn/src2/trunk
[10:49] <lapthrick> A write attempt was made in a read only transaction on LockableFiles(lock, file:///home/mathrick/Dev/rails/bzr-pokerolymp/.bzr/repository/)
[10:49] <lapthrick> man, I'm good :)
[10:51] <lifeless> intereseteing
[10:51] <lifeless> log should be read only
[10:52] <lifeless> I'm better bzr-svn is the culprit
[11:55] <igc> morning all
[11:55] <lifeless> hola
[11:55] <lifeless> you're up early :)