| jelmer | meteoroid, hi | 00:03 |
|---|---|---|
| jelmer | meteoroid: getting the cache screwed up is always a bug in bzr-svn | 00:04 |
| jelmer | meteoroid, not sure I follow what you're trying to do | 00:05 |
| jelmer | meteoroid, you branched inside svn or with bzr? | 00:05 |
| meteoroid | jelmer: i use bzr-svn to branch a small portion of the svn repo, then i deleted that bzr branch and bzr svn-import the whole repo.. | 00:30 |
| meteoroid | but, it just pulls this one location that i branched before | 00:30 |
| meteoroid | arguably the most important part but yanno.. | 00:31 |
| jelmer | meteoroid: this is a bug fixed in bzr-svn 0.4.11 | 00:32 |
| meteoroid | alrighty | 00:32 |
| jelmer | meteoroid: for now, remove ~/.bazaar/subversion.conf and try again | 00:32 |
| * meteoroid tries just removing that entry | 00:34 | |
| * jelmer gets some sleep | 00:34 | |
| meteoroid | thanks jelmer :) | 00:35 |
| === rocky is now known as rocky|away | ||
| sohail | hmm... bzr cloning a 16M repository taking a bit too long... | 01:31 |
| sohail | still going... | 01:31 |
| sohail | we have python running at 150M of RAM and 100% CPU | 01:32 |
| sohail | yay | 01:32 |
| lifeless | sohail: thats unusual, what is it ? | 01:35 |
| sohail | lifeless, my own repository | 01:35 |
| lifeless | sohail: has it been this slow for you before ? | 01:36 |
| sohail | lifeless, never | 01:36 |
| sohail | new situation: I am trying to clone from linux to windows | 01:36 |
| sohail | but the windows box has version 1.6 | 01:36 |
| sohail | linux has 1.3 | 01:36 |
| sohail | how can I upgrade the repository format? or do I need to? | 01:37 |
| lifeless | sohail: is it a pack or knit repo ? | 01:37 |
| sohail | I don't know what that means so whatever the default is | 01:37 |
| lifeless | well, the default changed at 1.0 - did you have this repo before 1.0 | 01:37 |
| sohail | no | 01:37 |
| sohail | but the repository I'm trying to clone was created with 1.3 | 01:37 |
| lifeless | lets check | 01:38 |
| lifeless | bzr info -v on the repository | 01:38 |
| sohail | lifeless, http://rafb.net/p/5XpErU98.html | 01:39 |
| lifeless | that should be fine | 01:39 |
| sohail | when I do bzr clone from the Windows machine, it hangs at "copying inventory texts 2/5" | 01:40 |
| sohail | err "copying context texts 3/5" | 01:40 |
| sohail | content** | 01:40 |
| sohail | geez | 01:40 |
| lifeless | has it allocated a lot of memory perhaps ?/ | 01:41 |
| sohail | oh yes | 01:41 |
| sohail | 200M | 01:41 |
| sohail | 250M now | 01:41 |
| sohail | I just did a bzr clone on the host and it finished in 30 seconds | 01:42 |
| sohail | :-/ | 01:42 |
| beuno_ | lifeless, I did see your export patch, you rock! I didn't comment because I say you superceded it later on, with something I couldn'y find! | 01:42 |
| sohail | lifeless, at 500M now | 01:43 |
| beuno_ | Pieter, the root to whatever it started on :) | 01:43 |
| sohail | man I am totally out of it today... The repository is 216M not 16M! | 01:45 |
| sohail | ok I'll just let it run for a while | 01:45 |
| lifeless | beuno_: the later was just refactoring | 01:45 |
| * beuno_ stabs LP for logging him out | 01:46 | |
| === beuno_ is now known as beuno | ||
| beuno | lifeless, that will go into 1.7 though, right? | 01:46 |
| lifeless | beuno: assuming it gets reviewed :) | 01:47 |
| lifeless | sohail: ok, I think its swapping | 01:47 |
| lifeless | sohail: are you branching into a new repo on windows or an existing one ? | 01:47 |
| * beuno searches for the merge request to add his +1 | 01:48 | |
| beuno | is BB down? | 01:49 |
| Peng_ | Several hours ago, it was slow, but not down. | 01:49 |
| Peng_ | Now, it might just be down. | 01:50 |
| lifeless | beuno: please check and see if the export patch is enough | 01:50 |
| beuno | lifeless, sure, I'll give it a spin now | 01:50 |
| beuno | lifeless, message id 1218178923.4514.146.camel@lifeless-64 | 01:51 |
| beuno | right? | 01:51 |
| lifeless | beuno: it may not be - I think it will tend to write to a file itself; but let me know | 01:51 |
| beuno | lifeless, btw, if you'd like to sponsor jelmer's packaging of bzr-search, we can get Loggerhead's package on it's way soon, with bzr-search as a recommends :) | 01:54 |
| markh | speaking of strangeness, I'm seeing bzr spin at 100% cpu and 400MB of ram for over 6 minutes doing "bzr merge --preview ..\other-bzr.dev-branch" | 01:54 |
| markh | progress bar is stuck at "0/0" and the "spinner" hasn't moved for many minutes | 01:55 |
| beuno | markh, what does .bzr.log claim? | 01:55 |
| lifeless | markh: also look for syscall activity | 01:55 |
| markh | heh - I think I need to go back to bed. The 2 trees were actually completely unrelated, so I'm sure it was trying really hard to find something to do :( | 01:56 |
| markh | sorry for the nouse | 01:56 |
| markh | noise too... | 01:57 |
| * markh has too many directories that start with 'bzr'... | 01:57 | |
| pickscrape | beuno_: Did you mean me here? -> "beuno_: Pieter, the root to whatever it started on :)" | 01:57 |
| beuno | lifeless, your patch does *exactly* what I need | 01:58 |
| beuno | pickscrape, oh, heh, yes | 01:58 |
| beuno | good catch | 01:58 |
| pickscrape | I'm still not completely sure what is required. Let's say we are serving from a non-branch directory that contains the path a/b/c, where c is a branch called 'bob' | 01:59 |
| pickscrape | When we browse to the branch, currently we will see this: "bob : viewing / for revision X" | 02:00 |
| pickscrape | Now, I can make 'bob' into a link that link to the branch root, but that doesn't help you to navigate further up the tree. | 02:00 |
| sohail | lifeless, I am cloning an existing repo | 02:01 |
| pickscrape | If we start showing the tree leading up to the branch as well, do you then also need to show the branch's directory name instead of its nic? | 02:01 |
| beuno | pickscrape, hm | 02:02 |
| pickscrape | That also puts you in a position where the branch root isn't very clearly marked | 02:02 |
| sohail | lifeless, and it died: http://rafb.net/p/C2dh6O38.html | 02:02 |
| pickscrape | This is why I didn't mess with what was displayed :) | 02:02 |
| beuno | pickscrape, maybe we should just make that part a clear path, instead of the jumbled text it is today | 02:02 |
| beuno | pickscrape, if you want to take a shot at making it less of a mess, that would be great. If not, I'll merge in your patch and work on top of that | 02:03 |
| pickscrape | I can try an idea and propose it for merging. The worst that could happen is it doesn't get merged :) | 02:04 |
| beuno | pickscrape, and a big hug for trying! | 02:04 |
| pickscrape | Happy to be involved :) | 02:04 |
| pickscrape | beuno: I'm thinking it might be worth merging what's done already so I can sandbox on top of that easily, unless you'd rather wait for the next step? | 02:05 |
| lifeless | sohail: I believe that that bug is fixed in 1.6rc1 | 02:06 |
| lifeless | markh: are tehre rc1 binaries for windows? | 02:06 |
| beuno | pickscrape, I sure can, but, on the other hand, we can take this opportunity and learn more about bzr. You can branch your branch, and work on top of that! | 02:06 |
| markh | not that i've uploaded - I keep trying getting distracted trying to fix things :) | 02:07 |
| markh | I'm just merging my latest test suite fix in and will test them, then upload them | 02:07 |
| lifeless | markh: I think sohail just hit a fixed bug in the betas | 02:07 |
| sohail | lifeless, good I'm just installing it now | 02:07 |
| sohail | (building from source) | 02:07 |
| lifeless | sohail: ok cool | 02:07 |
| lifeless | sohail: let mw know if its faster too | 02:08 |
| pickscrape | beuno: ok. So when I have something to present I just register another branch? Or just push over the one that is already there? | 02:08 |
| sohail | lifeless, will do | 02:08 |
| beuno | pickscrape, register a new one. Branch locally, play around, when you're happy, push to a new location in LP | 02:08 |
| pickscrape | Sweet | 02:08 |
| sohail | lifeless, ok so it isn't any faster, that's for sure! | 02:12 |
| lifeless | sohail: can you try something for me ? | 02:15 |
| lifeless | sohail: replace bzr+ssh with sftp in your url | 02:15 |
| markh | a binary will finish uploading in 15 minutes | 02:15 |
| sohail | lifeless, ok | 02:15 |
| sohail | lifeless, so you mean bzr clone sftp://...? or bzr clone sftp+ssh:/// | 02:16 |
| sohail | err bzr+sftp | 02:16 |
| sohail | lifeless, oh damn paramiko is needed for sftp... Do you know how to get distutils to use Visual Studio 2005? | 02:18 |
| markh | lifeless: most test failures now on Windows relate to a LockContention error being thrown. Can you think of any characteristics of your locks that would make them more likely to fail under windows (ie, do you ever assume you can delete the lock file while its open, for example?) | 02:18 |
| markh | note I'm yet to see a "real" lock contention error - just in the tests | 02:20 |
| lifeless | sohail: replace 'bzr+ssh' with 'sftp' | 02:24 |
| lifeless | markh: lockdir is unlikely to be a problem on windows; I'd expect the dirstate os lock is the problem | 02:25 |
| markh | yeah, I think you are right: | 02:25 |
| markh | LockContention: Could not acquire lock "O:/window~1/testbzr-ag21lz.tmp/tatus.test_pending_with_ghosts/work/b/.bzr/checkout/dirstate" | 02:25 |
| Leefmc | Question: So with bzr, is a project directory (ie, one which contains the .bzr folder) only ever contain one branch? (coming from a git person).. Say for example you have ~/project_src, if you need to create a test branch, do you then create a bzr copy and place ot elsewhere? ie ~/project_test | 02:33 |
| lifeless | Leefmc: have a look inside .bzr | 02:35 |
| markh | sohail: http://starship.python.net/crew/mhammond/bzr-setup-1.6rc1-mh1.exe should work pretty well | 02:36 |
| lifeless | Leefmc: there are three subfolders in a newly inited project - repository, branch, checkout | 02:36 |
| lifeless | Leefmc: the branch folder has the branch details, so yes, you need a directory per branch. but you don't need a new repository (where most of your data is) or a new checkout (which exists when your source code is unpacked on disk for editing) to have a new branch | 02:36 |
| Leefmc | lifeless: So for a project, you would have like ~/project/src/.bzr, and your branches would be ~/project/src/trunk ~/project/src/test etc? | 02:38 |
| === techII_ is now known as techII | ||
| sohail | markh, thanks | 02:39 |
| sohail | markh, are you the guy from Jurassic Park | 02:40 |
| markh | heh - well, I'm getting a little long in the tooth, but I'm not *that* old ;) | 02:40 |
| sohail | :-) | 02:40 |
| lifeless | Leefmc: yes, exactly | 02:40 |
| lifeless | Leefmc: if you have an expensive working tree - e.g. C projects where you don't want to rebuild | 02:41 |
| Leefmc | lifeless: K thanks. I enjoy git, even though i never got that deep into it, but at the same time it seems to have warped my mind for anything non-git heh | 02:41 |
| lifeless | then you'd have a one that you use to edit and switch between | 02:41 |
| lifeless | e.g. bzr checkout --lightweight trunk build | 02:41 |
| lifeless | cd build | 02:41 |
| lifeless | ./configure | 02:41 |
| lifeless | etc | 02:41 |
| lifeless | bzr switch test | 02:41 |
| lifeless | bzr switch trunk | 02:41 |
| lifeless | and so on and so forth | 02:41 |
| Leefmc | lifeless: Hmm, thats one thing i like about git though, is that in my IDE i never have to switch my files.. ie, say i am working on "main.py", if i want to try something i just create a new branch and try it, i never worry about which "main.py" (./test/main.py vs ./trunk/main.py) i am editing because its always my active branch | 02:43 |
| lifeless | Leefmc: so having one tree does that - | 02:44 |
| lifeless | you only have one copy of main.py on your disk at a tim | 02:45 |
| lifeless | Leefmc: if you have a bzr branch you're working on, its three commands to set this up, and 4 to demo it :) | 02:45 |
| Leefmc | lifeless: Yea but with bzr, if you want to take a piece of code and experiment, you make a second branch dont you? And thus, a 2nd main.py file on disk, correct? | 02:45 |
| lifeless | no, second branch doesn't imply second checkout | 02:46 |
| Leefmc | Git must have really screwed with me hehe :D | 02:46 |
| lifeless | do you ahve any code in bzr? | 02:46 |
| Leefmc | How is it that i find the "humane" vcs more confusing than one made by Linus! :D (not bashing bzr ofcourse, just poking fun at myself :p) | 02:47 |
| lifeless | well | 02:47 |
| Leefmc | lifeless: I've got plenty to try, but no projects set up with it yet | 02:47 |
| lifeless | git has some nice things about it | 02:47 |
| lifeless | its very optimised for the editing-C-code workflow | 02:47 |
| Leefmc | right now im creating my directory structures for a new project and i wanted to use bzr because of Launchpad | 02:48 |
| lifeless | this isn't intrinsically bad, but it does alter how things fit together | 02:48 |
| lifeless | ok | 02:48 |
| Leefmc | (I have more faith in launchpad for project hosting rather than Gitorious or Github, for example) | 02:48 |
| markh | I think your previous exposure to any other dvcs does tend to cloud your mind for a while when looking at another. | 02:48 |
| lifeless | grab a directory somewhere | 02:48 |
| lifeless | do this: | 02:48 |
| lifeless | bzr init-repo --no-trees repository | 02:48 |
| lifeless | bzr init repository/trunk | 02:48 |
| lifeless | copy some code - e.g. main.py into repository/trunk and then do | 02:49 |
| lifeless | bzr add | 02:49 |
| lifeless | bzr commit -m 'import' | 02:49 |
| Leefmc | A while back i even used bzr, and it seemed relatively simple and easy (bout too easy), but i had no idea how it worked with my Git-ified workflow of "branch testing" | 02:49 |
| lifeless | bzr remove-tree | 02:49 |
| lifeless | this will have created a branch in a shared repository with no working files | 02:49 |
| lifeless | now do | 02:50 |
| lifeless | bzr branch trunk test | 02:50 |
| lifeless | and | 02:50 |
| lifeless | bzr checkout --lightweight trunk working | 02:50 |
| lifeless | cd to working | 02:50 |
| lifeless | it will have your main.py | 02:50 |
| lifeless | bzr info | 02:50 |
| lifeless | will tell you that you are on the branch trunk | 02:50 |
| lifeless | bzr switch test | 02:50 |
| lifeless | will make test your active branch | 02:51 |
| Leefmc | bzr add gives an error about the current dir not being a branch | 02:55 |
| Leefmc | Perhaps it was a bad idea to initially learn bzr by the stupid 5 minute tutorial. I should have focused from the ground up. | 02:56 |
| Leefmc | I keep trying to make things relative to what i knew (Git) which is.. not easy heh. | 02:56 |
| Leefmc | I spose i add the file directory? bzr add ./repository/trunk/__init__.py | 02:58 |
| Leefmc | hmm, same thing.. im guessing then i need to cd into one of the repos you had me create. Im still confused on what the first two lines did though. To me it seems like you had me create 2 bzr repositories. | 02:59 |
| Leefmc | oh i see i think, bzr uses multiple .bzr files, one for a collection of branches (what git would consider an actual repo), and one for each branch | 03:00 |
| lifeless | Leefmc: oh, init probably honoured the no-trees | 03:01 |
| lifeless | Leefmc: yes, your last point is right | 03:02 |
| Leefmc | ok, im reading your steps tryin to make sense of it, and i am a bit confused. It seems you created 3 branches, trunk, test, and working. Now because there are .bzr dirs for each branch, you actually cd around to switch branches (as you do when you cd into "working"); However, you use a bzr switch command when inside of "working" to switch to "test", how is this possible? | 03:04 |
| Leefmc | does bzr cd you to a different directory? | 03:04 |
| lifeless | Leefmc: working isn't a branch | 03:12 |
| sohail | hey markh that version worked fine except I get this annoying message: "intl3_svn.dll was not found" | 03:12 |
| lifeless | Leefmc: its just a tree, like a svn checkout or a cvs checkout | 03:12 |
| markh | sohail: bugger - thanks - I'll try and fix that. If you don't care about bzr-svn, you could probably just nuke the plugins/svn directory | 03:13 |
| sohail | markh, yeah I did just that | 03:13 |
| sohail | now I need to figure out how to get bzr to ignore the symlinks in my repo :-/ | 03:14 |
| markh | heh - afraid I can't help you there ;) | 03:14 |
| Leefmc | lifeless: Roughly, what would that be in Git? Repositories are collections of Branches, Branches are each a specific revision (with history), so what is a Tree then? | 03:14 |
| markh | sohail: are you using a non-english windows? | 03:15 |
| sohail | markh, no, english | 03:15 |
| markh | hrm | 03:15 |
| Leefmc | lifeless: The guide sort of confuses me. It says a Branch is an ordered set of revisions, yet the working tree is the directory of those revisions.. which seems to sound synonymous with Branch | 03:15 |
| sohail | markh, maybe you can tell me how I can clone a subdirectory? That way I can just ignore the directory with the symlinks | 03:16 |
| Leefmc | lifeless: Or wait, i think i see. The "working tree" is Git's version of the Active Branch | 03:16 |
| Leefmc | lifeless: Except with bzr, it is an actual directory aswell (containing files of whatever branch) | 03:17 |
| markh | sohail: not sure about that either ;) I'm still learning the ins and outs myself | 03:17 |
| sohail | markh, really! and you are making installers already?!!! :-) | 03:20 |
| markh | heh - well that is what I *do* know about ;) | 03:20 |
| markh | I thought bzr was trying to hard to at least not break with symlinks on windows | 03:21 |
| markh | but I can't find any good references | 03:21 |
| sohail | markh, well afaict it isn't doing a very good job :-) | 03:22 |
| sohail | so does anyone here know how to clone a sub directory of a bzr repo? | 03:22 |
| Leefmc | Question: Is "working" the standard name for the.. working directory? Or is it trunk.. or main.. etc? | 03:39 |
| Leefmc | Or does it even matter? Will people only see the branch name, and not my working name? | 03:39 |
| sohail | ok I knew how to do this but... bzr clone ...; <do some changes>; bzr commit; bzr push => "No push location known or specified" | 03:45 |
| sohail | how do I fix that? | 03:45 |
| tacone | sohail: bzr push [location] | 03:45 |
| sohail | tacone yeah but what is location? | 03:46 |
| sohail | shouldn't bzr default to where I cloned from? | 03:46 |
| tacone | sohail: no | 03:46 |
| markh | sohail: you probably wanted "bzr branch" in the first place then | 03:46 |
| sohail | markh, ah! | 03:46 |
| sohail | ok then | 03:46 |
| sohail | I have to go just now but that is good to know | 03:46 |
| tacone | sohail: if you're using launchpad that could be for example: bzr push lp:~yournick/yourproject/namebranch | 03:46 |
| markh | sohail: heh - actually, "clone" is an alias for "branch"! | 03:53 |
| markh | so yeah, you have to give the same location you branched from if that is where you want to push it. I recall a long thread on the bzr mailing list about that now | 03:53 |
| markh | it should remember though, and later, you just "push" | 03:54 |
| Leefmc | Question: Is there any real difference between a branch and the working tree? Because "bzr checkout" creates a branch correct? Yet lifeless used checkout to create a working tree, so is there any real difference? | 04:10 |
| lifeless | bzr checkout without --lightweight | 04:23 |
| lifeless | will create: | 04:23 |
| lifeless | - a branch, bound to the source | 04:23 |
| lifeless | - a working tree at the same place as teh new branch | 04:23 |
| lifeless | with --lightweight | 04:23 |
| lifeless | bzr checkout creates: | 04:23 |
| lifeless | - a branch reference (basically a fancy symlink that works on windows) | 04:24 |
| lifeless | - a working tree | 04:24 |
| pickscrape | beuno: ping | 04:27 |
| beuno | pickscrape, pong | 04:29 |
| pickscrape | beuno: I need a way to find out if loggerhead is serving a branch at the root level or not | 04:29 |
| pickscrape | i.e. is the directory that http://example.com/ points to a branch, or a plain directory | 04:30 |
| pickscrape | I've got the directory breadcrumbs working. This is the only corner case I can find that makes it behave badly :) | 04:31 |
| beuno | pickscrape, for the directory nav? | 04:31 |
| pickscrape | Yes | 04:32 |
| beuno | pickscrape, it already knows, it shows different icons for each type | 04:33 |
| techII | (since i can't find the blog entry I read dealing with this) if I commit to a svn checkout with bzr version 1.3.1, is it going to dump the bzr related stuff into the svn repo? | 04:33 |
| pickscrape | Here's an example of what I mean. If I'm serving a loggerhead branch at the root, and I'm currently looking at the /loggerhead/apps directory, the link to the root needs to point to /files, otherwise I will jump to the revisions view | 04:34 |
| pickscrape | Conversely, if loggerhead is serving a plain directory at its root, the link to root just need to go to / | 04:34 |
| pickscrape | I suppose it's something that loggerhead could detect when it first starts up, but that sounds like quite a change :) | 04:37 |
| * beuno thinks | 04:38 | |
| beuno | pickscrape, this is mixing the files and directories view, right? | 04:39 |
| pickscrape | No, this is just making the directory path displayed at the top of the files view into breadcrumb links | 04:39 |
| pickscrape | Which entails a link back to / for completeness | 04:40 |
| pickscrape | The way I have it now, when the user is looking at a file they are able to jump directly to any of the file's parent directories in the branch, and the directories containing the branch, right up to the root directory that loggerhead is serving | 04:41 |
| beuno | I like that | 04:41 |
| pickscrape | The only case that doesn't work is when loggerhead's root is itself a branch | 04:41 |
| beuno | I see yor problem | 04:41 |
| beuno | can you push the branch, so I can toy around with it a little? | 04:41 |
| pickscrape | Yes. You'll be able to see the problem very clearly that way :) | 04:42 |
| pickscrape | Just give me a few to commit what I've done. | 04:42 |
| beuno | sure | 04:42 |
| beuno | I'm jumping in between dr. house episodes anyway :p | 04:42 |
| pickscrape | :) | 04:42 |
| * pickscrape is up to date on that ;) | 04:43 | |
| beuno | I'm gladly not | 04:43 |
| beuno | I tend to wait until series are past the 3rd season | 04:43 |
| beuno | so then, when I get addicted, I don't have to wait every week | 04:43 |
| pickscrape | Yeah, it's always a shame when there's nothing left of a good show to see. | 04:44 |
| pickscrape | beuno: lp:~pickscrape/loggerhead/directory_breadcrumbs | 04:50 |
| * beuno branches | 04:51 | |
| pickscrape | The other thing is, the file view appears to have a special case for when it is being run as part of launchpad. I've left that part alone. | 04:51 |
| beuno | oh, yeah, don't worry about that | 04:52 |
| beuno | pickscrape, so, I *love* the way it works now | 05:02 |
| beuno | I'll start poking at the "am I starting at the root" problem | 05:02 |
| pickscrape | Cool :) | 05:03 |
| beuno | and, I'm thinking we should drop the "viewing path/dir..." nonsense | 05:03 |
| pickscrape | I just need it to drop the (root) when the root is a branch. | 05:03 |
| beuno | and just make the whole thing a path | 05:03 |
| pickscrape | Yes, I was wondering about that too. | 05:03 |
| beuno | and maybe even make the revision number a link | 05:03 |
| beuno | because my instinct tells me that that should be clickable too | 05:04 |
| pickscrape | I just wonder if there should be some way to make it clear to the user what part of the path was the branch directory itself. | 05:04 |
| beuno | (for consistency's sake) | 05:04 |
| pickscrape | beuno: I found myself trying to click the revision number too :) | 05:04 |
| pickscrape | Then again, I'm not really sure where it should go | 05:04 |
| beuno | pickscrape, maybe a different color for the branch within the path? | 05:04 |
| beuno | or underlined? | 05:05 |
| pickscrape | I hate choosing colours :) My other thought was underlined. | 05:05 |
| beuno | or path == not bold, branch == bold | 05:05 |
| beuno | I think the revision number should go to "revision/$revno" | 05:06 |
| pickscrape | I actually like the current bold styling, as it is. Having said that, making it not bold makes it fit better horizontally for longer paths | 05:06 |
| beuno | where everywhere else links to | 05:06 |
| pickscrape | Yes, for the file_id that is currently being viewed. I like that. | 05:08 |
| beuno | hm | 05:08 |
| beuno | if you serve from: /code | 05:09 |
| beuno | and the branch is in: /code/coolstuff/loggerhead | 05:09 |
| beuno | then root goes back to /code | 05:09 |
| pickscrape | Yes | 05:09 |
| pickscrape | Since that's your root | 05:09 |
| beuno | what do you think of going even further, and making the breadcrumbs have the full path? | 05:09 |
| pickscrape | It goes as far as it can. | 05:10 |
| pickscrape | If you want to be able to browse the full filesystem, just run serve-branches / | 05:10 |
| beuno | rightoh, wait, ignore me | 05:11 |
| beuno | it works as I expected | 05:11 |
| beuno | I just need to pay more attention :) | 05:12 |
| beuno | let me see how we can work out this serve-from-root thing | 05:12 |
| pickscrape | If you're in a similar timezone to me, it being late is a good excuse ;) | 05:12 |
| beuno | it's 1am, not sure I can use that excuse yet | 05:12 |
| pickscrape | It's 11PM here, and I'd have no qualms about using it being late as an excuse already :) | 05:13 |
| beuno | hahah | 05:13 |
| beuno | good, then it's because it's late :p | 05:14 |
| pickscrape | Then again I was woken up by my son at the usual time of about 7:15 this morning. | 05:14 |
| beuno | right, and I... well... my dog got hungry around 1pm, and poked me with his cold nose | 05:14 |
| pickscrape | hehe :) | 05:15 |
| beuno | pickscrape, got it! | 05:29 |
| beuno | what was the other use case? | 05:29 |
| beuno | pickscrape, add: tal:condition="python:updir" | 05:29 |
| beuno | to the root bit | 05:29 |
| beuno | I'm already checking if we're at the top level | 05:30 |
| beuno | well | 05:30 |
| beuno | hm | 05:30 |
| beuno | no | 05:30 |
| beuno | that won't work | 05:30 |
| pickscrape | The problem is if you're not at the top level, but the branch is. | 05:30 |
| pickscrape | In that case the (root) link basically needs to go away. | 05:30 |
| beuno | pickscrape, hrm, also, the link is also invalid for the branch nick | 05:32 |
| beuno | because it builds a path, etc | 05:34 |
| pickscrape | Ah yes, so it does | 05:34 |
| beuno | so, two problems to fix now :) | 05:34 |
| pickscrape | Ah, no still one problem | 05:35 |
| pickscrape | if you edit inventory_ui.py, and change line 80 to be if True: | 05:35 |
| pickscrape | The link is correct | 05:35 |
| beuno | I see, you already have a plan to override | 05:36 |
| pickscrape | And that's the if that needs the 'is our root a branch?' question answering. | 05:36 |
| pickscrape | Yes, the code to handle both scenarios is already in place | 05:36 |
| pickscrape | Just needs the actual fact determining :) | 05:36 |
| pickscrape | It's late: I've already forgotten what my own code does :p | 05:37 |
| pickscrape | I need to go to bed now anyway: he'll be up at the crack of dawn tomorrow as well :) I'l read back here when I wake up tomorrow. | 05:38 |
| pickscrape | Thanks for you help! | 05:38 |
| beuno | pickscrape, I'll try and fix and push | 05:39 |
| beuno | you're welcome, and thanks for working on this :) | 05:40 |
| ml | hi, anybody here intimately familiar w/ the bzr installer for Mac OS? | 05:54 |
| meteoroid | if i set a commit hook or somesuch like for cia, say, or an email, in a bzr branch, does it travel with the branch, or only apply to that copy? | 07:05 |
| xshelf | does making socket reads async and having multiple threads pulling different changeset make bzr faster for pull or clone? | 07:06 |
| meteoroid | zshelf: it would depend on many factors.. | 07:07 |
| xshelf | I am yet to see a multi-threaded scm | 07:07 |
| meteoroid | heavy threading is more beneficial on highly multicore systems.. | 07:07 |
| * meteoroid has thought a lot about that | 07:07 | |
| meteoroid | i'm on 8-core now and looking at moving soon to a 16-core box | 07:07 |
| meteoroid | when i have 30-50 checkouts to make for a deployment i'd love some concurrency | 07:07 |
| meteoroid | esp if i could do a thread per repo / server | 07:07 |
| xshelf | home PC now have multi core or hyper threading | 07:08 |
| meteoroid | oh i know i'm just saying even with 2-core or 4-core with other things running, sometimes it's not a big deal to lack threading.. | 07:08 |
| meteoroid | but when you have an idle box with 8 or 16 cores, as i sometimes have, and a ticking clock on a systems update, concurrency could be awesome. :) | 07:08 |
| meteoroid | and yeh even a low-end multicore box relatively idle | 07:08 |
| xshelf | so, one can safely assume a majority of users have 1+ core (virtual) | 07:08 |
| meteoroid | well assume, no, assume likely, yes | 07:09 |
| meteoroid | performing poorly with one core would be bad, imo | 07:09 |
| xshelf | we can always have a flag to run in single threaded mode | 07:09 |
| meteoroid | sure. | 07:09 |
| meteoroid | fair enough :) | 07:09 |
| meteoroid | i like the way you think! | 07:09 |
| meteoroid | too bad my opinion doesn't matter for bzr ;d | 07:10 |
| meteoroid | yet! | 07:10 |
| xshelf | I had a tool to fetch source from CVS using CVSweb frontend as I was behind firewall | 07:10 |
| meteoroid | ouch | 07:10 |
| meteoroid | sounds painful | 07:10 |
| xshelf | It was a 2 day hack and I had all such fancy features! | 07:10 |
| * meteoroid doesn't doubt it | 07:10 | |
| xshelf | i managed to host that on savannah too and got people using it | 07:11 |
| meteoroid | good for you! | 07:11 |
| xshelf | Another idea: With all the distribution and duplication of changesets, would a bittorrent like approach improve speed? | 07:12 |
| meteoroid | well for large projects, perhaps.. not sure it's a change worth forcing on everyone | 07:13 |
| xshelf | ok | 07:14 |
| meteoroid | esp for projects with tons of readers vs. writers ratio | 07:14 |
| meteoroid | but also the DSCM approach helps | 07:14 |
| meteoroid | you can have a local master pass-through | 07:14 |
| xshelf | in a torrent like setup, you can pull bits (few changesets) from different machines. | 07:15 |
| xshelf | I just did a google, found an rfc: gittorrent | 07:15 |
| markh | multi-cores/threads would also only help if the network was fast enough that your cpu was working at 100% - otherwise asynch would do | 07:16 |
| meteoroid | sure.. again for something like linux it might make sense, but for other things a pass-through is even handier. | 07:16 |
| meteoroid | markh: well async can also be used to traffic cop for threads | 07:16 |
| meteoroid | you dont' have to peak each core to take adv of threads | 07:16 |
| lifeless | so | 07:16 |
| meteoroid | you lose some cpu cache opt from context switches but you can swap out with other stuff and still be faster.. | 07:16 |
| lifeless | actually git does some threading, but its a work around for design deficiencies | 07:17 |
| meteoroid | a lot of network-dependent apps spend time waiting | 07:17 |
| markh | no - but your total throughput will not improve unless the cpu is at 100% | 07:17 |
| meteoroid | so if you do 50 checkouts in one thread that waiting all stacks up in one time dimension | 07:17 |
| meteoroid | markh: again not true if you are able to put more in wait | 07:17 |
| meteoroid | you don't need 100% cpu for each thread | 07:17 |
| lifeless | bzr is generally latency and network bound over the network | 07:17 |
| meteoroid | you can have 8 cores and 20 threads if each is spending a lot of time in wait | 07:17 |
| markh | a true asynch framework would mean you can have as many as you want running, and none of them blocking | 07:17 |
| lifeless | e.g. twisted | 07:17 |
| lifeless | :P | 07:17 |
| meteoroid | :) | 07:17 |
| markh | exactly ;) | 07:17 |
| lifeless | anyhow | 07:18 |
| meteoroid | we're arguing about the same thing i think ;d | 07:18 |
| xshelf | how about stackless? | 07:18 |
| markh | not many high-perf network bound apps scale via threads | 07:18 |
| meteoroid | i'm just saying you don't need to peak each cpu | 07:18 |
| lifeless | we chose in bzr to write synchronous code to make it more understandable and approachable for contributors | 07:18 |
| xshelf | twisted makes you create a whole lot of processes | 07:18 |
| meteoroid | if there are a lot of requests happening, there's a lot of latency | 07:18 |
| lifeless | async code abstractions leak in various ways | 07:18 |
| meteoroid | and you can juggle more threads than cores | 07:18 |
| lifeless | some of the core of bzr uses threads | 07:18 |
| meteoroid | python threads? ;) | 07:19 |
| meteoroid | like zope. ahh.. zope.. | 07:19 |
| meteoroid | one process per thread zope.. | 07:19 |
| markh | threads are both easy and very cool - don't get me wrong ;) | 07:19 |
| meteoroid | er per core.. | 07:19 |
| xshelf | i just did a 'bzr pull --profile' on emacs | 07:19 |
| markh | easy compared to asynch programming ;) | 07:19 |
| meteoroid | well i mean with twisted generally you mix both.. | 07:19 |
| lifeless | xshelf: if you're interested in performance work on bzr | 07:19 |
| meteoroid | you respond to events in the main interpreter by launching events in thread via C so they don't depend on GIL | 07:19 |
| xshelf | The top consumer: 406/265 1848.725 4.554 1848.744 6.976 socket.py:278(read) | 07:19 |
| lifeless | xshelf: can I suggest you strt with the btree index plugin and ensure you have 1.6rc1 too | 07:20 |
| xshelf | lifeless: I love to work on bzr, I know almost nothing in python | 07:20 |
| markh | yeah - true asynch is *very* hard. A dedicated thread that does nothing but IO, and everything via waiting for the OS to tell you a request is complete. Less threads == less OS overhead in moving the bits off the wire. Then you actually have to do something with the bits, which is where it gets more complicated ;) | 07:20 |
| xshelf | lifeless: : My daytime job revolves around performance improvements too | 07:21 |
| lifeless | xshelf: cool | 07:21 |
| lifeless | xshelf: so I'm doing a lot of performance work | 07:21 |
| lifeless | xshelf: my current focus is a new compressor with the goal of reducing the amount that has to be sent over the network | 07:22 |
| lifeless | but there are several endemic performance issues | 07:23 |
| xshelf | lifeless: I have seen that and that really does not make too much of a difference with current network speeds | 07:23 |
| lifeless | xshelf: bzr branch for me saturates the network | 07:24 |
| xshelf | lifeless: I worked at McAfee and did some real speedups | 07:24 |
| lifeless | xshelf: so reducing the data sent be 60% will make a huge difference | 07:24 |
| lifeless | cool | 07:24 |
| lifeless | anyhow | 07:24 |
| lifeless | we have a variety of issues | 07:24 |
| xshelf | lifeless: I agree, 60% is big saving | 07:24 |
| lifeless | some are algorithmic | 07:24 |
| lifeless | working tree operations take time proportional to the number of files that are versioned | 07:25 |
| lifeless | so do any operation on historical trees - we have to generate an in memory object called an inventory, which is essentially the entire directory structure | 07:25 |
| lifeless | being able to do partial operations on that could make a significant difference | 07:25 |
| lifeless | and the repository size issue I mention | 07:26 |
| xshelf | point me to a good bzr architecture doc, I will start looking into it | 07:26 |
| lifeless | the new b+tree indices are 30% of the current index size | 07:26 |
| lifeless | hmm, some operations unnecessarily look at the entire network graph which is another issue | 07:26 |
| lifeless | e.g. time 'bzr log | head -n 1' | 07:27 |
| lifeless | vs time 'bzr log --line | head -n 1' | 07:27 |
| xshelf | Yes, I raised that issue on emacs list when talking on moving to bzr | 07:27 |
| lifeless | xshelf: there are various docs in doc/developer and the wiki; but most of the things that need fixing are in discussion on the bzr mailing list | 07:27 |
| xshelf | that is the first command I type after a pull and it took quite some time | 07:27 |
| xshelf | lifeless: I will join the list, which one should I be joining | 07:28 |
| lifeless | yeah | 07:28 |
| lifeless | http://lists.canonical.com/mailman/listinfo/bazaar | 07:29 |
| xshelf | will join right away | 07:29 |
| xshelf | i was working on hg, since emacs might just use bzr, I might invest in bzr | 07:30 |
| lifeless | some good folk to chat to - | 07:30 |
| lifeless | andrew bennetts does networking - spiv on irc | 07:30 |
| lifeless | I do low level storage as well as algorithmic higher level stuff | 07:30 |
| lifeless | jam is similar to me - thats John A Meinel | 07:31 |
| xshelf | ok, algorithms are over head for me :-( | 07:31 |
| xshelf | I do not have formal computer science background... | 07:31 |
| lifeless | thats fine | 07:32 |
| xshelf | i will do my best | 07:32 |
| meteoroid | xshelf: algorithm is just a fancy word for "way to solve a problem", and also a name for an entire formal branch of science / mathematics ;d | 07:32 |
| xshelf | lifeless: I realize that but I have failed in some interviews just because they ask an algo by a name and I will not be knowing it | 07:33 |
| xshelf | lifeless: In some places (Yahoo), they asked me to solve and I was able to! | 07:34 |
| xshelf | lifeless: Google asks many such algos by name | 07:34 |
| lifeless | meh | 07:35 |
| lifeless | simple memory is not a good indicator for aptitude IMO | 07:35 |
| lifeless | it may indicate regular activity in an area | 07:35 |
| lifeless | but my brain routinely pages shit out | 07:35 |
| xshelf | lifeless: That is most important | 07:36 |
| xshelf | lifeless: Anyway, I am now in a place where I get to learn and play with things I am interested in (NetApp) | 07:36 |
| lifeless | nice | 07:37 |
| lifeless | WAFL is quite interesting | 07:37 |
| markh | lifeless: do you happen to know if there is an implication repo.bzrdir.transport.local_abspath() should return a local_abspath with native backslashes on Windows? It currently returns "/" and tests are failing due to it. I'm wondering if I should focus on fixing local_abspath() or just hacking the tests to call os.path.abspath()? | 07:49 |
| lifeless | all internal paths should be / using | 07:49 |
| markh | yeah - but the name of "local_abspath() kinda implied it was an external interface | 07:49 |
| lifeless | AFAIK all os functions will work | 07:50 |
| markh | ie, it is converting from internal to external | 07:50 |
| markh | yeah - I understand that - just wondering what the abstraction was supposed to be | 07:50 |
| lifeless | markh: if its still in python its internal :) | 07:50 |
| markh | :) fair enough - so I'll fix the tests ;) thanks! | 07:50 |
| === samurai_ is now known as samurai | ||
| xshelf | lifeless: I got bumped due to drop in network | 08:12 |
| xshelf | lifeless: I have joined the bazaar mailing list and looking forward | 08:13 |
| lifeless | cool | 08:14 |
| Peng_ | FWIW, if the last message you saw was from 06:50:47 (it being 07:14 now), you didn't miss anything. | 08:14 |
| lifeless | I'm off for the night | 08:17 |
| lifeless | ciao | 08:17 |
| Peng_ | Good night. | 08:19 |
| === bronger is now known as Bronger | ||
| === Bronger is now known as bronger | ||
| === bronger is now known as Bronger | ||
| === Bronger is now known as bronger | ||
| xshelf | login | 11:40 |
| markh | if I do a merge that conflicts and leaves conflict markers, is it expected that the first 7 lines in the markers will be identical? | 12:09 |
| xshelf | ot: I have heard bzr has the best merge code, if that is true, would it be possible to have a stand alone merge that can be used through scripts? | 12:12 |
| Pieter | markh: did you check for whitespace differences? e.g. tabs vs spaces | 12:19 |
| markh | Pieter: I suspect that might be the case for eol markers (I'm on Windows) - but I suspect that these have been normalized in the file with the conflict markers, masking the error. | 12:21 |
| markh | (ie, it all looks fine in the file with the markers, but the source of the merge may have different eol markers) | 12:21 |
| markh | s/eol markers/eol settings/ | 12:22 |
| markh | *sigh* - the file with the conflict markers looks fine. The source of the merge leading to the conflict markers may have had different EOL style leading to what I see. | 12:23 |
| markh | too many branches, too little time ;) | 12:24 |
| mlh | xshelf: yeah I think so .. I know it's been asked before and the response is in the affirmative | 12:30 |
| mlh | but don't knw the details | 12:30 |
| mlh | you'll have to wait for bzr dev | 12:30 |
| mlh | 'a' bzr dev | 12:30 |
| Pilky | Is there any way to send authentication details inline with a command? eg "bzr branch lp:myproj --password mypass" or something like that | 12:50 |
| xshelf | is there any hack to use bzr-fastimport with perforce? | 12:51 |
| xshelf | lifeless: I was reading you entries on advogato on persistent b+tree/hashtable from python. Ever considered Berkeley DB? | 13:14 |
| rocky|away | jelmer: fyi, committing to a bzr-svn svn trunk is still very very slow | 13:15 |
| gnomefreak | im guessing bzr-svn wsa never fixed? | 13:19 |
| rocky|away | jelmer: to commit 7 file's changes (certainly not totalling > 2k) took 1m27s according to unix time command | 13:19 |
| gnomefreak | rocky|away: mines crahsing | 13:19 |
| === rocky|away is now known as rocky | ||
| gnomefreak | has been for a month or so | 13:19 |
| rocky | which version you using? i'm on ubuntu hardy heron running bzr-svn 0.4.10, svn 1.5, bzr 1.5 | 13:21 |
| gnomefreak | 0.4.10-2 | 13:28 |
| gnomefreak | 1.5 bzr | 13:28 |
| rocky | which os ? | 13:30 |
| gnomefreak | ubuntu | 13:32 |
| rocky | i don't know what to say, it works for me ... it's just very slow | 13:34 |
| jonnydee | hello, I'd like to create a .deb package of a bazaar plugin for PPA. can someone point me to related documentation or give me some hints? It's my first packaging trial, so I'm a novice regarding packaging. At the moment I'm reading https://wiki.ubuntu.com/PackagingGuide/Complete as suggested by https://help.launchpad.net/PPA... | 14:39 |
| Leefmc | Question: I added a file by mistake, how do i remove it before a commit? I dont really wanna comit it. | 16:49 |
| sabdfl | Leefmc: try bzr rm? | 16:51 |
| sabdfl | hmm... bzr rm --keep | 16:52 |
| Leefmc | sabdfl: Makes sense, and i thought of that, but oddly enough i dont see bzr rm in the bzr command list.. am i blind? I typed "bzr" and it gave me a list of commands, yet "bzr rm" is not on there.. is it? | 16:52 |
| sabdfl | "bzr help commands" will give you a more detailed list | 16:53 |
| sabdfl | remove is there | 16:53 |
| sabdfl | and i believe rm is an alias for that | 16:53 |
| sabdfl | cheers | 16:53 |
| Leefmc | k thanks | 16:54 |
| === sm_ is now known as sm | ||
| === cody-somerville_ is now known as cody-somerville | ||
| beuno | jelmer, ping | 20:35 |
| beuno | jelmer, bzr-upload has been accepted, and I'm poking the DD to upload bzr-search now | 20:43 |
| thorwil | i got a bzr: ERROR: exceptions.MemoryError: and filed a bug with traceback. but now i wonder how to fix the upload | 21:00 |
| thorwil | as on pushing again, i get [Errno 39] Directory not empty | 21:01 |
| thorwil | dang, gotta go | 21:07 |
| Adri2000 | hi | 21:56 |
| Adri2000 | when I merge one revision from another branch, and then commit, the commit message of the revision I merged doesn't appear in bzr log, can I change that? | 21:57 |
| edcrypt | Adri2000, the commit msg should appear on the log of the branch you merged *to* -- is this what you are doing? | 22:28 |
| Adri2000 | yes | 22:28 |
| Adri2000 | but it doesn't appear | 22:28 |
| pickscrape | Adri2000: did you merge using bzr merge -r ? | 22:28 |
| Adri2000 | it does appear if I merge more than one revision, but not if I merge only one | 22:29 |
| Adri2000 | yes, or -c | 22:29 |
| pickscrape | Yes, in that case you're just merging the patch, and not the actual revision. | 22:29 |
| pickscrape | As I understand it, tracking of cherry pick merge meta data isn't implemented yet | 22:29 |
| Adri2000 | it should work with -rRev1..Rev2? I though I tested that as well | 22:29 |
| Adri2000 | thought* | 22:29 |
| pickscrape | It only tracks if you don't specify any revisions at all | 22:30 |
| pickscrape | If you use -r (or -c), all that happens is that the patch of the revisions you specify get applied to your working tree | 22:31 |
| Adri2000 | ah indeed, so the only case where the commits are shown in the log is when you merge a branch completely | 22:33 |
| pickscrape | Yes, because that's the only case where it has the merge metadata. | 22:33 |
| Adri2000 | actually merging a branch up to revision X (-r X) brings the commit messages. so it's just cherry-picking one or multiple commits that doesn't | 22:35 |
| Adri2000 | pickscrape: and you say that may be implemented in the future? | 22:36 |
| pickscrape | I've heard that it is planned, though I don't know anything about when | 22:36 |
| Adri2000 | ok | 22:37 |
| === rocky is now known as rocky|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!