=== Kissaki is now known as Kissaki^0ff [02:35] jelmer: ERROR: test_push (bzrlib.plugins.git.tests.test_blackbox.TestGitBlackBox) seems to fail with on bzr-git tip [02:36] http://pastebin.ubuntu.com/189938/ [02:36] (with dulwich tip, but somehow i don't think that matters) [03:29] when i do a "bzr version-info" in /home/foo/xyz i get an error: "Format for file:///home/foo/bzr/.bzr is deprecated - please use 'bzr upgrade' to get better performance" [03:30] but when i do a "bzr upgrade" in that directory i get: "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." [03:31] yeah, that sucjs [03:31] pattern: are you using a shared repo? [03:31] no [03:31] oh [03:31] just a local one [03:31] pattern: pastebin what bzr info -v says? [03:31] e.g. here http://pastebin.ubuntu.com/ [03:33] http://pastie.org/503222 [03:34] pattern: oh [03:35] pattern: try running bzr upgrade :this [03:35] um, maybe not that [03:35] pattern: you have a bound branch, it seems? [03:35] pattern: the format of the bound and master branch are different, i guess [03:35] not really sure what i have, in bzr terminology [03:36] try bzr upgrade :bound [03:37] Format for file:///home/foo/bzr/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance [03:37] bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [03:38] hmm [04:37] mm [04:37] does merge (maybe with --lca) losing executable bits sound familiar to anyone? [04:47] mwhudson: I lost the xbit on a file once. I assumed it was because I did something like "mv foo.OTHER foo". [04:47] I never actually tracked it down, though... [04:47] Peng_: hmm [04:48] Peng_: there's basically no chance that the files that lost x bits conflicted, though there may have been a conflict in the merge [04:48] actually, i think what i did was either 'merge; revert; merge --lca; commit' or 'merge; remerge --lca; commit' [04:48] mwhudson: Oh, huh. I have no clue, then. [04:48] ...Ugh, what's wrong with my connection this time? [04:49] ah well, i'll look again, on monday :) [04:50] i think both files that lost the x bit moved in the merge, too [04:50] which seems unlikely to be a coincidence [04:50] 800-900 ms ping to hop #2?! WTF?! [04:50] WTF is with me and Internet problems this week? [04:51] Peng_: obviously you're getting subconsciously ready to move to .au or .nz [04:52] I've had problems with 2-3 different ISPs in different states in 1 week. :D [04:52] harsh, but fair [04:54] hey guys my commit is taking for ever, can some one help diagnose the problem? [04:55] treeform: Local? Internet? Checkout? Branch? Is it really gigantic? Define "forever"? RAM usage? CPU? [04:55] Oddly, this barely feels worse than my 300 ms pings last time. [04:59] Darn, it's confusing ntpd too. [05:00] Peng_: its my own remote server [05:00] i dont think its high on ram or cpu [05:00] its just taking for ever network wise [05:00] packing flowing for 2 hours to change 12 files [05:00] 12 python small files [05:01] i estimate it could have uploaded over gig now [05:01] on the server same thing [05:01] no ram or cpu problems [05:01] just open network connection [05:02] treeform: How large is the repo? [05:02] 1.8Gb [05:03] treeform: It's possible it's doing an autopack, which in old versions (or any version over a dumb protocol) means downloading a nd re-uploading a potentially significant amount of data. [05:03] treeform: Check .bzr.log [05:04] where would bzr log be [05:04] treeform: "bzr version" gives the location. Probably ~/.bzr.log. [05:04] oh the client is on windows and server is on linux [05:04] could that matter? [05:04] no [05:05] server 1.8 , client 1.2 [05:05] i just downloaded the client [05:05] maybe i got wrong one [05:06] Those are both rather old. [05:06] very [05:06] I'll leave it with you Peng_ :) [05:06] Wait, I was about to say that! [05:07] Ugh, typing over that SSH connection was driving me nuts. [05:08] i dont get the version numbers on the site [05:08] treeform: Huh? [05:08] every thing from 1.15 to 1.6 is up for grabs [05:08] treeform: 15 > 6 [05:08] The current stable version is 1.15final [05:08] but server say i have 1.8? [05:09] oh its 15 as in [05:09] ok got it [05:09] treeform: Check what's going on in .bzr.log on the client. If it says "Auto-packing repository", that's what's going on. If both the client and server were recent, auto-packing would occur server-side (if you're using the smart server). [05:10] where would .bzr.log be on windows? [05:10] treeform: I told you, ask "bzr version". [05:10] Seriously, how do people SSH over a satellite connection without just hanging themselves? It's awful! [05:10] Anyway, whining about that is off-topic. [05:13] http://dpaste.com/52384/ [05:13] the log is very very large [05:14] treeform: Scroll up to the last push. [05:14] treeform: Or commit, or whatever you were doing. :P [05:14] commit [05:14] i am not sure where it starts [05:15] The file includes both dates (in recent versions, anyway) and the command line. [05:15] oh found it [05:15] lifeless! I was about to leave! :( [05:15] there is tons of errors about locks [05:16] it has "Auto-packing repository" [05:16] so its autopacking 2GB of data? [05:16] and resending it? [05:16] treeform: Some portion of it. Probably not all of it. [05:17] i probably need to update bzr's [05:17] and figure out smart server [05:18] treeform: What type of connection are you using to the server? SFTP? bzr+ssh? [05:18] God forbid, FTP? [05:18] sftp [05:18] bzr+ssh gives locking problems [05:18] Oh, huh. [05:19] maybe its due to version being old [05:19] Could be. [05:19] bzr+ssh is still not a smart protocol? [05:19] only the bzr one is? [05:19] but the server it runs does not support authintication? [05:19] treeform: All of the schemes that start with "bzr" are smart. [05:20] so if i do get bzr+ssh working? it would give me smartness and authintication? [05:20] bzr+ssh simply uses SSH for auth. [05:20] ...As does SFTP.... :P [05:21] yes [05:21] i have all of the ssh setup [05:21] So switching to bzr+ssh should be easy. [05:22] I have no idea what your locking problems could be caused by, or if a newer version improves things. You should upgrade anyway, though. [05:22] could i cancel this commit and try bzr+ssh [05:22] should* [05:22] treeform: I wouldn't. It would waste all of the bandwidth you've already used. [05:23] hmm [05:23] but its been going for 2+ hours [05:24] basically i was voiping with people [05:24] and said ok ill commit this [05:24] and ... [05:24] Well, I don't know, it's your choice. [05:25] ok got the 1.15 on server [05:26] You could kill the commit, log into the server and run "bzr pack" on the repo. [05:26] oh [05:26] Then you wouldn't have to do a significant autopack for a long time. [05:26] (Note: That would temporarily double the amount of disk space used. And it would probably use a lot of RAM, I dunno.) [05:28] hmm only took 14 sec to do bzr pack on server [05:28] with 1.15 [05:29] Yes, well, local disks are a lot faster than the Internet. :P [05:29] was there a new better knit format since 1.8 ? [05:29] treeform: The --1.9 format has new, smaller and faster indexes. [05:29] treeform: (As its name suggests, it was intorudced in 1.9.) [05:29] ok [05:30] (And if I wasn't typing over this slow SSH connection, I'd fix that typo. :P ) [05:30] is it worth to switch and how would i switch to it? [05:30] treeform: You'd use "bzr upgrade --1.9". Obviously, all of your clients would have to be 1.9 or newer. [05:31] treeform: If the clients are new enough, there's not really any reason not to upgrade. It does improve performance, especially over dumb servers. [05:31] lets see if it can upgrade 2GB worth of data [05:31] treeform: BTW, you should run bzr check and (if necessary) bzr reconcile as well. [05:31] treeform: before upgrading [05:31] oh man [05:31] allready started [05:31] cancel? [05:32] treeform: Nah. [05:32] treeform: Well, it would still be a good idea to run check and reconcile after upgrading. And it'll be faster, to boot! :D [05:33] because i am using new shiny format [05:33] its done switching, checking now [05:34] is there a big performance difference between bzr+ssh and bzr straight? [05:36] treeform: Nah. And anyway, regular bzr:// is unencrypted and doesn't support any form of auth. Use each where it's more appropriate, not out of performance concerns. [05:36] using bzr+ssh gives this error on windows [05:37] "the procedure entry point ___lc_collate_cp_func could not be located in the dynamic link library msvcrt.dll" [05:37] this is in 1.15 just freshly downloaded [05:38] on the windows client [05:38] https://bugs.launchpad.net/bzr/+bug/341465 [05:38] Launchpad bug 341465 in bzr "bzr linked version of msvcrt.dll is missing" [Undecided,New] [05:38] Oh, there we go. [05:39] this is probalby i did not use bzr+ssh :) [05:39] probably why* [05:40] any advice? [05:41] I haven't touched Windows in like 5 years. :P [05:41] So, I don't know, sorry. [05:41] yeah i whish i did not have to live with it either [05:41] You might be able to run bzr from source, but I don't know how easy that is on Windows. Plus performance would be worse. [05:42] I think it's worth adding a comment on that bug, that it still affects you in 1.15. [05:45] random dll from the net does not have ___lc_collate_cp_func either [05:46] Try the mailing list or something. [05:46] I really don't know anything about Windows, and it's the weekend, so not many people are around. [05:46] crap now sftp does not work too!!!! [05:47] ill try restart [05:47] :) [05:57] same dam thing [05:59] oh i fixed it [05:59] yey [06:06] You fixed it? How? [06:07] i removed the svn plugin ( https://bugs.launchpad.net/bzr/+bug/341465/comments/2 ) [06:07] Launchpad bug 341465 in bzr "bzr linked version of msvcrt.dll is missing" [Undecided,New] [06:07] the trace lead to that [06:07] too bad i dont have the trace any more [06:08] other wise i would post it [06:08] Oh [06:10] treeform: its probably in your bzr log [06:10] yes [06:10] got it updateing [06:11] lifeless: Hi. :) [06:11] bzr --version will give you the path to the log [06:11] hi Peng_ [06:11] yeah i added it to commets [06:12] maybe it could help some poor sole in the future [06:12] Ooh, subvertpy. [06:13] its the svn2bzr stuff right? [06:13] i dont know, i just hack folder, stuff works [06:14] bzr+ssh feels faster [06:14] treeform: subvertpy provides Subversion bindings for Python. It's used by bzr-svn (and was, in fact, created by the author of bzr-svn for bzr-svn). [06:14] but its just an physiology thing [06:14] treeform: bzr+ssh is faster than sftp. [06:14] cool [06:14] just commit some binary files [06:15] 12megs [06:15] it went in fine [06:15] after the small 12 file commit that took 3 hours 1 minute and 9 second with sftp ... [06:15] and faild [06:15] treeform: Well, that was thanks to the auto-pack. [06:16] yeah [06:16] what are some of the largest bzr repos people have? [06:16] do they have Terabyte repos? [06:16] lifeless: Think that bug should be linked against subvertpy? [06:17] Peng_: bzr installer probably [06:18] lifeless: yeah. [06:18] Peng_: not sure what part should be responsible for doing the suckin of the dll [06:19] treeform: MySQL is probably the largest public project at the moment. [06:19] * Peng_ shrugs [06:19] I'm sure Launchpad has statistics. [06:20] treeform: Theres nothing in our dataformats preventing scaling to terabytes of history [06:20] but there are limitations on individual file size [06:20] lifeless: What about hte inventory? [06:21] my stuff is mostly 3d data [06:21] like huge images and huge files of 3d model [06:27] treeform: bzr currently wants to hold up to 5 times the size of a single file in memory while committing or diffing it [06:27] treeform: we have some plans about how we might fix this [06:28] probably post 2.0 [06:28] Peng_: inventory scales to 100K files+ in a single tree today [06:29] lifeless: Isn't dev7 down to 3 times for commit? [06:29] Peng_: once jams's patches land, and only dev7 which treeform won't be using yet. [06:30] Ah. Well, it's still progress in the right direction, right? [06:30] right [06:31] but better to be capped at (say) 5MB === BasicPRO is now known as BasicOSX === Kissaki^0ff is now known as Kissaki === beaumonta is now known as abeaumont [14:12] igc: ping [14:18] hi :) [14:18] Hi RockyRoad [14:19] maybe you could help me ? [14:19] Go ahead and ask. If I can't I'm sure someone else might be able to. [14:19] I was here friday, with a problem a bit complicated [14:20] I explained it here http://www.rocky-shore.net/misc/bzr-rebuild.html [14:22] I wondered if bzr rebase could help ? [14:22] I'm reading you page [14:23] There is a command half way down: bzr -r0..1 lp:branch_Bx [14:23] should that be bzr *merge* -r0..1 lp:branch_Bx [14:24] right ! [14:25] corrected [14:27] RockyRoad - So the problem is that you can't push from A to B? [14:27] I tried to push to a subdir of Bx, that fails [14:28] because the parent branch is different [14:29] Is these branches publicly accessible? - I think It will be much easier for me to look at the branches. [14:29] (i suppose) [14:29] sure [14:30] https://edge.launchpad.net/planet-drupal [14:31] so which is A and which is B? [14:31] A is drupal-planet and B is planet-drupal [14:35] FYI http://drupal.org/node/476042 [14:36] (so it's not a fork !) [14:37] RockyRoad: do you have qbzr installed? [14:37] bzr gtk and qbzr [14:38] I like bzr viz [14:38] you can run "bzr qlog lp:drupal-planet lp:planet-drupal" to see a visualization between the two branches. [14:39] one project after the other, not together ? [14:39] bzr: ERROR: extra argument to command qlog: lp:planet-drupal [14:40] Ah - what version of qbzr? [14:40] I have a lot of errors with qlog [14:41] qbzr 0.9.2-0ubuntu1 [14:42] Yes - It did not have that feature back then. [14:42] I'll upload a screen shot for you [14:43] thx :) [14:43] Now what command are you using to push from A to B? [14:44] bzr push lp:~m-baert/planet-drupal/planet-6-x [14:45] I'll pastebin all, one moment [14:45] http://pastebin.com/m30a5ff1c [14:47] http://garyvdm.googlepages.com/log-planet-drupal.png [14:47] You can get the latest qbzr from https://launchpad.net/~qbzr-dev/+archive/ppa [14:48] It's much nicer that what I have ! I will :) [14:54] ok - so I think what you want merge A into B [14:55] so go to your directory that contains B (lp:~m-baert/planet-drupal/planet-6-x ?) do bzr merge [14:56] and do bzr merge lp:drupal-planet [14:57] Check that it gets you what you want. [14:57] And then push [14:59] but there's no common ancestor ... [14:59] oh yep [14:59] brb [15:00] k [15:08] planet-6x$ bzr merge lp:drupal-planet [15:08] Nothing to do. [15:08] revno = 25 [15:13] Is there a way to bring my branch from drupal-planet to planet-drupal history ? [15:13] sorry - bzr merge *lp:planet-drupal* [15:13] These names are very confusing [15:14] I've no rights on drupal-planet, I have on planet-drupal [15:15] But you don't have to create a whole new project. [15:15] ? [15:16] You can just create a new branch lp:~rockyroad/planet-drupal/trunk (or dev or fork :-P) [15:16] I couldn't agree with the person who "administrates" drupal-planet and related projects [15:17] if you push to lp:~rockyroad/planet-drupal/trunk - then it will show up in the branches list for planet-drupal [15:18] but the "old history" I added ? [15:19] drupal planet starts from my trunk rev 3 [15:19] You can bring that in with bzr merge *lp:planet-drupal* [15:20] Earlier I said bzr merge lp:drupal-planet - that give you "Nothing to do. " because it an older branch of lp:~m-baert/planet-drupal/planet-6-x [15:21] from planet-drupal checkout directory ... [15:21] sorry I need time to figure it out [15:22] brb [15:22] k [15:24] what may be a trick is that I built a newer project (planet-drupal) to store older history (CVS) before a clone of drupal-planet [15:29] hi garyvdm [15:31] s/trick/pitfall/ [15:32] hi igc [15:34] Hi igc [15:36] RockyRoad - I think you need to try figure what you merge into what. qlog branchA branchB branchC can help you alot with that. [15:38] igc: Bazaar Explorer overlaps alot with qmain. [15:38] hi guys [15:38] I can't see it very clearly yet ... what kind of connection does qlog do between branches ? [15:38] garyvdm: I certainly took a lot of its design from qmain [15:39] It shows how their revision histories relate [15:39] well, the discussion around qmain at least [15:40] igc - I not against a split effort. I would just like to discuss it. [15:40] garyvdm: sure. Apologies for not discussing it more before I threw it together [15:41] garyvdm: the orginal focus was prototyping the menu I wanted in bzr-eclipse [15:41] And would still like to do qmain - because there are things that we will be able to do with qmain that will be more difficult. [15:42] garyvdm: by all means [15:42] Like integrate log into qmain. [15:42] garyvdm: right, I was looking for a lightwieght wrapper/shell because that best simulates the experience ... [15:43] that users of qbzr-eclipse and TortoiseBzr will get [15:43] So, If I understand you correctly, bazaar-explorer is really experimental? [15:43] garyvdm: at this stage, yes [15:43] garyvdm: but I'm using it for development and dogfooding it [15:43] so I expect it to rapidly improve [15:44] garyvdm: in fact, it's almost finished in one sense ... [15:44] I really do want it to be lightweight ... [15:44] Ok - cool. [15:44] and for most of the energy to go into the q* commands themselves [15:45] So I've been thinking alot about the idea that I posted as a response to one of your mails. [15:45] garyvdm: going further, I'd be interested in pushing any smarts in explorer down into q* commands even [15:46] Thats great. [15:47] garyvdm: tell me more about your idea [15:48] So my idea is now something like this. I create a "api" in qbzr where you can say wrap this bzr command, and show fields x, y, z on the dialog. [15:49] garyvdm: yes!! [15:49] garyvdm: I was thinking of code generating creating Qt forms [15:49] but your idea - dynasmic lookup of the Command objects - is better [15:50] It will try and what type of field it, so for say a revision spec field, it will show a revision selector, but will may have to provide it some extra information. [15:50] right [15:51] e.g. for push, it must show revisions from the current directory (or what was provided by -d), but for pull, it must show the location you entered. [15:52] That will make adding a new command only a couple of lines of code. [15:52] excellent [15:53] Right now though - I'm batteling to decide what to work on :-) [15:53] garyvdm: here's some simple ideas if they help [15:54] as I said, I've been dogfooding, trying to go command line cold turkey ... [15:54] some limits of our q* GUIs ... [15:54] Ha ha - I've tried that a couple of time ... [15:54] in qadd, I can do the equivalent of add foo/bar when foo is unversioned [15:54] s/can/can't/ [15:55] I can only add all of foo [15:55] so qadd needs a button like ... [15:55] Expand Directories [15:55] a second example ... [15:55] I can't use qmerge to merge a merge directive easily [15:56] as the 'branch selector' insists on a directory [15:56] That should be easy to fix. [15:57] garyvdm: there's lots of little stuff too ... [15:57] qbind and qunbind are essential [15:57] and both probably really simple (a few hours each I hope) [15:58] qbind/qunbind/qswitch are the type of commands that my api would make realy easy to do. [15:58] garyvdm: exactly [15:59] garyvdm: but the bind ones at least arguably need to be slightly nicer than generic, e.g. [16:00] re qadd: what I would like is for directories to have twisties so you can expand them. [16:00] bind takes an optional location now [16:00] qbind ought to say something like ... [16:00] [X} Bind to existing location: ... [16:01] [ ] Select a new location [16:01] and picking the seconf radio button ought to enable an entry field [16:02] qunbind ought to be a simple yes/no dialog even [16:04] garyvdm: quncommit is another one that ought to be easy ... [16:04] [X] Uncommit last revision [16:04] [ ] Select an earlier revision... [16:04] qunbind could be just when you select revert from the qcommit dialog. [16:05] garyvdm: probably, though it also needs to be separate I think [16:06] garyvdm: qunbind will turn something from a bound branch into an unbound branch in Explorer [16:07] so it probably needs to be a button on the Bound Branches tab of a repo [16:07] I meant - the qbind dialog should look like revert dialog initiated from qcommit. [16:08] garyvdm: ah - sorry, I'm yet to see that one :-) [16:08] and the code for that is implement is a very reusable fashion. [16:08] nice to hear [16:08] brb [16:09] About qadd [16:09] what I would like is for directories to have twisties so you can expand them. [16:09] To do that [16:10] +1 to that [16:11] currently we have 3 directory/tree browsers. The working tree widget used in qcommit/qadd/qrevert. The qbrowse widget, and the qbzr (aka qmain) widget. [16:12] I would like to see them refactored into one. [16:12] garyvdm: I'm not across enough of the qbzr code but ... [16:13] sound good to me [16:13] igc: can I ask for some none-tech advice? [16:13] garyvdm: fwiw, I'd like to see ... [16:13] qbzr have a widgets directory as well as a lib one [16:13] so the widgets are more easily discoverable [16:13] Ok [16:14] I've started doing that in bzr-explorer [16:14] Currently there are only 2 that are designed to be reuseabe. [16:14] log and working tree [16:15] garyvdm: non-tech advice? [16:15] fire away [16:15] And the currently unmerged into trunk revision selector [16:15] yes please [16:15] I can't decide what to work on. [16:15] I wouldn't like to disturb in your busy developers chat (qbzr rocks :), but I still need some help. Somebody else maybe ? jelmer what about rebase ? My problem is exposed here: http://www.rocky-shore.net/misc/bzr-rebuild.html [16:16] I started working on tests for log at uds [16:16] There is alot more test that should be written for qlog [16:16] Fix bugs? [16:17] Work on api for creating command? [16:17] Work on refactoring directory/tree widgets into one. [16:17] I cant decide. [16:18] garyvdm: there's no right answer :-) [16:18] but here's my view ... [16:18] pick whatever gives end users most value [16:18] if the bugs are stopping users from working, they become #1 [16:19] ok [16:19] garyvdm: fwiw, what helps me most is the sort of stuff above ... [16:20] because each one of them means "back to command line" [16:20] garyvdm: I feel that once we get those sort of rough edges smoothed out ... [16:21] then more people will start using our GUIs and they'll gain more momentum [16:21] and more developers to help us improve them [16:21] Yes [16:22] garyvdm: so, stepping back a second ... [16:22] If I work on the api - it may save other developers, and increase the momentum. [16:22] my vision is for each IDE and shell to have the same Bazaar menu ... [16:22] and for the menu options to be very lightweight code calling out to q* (and optionally g*) [16:23] putting together menus in most environments is easy [16:23] writing code behind them is hard [16:23] Yes - I agree that is the way to go. [16:24] garyvdm: so my preferred order for things is ... [16:24] 1) get coverage so menu options do something [16:24] 2) look at streamlining the commonly used dialogs [16:24] 3) the rest [16:25] Ok - so for me - [16:25] garyvdm: I think your API idea is excellent [16:25] 1) fix bugs [16:25] 2) command api [16:25] 3) tree/dialog refactoring [16:25] Cool - thanks for the advice [16:25] sounds good [16:26] 1 makes users happy and 2+3 will help build momentum [16:26] I was looking forward to meeting you at uds, and disappointed when I found out that you weren't going to be there. But I understand why. [16:26] garyvdm: :-( [16:26] I hear the sprint was great [16:26] and would have *loved* to be there [16:26] Did you see I signed your book. On one of the back pages :-) [16:27] I'm yet to receive that stuff [16:27] :-( [16:27] but I'll look for your name when I do :-) [16:28] Ok - thanks for the chat - I'm going to work on a bug, and then go visit my Dad. [16:29] garyvdm: my pleasure. I should get some sleep :-) [16:30] thanks garyvdm, good luck [16:30] RockyRoad: I also want to help you still if you have some time [16:31] you probably need to keep all these good ideas fresh in mind and go on with qbzr. I can understand that [16:32] I do want to help you [16:32] k [16:32] to refer back to my drawing http://www.rocky-shore.net/misc/bzr-rebuild.html (A/B less confusing names ?) what I understand of merging lp:planet-drupal into lp:planet-drupal/planet-6-x/ is merging B rev5 into By rev25, which looks like reverting to Bx rev 9. [16:33] I don't want to revert to that state ! [16:33] although I'm ok to rebuild all from the start if needed [16:34] also, I have no problem pushing lp:~m-baert/drupal-planet/6.x (Az) into lp:~m-baert/planet-drupal/6x-mich (Bz), but the problem I could have is to merge it into Bx or Bxy. [16:34] can you run bzr qlog lp:~m-baert/planet-drupal/planet-6-x lp:drupal-planet lp:planet-drupal [16:34] and tell me when It has loaded. [16:35] loaded [16:35] rev 5 from lp:drupal-planet != rev9 from lp:planet-drupal [16:36] It has rev9 merged into it [16:36] rev 5 from the yellow line [16:37] drupal-planet rev5 is nothing special [16:37] planet-drupal rev5 reflect drupal-planet/6x/ rev 9 [16:39] If i understand correctly, the yellow line (lp:drupal-planet) has changes that you want to merge into the black line (lp:planet-drupal / lp:~m-baert/planet-drupal/planet-6-x) [16:39] not really [16:39] Oh [16:40] the black line is a copy of lp:~sweetdave/drupal-planet/6.x [16:41] th yellow line is what I added [16:41] (old history + tags) [16:41] I see that [16:42] You want to merge the black line into the yellow line? [16:43] I pushed lp:~m-baert/drupal-planet/6.x as lp:~m-baert/planet-drupal/6x-mich , but it's not connected [16:44] Ok - let me have a look at thems [16:44] *them [16:44] I need to build a common ancestor [16:44] not reverting to previous development stage [16:46] those 0.x revisions in yellow are added recently to describe older project steps [16:47] so logically, I would prefer to see them _below_ rev 1 in black [16:47] but the connection line is fine [16:48] Ah - so you want to change them into one history? [16:48] Yes - you can do that with bzr-rebase [16:48] this part is ok, but I'd like to connect [16:49] lp:~m-baert/planet-drupal/6x-mich to the same history [16:50] because I will need to merge its rev 24 after black rev 25 [16:51] there's not much difference in code, but i'd like to keep its revision logs [16:52] on my graph, I showed a lot a "manual merges" , which can't appear in qlog, because they didn't use bzr merge, and were often partial [16:53] it's explained in rev logs [16:53] So you've got 3 options 1. Merge black in to yellow an push that your dev focus (yellow then becomes your main line). [16:53] yellow is the main line [16:54] 2. Merge yellow into black - and push - black stays you main line [16:54] or [16:54] yellow and black are fine as is [16:55] use rebase so that the black line follows on from rev 3 of the yellow line. [16:55] I just miss a third color [16:56] I thought about rebase, but I couldn't understand well if it was the thing I needed [16:56] and how to use [16:56] it [16:57] rebase 6x-mich to planet-6x [16:58] If I didn't merge black25 in yellow trunk, it's just because it's not ready yet, from a dev point of view [16:59] I could merge easily its rev 9, so I guess there's no problem to merge rev 25 [17:00] that because I used from planet-trunk$ bzr merge -r0..1 lp:planet-drupal/planet-6x [17:01] Yes [17:01] How come you created the .moved files? [17:01] with this exact step [17:01] merge -r0..1 [17:02] a matter of file-id that vila explained me in detail friday [17:02] Ok [17:03] I wonder if it is possible to specify when you do a cvs import to specify that it must use the file ids from an existing branch? [17:03] it's not a big issue, humans could quickly see the files are identical [17:04] but if you do bzr log file, or bzr annotate file, the history will stop at that merge. [17:04] As I understood, it's intentional to forbid that [17:04] (file-id trick) [17:05] it's not a big problem [17:05] So I think what I would want to do is redo the cvs import, and get it to use the bzr file-id's [17:05] Then you can rebase the start of the black line on the the end of the new cvs import. [17:05] My problem is not here [17:06] I need to link a _third_ branch [17:06] Oh - which is? [17:06] lp:~m-baert/planet-drupal/6x-mich [17:07] but that is exactly the same as lp:~m-baert/drupal-planet/6.x [17:07] yep [17:08] just copied in the new project [17:08] What do you mean by link? [17:08] something like merge -r0..1 [17:10] But they are the same - so you don't have to do any thing. [17:10] I need a common ancestor between planet-drupal/planet-6x and planet-drupal/6x-mich [17:11] to be able to do future merges [17:11] You don't need to do any thing. [17:11] You will be able to merge. [17:12] ok I retry [17:22] It sounds like it could do it but but renames+add again [17:22] that's more an issue at this stage [17:26] RockyRoad: No - if you make a change to lp:~m-baert/planet-drupal/6x-mich, and one to lp:~m-baert/drupal-planet/6.x, you should be able to merge one into the other with out any problems. [17:27] http://pastebin.com/d711d6fd7 [17:27] I don't need to merge 2 copies of the same branch that I own [17:28] I don't think so ... [17:29] oh no the moves don't concern the program files, it's ok [17:29] doc subdir is all my own [17:30] these are "ordinary" conflicts [17:33] but I find it mysterious why I can do it here what I couldn't on other branches ... [17:34] old command: bzr merge -r 1 lp:~m-baert/planet-drupal/planet-6x [17:34] # bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified. [17:35] Ok - I said lp:~m-baert/planet-drupal/6x-mich was the same as lp:~m-baert/drupal-planet/6.x [17:35] from planet-trunk [17:35] lp:planet-drupal/planet-6x and lp:~m-baert/planet-drupal/6x-mich are differnet - although they do have a common ancestor. [17:36] Let me look further at the errors === abentley1 is now known as abentley [17:38] So David Giard manualy added doc. [17:39] Had he done a merge (or a cherry pick merge) from your branch, then there would not be a conflict. [17:40] No [17:40] oops [17:40] Because he did it manually, the file id's of the doc folder are differnent [17:40] no problem [17:40] That's interesting [17:42] Ok - I must go [17:42] I hope I was a help [17:42] ok thanks a lot for your patience and help :) [17:43] I'll force a commit right now to check .. [17:43] It's a pleasure. [18:11] hey guys, is there any way to set the default external diff options? [18:25] use an alias [18:32] can i alias diff to di --diff-options=whatever ? [18:54] Glenjamin: yes [18:54] Glenjamin: see `bzr help alias` [18:54] excellent, thanks [18:54] i read the help, it doesnt mention replacing default commands [18:56] Glenjamin, I just tried it, like you could have, and it lets you set aliases that override default commands [18:58] cody-somerville: I suppose an example could be included that does that [19:00] * cody-somerville nods. [19:05] cody-somerville, Glenjamin: either of you interested in submitting a patch that does that? [19:18] is it normal for bzr resolve to need to specify the full file name for each file to resolve? [19:20] FryGuy-: instead of what? [19:20] just doing bzr resolve [19:21] maybe it's just a windows problem [19:21] i think i recall that there are a few places where wildcards don't work properly [19:22] FryGuy-: if you want to resolve a specific file, `bzr resolve path/to/file`, if you want to autoresolve what you can, just `bzr resolve`, if you want to force everything, `bzr resolve --all` [19:22] hmm [19:22] FryGuy-: if you're expecting that `bzr resolve` clears all conflicts, maybe the detection thinks it can't resolve yet [19:22] that, or you might indeed have found a bug [19:23] well in this case, i don't know how i can resolve it [19:23] FryGuy-: could you pastebin `bzr conflicts` output? [19:23] this happened at work, i'm trying to reproduce it [19:25] k i got it [19:26] http://pastebin.com/m4efe2a77 [19:27] on my work computer i've also gotten into cases where the conflict on switch happens, and it completely breaks the locks [19:27] * LarstiQ blinks [19:27] FryGuy-: and what is someproject [19:27] ? [19:28] http://pastebin.com/m27652c7c [19:28] there's how I reproduced it [19:30] er, excluding ilne 5 [19:41] * LarstiQ can reproduce that on Debian too [19:45] FryGuy-: so yeah, you certainly found a bug there [19:46] FryGuy-: however, if you explicitly `bzr resolve someproject`, that should get you out of the immediate situation [20:36] hi all [20:49] FryGuy-: I'm trying to make the case for reproducing it somewhat smaller [20:50] * LarstiQ tries an alternative approach [20:55] FryGuy-: http://pastebin.com/d6453183c [20:58] FryGuy-: there is a chance that the switch mechanics are different, but I believe the bug is in shared code [20:59] ah, there are some differences === mwhudson_ is now known as mwhudson [22:40] jelmer: thanks for the bzr-git test fix :) [23:28] are any bazaar developers working today? :) [23:45] mwhudson: its sunday :p [23:46] pygi: nonsense! [23:46] mwhudson: uh, actually, I just lied [23:46] its monday [23:49] pygi: and has been for nearly 11 hours now! [23:49] anyway, i figured things out myself [23:50] mwhudson: no, only 47 minutes [23:51] mwhudson: that's cool, share the findings :p [23:51] pygi: bzr tests fail with an old subunit around [23:51] (not very exciting) [23:52] indeed :p