| poolie | launchpad will be down for 3 hours, starting now | 00:00 |
|---|---|---|
| AfC | Three HOURS? | 00:18 |
| poolie | well, the window is that long | 00:18 |
| poolie | it will probably be less | 00:18 |
| lifeless | AfC: there is a large data-migration task being performed | 00:20 |
| lifeless | AfC: to improve performance | 00:20 |
| AfC | lifeless: no doubt. | 00:20 |
| awilkins | arse, launchpad is down | 00:22 |
| AfC | lifeless: planning and executing that sort of event is what we specialize in, after all. I'm just surprised to hear that {the window is that long | there is that much uncertainty associated with the event's duration}. That speaks of a number of issues. | 00:23 |
| lifeless | AfC: The test environment provides an upper cap; but exact block usage etc on a filesystem drives actual timings, so there is some variation. We also prefer to surprise than disappoint if the duration announced is wrong. | 00:25 |
| poolie | i think the bottleneck here is technical, at the db level, rather than organizational | 00:25 |
| lifeless | poolie: well, I think its arguable either way :). | 00:27 |
| AfC | We would generally argue that if a technical bottleneck exists at the db level, that is an architectural failure. But that's a conversation a bit outside the realm of operational circumstances, more in line with "what do we do to prevent this from ever happening again". Which, of course, are the best conversations. But in the mean time, | 00:28 |
| AfC | yes, there are both technical and organizational issues. | 00:28 |
| beuno | AfC, maybe devs didn't setup the enviroment to such a large scale. It happens everywhere | 00:30 |
| AfC | beuno: big time | 00:31 |
| AfC | beuno: all though Robert did say "test environment" which speaks of a proper pre-production staging facility. | 00:31 |
| AfC | beuno: the problem at that level tends to be that at a certain point it is (business economically) impossible to have a duplicate of the production data store as it is usually too big. | 00:32 |
| AfC | beuno: and/or they run production on fast kit, but staging on not-fast kit | 00:32 |
| AfC | that sort of thing happens a lot. | 00:32 |
| beuno | AfC, generally used for new features rather then scaling testing. It's a bit hard to predict _how_ users will use the application. I don't think it's anything our of the ordinary | 00:33 |
| lifeless | to be more precise in this case; we're getting a faster database server. | 00:34 |
| AfC | Well, it may not be unusual, but it doesn't change the fact that it's pathetic that so many organizations back themselves into such a corner. | 00:34 |
| beuno | there ya' go | 00:34 |
| lifeless | there is a lot of data to get fully synchronised across. | 00:34 |
| AfC | So the architectural failure here is that the system design did not forecast this operation nor allow for it to happen in such a way that did not require hours of downtime. <10 seconds is the usual standard. | 00:35 |
| AfC | (but that requires engineering the system to not have a single point of failure) | 00:36 |
| AfC | (hence my observation that that's is an architectural problem) | 00:36 |
| lifeless | AfC: it requires rather more than that | 00:36 |
| lifeless | no single points of failure is neither necessary nor sufficient for this sort of problem - sorry :) | 00:37 |
| beuno | AfC, launchpad devs seem to be generally very skilled, I'm sure they have more than enough reasons to do so | 00:38 |
| AfC | lifeless: single point of failure in this case is "a single data base that must be downed to do migrations" | 00:38 |
| AfC | the fact that your company is offline right now is more than enough evidence to that point. | 00:38 |
| foom | heck, the data warehouse at MIT goes down for 4 hours every sunday night for backups. | 00:57 |
| lifeless | abentley: mailed re: branch's having the pointer. | 01:09 |
| lifeless | abentley: happy to chat in higher bandwidth if you'd like. | 01:09 |
| abentley | Sure. Skype? | 01:09 |
| lifeless | yeah, let me change rooms | 01:10 |
| awilkins | Is there a reason the tests don't use osutils for platofrm checks? | 01:13 |
| awilkins | (I mean a good one, not "meh, platform == 'win32' is easy to type") | 01:13 |
| lifeless | abentley: no | 01:53 |
| lifeless | meh | 01:54 |
| lifeless | awilkins signed ogg | 01:54 |
| === Verterok_ is now known as Verterok | ||
| eetfunk | Hello all! Is there a way to convert git to bzr? | 02:43 |
| jdong | I think you need linus-proof class 10 armor first.... | 02:47 |
| lifeless | there is an experimental branch of bzr-git that will do conversions; dunno how good it is. There is also Tailor. | 02:48 |
| jdong | lifeless: has tailor gotten better at dealing with distributed vcs branching relationships? | 02:49 |
| jdong | last time I used it , it was virtually a "playback one revision, commit it to bzr" deal | 02:49 |
| lifeless | jdong: no idea | 02:50 |
| jdong | whoa, cool, bzr commit --show does --show-diff | 02:51 |
| jdong | does that apply to all options? incomplete ones expand out? | 02:51 |
| eetfunk | lifeless: thanks, i'll check it out | 03:03 |
| abentley | jdong: Yes. Standard behavior of the Python optparse library. | 03:16 |
| jdong | abentley: very cool didn't know that :) | 03:16 |
| abentley | It was basically an accident. Commands don't do that. | 03:17 |
| abentley | i.e. bzr com won't commit. | 03:17 |
| elmo | hmm? | 03:19 |
| Bloguero__Connor | why I am having this problem?: http://pastebin.com/m57a4a9b8 | 03:19 |
| elmo | st and di work | 03:19 |
| elmo | or are they specific short forms? | 03:19 |
| abentley | elmo: yes, only specific aliases work. | 03:19 |
| abentley | Bloguero__Connor: It looks like in a previous invocation, you did "bzr send sallycode.patch" and it remembered that location. You need to specify the target branch to override it. | 03:21 |
| jdong | abentley: another case of Python Magic (tm) | 03:23 |
| Bloguero__Connor | abentley: Yes, that was what happened, now, How I do that (specify the target branch)? | 03:23 |
| lifeless | jdong: we'll probably fix this at some point | 03:23 |
| jdong | lifeless: is it really broken? Kinda useful for those long options without a short alias | 03:23 |
| abentley | Bloguero__Connor: it is the first argument, so you would do "bzr send -o sally.patch TARGET_BRANCH" | 03:24 |
| Bloguero__Connor | ok, gonna try | 03:24 |
| lifeless | jdong: yes, its broken. | 03:24 |
| Bloguero__Connor | abentley: Target_BRANCH is the branch where I want to sen the patch or it is my branch? | 03:31 |
| abentley | It is the branch where you want to send the patch. | 03:31 |
| Bloguero__Connor | but I want to create a "merge directive" to by send by email. | 03:34 |
| abentley | A merge directive needs to know what data to send. It does this by determining what's already present in the branch you want the directive to be merged into. | 03:35 |
| Bloguero__Connor | I have a branch that is a copy of another code (Harry code). Then I made a change. I commited to my private branch (projectY-fromH). Now I want to send the patch back to the main branch (Harrys one). | 03:38 |
| beuno | Bloguero__Connor, bzr push branch_location | 03:46 |
| Bloguero__Connor | How the receiving location can accept or reject the change? | 03:47 |
| Bloguero__Connor | (hola!) | 03:47 |
| Bloguero__Connor | Does Harry have a chance to accept or reject what I push to him? | 03:48 |
| Bloguero__Connor | BTW, my user don't have write permission in the other's users filesystem. So the push didn't work. | 03:52 |
| Bloguero__Connor | That is why I want to send him a patch using send | 03:52 |
| lifeless | Bloguero__Connor: you can push to a public location of your own | harry can give you access to push to his branch | you can use bzr send | 03:53 |
| Bloguero__Connor | ok, will try it now | 03:53 |
| Bloguero__Connor | lifeless, YES, I see it now. I was the eclipse, now is backing off and I undesrtand :) | 03:55 |
| beuno | Bloguero__Connor, or harry can pull/merge from you | 03:56 |
| * beuno is off to bed now | 03:56 | |
| Bloguero__Connor | beuno: I made the send by using Harry path. To create the .patch file I dont need write access | 03:56 |
| Bloguero__Connor | gonna sleep, bye! | 04:02 |
| lifeless | woo stacked check passing. | 04:42 |
| poolie | lifeless: gentle nudge re the baz packages for this week | 04:45 |
| poolie | also, woot | 04:45 |
| lifeless | poolie: didn't you see me hand off to beuno yesterday :) | 04:46 |
| poolie | i saw you talk to him | 04:46 |
| poolie | can he actually do it? | 04:46 |
| lifeless | he has as much access as I IIRC | 04:46 |
| lifeless | in Debian there is a maintainer lock, noone can do it other than anand unless its rc. | 04:47 |
| lifeless | in Ubuntu we need to do stuff in main | 04:47 |
| igc | bbiab | 05:20 |
| lifeless | poolie: 'bazaar' is another possible venue; and the food there is divine :) | 06:01 |
| === pooli1 is now known as poolie | ||
| lifeless | 17:01 < lifeless> poolie: 'bazaar' is another possible venue; and the food there is divine :) | 06:29 |
| lifeless | wheee done | 06:59 |
| lifeless | poolie: it propogated just fine. | 07:00 |
| ubotu | New bug: #193893 in bzr-loom "branching over bzr+ssh does not propogate loom threads" [High,Triaged] https://launchpad.net/bugs/193893 | 07:01 |
| AfC | What's a loom thread? | 07:11 |
| mwhudson_ | AfC: install the plugin and 'bzr help loom' is one approach | 07:16 |
| mwhudson_ | it's a way of maintaining separate threads of development in one branch | 07:17 |
| mwhudson_ | (roughly speaking) | 07:17 |
| AfC | Ah | 07:17 |
| AfC | Not a fancy new threading system :) | 07:17 |
| === doko_ is now known as doko | ||
| === mwhudson__ is now known as mwhudson | ||
| g0ph3r | hi folks, i'll have a quick question: i'm using bzr + bzrtools on ubuntu but noticed yesterday that upgrading bzr forced bzrtools to get removed. i'm using the bzr PPA packages for ubuntu gutsy. is this an already known issue? does anybody have any idea if/when this is going to get fixed? thanks a lot in advance! | 07:42 |
| g0ph3r | my entry in sources.list is (according to the PPA launchpad info): deb http://ppa.launchpad.net/bzr/ubuntu gutsy main | 07:48 |
| g0ph3r | now when i try to reinstall bzrtools (version 1.2.0-1) i get the following complaint: "Depends: bzr (<1.2~) but 1.2-1~bazaar2~gutsy1 is to be installed" | 07:49 |
| awmcclain | Anyone alive and familiar with bzr-svn? | 07:49 |
| jkakar | lifeless: Congratulations on announcing looms! | 07:50 |
| deepjoy | I still cant find any reference to bazaar loom short of installing the plugin | 08:05 |
| deepjoy | is there a website? | 08:05 |
| poolie | deepjoy, just https://edge.launchpad.net/bzr-loom | 08:06 |
| abentley | lifeless: I'm looking at test_combine_last_two_threads in the loom plugin, and I don't understand why it ever passed. | 08:07 |
| TFKyle | hmm, wonder how reasonable it'd be to push a statically built web ui whenever you push a branch instead of having dynamic ones, it'd probably use quite a bit of space for branches with lots of history or large branches though | 09:11 |
| abentley | TFKyle: it would reduce the flexability too-- many web UIs let you compare any revision to any other revision. | 09:24 |
| TankEnMate | Why does bzr use so much RAM? | 09:28 |
| visit0r | python produces some overhead | 09:28 |
| TankEnMate | I'm doing an initial check out of the ubuntu desktop course, and bzr is using about 400M and hasn't written anything to disk.. | 09:28 |
| TankEnMate | It's enough to turn people off altogether.. | 09:29 |
| TankEnMate | If I didn't have to check this stuff out I would have given up long ago.. | 09:29 |
| TankEnMate | Isn't there a way to clone a repo just by using rsync? | 09:29 |
| TankEnMate | At last!! After reaching 500+M it has decided to write out.. | 09:32 |
| TankEnMate | what a disk storm... | 09:32 |
| TankEnMate | is there a way with bzr to clone a repo using rsync? | 09:35 |
| TankEnMate | guess not... | 09:36 |
| lifeless | abentley: I don't understand why the movement of the fetch is needed, the other stuff is obviously correct | 09:39 |
| lifeless | jkakar: thanks! | 09:39 |
| lifeless | poolie: I need to add loom to the bzr plugins page too | 09:39 |
| johnny | how do folks manage plugins across a group of collaborating developers? | 09:40 |
| fredp | hi, what would be the easiest way to know if there are uncommited changes ? I am currenty using if [ $(bzr status | grep modified) ]; then ... | 09:55 |
| fredp | but there may be a better way. | 09:55 |
| awilkins | You don't count new files as uncomitted changes? | 09:56 |
| fredp | this is just to prevent an automatic commit to apply unexpected changes; and I considered people using bzr add would not forget to bzr commit. | 09:58 |
| fredp | but better safe than sorry, I'll also check for ^added | 09:59 |
| awilkins | And unknown | 09:59 |
| fredp | you're right, and removed, and I'll be set. | 10:03 |
| fredp | do you know by chance if it is possible to pipe the commit message to bzr commit ? | 10:04 |
| fredp | echo whatever | bzr commit --file=- doesn't work | 10:05 |
| TFKyle | fredp: and renamed :) | 10:07 |
| awilkins | That was weird, I tried piping it in POwershell and I got trapped in an instance of Vim that was pretending to be a shell..... | 10:07 |
| TFKyle | (hmm, and kind changed if bzr st shows that) | 10:11 |
| fredp | it would probably be wiser for me to match ^[a-z]+:$ to get everything | 10:13 |
| tseliot | hi all, I'm having a problem with my bzr branch on launchpad | 10:38 |
| tseliot | whenever I try to push the code to my branch I get this error: | 10:38 |
| tseliot | http://pastebin.com/m2196a82d | 10:39 |
| tseliot | any ideas? | 10:39 |
| luks | you can use "bzr break-lock" if you are sure the lock is wrong (for example caused by a network failure on push) | 10:51 |
| sabdfl | hey folks, what's the recommended way to convert baz to bzr? | 10:59 |
| sabdfl | i found an ooold baz archive and I think it has revisions that never got properly converted | 10:59 |
| jrydberg_ | who's maintaing trac-bzr these days? | 11:02 |
| tseliot | luks: thanks, I'll try it | 11:04 |
| timparkin | Hi, I'm trying to use bzr and subversion but am having problems in that bzr-svn needs bzr 1.1 which I can't get hold of (1.2 seems to be the only one available) | 11:14 |
| tseliot | luks: it worked. Thanks again :-) | 11:14 |
| timparkin | Is there a 1.2 bzr-svn ? or should I try to find a bzr 1.1 | 11:14 |
| jelmer | timparkin: there is no 1.2 bzr-svn yet | 11:24 |
| timparkin | Hi Jelmer - I guessed at the tarball name and path by changing 1.2 to 1.1 which worked fine... It may be useful to add this path to the bzr download page | 11:38 |
| timparkin | and thanks for the response ;-) | 11:39 |
| awilkins | timparkin: As far as I can tell bzr-svn 0.47 works fine with 1.2 (better, in fact, due to 1.2 improvements) - you can ignore the version warning, or edit the code that checks it. | 11:53 |
| awilkins | But jelmer has the final say, of course :-) | 11:53 |
| lifeless | sabdfl: bzr baz-import | 12:18 |
| sabdfl | lifeless: how do i re-use history? | 12:18 |
| === cprov-out is now known as cprov | ||
| g0ph3r | hi folks, the currently available bzrtools package on PPA for ubuntu gutsy is incompatible with bzr. are there any plans to upgrade bzrtools to a compatible version or to fix the package? | 13:00 |
| ubotu | New bug: #193980 in bzr "revert after add destroy my working tree" [Undecided,New] https://launchpad.net/bugs/193980 | 13:10 |
| === mrevell is now known as mrevell-lunch | ||
| abentley | lifeless: bzrlib/test/branch_implementations/test_pull specifically tests that fetch is done before raising DivergedBranches. | 13:15 |
| * awilkins has just exclaimed out loud that bzr is "freaking awesome" | 13:25 | |
| awilkins | Just merged two unrelated (but smae content, essentially) trees for the first tim | 13:26 |
| === deepjo1 is now known as re1 | ||
| === re1 is now known as deepjoy | ||
| jelmer | awilkins, :-) | 13:31 |
| === mrevell-lunch is now known as mrevell | ||
| === maw is now known as mw- | ||
| decko | Guys, there's any place to download bzr documentation and tutorials??? | 15:16 |
| jabr | bazaar-vcs.org | 15:21 |
| johnny | lol | 15:23 |
| jelmer | igc: hi | 15:31 |
| No` | hi all | 15:34 |
| No` | dunno if it's possible in bzr, but I'd need somthing like the "externals" in subversion | 15:34 |
| LeoNerd | Perhaps explain what those are? | 15:35 |
| No` | i.e. a branch inside a branch, that I could sync/pull | 15:35 |
| LeoNerd | I imagine most of us here aren't that familiar with SVN | 15:35 |
| johnny | it's a branch that links to another branch | 15:35 |
| johnny | No`, afaik it is not possible yet | 15:35 |
| awilkins | "Nested Trees" | 15:35 |
| awilkins | Sort of | 15:35 |
| johnny | nested could exist without on repository, but what is the other trees are outside of your control? | 15:35 |
| johnny | err with one* | 15:36 |
| No` | johnny: ah. too bad. If a project shares "libraries" with others, we could have to manually update them together | 15:36 |
| awilkins | True... wasn't there some sort of branch manager thingy hanging around?> | 15:36 |
| johnny | my related question, is how do you folks handle plugins within a group of devs on a project? | 15:36 |
| johnny | that should be a simple question.. | 15:36 |
| No` | well it's not "out of my control", but I'd like to automagically have a mirror of a library that could belong to a given rep | 15:36 |
| johnny | hmm.. i know monotone had a mirror hook | 15:37 |
| No` | anyway. if it's not possible, then it's not possible | 15:37 |
| johnny | bzr can prolly do the same thing | 15:37 |
| tolbrino | Hey guys. I am new to bazaar and wanted to checkout a existing subversion branch with bazaar. I have successfully installed the bzr-svn plugin. But everytime I try to co from svn I receive a "Not a branch" error message. Is that not a supported use case? | 15:43 |
| awilkins | tolbrino: Which protocol are you using to access svn? | 15:51 |
| VSpike | I'm looking for a bit of best practice advice. I've been using bzr on a single machine and getting on pretty well with it. | 15:51 |
| tolbrino | awilkins: I'm using http | 15:51 |
| VSpike | I'd like to create a main branch on a different machine to enable "Team Collaberation, Distributed Style" as shown in the user guide | 15:52 |
| awilkins | Try bzr branch svn+http://my/repo my-local-branch | 15:52 |
| tolbrino | awilkins: all right, I check that | 15:52 |
| VSpike | On that machine, would I normally create a dir or symlink under root to simplify the sftp URLs? | 15:53 |
| tolbrino | awilkins: Now I receive a "Unsupported protocol for url..." error | 15:53 |
| VSpike | And then create a user account for everyone that wants to access it, probably under a bzr group? | 15:53 |
| VSpike | sftp://something.some.net/home/bzr/main is OK I guess | 15:54 |
| VSpike | Just wondering how people normally do it | 15:54 |
| dato | something like that, yes | 15:54 |
| VSpike | Is there any need to create a separate unix account for each user if bzr has its own concept of who people are? | 15:55 |
| dato | VSpike: you normally would call the group "projectname" instead of "bzr", and put "main" under /home/bzr/projectname, eg. | 15:55 |
| dato | VSpike: well. sharing a single account by everybody would work too, if you want that. that's just server administration realm, nothing to do with bzr :) | 15:56 |
| VSpike | oh yeah, understood :) | 15:56 |
| tolbrino | awilkins: The subversion repository I want to access does only support http and https | 15:56 |
| VSpike | when you identify yourself to bzr where is that info stored? | 15:57 |
| luks | tolbrino: is the svn plugin listed in `bzr plugins`? | 15:57 |
| VSpike | in the branch you're working on? | 15:57 |
| tolbrino | luks: yes it is | 15:57 |
| dato | VSpike: depends | 15:57 |
| VSpike | or at a user level on your current system? | 15:57 |
| dato | VSpike: you can set it by hand in an env. var, or if you use `bzr whoami John <john@foo.com>`, it'll be stored in a configuration file under ~/.bazaar | 15:58 |
| dato | ~/.bazaar/bazaar.conf | 15:59 |
| VSpike | but the account/identity that I use to sftp into the repo is irrelevant as far as bzr is concerned? | 15:59 |
| VSpike | its only a transport level concern | 15:59 |
| dato | correct | 15:59 |
| VSpike | Great. Well a single user would work fine for me then I think | 16:00 |
| * dato has to leave now. | 16:00 | |
| VSpike | If I want to move to a gatekeeper model, i can do that with file permissions, can't i? | 16:00 |
| VSpike | dato: thanks for the help | 16:00 |
| dato | np | 16:00 |
| VSpike | simple make the main trunk read only for regular user(s) | 16:01 |
| VSpike | but allow them to create/edit branches | 16:01 |
| dato | VSpike: you could change the permissions to not allow writing for the shared account | 16:01 |
| dato | yes, what you say too | 16:01 |
| VSpike | dato: if I did that, by what means would they submit changes? just tar the whole lot and email it, for example? | 16:02 |
| VSpike | dato: if I did that ^ thing you said | 16:02 |
| dato | VSpike: there is bzr send | 16:02 |
| VSpike | ohh | 16:02 |
| VSpike | right .. will read up on it. thanks again | 16:03 |
| dato | that generates a patch + metadata that you can pull/merge from | 16:03 |
| tolbrino | luks: Rechecked the plugins. Seems like cygwin(yes I am running windows) did not load it properly. | 16:03 |
| dato | leaving nor for real | 16:03 |
| VSpike | :) | 16:03 |
| VSpike | bye! | 16:03 |
| === kiko is now known as kiko-fud | ||
| tolbrino | luks: The plugin is working now. But bazaar shows another error even when I just type "bzr version". | 16:16 |
| tolbrino | I guess that is caused by the version bzr which cygwin uses. Version: 1.0.0 | 16:16 |
| tolbrino | Further upgrading to version 1.2.0 did not help. The error is : "AttributeError: 'module' object has no attribute 'svn_swig_py_cancel_func' in client.py | 16:29 |
| tolbrino | Any help? | 16:29 |
| luks | are these the patched svn bindings? | 16:29 |
| luks | I'd try native bzr and the binaries linked on the website | 16:30 |
| tolbrino | ok, I double check that | 16:30 |
| tolbrino | Yes, I have installed the patched subversion bindings | 16:31 |
| jelmer | tolbrino: that error suggests the python-subversion installation is corrupt | 16:33 |
| tolbrino | jelmer: well, maybe the source I have used for cygwin do not fit. I used the ones provided on http://d5190871.u44.websitesource.net/bzr/ | 16:35 |
| jelmer | tolbrino: I don't think those are meant for use with cygwin, but with the native build of bzr for windows | 16:35 |
| tolbrino | ok, are the patched subversion bindings provided somewhere? | 16:42 |
| jelmer | the patches are listed on the page you just mentioned | 16:45 |
| jelmer | I don't think there are binaries for cygwin available | 16:46 |
| mtaylor | bzr: ERROR: The branch format bzr loom format 6 (based on bzr branch format 6) | 17:30 |
| mtaylor | is not supported by loomify. | 17:30 |
| mtaylor | um | 17:31 |
| mtaylor | huh? | 17:31 |
| mtaylor | fog: how do you get this to show in your user: n=fog@debian/developer/fog ? | 17:33 |
| fog | mtaylor: it is a cloak. | 17:35 |
| fog | mtaylor: you can ask for a cloack if you found the irc netowork or are part of some kind of org | 17:36 |
| mtaylor | fog: cool. thanks | 17:37 |
| * mtaylor learns new things | 17:37 | |
| fog | :) | 17:37 |
| mtaylor | anybody on with loom zen? | 17:40 |
| tbye | Could an OS X 10.5.x user help me to uninstall the .dmg? I need features in 1.2 and will be installing from the src tar.gz. | 17:40 |
| tbye | Is there an uninstall procedure for the OS X dmg's? | 17:47 |
| abentley | mtaylor: It looks like your branch is already loomified. | 17:52 |
| johnny | tbye, not that i know about | 17:53 |
| mtaylor | abentley: so I loomified a branch (trunk) , then branched that branch to a new branch (new-trunk) | 17:53 |
| tbye | I'm noticing on the wiki that "a one-touch uninstall" is listed as a missing feature. :-( I'm looking through the package content to uninstall manually. | 17:53 |
| mtaylor | abentley: the new-trunk branch didn't show anything in show-loom | 17:54 |
| abentley | mtaylor: branching usually preserves the source format. | 17:54 |
| mtaylor | abentley: ok, so did I not get the loom as well because I hadn't done bzr record in the trunk branch? | 17:54 |
| abentley | Well, I know about as much about looms as you do. | 17:55 |
| abentley | But I would assume branch only copies the traditional branch data, not the thread info. | 17:56 |
| === kiko-fud is now known as kiko | ||
| jelmer | abentley: So is loom like git-style branching? | 18:01 |
| abentley | jelmer: A bit. The main thing is that it's an ordered list of branches. | 18:02 |
| abentley | (each called a thread) | 18:03 |
| abentley | But like git, the threads are all associated with a single repository and working tree. | 18:03 |
| Yasumoto | Hey guys. I'm trying to install bzr (and bzrtools) but am having some issues with the python2.5 bzrlib. "Please check bzrlib is on your PYTHONPATH." | 18:08 |
| Yasumoto | I've been searching on google and trying to figure out how to fix my pythonpath, but I'm not having much luck | 18:08 |
| jelmer | abentley: Ah, thanks | 18:09 |
| awilkins | Hmmph, I'm getting a "Not enough space" error on some long line diffs | 18:27 |
| mtaylor | abentley: so do you know if there's a way to merge/pull or push all of the threads associated with a branch? because merge, etc. each seem to operate on the active thread (other than the first push to create a new branch) | 18:29 |
| abentley | mtaylor: No, I don't know that. | 18:29 |
| mtaylor | ok. | 18:29 |
| * mtaylor is trying to figure out when to use loom and when to use different branches and stuff | 18:30 | |
| abentley | mtaylor: I think for publishing purposes, looms aren't too hot right now. Because you can't really ask people to pull or merge from a particular thread. | 18:49 |
| mtaylor | abentley: ok... so for now they're mainly good for work on my personal computer | 18:49 |
| fullermd | Looms are stored in the branch, so I could branch a loom'd branch [in the same repo] and blow away all the threads except the base? | 18:51 |
| jdong | I think there's some confusion looming about... urgh forget it too early in the morning to pun | 18:52 |
| abentley | It's always too early in the morning somewhere :-) | 18:52 |
| Yasumoto | jdong: brutal, haha | 18:53 |
| abentley | fullermd: I think that's not quite right. | 18:53 |
| abentley | I think the last_revision for a loomified branch is set according to the *current* thread, not the *base* thread. | 18:53 |
| mtaylor | that's what record does, right? set's last_revision? | 18:54 |
| mtaylor | so what exactly does that mean... does that set the revision up-to-which to branch if I branch from that branch? | 18:55 |
| mtaylor | branch branch branch | 18:55 |
| fullermd | Well, what I was thinking (from glancing at the docs) is, the stack of threads is a single stack, so if I want to make a new one on top of the base unrelated to the others, I'd have to make a new branch of the base, and create on top of that, right? | 18:57 |
| abentley | mtaylor: No, IIUC, up-thread and down-thread set last_revision, not record. | 18:58 |
| mtaylor | so what does record do? | 18:58 |
| mtaylor | fullermd: that's how I understand it | 18:59 |
| fullermd | It sounded to me like 'record' was sorta a 'meta-tag' on the state of all the threads at the given time. | 18:59 |
| mtaylor | yeah - but since I can't actually sync the state of all threads at a given time to somewhere else, I'm confused | 19:00 |
| * mtaylor hopes he doesn't sound too negative - he likes the overall concept, just is trying to figure out how to use it | 19:01 | |
| abentley | mtaylor: I may be wrong that push/merge don't work, since the docs say they do. | 19:01 |
| fullermd | I think push/pull are supposed to, though lifeless did file a bug about bzr+ssh not doing so. | 19:02 |
| fullermd | (presumably, bzr and bzr+http as well) | 19:02 |
| mtaylor | ahh.... so push and pull do the full loom, but merge is the thing that's just getting the currently active thread | 19:02 |
| mtaylor | let me try that... | 19:02 |
| mtaylor | nope | 19:05 |
| mtaylor | push pushes the current thread into the current thread of the other branch | 19:05 |
| mtaylor | so I guess there's just a semantic issue of not being able to specify "I'd like to merge the thing this working tree is associated with to/from this other specific thing" and "I'd like to sync this loom to this other loom" | 19:07 |
| abentley | fullermd: going back to your "unrelated threads" thing, uncommit and pull --overwrite provide ways to change a branch/thread into something completely unrelated. | 19:09 |
| abentley | But having unrelated threads defeats the point of looms. | 19:09 |
| abentley | The point being that this is an ordered set of branches, each building on the last. | 19:10 |
| fullermd | Yeah, but I don't want to change, I want to have something else. branch (AIUI) will branch the whole loom, not one thread out of it. | 19:10 |
| fullermd | So I'd have to blow away all the threads other than the base in the new copy, if I want to make a new unrelated thread on top of the base. | 19:10 |
| abentley | If you have something, and you want something else, how can that happen unless you change something. | 19:10 |
| fullermd | I was verifying that all the loom info is located in the branch, so if I do that in a shared repo, it's not going to do anything to my original loom (which I still want to go on with for whatever it's currently doing) | 19:11 |
| fullermd | I don't want something else _instead_, I want something else _in addition_. | 19:11 |
| abentley | Right, so you create a new thread, and then you change it into what you want. | 19:11 |
| fullermd | Yeah, but I want that new thread in a different loom, because it's intended to be a new layer off the base, not depending on other threads in the current loom, nor having any of them depending on it. | 19:12 |
| lifeless | moin | 19:12 |
| lifeless | fullermd: hi | 19:12 |
| abentley | fullermd: huh? | 19:12 |
| abentley | If you want the new thread to be in a different loom, you create it in the different loom. | 19:13 |
| lifeless | fullermd: the idea is that a loom is a single think working towards a feature X. Do you want this thread to be part of feature X? | 19:13 |
| * fullermd doesn't think we're connecting... | 19:13 | |
| fullermd | The loom is in the branch entirely, right? Nothing at all to do with the repository? | 19:13 |
| abentley | fullermd: yes. | 19:13 |
| lifeless | fullermd: the loom is versioned, to allow collaboration | 19:13 |
| lifeless | fullermd: the versioning gets stored in the repo, but if you don't record it, then nothing goes into the repo | 19:14 |
| fullermd | When I "branch" a loom, I get a new loom that's a copy of the original? Or do I get one with just the active thread? | 19:14 |
| abentley | Oh, I thought the versioned stuff was in the branch, too. | 19:14 |
| james_w | hi lifeless, thanks for the loom plugin. I'll try and look at it this weekend. | 19:15 |
| lifeless | abentley: well, I didn't want to reinvent the wheel, it just uses a specific file id. | 19:15 |
| lifeless | abentley: rather like inventory does. | 19:15 |
| lifeless | james_w: hi, cool. | 19:15 |
| BasicOSX | Anyone able to get loom working with1.3.0.dev.0? I submitted a bug on it, but thought I'd ask here | 19:21 |
| abentley | lifeless: Come over to the Storage dark side. We have namespaces for you. :-) | 19:22 |
| lifeless | BasicOSX: its working for me :), whats happening for you | 19:23 |
| lifeless | abentley: yeah well :> | 19:23 |
| lifeless | abentley: what I've done as a new namespace would be wrong fwiw. | 19:24 |
| BasicOSX | lifeless: needs to be in plugins/loom | 19:24 |
| BasicOSX | I did plugins/bzr_loom | 19:24 |
| BasicOSX | :-( | 19:24 |
| lifeless | BasicOSX: thats right :) | 19:24 |
| abentley | lifeless: I don't know if you saw my response, but moving fetch is required to pass the bzr test suite, which expects fetch to be done before DivergedBranches is raised. | 19:26 |
| lifeless | fullermd: when you branch a loom, you get the last recorded loom | 19:26 |
| lifeless | abentley: ah!. So, I did merge your patch; but I think we should fix that in the bzr test suite, as its arguably wrong. | 19:26 |
| abentley | I make no judgement about whether that expectation is sane. | 19:26 |
| abentley | But it even had a comment saying that was intentional. | 19:27 |
| lifeless | blink. | 19:28 |
| lifeless | I can imagine why, I think we were smoking toenails. | 19:28 |
| fullermd | lifeless: So if I branch a loom, blow away all but one of its threads, then create a new thread in it, that will have no ties to the original loom that will affect it? | 19:29 |
| lifeless | fullermd: if the loom has been recorded, they will have a common ancestor | 19:30 |
| lifeless | and once my aroundtuit of hooking in 3-way logic is done, doing a pull back to the other branch will remove its threads. | 19:31 |
| lifeless | fullermd: lets step away from the machinery for a second, and have you tell me what you want to _achieve_ | 19:31 |
| abentley | lifeless: You are doing source.repository.get_ancestry. Am I reading this wrong, or is that a network operation? | 19:31 |
| fullermd | lifeless: OK. I have a loom, say based on an upstream thread. There's a thread on top of that with a change intended to go upstream 'sometime', and a thread on top of that with some local change I want depending on them. | 19:31 |
| lifeless | abentley: it is; theres a lot of room for improving looms to use our newer better apis. | 19:31 |
| abentley | lifeless: So I'm reasonably sure the test was based on the premise that such checks should be done on the local repository always. | 19:32 |
| fullermd | lifeless: I want to make some other change to send upstream, based on the upstream, but TOTALLY unrelated to any of that. How do I make a new loom based on that upstream thread, with no relation to or effect upon the loom I have (which I intend to keep and keep working on by itself)? | 19:32 |
| lifeless | abentley: I think the assertion was about performance and not copying data twice; otoh I thinkmerging $private code to $public branch by mistake should error and -not- have inserted the data. | 19:33 |
| fullermd | The obvious way to me is to branch the upstream thread, or failing that, branch the loom and whack those other threads in the new copy. | 19:33 |
| lifeless | fullermd: so two things here. | 19:33 |
| lifeless | fullermd: I don't expect 'trunk' to be a loom ever. | 19:33 |
| lifeless | fullermd: looms are a tool for folk preparing things for merging to trunk. | 19:34 |
| lifeless | fullermd: so if you have a loom from someone else, its because they are working on a feature X to go in trunk, and which you want to either use that feature, or collaborate on its development. | 19:34 |
| fullermd | I'm assuming that the upstream thread in this loom I'm working on is the only copy of the upstream I have handy. | 19:35 |
| lifeless | fullermd: now, if you want to do two things at once: develop a feature Y, not depending on X, and, use a version of the code that combines both X and Y. | 19:35 |
| lifeless | fullermd: have I got your use case approximately right ? | 19:36 |
| fullermd | Half; I don't want the latter at all, just the former. | 19:36 |
| fullermd | Doing it now, I'd have branches A and B based on trunk, and C based on A. | 19:37 |
| lifeless | fullermd: so the use case is 'I have a loom containing trunk and feature X of a project; I want to develop a feature Y not related to feature X.' How do I do that ? | 19:37 |
| fullermd | Right. | 19:37 |
| lifeless | fullermd: I'm not sure where C comes in, if my pithy version is right. | 19:37 |
| lifeless | anyhow, heres what I'd do: | 19:38 |
| lifeless | bzr init X; bzr nick trunk; bzr loomify; pull -r thread:trunk ../Y; bzr create-thread X; hack hack hack | 19:38 |
| lifeless | fullermd: if you map every branch to a thread, looms work best when there is a linear path rather than a graph, because the workflow is a compromise between infinite flexability, and pragmatic use. | 19:39 |
| lifeless | fullermd: that means if you have two branches you would not merge, you would keep them in separate looms | 19:40 |
| lifeless | fullermd: if you have a branch you'd merge into every feature branch, you'd slot it into every feature loom | 19:40 |
| lifeless | fullermd: one thing to think about is that better cherrypicking will make looms much more powerful. | 19:40 |
| ubotu | New bug: #194099 in bzr "Unable to load plugin 'bzrloom' " [Undecided,New] https://launchpad.net/bugs/194099 | 19:41 |
| lifeless | james_w: when you say 'look at', do you mean package? :) | 19:41 |
| fullermd | Hm. Could "branch -rthread:trunk" work? | 19:43 |
| lifeless | fullermd: both branch -r thread: and pull -r thread: need some ui care | 19:44 |
| lifeless | fullermd: branch -r thread: should indeed give you a regular branch | 19:44 |
| lifeless | fullermd: and pull -r thread between two looms should pull a single thread not the entire loom. | 19:44 |
| lifeless | I think both of these are in TODO | 19:45 |
| fullermd | Reasonable enough. Thanks. | 19:46 |
| lifeless | fullermd: what do you think of looms so far ? | 19:47 |
| lifeless | mtaylor: merge is one of the things that is not fully implemented in looms | 19:50 |
| lifeless | mtaylor: if you wanted to do the work on it it should be fairly straight forward. | 19:50 |
| lifeless | mtaylor: and I'd be delighted to mentor | 19:50 |
| lifeless | mtaylor: what merge should do is add the loom being merged to the loom parents, which gives you essentially a merged working tree, for every loom in the stack. | 19:51 |
| mtaylor | lifeless: yes... that's the behavior I expected... | 19:52 |
| lifeless | mtaylor: then from the bottom up, if a fast-forward is possible on a single thread, do it, otherwise stop on that thread for the user to merge and commit, then go up to the next thread, etc | 19:52 |
| lifeless | mtaylor: and going up naturally merges as well, so some ui care is needed (or perhaps getting 3-parent trees is appropriate here). | 19:52 |
| lifeless | the loom on disk has all the needed slots to handle this, so no formatting or serialisation stuff is needed. | 19:53 |
| lifeless | jelmer: you can use loom to do git style branching - ignore the record and up-thread/down-thread commands. Then just use 'bzr switch' and 'bzr merge -r thread:threadname' | 19:55 |
| lifeless | jelmer: but git-style branches are not versioned structures that can be merged and annotated; looms are. I see this as an ok, but natural tension. | 19:56 |
| mtaylor | lifeless: what if the merge just did the merge in each thread like you mentioned... | 19:56 |
| mtaylor | lifeless: oh, nevermind... | 19:56 |
| mtaylor | fingers went faster than head | 19:56 |
| lifeless | mtaylor: you are merging two things - the shape of the loom, and the content of each thread :) | 19:56 |
| mtaylor | yes | 19:57 |
| lifeless | fredp: bzr st || echo 'changes' perhaps ? | 19:57 |
| jelmer | lifeless: Not sure I understand what you mean | 19:58 |
| jelmer | lifeless: Can't be merged and annotated? | 19:58 |
| lifeless | sabdfl: sorry, I was on the way to bed when I answered you; baz-import will create ghost-links appropriately. | 19:58 |
| lifeless | sabdfl: if you are within a shared repository, that will reuse history for you | 19:58 |
| lifeless | jelmer: the existence of a thread has history | 19:59 |
| lifeless | jelmer: so that I can branch you loom for (say) kerberos AD support; remove a thread, record, and when you merge me the removed thread gets removed. | 19:59 |
| lifeless | jelmer: but if you revert that thread back and record, subsequent merges from me will not remove the thread. | 20:00 |
| jelmer | thanks for the explanation | 20:00 |
| jelmer | it's still not entirely clear to me but I guess I should just try it | 20:00 |
| lifeless | jelmer: or in packaging, if debian and ubuntu both use a loom to package FOO, there will be an ubuntu thread debian don't want. so when debian merge ubuntu they discard that thread, and when ubuntu merge debian the first time after they revert to keep it. | 20:01 |
| lifeless | jelmer: uhm. git's list of branches is static. To combine them is a two-way operation. Looms is versioned, combining is three-way. Is that a better explanation ? | 20:01 |
| jelmer | lifeless: ahh | 20:01 |
| jelmer | yeah, makes more sense now | 20:02 |
| lifeless | so the goal of loom is to build upon this versioned history the ability to collaborate on the list of branches | 20:02 |
| lifeless | which only really makes sense if you have some particular thing you are collaborating on - e.g. packaging something, or a feature | 20:03 |
| lifeless | I often present loom as 'versioned queues' | 20:03 |
| fullermd | lifeless: Oh, my interest and questions are purely academic. I don't really see anywhere they'd fit my uses. | 20:05 |
| jelmer | lifeless: So it's a bit like that mercurial feature people keep asking about? | 20:05 |
| jelmer | mq or something? | 20:05 |
| lifeless | yes, loom is a superset of mq | 20:05 |
| lifeless | and of stacked git | 20:06 |
| lifeless | and quilt | 20:06 |
| awmcclain | If I have a bzr branch at /foo, and I want add a level to the root directory (to make the branch look like /baz/foo), how would I do that? | 20:06 |
| lifeless | awmcclain: mkdir /tmp; mv /foo /tmp/foo; mv /tmp /baz ? | 20:06 |
| awmcclain | and then commit that back to the repo? | 20:07 |
| lifeless | oh, sorry, if this is al versioned files then: | 20:07 |
| jelmer | lifeless: nice | 20:07 |
| awmcclain | Exactly | 20:07 |
| awmcclain | I want to do this all in the repo | 20:07 |
| lifeless | mkdir baz; bzr add baz; bzr mv <list of root paths here> baz; bzr commit | 20:08 |
| awmcclain | a ha!@ | 20:08 |
| awmcclain | ok | 20:08 |
| lifeless | awmcclain: I'm worried that you are conflating 'repo' and 'tree'. | 20:08 |
| fullermd | Is there some rich-root way of moving the actual rich root? So potential merges could DTRT? | 20:08 |
| awmcclain | lifeless: I'm sure I am, I'm quite new. :) | 20:08 |
| lifeless | awmcclain: repositories do not version the list of branches or the shape of the repo. | 20:08 |
| awmcclain | Porting from SVN | 20:08 |
| fullermd | Something like mtn pivot_root, I guess. | 20:08 |
| lifeless | awmcclain: ok, a major difference for you then is that branches are not versioned by the repo. branches record versions of trees. | 20:09 |
| beuno | theoretical question: I've got about 200 branches of different size and shapes. About 20 users branching them to their home folders (all on the same server). Would it make sense to have a shared repo on the top level? Will it decrease performance? Will file permissions collide among users? | 20:09 |
| mtaylor | lifeless: I'm about to go get on a plane, but I'll ping you next week about merges | 20:09 |
| lifeless | mtaylor: cool | 20:09 |
| lifeless | beuno: I would let different users have their own repo; but it would probably work | 20:10 |
| lifeless | got to run for a bit, I will be back in a couple hours | 20:10 |
| awmcclain | lifeless: Ah. So I should have said, "I want to change the structure of the tree within my branch" | 20:10 |
| beuno | lifeless, that's the current setup. I was just wondering if it was worth having shared repos to save space. Thanks. | 20:10 |
| lifeless | awmcclain: yes; that parsing unambiguously. | 20:11 |
| lifeless | grammar bad mine :) | 20:11 |
| * lifeless goes | 20:11 | |
| awmcclain | Ok, so I'm importing my SVN directory "panda" into my shared bzr repo as a new branch. I want the tree to look like panda_src/panda/, though. Do I branch the panda directory into the repo, then check it out, bzr add panda_src; bzr mv panda into panda_src, then bzr commit? | 20:26 |
| oly | hi, is there a way to check all my local files with remote ones and repull any that do not match | 20:58 |
| oly | both versions say there the same, but some of my files are slightly different | 20:58 |
| beuno | oly, bzr pull --overwrite | 20:58 |
| thatch | oly: bzr revert? | 20:58 |
| oly | okay, will give them a go and see where i end up, cheers :) | 20:59 |
| lifeless | awmcclain: two questions; have you considered just pull with bzr-svn ? | 21:19 |
| awmcclain | lifeless: That's what I was about to do... you mean pull rather than branch? | 21:20 |
| lifeless | awmcclain: secondly, when you say you want the tree to look like that, you realise that means that anyone making a new branch will have 'panda_src/panda' in the branch ? | 21:20 |
| awmcclain | lifeless: I guess I'm really confused about the notion of branches and trees then. Right now, my SVN directory structure looks like blah/blah/panda_src/panda blah/blah/panda_src/other_stuff ... My thought was to split up my projects into branches in my shared repo. | 21:22 |
| lifeless | right | 21:22 |
| lifeless | so you want a branch where the tree starts from the path 'blah/blah/panda_src/panda | 21:23 |
| awmcclain | However, I want my developers to be able to branch "panda_src" becuase the dev environment requires a directory above it. | 21:23 |
| lifeless | awmcclain: with respect, I suggest that you ignore that :) | 21:24 |
| awmcclain | So: I could either "import" (using bzr-svn) panda_src and lop off the unneeded subdirectoriees | 21:24 |
| awmcclain | Or import panda and add a directory | 21:24 |
| lifeless | awmcclain: your current repository is structured so that either you have everything under panda_src versioned as one tree, or you have everything under panda_src/panda as one tree | 21:24 |
| awmcclain | correct | 21:25 |
| rysiek|pl | hi all | 21:25 |
| lifeless | awmcclain: so I'd worry about getting your history migrated cleanly. having to have a directory above seems like something very easily documented :) | 21:26 |
| rysiek|pl | guys, I am having a serious problem here | 21:26 |
| rysiek|pl | here's the crashdum | 21:26 |
| rysiek|pl | p | 21:26 |
| rysiek|pl | http://www.wklej.org/id/e7bbf75efb | 21:26 |
| rysiek|pl | generally it's about "end of file reading from server." | 21:27 |
| rysiek|pl | while the server is AOK (it's a bzr+ssh server and worked fine just a minute ago) | 21:27 |
| awmcclain | lifeless: So maybe it'd be better to just pull panda_src from svn, then trim off the unneeded branches in bzr? | 21:27 |
| rysiek|pl | I need to get this up-and-running ASAP, any ideas what might be the cause? | 21:28 |
| lifeless | awmcclain: if you do that you will be carting around the unused directories in your history forever. | 21:31 |
| awmcclain | lifeless: exactly. :( | 21:31 |
| awmcclain | forrreeeevvvveeeer | 21:31 |
| lifeless | awmcclain: which is why I wouldn't; I would just documented that you need to mkdir foo; bzr branch $URL foo/panda | 21:32 |
| lifeless | awmcclain: and file a severe bug that this has to be done and shouldn't.:) | 21:32 |
| lifeless | rysiek|pl: check your permissions | 21:33 |
| lifeless | rysiek|pl: mkdir is failing | 21:33 |
| rysiek|pl | humm | 21:33 |
| rysiek|pl | perms sez you | 21:33 |
| awmcclain | lifeless: Unfortunately that doesn't help me, since makes another step every time I branch... and the whole reason I'm switching is to encourage everyone to branch. | 21:33 |
| awmcclain | lifeless: I'm not worried about losing history on this so much | 21:33 |
| lifeless | rysiek|pl: also, consider upgrading to bzr 1.2 ;)\ | 21:33 |
| lifeless | awmcclain: well you can add the directory inside the tree after you've got everything converted | 21:34 |
| rysiek|pl | yeah yeah, as soon as it gets into Debian and Ubuntu repos ;) | 21:34 |
| lifeless | awmcclain: as previously documented | 21:34 |
| lifeless | rysiek|pl: for ubuntu there is a ppa we maintain | 21:34 |
| awmcclain | lifeless: Ok, that's what I thought originally. :) | 21:34 |
| awmcclain | lifeless: Thank you so much for the help. | 21:34 |
| lifeless | no probs | 21:35 |
| awmcclain | Any suggestions for the standard distributed workflow? When do you decide to backup your local feature branch? | 21:36 |
| rysiek|pl | lifeless: hummm... any hints which file/dir should I check? | 21:37 |
| lifeless | awmcclain: I don't back up branches; I publish them ;) | 21:37 |
| lifeless | rysiek|pl: .bzr/branch/lock and .bzr/repository/lock | 21:37 |
| rysiek|pl | lifeless: I have a script that sets-up proper perms, and I run it everytime I do a bzr ci | 21:37 |
| rysiek|pl | ok, checking, thanks | 21:38 |
| rysiek|pl | lifeless: on server-side, right? | 21:38 |
| lifeless | yes | 21:38 |
| awmcclain | lifeless: When do you decide to publish your local feature branches to a central, backed-up location? | 21:38 |
| awmcclain | ;) | 21:38 |
| lifeless | awmcclain: For many things I use launchpad; generally I push early push often | 21:39 |
| awmcclain | Ok. Great! Again, thank you so much. It really helps new users when there's a good community. It's one of the reasons I chose bzr over hg. | 21:42 |
| rysiek|pl | lifeless: humm... it's rwxrwxrwx now... and still same thing | 21:46 |
| rysiek|pl | hmmm | 21:48 |
| rysiek|pl | the lockdirs exist | 21:48 |
| rysiek|pl | should I delete them? | 21:48 |
| lifeless | rysiek|pl: it may be trying the wrong path | 21:48 |
| lifeless | rysiek|pl: no | 21:48 |
| lifeless | rysiek|pl: you shouldn't need to be chmodding or touching the inside of .bzr at all | 21:48 |
| lifeless | rysiek|pl: perhaps the path you are using is wrong | 21:48 |
| rysiek|pl | that would be most strange, as - as I said - few minutes before it worked | 21:48 |
| lifeless | rysiek|pl: what url are you pushing to | 21:48 |
| rysiek|pl | it got saved in the bzr settings somewhere, so you need to tell me how to check it | 21:49 |
| lifeless | 'bzr push' will show it | 21:49 |
| rysiek|pl | but won't it push my rev to the server? | 21:49 |
| lifeless | what operation is failing | 21:50 |
| rysiek|pl | bzr ci | 21:50 |
| lifeless | whatever operation is failing is doing it on a url | 21:50 |
| lifeless | ok; bzr info then | 21:50 |
| lifeless | will say where it is a checkout of | 21:50 |
| lifeless | how did you get the checkout - did you do 'bzr checkout' ? | 21:51 |
| rysiek|pl | bzr ci the_path | 21:51 |
| rysiek|pl | *co | 21:51 |
| lifeless | ok | 21:51 |
| lifeless | and what was the_path | 21:51 |
| rysiek|pl | http://wklej.org/id/a96f92e5a7 | 21:51 |
| rysiek|pl | there you are | 21:51 |
| rysiek|pl | "serwek" is one of the machines on ma LAN | 21:52 |
| lifeless | ok. | 21:52 |
| rysiek|pl | and there is a corresponding entry in /etc/hosts | 21:52 |
| lifeless | and the branc is in /var/bzr ? | 21:52 |
| rysiek|pl | nope | 21:52 |
| rysiek|pl | /var/bzr/ypdf | 21:52 |
| rysiek|pl | I did a bzr up *minutes* before trying to do a ci that failes | 21:53 |
| rysiek|pl | lifeless: ^^^ | 21:54 |
| rysiek|pl | lifeless: and it went AOK | 21:54 |
| lifeless | rysiek|pl: thats because its write permission that is failing | 21:54 |
| rysiek|pl | ah, right | 21:55 |
| lifeless | can you do bzr info -v bzr+ssh://server/var/bzt/ypdf | 21:55 |
| rysiek|pl | moment | 21:56 |
| rysiek|pl | loading, please wait ;) | 21:57 |
| rysiek|pl | lifeless: http://www.wklej.org/id/08520be458 | 21:58 |
| rysiek|pl | lifeless: and made by root@serwek: http://www.wklej.org/id/8ec0664769 | 22:00 |
| rysiek|pl | lifeless: any pointers? | 22:09 |
| rysiek|pl | lifeless: and how do you know it's related to mkdir? I can't seem to find it in the dump | 22:09 |
| lifeless | rysiek|pl: File "/usr/lib/python2.5/site-packages/bzrlib/transport/remote.py", line 213, in mkdir | 22:15 |
| rysiek|pl | ah | 22:15 |
| lifeless | try doing 'ssh serwek mkdir /var/bzr/ypdf/.bzr/branch/lock/test' | 22:16 |
| lifeless | also ssh serwek cat $$HOME/.bzr.log | 22:17 |
| lifeless | may give more diagnostics | 22:17 |
| rysiek|pl | worked AOK | 22:18 |
| lifeless | what filesystem is /var/bzr/pdf on ? | 22:18 |
| rysiek|pl | lifeless: wouldn't cat ~/.bzr.log be shorter? ;) | 22:18 |
| lifeless | rysiek|pl: you need to expand it on the remote server | 22:18 |
| lifeless | rysiek|pl: as the user the bzr serve process is invoked as | 22:19 |
| rysiek|pl | ah | 22:19 |
| rysiek|pl | you're right | 22:19 |
| rysiek|pl | lifeless: .bzr.log | 22:20 |
| rysiek|pl | http://www.wklej.org/id/104ee48b3a | 22:20 |
| lifeless | thats got no record of commands running | 22:21 |
| lifeless | are you sure its the entire thing? | 22:22 |
| lifeless | I have to go for a bit; back in < 30 | 22:22 |
| rysiek|pl | 'kay | 22:22 |
| rysiek|pl | yeah, it's the whole thing | 22:22 |
| rysiek|pl | in the mean time I'll try to update bzr on the server | 22:23 |
| Le-Chuck_ITA | Hi all | 22:27 |
| Le-Chuck_ITA | how do I revert a bazaar branch to a given version? | 22:27 |
| rysiek|pl | man bzr? :) | 22:29 |
| rysiek|pl | bzr revert -r NUMBER | 22:29 |
| Le-Chuck_ITA | oh | 22:29 |
| Le-Chuck_ITA | this is not the right time to work :) | 22:29 |
| luks | revert as in change files as they were in that revision, or make a branch of that revision? | 22:29 |
| Le-Chuck_ITA | sorry for dumb question | 22:29 |
| Le-Chuck_ITA | revert takes an argument, oh yes ::() | 22:29 |
| Le-Chuck_ITA | I just want to get back to rev n xxx | 22:30 |
| Le-Chuck_ITA | and I was obviously missing the -r switch | 22:30 |
| Le-Chuck_ITA | I am too tired | 22:30 |
| Le-Chuck_ITA | thansk | 22:30 |
| luks | then you probably want uncommit | 22:30 |
| luks | or bzr branch -r X | 22:30 |
| rysiek|pl | Le-Chuck_ITA: no prob | 22:30 |
| luks | revert will change your working files | 22:30 |
| luks | and then you can commit those changes | 22:30 |
| Le-Chuck_ITA | yes but I just copied them so I won't care - I need to test if a previous release really did what I remember | 22:31 |
| luks | I'd make a new temporary branch then | 22:31 |
| Le-Chuck_ITA | yes I did tha | 22:31 |
| Le-Chuck_ITA | t | 22:31 |
| igc | morning all | 22:32 |
| igc | hi jelmer | 22:32 |
| Le-Chuck_ITA | igc: where are you ? | 22:32 |
| igc | Brisbane, Australia | 22:32 |
| jelmer | igc: I was just curious whether the fast-import stuff is faster than bzr-svn's svn-import and if so, how? | 22:32 |
| Le-Chuck_ITA | so good morning igc | 22:33 |
| igc | morning Le-Chuck_ITA | 22:33 |
| lifeless | jelmer: I doubt it will have the right ids ;)) | 22:33 |
| igc | jelmer: I'm yet to compare to be honest | 22:34 |
| jelmer | lifeless: well, I'm mainly interested in stealing ideas from it | 22:34 |
| lifeless | igc: whats the interface fast-import exposes? does it capture renames? | 22:34 |
| jelmer | igc: Ah, so the bzr side of it doesn't have any specific optimizations? | 22:34 |
| igc | jelmer: yes, the bzr side is optimised to my current ability :-) | 22:34 |
| igc | I know lifeless and others could go further of course ... | 22:35 |
| igc | but there's enough 'tricks' in there already | 22:35 |
| igc | jelmer: the code that might be of interest is called revisionloader.py | 22:36 |
| igc | that's where most of the time is saved over vanilla bzr importers | 22:36 |
| lifeless | igc: what does it do that is different, and is it _correct_ ? | 22:37 |
| === kiko is now known as kiko-afk | ||
| igc | lifeless: the fast-import stream spec does include renames | 22:37 |
| lifeless | igc: and empty directories? symlinks? file copies? | 22:37 |
| igc | it caches serialised inventories & skips a check for existence mainly | 22:38 |
| lifeless | igc: you've found a new toy; I want to find its edges :)) | 22:38 |
| igc | oh - there *are* edges | 22:38 |
| igc | right now though, my immediate focus is solving the OOo into Bazaar dilemma | 22:39 |
| igc | I'm down to 100 commits in around 2 minutes but ... | 22:39 |
| lifeless | wow, registering a registered branch is fugly | 22:39 |
| lifeless | page long traceback | 22:39 |
| igc | that still implies a 12 days conversion | 22:39 |
| lifeless | igc: you using packs ? | 22:40 |
| igc | yes | 22:40 |
| igc | of course | 22:40 |
| lifeless | igc: some things | 22:40 |
| lifeless | hold a write lock the entire time | 22:40 |
| igc | inventory.copy takes 20% | 22:40 |
| lifeless | if you can, do a single write group for say 100 commits | 22:41 |
| igc | I'm pretty sure I'm holding one write lock as suggested | 22:41 |
| igc | by default, it's one write lock for 10000 commits :-) | 22:41 |
| lifeless | if you're using commit builder that won't be possible at the moment | 22:41 |
| lifeless | one write lock for the entire operation, don't drop it at any point. | 22:41 |
| igc | there's a command line param to tune that though | 22:41 |
| lifeless | inventory.copy - yeah. use my journalled inventory format (kidding!) | 22:42 |
| igc | I'm really looking forward to it after these last 2 weeks on this project | 22:43 |
| igc | i.e. the migration project | 22:43 |
| igc | lifeless: all the work you did on commit has been essential for making import faster of course | 22:44 |
| igc | I'm not quite gaim to skip some of the checks though for data from a foreign source | 22:44 |
| igc | s/gaim/game/ :-) | 22:44 |
| lifeless | igc: thanks | 22:48 |
| === cprov is now known as cprov-out | ||
| ja3 | igc: just to be clear, a write group is different than a write lock | 23:01 |
| === ja3 is now known as jam | ||
| jam | you would hold a write lock for the whole time | 23:02 |
| igc | jam: doing that | 23:02 |
| ubotu | New bug: #194161 in bzr-loom "up-thread, down-thread and switch are slow" [High,Triaged] https://launchpad.net/bugs/194161 | 23:06 |
| rysiek|pl | lifeless: update to bzr 1.1 on the server solved the problem | 23:47 |
| rysiek|pl | lifeless: I must have gotten some update of bzr on the desktop lately, and that broke desktop<->server communication | 23:48 |
| rysiek|pl | lifeless: thanks for your help :) | 23:48 |
| eric_programmer | I'm trying to understand the support for nested trees. Some docs on the websites says it is still in development while other docs say it was included in release 0.15rc1. | 23:53 |
| eric_programmer | I have an existing branch. I want to import another project as a directory in this existing project. | 23:54 |
| eric_programmer | I tried "bzr branch http://other/project other_project" This worked but it says other_project is unknown when I do bzr status and I cannot add it to make it known. Am I misunderstanding something? | 23:55 |
| lifeless | eric_programmer: the disk format is supported; but the ui for it is unpolished | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!