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