| ricosecada | Hi. I am just in the process of migrating from cvs to bzr. I have a debian server just running sshd. On cvs I normally just specify a CVSROOT variable which points to the server, and after doing an init on the server it is set up. I can't seem to figure out, if its possible to run bzr the same kindda way? | 00:23 |
|---|---|---|
| fullermd | Well, there's no CVSROOT equivalent; the concept doesn't map. But you get a CVS-like workflow using checkouts. | 00:31 |
| fullermd | You just have to specify the full remote URL when you do the checkout. | 00:33 |
| ricosecada | fullermd, do I have to specify the url when I do commits as well then? | 00:35 |
| Odd_Bloke | ricosecada: No, your branch will remember where it is checked-out from. | 00:36 |
| fullermd | No, any more than you need to specify the module or have $CVSROOT set when you do a CVS commit. | 00:36 |
| ricosecada | since the server is running ssh, what would the complete command look like? | 00:37 |
| ricosecada | with the url | 00:37 |
| fullermd | bzr+ssh://server/path/on/server/ (or sftp:// if you can't get bzr running on the server) | 00:37 |
| ricosecada | aah :-) | 00:38 |
| lifeless | e.g. bzr checkout bzr+ssh://server/path/on/server/ | 00:38 |
| fullermd | Hm. That reminds me; we have a bug open for "No ~ on bzr+ssh", right? | 00:38 |
| lifeless | yes | 00:38 |
| fullermd | That's one of the sort of things I'd put on the "rough edges that 1.0 shouldn't like" list. | 00:39 |
| fullermd | Little and rather piddly stuff, but it makes you frown. | 00:40 |
| ricosecada | do I need to specify the BZR_REMOTE_PATH anywhere? | 00:42 |
| lifeless | only if bzr is not in the usual place | 00:42 |
| tanderson | So if I want to start a new project using bzr I can store my project in a location accessible via my webserver to allow anyone to do a checkout via bzr http://... right? | 00:44 |
| lifeless | yes | 00:45 |
| lifeless | though anonymous users will usually use bzr branch | 00:45 |
| tanderson | I see | 00:46 |
| ricosecada | are there any specific packages needed to use bzr with ssh? | 00:49 |
| lifeless | ricosecada: install the recommends: | 00:49 |
| ricosecada | lifeless, I did. I can do a checkout from the ssh server fine now, but when I try to commit I get this bzr: ERROR: exceptions.AssertionError: end of file reading from server | 00:49 |
| tanderson | And if a developer wanted to work on this project and did an initial checkout/branch via bzr http://.... I would need to install the webdav plugin to allow them to commit back to http:// right? | 00:50 |
| ricosecada | looks like a bug | 00:56 |
| lifeless | ricosecada: hmm, there are some bugs open | 00:57 |
| lifeless | ricosecada: its likely the permissions error bug, we mis-represent a permissions error sometimes | 00:57 |
| ricosecada | and I was just beginning to enjoy this :-) | 00:57 |
| lifeless | ricosecada: you could try sftp:// with the same url; it might give a better diagnostics | 00:57 |
| ricosecada | I'll try that | 00:58 |
| ricosecada | lifeless, it works fine with sftp | 00:59 |
| ricosecada | no errors | 00:59 |
| fullermd | What version do you have on the client and server sides? | 00:59 |
| ricosecada | on the client 0.91.0 on the server 0.11.0 | 01:00 |
| fullermd | Wuff. | 01:00 |
| ricosecada | I am running debian testing on the client and stable on the server | 01:01 |
| ricosecada | but its ok when its working with sftp | 01:01 |
| fullermd | I think 0.11 supported bzr+ssh (though it was brand new then). But it didn't support dirstate-tags branches, which I guess you have. | 01:01 |
| fullermd | sftp doesn't use bzr on the server side at all. | 01:02 |
| abentley | ricosecada: For bzr+ssh compatibility, I'd recommend something much more recent. That support has been evolving rapidly lately. | 01:02 |
| ricosecada | I will perhaps upgrade the bzr packages on the server | 01:03 |
| ricosecada | one more question, I have been searching for the variables like $author$ and $id$ to insert in the files. would someone mind pointing me in the direction to doc on that? | 01:04 |
| fullermd | That's filed under "keyword expansion". Support doesn't exist yet. | 01:04 |
| ricosecada | ok | 01:05 |
| ricosecada | I upgraded bzr on the server - no bugs now | 01:16 |
| lifeless | ricosecada: fullermd failed to mention 'bzr version-info --help' | 01:25 |
| lifeless | ricosecada: this is in many ways technically superior - its simpler, works with binaries as well as sources, etc. | 01:26 |
| ricosecada | ok | 01:26 |
| ricosecada | I am running 0.91 on both server and client now | 01:26 |
| ricosecada | I do miss the keyword expansion though | 01:26 |
| fullermd | Hm. That reminds me, I should rewrite some scripts to use revision-info | 01:26 |
| lifeless | ricosecada: we have no moral objection to it, and will eventually do it for folk that want the bad ol' days :) | 01:27 |
| * fullermd is one who wants the bad ol' days ;) | 01:27 | |
| ricosecada | :-) | 01:27 |
| fullermd | WAG'ing from the current active lists, I'd be surprised if we saw it before next summer at the earliest. | 01:28 |
| fullermd | Probably farther out than that. | 01:28 |
| lifeless | abentley: I find working with [NULL_REVISION] rather than [], to be quite annoying. As we have None to represent 'not here', all it really means is that [] is *never* used | 01:28 |
| abentley | lifeless: Well, in theory it would be used for get_parents(NULL_REVISION) | 01:30 |
| lifeless | abentley: I'm not saying NULL_REVISION shouldn't exist. just that having end-of-graph be coerced to it is extra typing and logic | 01:30 |
| lifeless | I appreciate NULL_REVISION having to exist to differentiate unpassed parameters (None), and NULL_REVISION itself. | 01:31 |
| lifeless | anyhow, I may be wrong, there may be some point where it turns out to be useful, so I'm using it. | 01:31 |
| jelmer | abentley: btw, any particular reason Repository.get_parents() uses self.get_revision(x).parent_ids rather self.revision_parents() ? | 01:32 |
| jelmer | my guess would be that revision_parents() is intended to be deprecated, but it's not marked as such (yet) | 01:32 |
| lifeless | jelmer: I think you'll find knit and pack repos have a different get_parents, and also see Repository.get_graph. | 01:34 |
| abentley | lifeless: Well, I was thinking two things: 1. the graph is more accurate with NULL_REVISION in it. 2. I've seen what a pain it is when we don't use NULL_REVISION enough, so let's try erring on the other side. | 01:34 |
| jelmer | lifeless: Still, it would be nice to have a fast default implementation | 01:35 |
| lifeless | jelmer: for jbof repositories, get_revision.parent_ids is fast | 01:35 |
| lifeless | jelmer: there really is no well defined 'fast' :) | 01:35 |
| jelmer | lifeless, revision_parents() will always be faster I imagine, as it is more specific | 01:35 |
| jelmer | since the information it returns is a subset of the information returned by get_revision() | 01:36 |
| jelmer | *faster or same speed | 01:36 |
| lifeless | sure I guess | 01:36 |
| lifeless | just saying, check around a bit | 01:36 |
| lifeless | if you come to a conclusion, send a patch | 01:36 |
| jelmer | sure, will do | 01:37 |
| abentley | jelmer: frankly, I don't remember. I may have been thinking that for weave repos, the implementation just needed to be correct, not fast. | 01:38 |
| lifeless | abentley: if so, revision_parents has the same constraint though; also weaverepo.py can handle that. (Not critiquing, just noting) | 01:39 |
| abentley | Oh, what about ghosts? Weaves don't record ghost parents. | 01:45 |
| lifeless | a weave will return [NULL_REVISION] when it shouldn't | 01:53 |
| abentley | Sounds like a bug. Do you know where it is? | 01:54 |
| lifeless | my point is that weaves can't tell [] from [NULL_REVISION] | 01:55 |
| lifeless | so they can't choose to return [] instead of [ghost], so any mapping will just preserve the defect | 01:55 |
| lifeless | you have to go out to the real data to tell; and if you do that you can return [ghost] correctly anyway | 01:56 |
| abentley | Are we talking about jelmer's thing or your thing? | 02:02 |
| lifeless | my thing | 02:04 |
| lifeless | sorry for adduing confusion | 02:04 |
| abentley | The implementation of get_parents for weaves does hit the real data. | 02:05 |
| Peng | bzr.dev reconcile took 356 minutes wall-clock time, 305m user time and 44m sys time. | 02:05 |
| lifeless | Peng: yah | 02:06 |
| lifeless | Peng: newer one is nearly done | 02:06 |
| lifeless | I have _generate_text_key_index written | 02:06 |
| lifeless | just need to hook in the LRU cache | 02:07 |
| lifeless | damn its not too shabby | 02:09 |
| lifeless | 2K/36K done | 02:09 |
| lifeless | -no cache- | 02:09 |
| lifeless | 4K | 02:09 |
| lifeless | ok, I'm out for the day. damn 4am starts :) | 02:10 |
| lifeless | I'll send this in for review but not merge. | 02:10 |
| lifeless | 80M memory usage | 02:10 |
| Peng | vs. 7 GB? | 02:11 |
| Peng | Or whatever it was? | 02:11 |
| lifeless | this is bzr.dev | 02:11 |
| lifeless | so you were seeing how much yesterday? | 02:11 |
| lifeless | 6.5K | 02:11 |
| lifeless | 8K | 02:12 |
| lifeless | 12K | 02:15 |
| Peng | Didn't you mention that it used like 7 GB of virtual RAM? | 02:17 |
| lifeless | that was launchpad | 02:17 |
| Peng | Oh. | 02:17 |
| lifeless | I'm testing that now | 02:17 |
| lifeless | it's using 88M | 02:17 |
| Peng | Ooh, bzr check is almost done. | 02:17 |
| Peng | Wow. | 02:17 |
| Peng | Umm. | 02:18 |
| Peng | There are MORE inconsistent parents since running reconcile. | 02:18 |
| lifeless | okies, I'm happy with this. | 02:18 |
| Peng | Well, I made another commit, so that's probably that. | 02:18 |
| lifeless | Peng: using what bzr version ? | 02:18 |
| Peng | bzr.dev. | 02:18 |
| lifeless | thats bizaare | 02:18 |
| lifeless | bzr.dev won't create inconsistent parents | 02:18 |
| Peng | Hee, 19,996 unique file texts. | 02:18 |
| Peng | Well, the increase is probably because I made another commit. | 02:19 |
| Peng | But reconcile definitely didn't help. | 02:19 |
| lifeless | not if you committed using bzr.dev | 02:19 |
| Peng | Oh, I didn't commit using bzr.dev. | 02:20 |
| Peng | I only used bzr.dev for reconcile and check. | 02:21 |
| Peng | Wasn't bzr.dev's check supposed to fix this? | 02:22 |
| lifeless | do you mean reconcile? | 02:22 |
| lifeless | and I thought you converted to packs. ... | 02:22 |
| Peng | I still had the knit version around. | 02:23 |
| Peng | So I ran reconcile on it. | 02:23 |
| lifeless | ok | 02:26 |
| Peng | And it didn't help. | 02:26 |
| lifeless | well bzr.dev reconcile is meant to correct mismatched texts, but IIRC it keeps unreferenced and unused texts around just in case. | 02:26 |
| Peng | I can successfully push, so I should just keep all of the messed up parent stuff? | 02:28 |
| lifeless | with packs? I'd keep a backup of the knit repo just-in-case. Until I can have you run a native reconcile I'm just a tad cautious is all. | 02:29 |
| Peng | I'm planning to keep a backup of the knits. | 02:29 |
| lifeless | ciao | 02:33 |
| Peng | This is making my head hurt. | 02:33 |
| lifeless | ignore it | 02:35 |
| lifeless | use the packs | 02:35 |
| lifeless | enjoy the packs | 02:35 |
| lifeless | and don't delete the knit copy for now:) | 02:35 |
| Peng | Uh-huh. | 02:35 |
| Peng | "Don't worry about the errors. Have fun. But don't delete your backup." I'm so confident. :P | 02:36 |
| lifeless | they are a trivial defect 99.99% of the time | 02:37 |
| lifeless | the only place we *know* to be affected by the non-trivial case is bzr.dev, from the bad ole weave days | 02:38 |
| lifeless | another day or so and a clean pack reconcile should be available | 02:38 |
| lifeless | and I'll get you to run that | 02:38 |
| Peng | Okie-dokie. :) | 02:38 |
| * igc lunch | 02:43 | |
| abentley | Am I correctly understanding that we have no general way of fetching between repositories whose serializers differ? | 02:47 |
| lifeless | none hooked up commitbuilder is probably the closest thing | 02:48 |
| lifeless | that was one of its intents | 02:48 |
| abentley | Hmm. Bundles can do it, though. | 02:55 |
| abentley | I'm having trouble parsing "none hooked up commitbuilder" | 02:55 |
| lifeless | i ,but | 02:56 |
| abentley | I beg your pardon? | 03:01 |
| lifeless | none hooked up, but commitbuilder is probably the closest thing | 03:03 |
| lifeless | i starts insert mode in vim ;) | 03:03 |
| abentley | Gotcha. | 03:12 |
| abentley | I would think it's cheaper to deserialize and reserialize than to run through CommitBuilder. But I guess CommitBuilder handles the case where more than the serializer differs. | 03:16 |
| lifeless | right; AFAIK we have no cases where the serializer is the only difference | 03:26 |
| lifeless | (today) | 03:26 |
| ricosecada | Hi. How does bzr handle binary files? | 04:16 |
| AfC | ricosecada: uh, correctly? | 04:17 |
| ricosecada | Afc, and how is that? | 04:17 |
| fullermd | I was gonna say "with heavy leather gloves and 4 foot tongs"... | 04:21 |
| Peng | Wow. The local repo that I converted to packs is a 225 MB .pack file. But when pushing it, it's a bit less than 200 MB. That's a lot of space wasted by revisions I had uncommitted. | 04:44 |
| AfC | Whoa. `bzr viz` in bzr-gtk 0.92.1 is _really_ sexy | 04:54 |
| ricosecada | Does bzr allow one to checkout a single directory with a repos? | 04:58 |
| Peng | Nope. | 04:59 |
| Peng | I don't think any of the DVCSes do. It would be a little tricky. | 05:00 |
| ricosecada | Some of them does: http://better-scm.berlios.de/comparison/comparison.html#work_on_dir | 05:03 |
| * Peng has fun deleting gigabytes of data. | 05:12 | |
| lifeless | lol | 05:30 |
| lifeless | ricosecada missed that all of those that said yes, were not (D)VCS | 05:30 |
| lifeless | Peng: ? | 05:30 |
| Peng | I had a bunch of copies of everything from when I converted from bzr to hg. I just deleted most of them. | 05:39 |
| Peng | Well, anyway, the pack version of that other repository is working fine, not that I've done much of anything with it. | 05:45 |
| Peng | One commit. | 05:45 |
| fullermd | Well, when I was a kid, my parents told me that if I could keep the bike balanced all the way to the mailbox, I could keep it balanced for any distance. | 05:54 |
| fullermd | So by that logic, if it worked for one commit, it'll never fail :] | 05:54 |
| Peng | Ack. Duh, compressing a tar of compressed stuff doesn't help much... | 05:59 |
| Peng | Well, it saved 4 MB. | 06:00 |
| Peng | Out of 1.2 GB. | 06:00 |
| fullermd | Not bad. I've got a whole hard drive that would save... | 06:01 |
| Peng | Wait, way more than that. | 06:01 |
| Peng | 60 MB. | 06:02 |
| Peng | Anyway, unless p7zip can extract things *really* fast, that's not really worth it. | 06:03 |
| Peng | At least I can save a bunch of inodes. | 06:03 |
| abentley | jelmer: initial version of a rich-root repo format is here: http://code.aaronbentley.com/bzr/bzrrepo/rich-root | 06:18 |
| quicksilver | abentley: thanks. We're playing with it. | 06:53 |
| quicksilver | abentley: certain amount of yak shaving was involved in getting the rights versions of python and stuff, but that's computers for you. | 06:54 |
| Peng | Hey, I just pulled ~30 new changesets from bzr.dev and it only took like 10 seconds. How did that happen? | 07:03 |
| lifeless | no idea | 07:04 |
| fullermd | I'd guess you already had most of 'em. | 07:06 |
| fullermd | Actually, with that timing, near all.. | 07:06 |
| Peng | Ohh. You're right. | 07:06 |
| Peng | All of them were already in the repo because I had just pulled another branch. | 07:07 |
| ig1 | night all | 08:03 |
| mwhudson | can someone here explain what's required of a progress bar? | 11:15 |
| Kinnison | Ideally, indicate what's going on, progress evenly and monotonically giving a good indication of the amount of time consumed/remaining rather than number of tasks | 11:16 |
| mwhudson | ah, i was imprecise | 11:17 |
| mwhudson | i meant expected from a bzrlib point of view | 11:17 |
| mwhudson | i need to provide an alternative implementation, and wonder what methods i need to provide | 11:18 |
| Odd_Bloke | mwhudson: Checkout bzrlib.progress | 11:18 |
| Odd_Bloke | *Check out | 11:18 |
| Odd_Bloke | It has a base class and a number of implementations. | 11:19 |
| mwhudson | i guess i can just inherit from DummyProgress and override everything | 11:20 |
| === cprov-away is now known as cprov | ||
| === RichardL is now known as rml | ||
| === AnMaster_ is now known as AnMaster | ||
| mwhudson | gar, raising exceptions that hide other exceptions is pretty rude | 12:56 |
| === fo1 is now known as fog | ||
| howari | ls -la | 14:23 |
| jam-laptop | . | 14:44 |
| jam-laptop | .. | 14:44 |
| jam-laptop | foo | 14:45 |
| jam-laptop | bar/ | 14:45 |
| jam-laptop | howari: any other files? | 14:45 |
| Odd_Bloke | :D | 14:45 |
| === mwhudson_ is now known as mwhudson | ||
| === cprov is now known as cprov-lunch | ||
| === jam-laptop is now known as jam | ||
| jelmer | abentley: Cool, I'll have a look | 15:16 |
| sbalneav | Hello. I'm using bzr, and all of a sudden, I'm getting an error trying to do a commit. Is there a pastebin for this channel? | 15:17 |
| sbalneav | !pastebin | 15:17 |
| ubotu | pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic) | 15:17 |
| sbalneav | perfect | 15:17 |
| sbalneav | http://paste.ubuntu-nl.org/44622/ | 15:18 |
| sbalneav | Seems to be complaining that the branch is read-only. | 15:19 |
| sbalneav | Permissions are fine. However, it's on an NFS mounted home dir. Might that be the problem? | 15:20 |
| jelmer | sbalneav: you appear to be committing over http - is that intentional? | 15:20 |
| jelmer | it doesn't know how to send commits to the master branch using http | 15:20 |
| sbalneav | ah, wait. | 15:21 |
| sbalneav | maybe I did a bzr checkout instead of a branch? | 15:21 |
| jelmer | ah | 15:21 |
| sbalneav | Might that be it? | 15:21 |
| jelmer | That would explain it | 15:21 |
| sbalneav | durr | 15:22 |
| * sbalneav facepalms | 15:22 | |
| jelmer | you can unbind from the master branch using "bzr unbind" | 15:22 |
| jelmer | hey Szilveszter | 15:22 |
| phanatic | hey jelmer | 15:22 |
| sbalneav | ok, then just push back later with bzr push sftp://? | 15:22 |
| jelmer | yup | 15:23 |
| sbalneav | perfect. | 15:23 |
| jelmer | or bind to that branch using "bzr bind sftp://" and it will automatically push when you commit | 15:23 |
| sbalneav | ah, even better. | 15:23 |
| sbalneav | one of these days my bzr-fu will get to the point where I'm not so helpless :) | 15:23 |
| jelmer | sbalneav: well, I admit the error you got when committing to the checkout wasn't very helpful | 15:24 |
| sbalneav | Nah, makes sense now that I look at it. I was simply panicky after doing 1/2 hour of work :) | 15:25 |
| sbalneav | Didn't know about the bind tho'. That's a nice tip. | 15:26 |
| jam | jelmer, sbalneav: that error has been improved in 0.91 or 0.92 to not give the ugly traceback | 15:33 |
| jelmer | jam: ah, nice | 15:33 |
| jam | now you get a single line error: | 15:34 |
| jam | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Ebzr/bzr-cvsps-import/trunk/.bzr/repository/lock): Transport operation not possible: http does not support mkdir() | 15:34 |
| jam | It isn't perfect, but it does make it a lot more obvious | 15:35 |
| === fredp is now known as fredp-afk | ||
| === fredp-afk is now known as fredp | ||
| === fredp is now known as fredp-afk | ||
| === fredp-afk is now known as fredp | ||
| === fredp is now known as fredp-afk | ||
| sbalneav | Yeah, working fine now after the bind. | 15:50 |
| sbalneav | jelmer, jam, thanks muchly. | 15:50 |
| sbalneav | Cheers! | 15:50 |
| jam | happy to help | 15:50 |
| === fredp-afk is now known as fredp | ||
| === fredp is now known as fredp-afk | ||
| nelius | is it possible to push a branch to a samba share? | 16:53 |
| nelius | on a local fs it works, but on a samba share i get : bzr: ERROR: [Errno 5] Input/output error | 16:53 |
| jelmer | nelius: Sure, if you've mounted that share locally | 16:53 |
| beuno | nelius, absolutely, it's the same as pushing locally | 16:53 |
| jelmer | nelius: How have you mounted the share, and what is the server running? | 16:54 |
| nelius | my client is osx, i mounted is as smb:// from finder | 16:55 |
| nelius | the server runs samba 3 on sun os 9 | 16:55 |
| jelmer | I'm not sure how much of the POSIX extensions are implemented in OS X's smb implementation at this point | 16:56 |
| jelmer | nelius, Can you run with BZR_PDB=1 set and see what function is failing? | 16:57 |
| === sii` is now known as sii | ||
| nelius | jelmer: please advice, how do i set BZR_PDB=1? | 16:58 |
| jelmer | it's an environment variable | 16:59 |
| nelius | jelmer: btw this mornig i mailed that bzr selftest fails from macport | 16:59 |
| === fredp-afk is now known as fredp | ||
| nelius | jelmer: http://paste.uni.cc/17598 | 17:12 |
| jelmer | nelius: hmm, odd | 17:12 |
| jam | I would rather just see the output from ~/.bzr.log | 17:13 |
| jam | rather than BZR_PDB=1 | 17:13 |
| jam | I think jelmer was actually wanting "bzr -Derror ..." | 17:13 |
| jam | which prints the traceback to the screen | 17:13 |
| jam | BZR_PDB=1 puts you into the debugger to interactively figure out what is going on | 17:14 |
| jelmer | yeah, ~/.bzr.log would've worked too | 17:14 |
| jelmer | though this helps us somewhat too | 17:14 |
| * jelmer first thought would still be to blame Mac OS X's smb implementation | 17:14 | |
| jam | Well, it tells us that writing to a file descriptor is failing for some reason | 17:15 |
| jam | Which does sound like a problem with smb:// | 17:15 |
| jelmer | it would be interesting to see if this also breaks with a Linux client | 17:15 |
| nelius | if i try again and again, in some cases bzr enters the "Fetch phase 0/4" but in most cases it breaks just after i hit enter | 17:16 |
| nelius | i'll paste the .bzr.log after the current try failed | 17:16 |
| nelius | http://paste.uni.cc/17599 | 17:17 |
| jam | weird, it seems capable of copying the file texts up, but when we try to start pushing revisions | 17:22 |
| jam | it fails at the signature file | 17:22 |
| jam | you know what, though, we are probably creating the file with 0 bytes of data | 17:23 |
| jam | So that the file exists, but doesn't hold anything | 17:23 |
| jam | nelius: can you try this patch: http://paste.uni.cc/17600 | 17:25 |
| nelius | jepp, i'm trying... the fech phase takes really long... pleas hold the line | 17:29 |
| nelius | argh... it failed, but in a new file: /opt/local/lib/python2.5/site-packages/bzrlib/atomicfile.py(97)write() | 17:29 |
| nelius | want a log? | 17:30 |
| nelius | http://paste.uni.cc/17601 | 17:31 |
| lnxtech | If I want to setup a smart server that will be accessed via bzr:// does it use the local accounts of the server? | 17:36 |
| vila | lnxtech: no it will use the account it is run from | 17:38 |
| vila | you should use bzr+ssh for now if you want authentication | 17:39 |
| lnxtech | vila: thanks. | 17:40 |
| lnxtech | Also, Is it possible to push/commit to two separate locations at the same time? I want to have a bazaar repository for my projects at work, but I also want to mirror to my external server so I can work from home and what not | 17:43 |
| vila | lnxtech: you want bound branches, look at 'bzr help bind' | 17:54 |
| lnxtech | vila: thanks again | 17:55 |
| jam | nelius: sorry about the delay, it looks like the same bug. We are creating a file and writing a 0-length string to it, and that is causing a failure | 17:59 |
| jam | nelius: http://paste.uni.cc/17602 | 18:02 |
| jam | use that and the earlier patch | 18:02 |
| jam | nelius: I filed bug 162930 for your use case | 18:15 |
| ubotu | Launchpad bug 162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/162930 | 18:15 |
| ubotu | New bug: #162930 in bzr "Bazaar tries to write 0-length strings to files" [Undecided,New] https://launchpad.net/bugs/162930 | 18:15 |
| ubotu | New bug: #162931 in bzr "`bzr check` incorrectly reports about inconsistent parents" [Low,Confirmed] https://launchpad.net/bugs/162931 | 18:15 |
| vila | lnxtech: you may want to track progress on bug #126911, but don't hold your breath | 18:16 |
| ubotu | Launchpad bug 126911 in bzr "Smart server has no built in authentication" [High,Triaged] https://launchpad.net/bugs/126911 | 18:16 |
| * vila dinner | 18:17 | |
| jam | mmmm.... food | 18:19 |
| dato | hm. what was the recipe to merge two unrelated branches? | 19:03 |
| dato | I just want to merge a branch containing one file into another. | 19:03 |
| bialix | bzr merge -r0..-1 | 19:04 |
| dato | ah, thanks. | 19:04 |
| dato | I was trying -r 0.. only | 19:04 |
| bialix | if you supplied only one rev merge try to merge up to this revision | 19:05 |
| bialix | so you actually did merge -r0..0 | 19:05 |
| === fredp is now known as fredp-afk | ||
| lifeless | moing | 20:06 |
| lifeless | adsl-- | 20:06 |
| jelmer | hey lifeless | 20:07 |
| jelmer | I think that was the first time I see you actually disconnect from IRC :-) | 20:07 |
| lifeless | I didn't. My ISP disconnected *me* :) | 20:11 |
| jelmer | :-) | 20:12 |
| lnxtech | When you run bzr init-repo does it default to using --trees or --no-trees? | 20:18 |
| lifeless | trees | 20:19 |
| lifeless | on bzr 0.9x and above | 20:20 |
| lifeless | this is the same as '--init' creating a tree | 20:20 |
| lifeless | so we felt it was more predictable | 20:20 |
| lnxtech | If I'm wanting to create a shared repo to hold several projects it is generally recommended to use trees or no-trees? | 20:23 |
| lnxtech | or is it personal preference? | 20:23 |
| lifeless | personal preference | 20:25 |
| lifeless | if you are working within the repo, trees is handy | 20:25 |
| lifeless | if the repo is somewhere else, and you're using it like a svn or cvs repo, no-trees is better on disk space | 20:25 |
| lifeless | jam: ping | 20:28 |
| jam | lifeless: pong | 20:29 |
| lifeless | jam: my stack of patches is growing alarmingly | 20:34 |
| lifeless | jam: could you review e.g. find_text_key_references ? | 20:35 |
| jam | sure | 20:35 |
| lifeless | its not in BB for some reason | 20:35 |
| lifeless | but it is on the list | 20:35 |
| lifeless | abentley: ^ btw, that may be me misuing bzr send; I sent in a cherry pick to get the right diff for _generate_text_key_index | 20:38 |
| igc | morning | 20:47 |
| lifeless | hi | 20:48 |
| lnxtech | lifeless: Why is no-trees better on disk space? (I've been reading through the documentation about this but for some reason I can't seem to get my head around the differences) | 21:06 |
| dato | lnxtech: because it doesn't contain the trees. :) | 21:06 |
| lifeless | say your source code is 100MB extracted on disk | 21:07 |
| lifeless | and say you have 10 branches | 21:07 |
| dato | lnxtech: you normally use --trees for the repository at home, and --no-trees for what you publish on your webserver. | 21:07 |
| lifeless | our branch metadata is a few hundred bytes. | 21:07 |
| lifeless | so with disk cluster overhead thats, oh, 200K for 10 branches. | 21:07 |
| lifeless | and 1G for 10 working trees. | 21:07 |
| sabdfl | lifeless: very cool perspective from Gerry, huh? | 21:19 |
| lifeless | absolutely | 21:19 |
| lifeless | Ian said about my reply: 'That's what I love about you Rob' - always to the point. :-)' | 21:19 |
| === phanatic_ is now known as phanatic | ||
| glyph | hello! let me preface this by saying that I am not trolling | 22:10 |
| * jml waves | 22:10 | |
| glyph | I am about to recommend bzr to someone | 22:10 |
| glyph | or rather, I'd like to | 22:10 |
| glyph | but a hard requirement for them is sensible GUI tools for Windows clients, where tortoiseSVN has set a baseline for "reasonable" | 22:10 |
| glyph | erm sensible | 22:11 |
| glyph | is there such a thing for bzr yet? | 22:11 |
| poolfool | glyph: http://bazaar-vcs.org/TortoiseBzr | 22:14 |
| glyph | the other thing that this particular recommendation hinges upon is "asset" (large binary file) management | 22:16 |
| lifeless | what does that mean | 22:16 |
| glyph | lifeless: I'm not sure that I can give a good answer, because it's large and sprawling, and I am not an artist myself, but "this stuff: http://www.softimage.com/products/alienbrain/" is probably a good approximation | 22:17 |
| glyph | lifeless: the person I am talking to is a game developer who needs a single version control system for all the art associated with the game as well as the code | 22:18 |
| glyph | lifeless: they also need to give their (non-technical, windows-using, and somewhat obnoxious) publisher access to the code as it is developed, hence the GUI requirement | 22:19 |
| lifeless | wowser | 22:19 |
| glyph | everything has problems | 22:19 |
| lifeless | anyhow | 22:19 |
| glyph | AlienBrain is ... unsuitable for code | 22:19 |
| lifeless | (the wowser was me looking at the alienbrain page) | 22:20 |
| lifeless | bzr versions binaries fine | 22:20 |
| lifeless | if they are /huge/ it will eat memory | 22:20 |
| lifeless | and really big may thrash/error. We have a plan there. | 22:20 |
| glyph | lifeless: is 200MB "huge"? | 22:21 |
| lifeless | if you have 600MB of ram, no. | 22:21 |
| lifeless | I think 3 times is our current peak | 22:21 |
| lifeless | it might be 4 time | 22:22 |
| glyph | hmm | 22:22 |
| glyph | lifeless: if you were doing a checkin that touched 6 200MB files would you need a gig and a half of RAM or only 600M? | 22:22 |
| glyph | erm I mean 4G | 22:23 |
| lifeless | one base copy, one current copy, do a diff, generate a zip store | 22:23 |
| lifeless | glyph: each file is done serially, 600M | 22:23 |
| glyph | lifeless: that's on commit, right? any issues with update? | 22:24 |
| glyph | maybe I mean "pull" | 22:24 |
| lifeless | in non-merge cases we'll extract the new text (200MB) and write to disk | 22:24 |
| lifeless | in merge cases we'll extract 3 copies to do a 3-way merge and write a new one to disk, until it trips the binary flag. so 800MB peak. | 22:25 |
| glyph | that's pretty hefty, but probably not a problem | 22:25 |
| glyph | these artists have ridiculous machines | 22:25 |
| lifeless | but I wouldn't expect artists to be trying to merge these files, that would bad. | 22:25 |
| lifeless | binaries and merging. eewww. | 22:25 |
| glyph | it's apparently not uncommon to have a 64bit windows box with 16G of RAM | 22:25 |
| glyph | lifeless: actually that is the major feature of alienbrain, it does merging on things like photoshop and 3d studio max files | 22:26 |
| glyph | lifeless: by having plugins for the appropriate programs which visually display the differences | 22:27 |
| hugh | hi folks, I've been using bzr for a couple of months, after having used svn for a long time | 22:27 |
| hugh | I'm still having trouble getting robust mental models of the entities in the bzr world | 22:28 |
| glyph | (one day, when I have a billion dollars and nothing better to do, I am going to make bzr do that. starting with Python, and "emacs" as the "appropriate program" to have a plugin for.) | 22:28 |
| hugh | Could someone patiently explain to me the difference between a branch and a checkout? | 22:28 |
| LeoNerd | A checkout contains copies of the actual files, that you can work on | 22:29 |
| LeoNerd | A branch simply stores history | 22:29 |
| lifeless | glyph: we can do that if someone writes the code; merging is already pluggable | 22:29 |
| hugh | Ok, thanks; so what is the difference between a checkout and a working tree? | 22:29 |
| LeoNerd | Other RCSes call it a "working directory" or a "workspace" or a "working tree" or similar | 22:29 |
| lifeless | hugh: checkout is more about workflow - working like CVS and svn. working tree is as LeoNerd says. | 22:30 |
| hugh | OK; the documentation repeatedly refers to a checkout as a thing rather than a process; this has been confusing. | 22:30 |
| lifeless | hugh: it is - 'bzr checkout' creates a checkout | 22:30 |
| lifeless | a checkout is a thing which is geared to act as a drop-in replacement for cvs or svn | 22:31 |
| hugh | my point exactly, 'a checkout' a thing rather than a process... | 22:31 |
| lifeless | its a thing to support a process :) | 22:31 |
| hugh | is a checkout a thing that is any different from the working tree? | 22:31 |
| lifeless | a working tree is a component of a checkout | 22:31 |
| lifeless | a working tree is also present when you have a branch with a tree, so that you can edit and commit in the branch | 22:32 |
| hugh | ok; what else are components of a checkout? | 22:32 |
| igc | hugh: A new User Guide is coming that tries to help explain the concepts up front. See http://people.ubuntu.com/~ianc/doc/en/user-guide/index.html for progress to date. | 22:32 |
| lifeless | a checkout has one of two additional components: Either a 'branch pointer' that points to a branch somewhere else. We call this configuration a 'lightweight checkout'. | 22:33 |
| lifeless | hugh: or it has a 'bound branch', which is a regular branch with a configuration setting that makes commits/pushes/pulls etc to it also be applied to a remote branch. | 22:33 |
| lifeless | we call that a 'heavyweight' checkout, because you have all the history of the project locally so they take more time to create, and more disk space | 22:34 |
| hugh | ok, so the lightweight checkout is more like the svn view of things, whereas the heaveyweight checkout bring in bzr's ability to keep the | 22:38 |
| hugh | entire branch history locally | 22:38 |
| lifeless | right | 22:38 |
| lifeless | lightweight checkouts have minimal offline capability; heavyweight checkouts have comprehensive offline capability | 22:38 |
| lifeless | many people don't use checkouts at all, just regular branches. It really depends on your team workflow and needs. | 22:39 |
| lifeless | if you are a solo developer, you can ignore checkouts. | 22:39 |
| hugh | so the different checkout variants each get you a working tree, but with more or less support for offline capabilities | 22:39 |
| hugh | no I'm working with several folks sitting in different states | 22:40 |
| hugh | we're only rarely at the same site at the same time | 22:41 |
| hugh | so we have an 'official' repository, and one guy who's more bzr savvy keeps one or more other branches.... that mirror the official repo | 22:41 |
| hugh | the basic model of: modify files, do local commits, do a push more or less makes sense, it's when things go wrong that I get confused | 22:42 |
| glyph | lifeless: that's great to hear | 22:43 |
| hugh | and then I go look at the man page for the 70th time and try to solidify my mental picture of what's happening :-) | 22:43 |
| beuno | hugh, if you're going to be doing local commits, I believe branching makes more sense the checkouts | 22:43 |
| glyph | lifeless: It looks like tortoisesvn isn't quite there yet, although it's getting close | 22:44 |
| * glyph reluctantly recommends SVN plus a bunch of horrible Apache configuration | 22:44 | |
| hugh | I think I have a local branch (but am not sure). I do local commits and then push later | 22:44 |
| beuno | when using checkouts, local commits are normally an exception (have to add an extra parameter), but when branching out, it's local by default, and you send the changes off with "push | 22:44 |
| beuno | " when needed | 22:44 |
| hugh | yes, I must have a local branch | 22:44 |
| beuno | hugh, sounds like bzr branch is what you want | 22:45 |
| beuno | unless lifeless proves me wrong :D | 22:45 |
| lifeless | glyph: ah well. | 22:45 |
| lifeless | beuno: I think you're right | 22:46 |
| lifeless | checkouts are when you want to be in lockstep with other people | 22:46 |
| lifeless | have a look at the Workflows wiki page | 22:46 |
| beuno | hugh, using checkouts for that kind of workflow won't break anything, just make it a bit more uncomfortable as you will have to be adding an extra parameter every time | 22:48 |
| lifeless | beuno: extra parameter ? | 22:49 |
| beuno | lifeless, --local? | 22:49 |
| lifeless | oh right; when you want offline | 22:50 |
| beuno | (when using checkouts) | 22:50 |
| lifeless | anyhow, my advice is - | 22:50 |
| beuno | he was saying he does local commits until he wants to send it off to the parent branch | 22:50 |
| lifeless | if you are used to cvs or svn, use the cvs and svn commands - bzr checkout, bzr commit, bzr merge, bzr branch REMOTEURL to create a new branch then bzr checkout that URL | 22:51 |
| lifeless | if you are not used to cvs or svn, do not use the checkout command at all until you are comfortable with regular branches | 22:52 |
| jml | how can you use an external diff util w/ bzr? | 22:53 |
| jml | there's a diff option option, but not a diff cmd option. | 22:54 |
| beuno | jml, you can use aliases for that | 22:54 |
| jml | how? | 22:54 |
| dato | jml: I *think* there is a plugin | 22:54 |
| beuno | jml, http://doc.bazaar-vcs.org/latest/en/user-guide/using_aliases.html | 22:55 |
| lifeless | jml: it will automatically use gnu diff if the options are not supported in bzr | 22:55 |
| beuno | wait, the example isn't there | 22:55 |
| lifeless | jml: also there is a diffutils plugin | 22:55 |
| * beuno looks for the example of using different diff utils | 22:55 | |
| beuno | wasn't there one laying around that used meld? | 22:56 |
| lifeless | I thought diffutils did that | 23:02 |
| lifeless | meld is in my ep2006 talk slides | 23:02 |
| igc | jml: the diffutils plugin is great | 23:03 |
| igc | I use it in combination with meld all the time | 23:03 |
| YGingras | I see that mercurial uses bzr's diff3, anyone knows if it have been factored out from either rev control system? I'd need 3-way merge in Gazest, a wiki I'm working on | 23:07 |
| igc | bbiab | 23:07 |
| lifeless | YGingras: you could just import bzrlib :) | 23:08 |
| YGingras | lifeless is it exported in a way that I can use it without a bzr repo? | 23:10 |
| lifeless | yes | 23:11 |
| YGingras | will bzr easy_install cleanly on most plateforms? | 23:12 |
| YGingras | I see C extentions: probably not | 23:13 |
| lifeless | they are optional | 23:13 |
| lifeless | and | 23:14 |
| lifeless | won't affect loading the diff3 stuff you need | 23:14 |
| YGingras | so, in Merge3.__init__(self, base, a, b), base, a and b are paths? I thought those were rev-ids or something | 23:16 |
| hugh | lifeless: beuno: others: thanks for your feedback; this is helping me a lot; catch you later | 23:18 |
| YGingras | ok, I see it: list of lines | 23:18 |
| YGingras | lifeless: how does it compares with gnu diff3? | 23:18 |
| beuno | hugh, anytime :D | 23:19 |
| lifeless | YGingras: they are texts | 23:21 |
| lifeless | Merge3(['line\n', | 23:21 |
| lifeless | 'line2\n'], [], []) | 23:21 |
| lifeless | for instnace | 23:22 |
| YGingras | lifeless: sounds good, I think I'm going to use it. Will you guys be mad at me if I end up repackaging it yet another time? :-) | 23:24 |
| lifeless | mad? no. Think its a bit pointless and that you miss out on improvements; yes. | 23:25 |
| YGingras | of course I'm going to watch for improvements but this file seems really stable ;-) | 23:33 |
| lifeless | I'm surprised more of the vcs infrastructure isn't usable for you; wikis and branches have lots in common | 23:39 |
| YGingras | lifeless: I use some bits from mercurial for finding LCA, I probably go hunting in bzr an hg again when I implement new features | 23:41 |
| lifeless | well | 23:41 |
| lifeless | I was meaning more about history storage | 23:41 |
| lifeless | e.g. using a pack repository object directly, no commit or inventory objects though | 23:42 |
| YGingras | lifeless: that questing comes often. I don't know how you do it precisely in bzr but interface offered by drcs is typically for a whole repo while most wiki acitons are for a single file | 23:45 |
| YGingras | it's easy to roll my own branch on a single file that to call bzr in a pipe to branch the repo everytime someone hits the edit link | 23:46 |
| lifeless | YGingras: using the library its easy to use the core storage facilities to do what you need | 23:47 |
| lifeless | I wouldn't have mentioned it if it wasn't trivial | 23:47 |
| YGingras | lifeless: I can't count the number of persons who mentioned calling git in a pipe like it was trivial | 23:49 |
| lifeless | meh | 23:50 |
| lifeless | I wouldn't call a pipe level interface trivial | 23:50 |
| lifeless | libraries are so much better | 23:50 |
| YGingras | "use git: git is super fast => your wiki is going to be uber fast" | 23:50 |
| lifeless | anyhow, the point is that you don't need whole-tree operations; and bzr's core doesn't force you to use whole-tree operations in the sort of scenario you are talking about | 23:50 |
| YGingras | lifeless: that's really interesting, I'll have a serious look at it | 23:51 |
| lifeless | In particular I'm thinking of PackRepository's text index / mapped knits layer | 23:51 |
| lifeless | you could use the path to the wiki page as the key | 23:52 |
| lifeless | so this does not give you 'a wiki you can bzr branch', it just gives you a db that supports annotate and other such things as built in primitives | 23:52 |
| YGingras | lifeless: how would it scale across multiple webhead? I recall some obsure performance issues on NFS | 23:53 |
| lifeless | uhm | 23:53 |
| lifeless | packs should be fine on nfs | 23:53 |
| lifeless | granular locking during data insertion | 23:53 |
| lifeless | no need for oslocks | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!