[00:05] asac: ping [00:12] how do I remove a branch from a shared repository? [00:13] rm [00:14] but won't that leave copies of the data in the repo? [00:14] I know I can safely rm a standalone tree, but this branch has nothing worth saving. [00:14] yes [00:14] don't think there's a 'bzr gc' command yet [00:14] so if you really care, afaik, you'd have to make a new repo and branch everything to it [00:15] ok [00:16] hmm, bzr pack wouldn't do garbage collection would it? [00:17] It does not do garbage collection. [00:17] That is, it doesn't remove anything. It just organizes and compresses it more efficiently. [00:20] Is a gc command on the roadmap? [00:21] It would be nice to have, there's a bug report for it somewhere, but it's not a priority. [00:24] yea, I suppose I didn't have gc with svn after all. Deleting branches in svn only add to diskspace requirements. [00:44] hmm, what about bzr reconfigure --standalone and rm? [00:44] will that remove extra copies from the repo or do copies always stay in the repo? [00:44] I'd be very surprised if that removed all the now-unneeded revision data from the repository [00:45] I suppose the repo just doesn't track which branches are using it so the above would be very difficult. [00:46] Right. [00:46] When you get into stacked branches, remote clients and stuff, it becomes impossible. [00:52] jelmer: Here's the bug report for that bzr-svn authentication.conf bug I was having https://bugs.launchpad.net/bugs/532292 [00:52] Launchpad bug 532292 in bzr-svn "Doesn't get user/password details from authentication.conf" [Undecided,In progress] [00:52] urlparse.urlsplit doesn't like 'svn+https' urls :S [00:57] dcoles: I've just fixed it :-) [00:58] jelmer: Cheers :) [00:59] dcoles: thanks for the detailed bugreport, that made it really easy to fix. [01:01] Has anyone encountered bzr-svn corrupting its cache.tdb if Ctrl-C'ed whilst caching new revisions? [01:01] jelmer: I do a lot of python programming for work... and bazaar being python based makes it really easy to hack on ;) [01:02] It seems to manifest as some paths/ keys going missing from the tdb [01:02] maxb: I've seen it, I'm 99% sure it's because of the "svn log" fetch reversal patch that went in for 1.0.2 [01:02] ooh, that would entirely explain it - log-last is ending up pointing to a higher number than completely cached [01:03] maxb: I haven't had time to look into it yet, but if you can provide a bug report/patch that would be most welcome :-) [01:03] * maxb will have a think. Unfortunately I guess you reversed the fetching for a reason, and fixing it without just backing it out doesn't seem obvious [01:04] the reversing is done because svn servers are quicker if asked for the revision data from newest to oldest [01:07] The "obvious" way to fix this would be to bin log-min and log-last and store a list of ranges which are cached [01:07] but that's a compatibility can of worms, I suppose [01:15] jelmer: this one failed in discovering tags, i think: http://launchpadlibrarian.net/40213543/vcs-imports-sit-trunk-log.txt [01:19] mwhudson: there's an open bug about that issue [01:19] mwhudson: would be nice if we could associate bugs with import failures (-: [01:19] jelmer: oh cool [01:20] jelmer: well yeah, i'll do the unsophisticated whiteboard/comment thing i guess [01:21] What's your opinions about keeping documents stored in a bzr branch? [01:24] jelmer: hm, it seems none of the 5 vaguely similar bugs is in tag discovery [01:24] mwhudson: it's not really the tag discovery that's relevant but rather the code that infers the revision graph from a svn repo [01:25] jelmer: oh ok [01:25] Hi, I want to use bzr in the following scenario. I have some html files on a server. I want several people to edit them using bzr. How should I set this up? I setup the server, did init-repo, copied the html in here, did 'bzr init' in the html folder. Then my devs can branch fine. But if they push, the worknig tree isn't updated. How should I set up the repository? [01:25] mwhudson: I think bug 384192 [01:25] Launchpad bug 384192 in bzr-svn "Assertion in _set_direct_lhs_parent_revmeta when pulling from remote branch" [Medium,Triaged] https://launchpad.net/bugs/384192 [01:25] jelmer: then probalby all these bugs are duplicates: https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.searchtext=Tried+registering [01:27] mwhudson: yep, thanks! [01:27] np :) [01:28] MTecknology: it's up to you :-) Should work well, although diff probably isn't much use if they're binary documents. And if the documents are *very* large (gigabytes) it's probably also a bad idea. [01:28] Traveler2: check out the bzr-upload plugin [01:29] jelmer: It won't be a lot of massive files, the only thing I'm not sure about is, when they delete a file or alter it and the diff is just the replaced file; then that .bzr they always have to pull down will get massive pretty quick [01:31] MTecknology: how big the deltas are going to be depends on the document format really [01:31] jelmer: thanks, but with this plug-in does it mean no repository is kept on the server? Will revision history be shared with other developers this way? [01:32] Traveler2: the plugin is used independently [01:32] Traveler2: I assume you don't want to push your history to the same location as your web site, as that would mean visitors of your web site could access the source code and the history. [01:32] jelmer: ya lost me with the word delta [01:33] jelmer: probably mostly pdf and mso 2007 docs [01:33] MTecknology: the binary diff between the old and new version of a file [01:34] jelmer: oh [01:34] hrm... I think I just figured out exactly what I want to do :D [01:34] jelmer: I do want to push it there, it's just html and I take care of people accessing it with apache [01:35] jelmer: thanks, I'll try out diffs from changing some things [01:35] Traveler2: in that case you might be interested in the push-and-update plugin [01:36] MTecknology: I should say, "bzr diff" isn't a good indication of the size of the data that's going to be stored [01:37] jelmer: I suppose if I just make a new branch for every year I won't need to worry about the size that much [01:37] jelmer: cool, thanks again! [01:38] jelmer: thanks for the info, I'll do a little trial, mess around with docs, check the diff size, see how big things grow [01:43] jelmer: Looks like another small issue - passwords from authentication.conf can come back as unicode strings [01:45] jelmer: Ah. Never mind. That's fixed in lp:452121 [03:08] hello all [03:10] Hi. :) [03:10] hi [03:12] I'm trying to use the bazaar explorer for windows. Is there any way to use this to setup a shared key? I don't want to give this user account a password if I can help it - I prefer accepting connections with keys only [03:13] I don't even see how you can open it using a shared key if you do have one.. [03:14] yes [03:14] the launchpad docs explain how [03:14] (assuming you mean "I'd like bzr explorer to use a ssh key to connect to my remote bzr repository via bzr+ssh/sftp") [03:15] will it let me generate the key in the bzr explorer too? [03:16] does the lp plugin provide a shorthand way of saying 'push to a branch which isn't asociated with any project'? 'help lauchpad' only talks of projects [03:17] 'bzr push lp:~username/+junk/branchname' [03:17] Kamping_Kaiser: bzr push lp:~user/+junk/branch_name [03:18] so i need to enter the whole ~username/+junk bit? ah well. thanks both :) [03:19] put 'export J=lp:~username/+junk' in your bashrc, then you could do 'bzr push $j/branchname' :P [03:19] Er, $J [03:19] hello all [03:19] hi spiv [03:20] bob2: I'm not finding the docs for that [03:20] spiv: trying to decide if i want shorthand way enough to file a bug ;) [03:20] https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Next step [03:24] bob2: thanks [03:30] Kamping_Kaiser: you can always write a plugin to provie a junk: namespace as a shortcut to lp:~you/+junk [03:33] spiv: much as i like the idea, i won't know enough python (any) to do that for a while [03:34] Kamping_Kaiser: bzrlib/plugins/launchpad/lp_directory.py would be a starting point if you felt like trying anyway ;) [03:34] ok, so I have the key generated but the bazaar explorer is still confusing me, I thought it would let you pick a key in the branch operation [03:34] spiv: tempt me not! or i might not be able to resist :p [03:35] or do I need to put it in C:\Users\Username\.ssh or something like that? [03:36] * MTecknology is remembering how much it sucks to deal with windows [03:44] bob2: any chance I could just get a little more help with that? [03:45] MTecknology: I don't think bzr or explorer have a concept of a key per branch, if that's what you're asking? [03:45] spiv: I can't use a shared key with the bazaar explorer? [03:46] what do you mean when you say "shared key" [03:46] ssh key [03:46] ok [03:46] in what way do you think bzr explorer should be involved in this? [03:47] use the private key to authenticate the same way when I pull the branches in linux [03:49] bzr branch bzr+ssh://user@server/path/to/branch [03:49] sure, follow the launchpad page and bzr will use pageant [03:49] afaik [03:50] pretty sure it has nothing to do with bzr explorer specifically [03:54] hm...looks like my pet bug got pushed back farther. [03:56] ok... so use puttygen to create the ssh key; add public key to server; start pageant; add key to it; leave running; try to pull branch; still asks for password [03:58] hrm.. authentication (publickey) failed is showing up in the output, must be at least trying to use it?? [04:01] AWESOME! [04:01] bob2: thanks - sorry if I was annoying [04:02] yay [04:02] I REALLY hate how windows works.... [04:02] Linux, ssh-keygen; put id_*.pub on server; done [04:02] so simple :D [04:05] bob2: thanks again, time to relax :) === samurai is now known as samiam === samurai is now known as samiam [05:24] spiv, can you answer https://answers.edge.launchpad.net/bzr/+question/98083 ? [05:24] * spiv looks [05:27] Done; I've essentially just repeated jam's answer. [05:29] lifeless: can you have a look at https://bugs.edge.launchpad.net/bzr/+bug/528793 for me? [05:29] Launchpad bug 528793 in bzr "MemoryError in _ensure_content during commit in small repository" [Medium,Confirmed] [05:33] spiv, and also https://answers.edge.launchpad.net/bzr/+question/103163 [05:34] I wonder why I don't receive question notifications. I guess I need to subscribe somehow... [05:34] mm [05:34] i just made ~bzr-qa be subscribed [05:35] are the per-file merge hooks in the user guide? [05:36] They'll be in the hooks documentation at least, but they probably need better docs than that. [05:45] poolie: http://software.intel.com/en-us/articles/itaniumr-processor-family-performance-advantages-register-stack-architecture/ [06:02] so, spiv, could you answer that guy? [06:02] https://answers.edge.launchpad.net/bzr/+question/103163 [06:02] and i'll file a bug for documenting it [06:09] https://bugs.edge.launchpad.net/bzr/+bug/532435 [06:09] Launchpad bug 532435 in bzr "need user-guide documentation of per-file merge hooks" [Undecided,New] [06:11] poolie: yes, I just did, was composing and testing the code for the answer [06:11] thanks [06:11] The code for that is still a little more complex than is ideal :/ [06:12] urk [06:12] i think he was hoping for a single configuration item :) [06:14] Well, I suppose that plugin could be tweaked to read patterns from a .bzrmeta/fauxbinaries file ;) [06:14] i'd like to put it in the rules file [06:14] we have too many places [06:18] I so wish you could have put the meta data in .bzr [06:18] I gather you had reasons, but it seems such a shame to have more .bzr* files than 1 [06:20] mm [06:20] did any of you see a failure in https://bugs.edge.launchpad.net/bzr/+bug/532435 [06:20] blah [06:20] Launchpad bug 532435 in bzr "need user-guide documentation of per-file merge hooks" [Medium,Confirmed] [06:20] ERROR: bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh [06:21] poolie: what sort of failure? [06:21] SocketConnectionError: Unable to connect to SSH host localhost:35949; [Errno 111] Connection refused [06:21] I haven't seen that test fail, or that type of failure in general, no. [07:28] hi all ! [07:33] uh-oh. If I see vila wake up, I *must* need to go to bed! [07:33] night all [07:34] Note to self: Impersonate vila in the middle of the afternoon to screw with jam. [07:36] jam: eeerk [07:36] jam: have a good night [07:49] !localtime Peng [07:49] aww [08:42] * igc dinner [08:54] bialix, bialix, where are you ? [09:58] vila: hi! thanks! [09:58] * bialix waves hi all [09:59] bialix: hehe, just so your Approve vote, thanks for that [09:59] s/so/saw/ [09:59] * bialix starting to understand vila even with typo like that [10:01] I'm wondering if 'so' and 'saw' are pronounced differently in English in which case I'll blame my awful accent (or so cute accent depending who you ask :) [10:05] They are pronounced differently in my accent. [10:06] Peng: ha good... [10:06] Peng: ... what is your accent ? :-) [10:06] I don't know. Isn't it said that people don't hear their own accent? [10:07] say us who you are and we say what is your accent ;-) [10:07] vila: I'm from Florida, US. [10:08] Peng: Well, my girlfriend recorded me lately (without notice) and I could clearly hear my accent :) [10:08] Peng: So you're a native speaker and for bialix and me I think that counts as no accent :) [10:08] Heh. [10:08] hello all .. [10:09] sup! [10:09] i want to merge svnA into svnB using bazaar .. what's the Right Way? [10:09] STing has a song in French: La belle damme sans regret, it's funny to listen his accent [10:09] i managed to do it, but now svnB doens't have the history [10:10] ghost around us? [10:10] Hmm, what's a stereotypical southern greeting? I couldn't come up with one... [10:10] hi y'all [10:10] Ah! Good one! [10:11] bialix: weirdo :) Listening to foreign accents in foreign foreign languages :) [10:11] neaj: hi, what it means "does not have the history"? [10:11] I can't say "y'all" with a straight face. :( [10:11] 'bzr log' shows only 7 revisions, but svnA has 283 revisions [10:11] vila: yep [10:11] neaj: try bzr log -n0 [10:12] !! [10:12] * neaj gives bialix a noisy kiss [10:12] oh no [10:12] neaj: bonus: install QBzr and try qlog [10:12] OK :-) [10:12] wow that was a nice discovery :-) [10:14] neaj: There should have been a message at the end of 'bzr log' (use -n0 blah blah) [10:14] neaj: did you just miss it ? [10:16] neaj: I'm asking to know what could have helped you discover it alone (since that's why we put the message there in the first place) [10:29] vila: yes, i completely missed it, sorry .. [10:30] neaj: no no, you don't have to be sorry, instead, tell us what could have helped you notice it [10:31] rats, I will lose *power* in ~30mins for 2 hours, I'll have to shut down properly *now* [10:32] neaj: feel free to file a bug with your ideas [10:33] * vila goes back to shutting down every work in progress and migrate some stuff to the battery-powered laptop :) [10:33] something like this? http://pastie.org/855302 [10:35] hmm, embedding or at the top, yeah, makes sense, will not fly well with our current implementation but I think it's worth addressing for people using '| more or less [10:36] * vila runs [10:40] hmm, now is this history in svnB? when i 'svn co svnB', svn log shows only 7 revs also. [10:41] neaj: No. It's just in bzr. [10:41] I think. [10:42] i did: 'bzr branch svnA; bzr branch svnB; cd svnA; bzr merge -b 0..283 ../svnB; bzr commit -m "Merged"; bzr push' [10:52] vila: may I ask your wisdom advice? re scmproj [10:54] bialix: vila is gonna be AFK for the next 2 hours because of a power outage. [10:55] oops [10:55] * bialix sends vila some spare batteries [11:10] any bzr guru's on line? [11:10] need help to work around https://bugs.edge.launchpad.net/bzr/+bug/532550 [11:10] Launchpad bug 532550 in bzr "bzr error: Bad message kind byte: '\\x1d'" [Undecided,New] [11:14] joey: does this error reproducible? [11:15] does you have any proxy between you and lp? [11:15] bialix: I'm trying. It happens 47 mins into my push [11:15] bialix: probably, I'm in a hotel in London [11:16] bialix: I'm pushing up about a 4 gig diff [11:16] :-) [11:16] try to run bzr missing first to understand how many revisions you're about to push, and try then push in chunks [11:16] 4 gig? could be 32bit issue, maybe? [11:16] good idea [11:16] sorry, I'm not really guru in 4 gig question [11:17] oh right, I'm on a 32bit netbook not more normal 64bit system [11:17] * bialix summons spiv, lifeless [11:17] 2 revs down, 1 I just did after the crash on the 1st [11:17] may be push in chunks would help [11:18] joey: ouch, big diff! [11:18] I doubt it's a 32-bit vs. 64-bit issue. [11:19] and here is: our smart server guru: spiv! [11:19] applause [11:19] joey: please add -Dhpss -Dhpssdetail to the command line, try again, and then attach the .bzr.log to the bug [11:20] joey: it's certainly a bug in bzr, although it's one I haven't seen before [11:21] joey: bialix's advice about pushing less revisions at a time is probably the best workaround I can think of. [11:22] joey: hmm, although sftp might be a workaround too? 'bzr push sftp://joey@bazaar.launchpad.net/~oem-solutions-group/oem-process/oem-presentations/' [11:22] joey: I need to go to bed; please put any further info you get into the bug, I'd really like to understand what's gone wrong here. === mrevell is now known as mrevell-lunch [12:09] hmm [12:10] I think I might have found the issue.... [12:10] there was a file name that included a funny space and two periods. [12:10] I changed that and am attempting to push again [12:13] where was the file [12:13] jml: does the lp server capture server side errors to oops yet? [12:13] lifeless, no. [12:13] or to some log we can see - i want the server side backtrace [12:16] joey: filenames really should not have that effect on the network protocol [12:16] (will be in bed soon, really!) [12:16] spiv: I'll give it a shot. [12:17] joey: so I very much doubt that is the issue, it just doesn't fit with symptoms so far at all [12:17] oh you know, maybe I should have done a -Dhpss [12:17] lifeless, whatever logs we have are synced to devpad -- I doubt the server-side backtrace is synced though. a losa will be able to point you at the right directories, and might be able to sync the appropriate ~/.bzr.log on request. [12:18] jml: well, its 2317; I'm beat [12:18] lifeless, ok. thanks for trying. [12:18] this needs to be gathered to move this further I suspect [12:19] joey: if you want to track down the log for the error, so we can look at it when .au rolls around (or so vila can look at it), that would be great. [12:19] joey: the error you see is local bzr saying 'the server spat at me. waaah.' [12:19] joey: there is a real backtrace on the server somewhere. [12:20] joey: yes, -Dhpss -Dhpssdetail, please [12:20] lifeless: I was hoping that was the case :-) Just wondering if I can translate the "waahh" into something that might help me diag the problem [12:21] joey: the server-side traceback is what we really need, but -Dhpss -Dhpssdetail on the client might provide some useful clues [12:24] joey: talk to a losa; they can flail about more effectively. [12:24] :) [12:24] thanks spiv... and lifeless ... I'll wait to this one finishes or crashes to prove my theory and if it abends I'll try the debug items [12:25] heh. Maybe herb or mthaddon can find something for me [12:57] spiv: lifeless - the filename rename did the trick [12:57] * joey updates the bug === Kohlrabi_ is now known as Kohlrabi [13:00] It did? But...why? [13:00] o_O [13:00] joey: I *really* doubt that is more than a co-incidence === mrevell-lunch is now known as mrevell [14:56] morning all [15:05] evening igc [15:05] morning [15:05] hi jam [15:06] igc: other than needing to go to bed, how are things going? [15:07] I'm fighting windows installers tonight [15:07] debugging me new scripts [15:17] jam: any chance you can upload one of the installers I built to people.canonical.com say? [15:17] jam: I'm heading to bed now but I'd like to test it on the weekend [15:17] k [15:17] it's the one tagged igc [15:17] jam: ^ [15:17] jam:thanks [15:18] on d? === salgado is now known as salgado-lunch [15:42] hrmm. [15:43] what would cause a commit back to svn to have the property bzr:pointless? [15:43] It seems to be doing those commits to store some sort of metadata in the commit properties, but I only have 2 revisions in my local repo to push. [15:43] NfNitLoop: a commit that is pure administrative [15:44] NfNitLoop: i.e. shouldn't appear in "bzr log" but is required because of the way svn works [15:44] does bzr have any special provision to handle the situation where a branch contains large, binary files that often change? [15:44] required for what reason? [15:45] Tak: It'll diff binary files just like text files.... no special provisions, AFAIK. [15:47] jelmer: I mean, I see why you might need that. I'm just wondering what the common case for it would be. [15:47] (My 2 revisions seem pretty straightforward, not sure why I'm seeing this behavior for the first time today.) [15:50] I did do a rebase before pushing back to SVN. [15:50] but I don't know why that should matter. [15:53] hm - I ask because I went to branch from an svn repo (where that happens), and I was around a gig downloaded at ~200/~18000 revisions in, and the tip wc size is substantially less than a gig [15:53] NfNitLoop: IIRC if you push a branch that adds a tag while there is no 'tags' directory and bzr-svn creates the tags directory for you it'll set that revprop [15:57] hrmm, nope. it doesn't appear to have changed anything other than that property. [16:02] Tak: Well, it does keep all of your history. [16:03] Tak: you might consider a stacked branch next time you do a checkout. [16:03] that'll download just enough history to recontruct a working copy. [16:06] jelmer: aah. It looks like my coworker updated a branch in the /tags directory. [16:07] and for some reason those commit messages got copied into the branch from which that tag was created. [16:07] which is wrong, because those changes weren't committed there. [16:09] (Yes. It's a complete misuse of the "tags" directory. But in my experience, it is not uncommon in SVN usage.) [16:38] jam: ping [16:39] is it possible to mark command-line option as deprecated? [16:39] there is hidden flag [16:39] I want to make some options hidden and deprecated [16:39] does bzr has some support for this? [16:40] hi vila [16:40] bialix: no idea :-/ === beuno is now known as beuno-lunch [16:41] jam: I'm searching how to find back a file-id for a file that has been deleted in a working tree [16:41] bialix: yeah, I think you can add hidden=True to Option()'s constructor [16:41] I'm not very good in optparse, what method is called when option processed? [16:41] vila: you have to walk history until you find a revision where it existed [16:41] jelmer: yes, hidden=True works fine [16:42] I want to make some deprecation check now is some universal manner [16:42] bialix: I don't think we have a deprecated=True flag, but I guess you could warn the user if you see they use that flag [16:42] jam: what is the purpose of has_or_had_id (slightly related) ? [16:42] hmm, Option constructor has custom_callback [16:43] vila: I think that only checks the WT before commt [16:43] I think I need to provide my callback with deprecation warning [16:43] * bialix trying [16:43] so if you delete a file, you 'had' the file, referenced by the existing file_id [16:43] once you commit, that will return nothing [16:43] I think [16:44] :-/ Yeah, my wt is just in that state, the file *is* deleted by the merge but was present in a least one of the parents [16:44] vila: well, it is easy enough to just probe all parents with path2id [16:44] if it was deleted in the merge [16:45] then doesn't it have to be present in the basis (left-hand parent)? [16:45] otherwise it would have been deleted already [16:46] yes, but I don't have that info anymore when starting from the conflict object [16:46] but " probe all parents with path2id" should be enough [16:46] it isn't great, but I think it will work for what you need [16:46] though... [16:47] could you have a conflict if the file was deleted in all parents but had been locally versioned (not yet committed)? [16:47] jam: no worries, I plan to need that only for conflicts created *before* I fix bug #531967 [16:47] Launchpad bug 531967 in bzr "bzr resolve --take-this or --take-other fails for PathConflict if a dir is deleted" [High,Confirmed] https://launchpad.net/bugs/531967 [16:47] bzr add new-file; bzr merge ../other # conflict with 2 files wanting to be 'new-file' [16:48] bzr add-new file should create a new file-id so I think it's a different case, let me think [16:49] custom callback working fine [16:49] vila: sure, it just is a potential to cause a conflict [16:49] another way is just [16:49] touch new-file [16:49] bzr merge ../adds-new-file [16:49] jam: I think that will be a DuplicateEntry conflict which can have two file-id involved [16:49] well, --force [16:50] vila: I trust that you know better than me, I'm just trying to bring up edge cases [16:50] jam: thanks for that [16:50] * vila notes to add tests for just to be safe ;) === deryck is now known as deryck[lunch] [16:52] jam: (Pdb) pp tree.revision_tree('other').path2id('new-dir') [16:52] 'dir-id' [16:52] \o/ === salgado-lunch is now known as salgado [17:24] jam: (teddy bear) Can you think of a *simple* way to restore an inventory entry as it was in an available revtree ? This has to cope with the entry being of any kind of course [17:26] vila: you mean like 'bzr revert' sort of thing? [17:27] I'm not really sure what you mean by 'restore' [17:27] are you trying to do something on disk? only in the inventory, etc? [17:27] and I assume this is in a WT? [17:27] then entry doesn't exist in my current wt, I want to add one from a revtree [17:27] vila: the only stable way I can think of is to use 'revert(specific_files)' [17:28] I don't think it is particularly simple [17:28] jam: yeah, I thought so :-/ [17:28] _mod_merge.transform_tree(tree, tree.basis_tree(), interesting_ids) [17:28] is what "bzr remerge" uses [17:28] before it re-applies the merge [17:29] I'll punt then and abort in that case, it should be rare enough to not be really that important [17:29] so transform 'tree' into 'other_tree' for objects mentioned in 'interesting_ids' [17:29] vila: it is a single line of code :) [17:29] haaa, *that* sounds what I'm after === beuno-lunch is now known as beuno [17:40] hi - I just had bzr traceback when I was merging a bundle: http://pastebin.ubuntu.com/389096/ === deryck[lunch] is now known as deryck [17:55] jam: bah, that doesn't work, long story short, I need my fix first which sucks because it means my tests won't be failing anymore which in turn means I won't be able to test my backup plan 8-{ [18:05] jam: using tree.revert([revtree,id2path(file_id)], etc) seem to work better ! \o_ === radoe_ is now known as radoe [18:07] vila: the only concern there is that I *think* 'tree.revert(dir-id)' will revert all files underneath it? [18:08] jam: At that point, the directory *should* be empty (at least I hope so :) [18:08] It doesn't exist anymore so I just need to recreate it, I'm pretty it's empty, [18:09] for dirs that is, for files and symlinks... well, that doesn't apply ;-) [18:14] vila: but wouldn't it end up restoring the files that used to be in the directory in that parent? [18:14] (not sure, but def something to test) [18:14] jam: I sure will, but AIUI, the conflict can't be created if the dir is not empty (that's what I need to check) [18:15] Is an "inconsistent delta" error as critical as it sounds in #256409 [18:17] * vila EODing [18:17] bye all ! [18:18] jam: thanks for help and the teddy bearing ;-) [18:29] awilkins: there is a known form where 'bzr commit' and a deleted nested directory (deleting a/ and a/b/ and a/b/c), which commits fine, but fails at one point, and you need to run 'bzr update' afterwards [18:30] there it isn't serious [18:30] just a bug in handling recursive removal [18:30] otherwise, prob serious [18:32] jam: The scenario is as follows... this branch was pulled from an SVN repo. The lead developer has had a moment of confusion (doesn't seem to understand version control) and copied a folder from an old revision forwards in time as an attempt at renaming it. [18:33] awilkins: well, that sounds like a bzr-svn issue, as it could be supplying an invalid delta to the rest of the code [18:33] awilkins: bzr-svn should be able to handle that [18:33] jam: It's happening during a bzr mv --auto [18:33] awilkins: this is a change that's already been committed? [18:34] jelmer, They must be because I'm working in a fresh checkout of a past revision [18:34] awilkins: how do you know it happened during a bzr mv --auto ? [18:35] jelmer, The error was raised during bzr mv --auto ; I don't know when the root cause of the error arose [18:35] I'm trying to create a revision that's this persons changes done right... then I can merge the changes from everyone else which he's ignored because he's not committed for a few weeks [18:36] awilkins: hmm.. I've seen that with stuff trying to be renamed into a dir that wasn't versioned [18:36] again, a bug, but shouldn't long-term break anything [18:36] the error is to prevent getting corruption [18:36] so getting it during 'bzr mv' is probably ~ok, getting it during 'bzr commit' is more worrisom [18:36] jam: Yes, eventually it stops throwing the error if you manually add a bunch of parent folders [18:36]