| luislavena | hello everybody. | 00:12 |
|---|---|---|
| luislavena | anyone had experience installing bzr on a shared host? | 00:13 |
| poolie | yes, sure | 00:13 |
| luislavena | poolie: dreamhost, bluehost or site5? | 00:14 |
| poolie | oh, huh | 00:14 |
| poolie | none of those | 00:14 |
| poolie | why not use launchpad.net? | 00:14 |
| luislavena | poolie: is for a private project | 00:15 |
| luislavena | poolie: been pushing via ftp and pulling via http, but these dumb protocols are a bit slow. | 00:15 |
| poolie | are you using a pack repository? | 00:15 |
| luislavena | yep, pack-0.92 | 00:16 |
| luislavena | with 1.1 | 00:16 |
| luislavena | sorry, bzr 1.1 | 00:16 |
| luislavena | freshly created repos :) | 00:16 |
| beuno | luislavena, I'm not sure you can install python apps on shared hosts | 00:16 |
| beuno | (I'm fairly sure you can't unless it's a virtual server or the likes) | 00:17 |
| luislavena | beuno: thank you | 00:19 |
| luislavena | beuno: maybe something like this | 00:20 |
| luislavena | beuno: http://joshstaiger.org/archives/2007/01/bzr_on_dreamhos.html | 00:20 |
| beuno | luislavena, ah, seems pretty straight forward | 00:21 |
| luislavena | beuno: I'll need to check if the dependencies can be installed in the same way, since I've 2.4.3 available and only tested bzr with 2.5.1 | 00:22 |
| beuno | if you're allowed to install stuff in your home, for the most part, those same steps should work | 00:22 |
| beuno | luislavena, bzr works fine with python 2.4X | 00:22 |
| luislavena | beuno: thank you for the info | 00:23 |
| luislavena | beuno: is there a way I can see if everything works as expected ? (selftest?) | 00:23 |
| beuno | luislavena, yeap, bzr selftest | 00:24 |
| fullermd | Uff. Not a particularly kind thing to do... | 00:26 |
| Odd_Bloke | fullermd: What in particular? | 00:27 |
| luislavena | fullermd: yes, I know... will make the shared host a nightmare to other users. | 00:27 |
| fullermd | Odd_Bloke: running 'selftest' on a shared webhost? | 00:29 |
| poolie | because of cpu usage? | 00:29 |
| poolie | run it niced... | 00:29 |
| poolie | or run, say 'selftest command' | 00:29 |
| poolie | sorry, i mean 'blackbox' | 00:29 |
| fullermd | cpu, disk... last time I ran it, it made my workstation crawl for about 40 minutes. | 00:30 |
| fullermd | Still negotiating the restraining order my hard drive filed at the time... | 00:30 |
| luislavena | fullermd: hehehe, no problem, the InstallationFaq contains pointers on how to check for the missing dependencies. | 00:31 |
| luislavena | so far, the shared host lack all of them :P | 00:31 |
| luislavena | I'll see if I can install them like bzr... | 00:31 |
| luislavena | (on $HOME) | 00:31 |
| Odd_Bloke | fullermd: Ah, OK, I was thinking more generally. | 00:32 |
| bob2 | ffworked fine on dh for me | 00:40 |
| luislavena | bob2: how did you handle the dependencies? ElementTree, pyramiko, etc? | 00:44 |
| fullermd | Well, you don't need paramiko unless you're sftp'ing _out_ from there. | 00:45 |
| bob2 | aelementree is python, as is paramiko, and what fullermd said | 00:46 |
| bob2 | you could probably even get bzr+http working, I think they do fastcgi | 00:46 |
| lifeless | revie requested: http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E | 00:50 |
| luislavena | bob2: how bzr+http will handle authentication? | 00:54 |
| bob2 | poorly! | 00:54 |
| lifeless | bob2: uhm | 00:56 |
| lifeless | luislavena: it should handle it fine | 00:56 |
| luislavena | lifeless: thank you :) | 00:56 |
| luislavena | but anyway, it fails to compile the c part of bzrlib | 00:57 |
| luislavena | so I think this shared host is not as good as other ;-) | 00:57 |
| bob2 | hm, I was reading the bzr+http docs yesterday, and it looked like you couldn't control what people could write to | 00:57 |
| lifeless | bob2: thats access control not authentication | 00:58 |
| lifeless | bob2: bzr+http delegates authorisation and authentication to apache and makes no direct effort at access control | 00:59 |
| bob2 | touche | 01:00 |
| fullermd | Well. Access control is a subset of authorization... | 01:00 |
| lifeless | fullermd: bup | 01:00 |
| lifeless | fullermd: bah, nup, its not | 01:00 |
| lifeless | fullermd: its a subset of AAA, but other than that you can have any one without the other two | 01:01 |
| fullermd | The third A in AAA is 'accounting', though. | 01:01 |
| bob2 | but it's not possible to have differing read and write authorization with bzr+http yet, right? | 01:01 |
| lifeless | bleh, my brain has clearly faded | 01:01 |
| fullermd | Dirstate does that to ya ;) | 01:02 |
| lifeless | bob2: depending on what granularity you want, yes or no | 01:02 |
| lifeless | bob2: in a single repository, we still depend on VFS access for some methods, so any access to the data base implies full data visibility | 01:02 |
| fullermd | I would phrase it as "bzr+http delegates authentication to Apache, and abdicates authorization to merely be contingent on authentication". | 01:03 |
| lifeless | bob2: but you can certainly split read and write access in a couple of ways - you can run the server with different parameters via the apache config to block writers | 01:03 |
| fullermd | The usual suggestion for that is "read/only bzr+http, read/write bzr+https with HTTP auth" | 01:04 |
| lifeless | not sure why you'd split the protocol | 01:05 |
| lifeless | but whatever | 01:05 |
| fullermd | Well, that makes the URL's almost the same on both sides. Gives you SSL where you're sending auth info over the wire. | 01:09 |
| lifeless | digest auth ftw; or has that not landed yet ? | 01:10 |
| fullermd | Well, it would also prevent a MitM when you were pushing data. If anybody still bothers trying to carry those out. | 01:10 |
| lifeless | digest supports body signing | 01:11 |
| lifeless | plus sign your commits kthxbye | 01:11 |
| lifeless | igc: I wonder if I can borrow you for http://bundlebuggy.aaronbentley.com/request/%3C1201262061.16337.52.camel@lifeless-64%3E | 01:16 |
| igc | lifeless: sure. Meant to get to it yesterday. | 01:17 |
| igc | I'll move it to the top of my review list | 01:17 |
| igc | (ahead of thumper's one) | 01:18 |
| thumper | :( | 01:18 |
| luislavena | guys, there is no feed generator that can hook push and commit? | 01:21 |
| luislavena | branchfeed seems old and don't work. | 01:22 |
| lifeless | luislavena: my plugin should still work | 01:23 |
| luislavena | lifeless: can you point me to the branch? | 01:23 |
| lifeless | one sec | 01:23 |
| luislavena | lifeless: thank you | 01:24 |
| lifeless | branchfeed is what I called mine lol, I had to re-read it | 01:25 |
| luislavena | lifeless: the one here doesn't work: | 01:26 |
| luislavena | https://code.launchpad.net/~bzr/bzr-branchfeed/trunk | 01:26 |
| luislavena | it's supposed to generate a feed in .bzr/branch/branch.atom, but no file get generated. | 01:27 |
| lifeless | https://bugs.edge.launchpad.net/bzr-branchfeed/ | 01:28 |
| lifeless | could you file a bug please | 01:28 |
| luislavena | lifeless: will help you if I run the plugin selftests? | 01:29 |
| lifeless | is the plugin installed on your client or server? | 01:30 |
| luislavena | client, doing everthing locally and sometimes using smart server. | 01:30 |
| lifeless | yah, I can't look at this right now | 01:31 |
| lifeless | please file a bug with as much info as you can gather | 01:31 |
| luislavena | lifeless: yeah, sure. thank you again :) | 01:31 |
| luislavena | lifeless: done :) | 01:39 |
| ubotu | New bug: #187479 in bzr-branchfeed "BranchFeed don't generate atom feed after commit or push" [Undecided,New] https://launchpad.net/bugs/187479 | 01:45 |
| === mw is now known as mw|out | ||
| luislavena | guys, another silly question, but i cannot find a way to verify the signed commits | 02:07 |
| luislavena | there is sign-my-commits and re-sign, but no verify-signed-commits or something similar. | 02:08 |
| lifeless | poolie: perhaps https://code.edge.launchpad.net/~mbp/bzr/dev should be registered, its a dupe with https://code.edge.launchpad.net/~bzr/bzr/trunk | 02:11 |
| lifeless | luislavena: yah, someone was working on it | 02:11 |
| luislavena | lifeless: good to know, the check_signature and create_signatures configuration options works? | 02:13 |
| luislavena | (branch based and globals) | 02:14 |
| luislavena | ok, it seems so, just wanted to be sure :) | 02:15 |
| abentley | lifeless: is get_data_stream_for_search meant to have ordering restrictions? | 02:15 |
| === variaas_ is now known as variaas | ||
| === variaas is now known as variaas_ | ||
| lifeless | abentley: no more so than the get_data_stream api it replaced | 02:59 |
| abentley | They both have prefixes with lists of versions after them. | 03:00 |
| abentley | I'm not sure whether a prefix is allowed to be repeated. | 03:00 |
| abentley | The use of prefixes suggests that the designer wasn't expecting the prefix to change frequently. | 03:00 |
| lifeless | I don't think the current code or tests prevent that | 03:00 |
| lifeless | the goal was a single namespace for all data atoms | 03:01 |
| abentley | Since ('a')['b'], ('c')['d'] isn't all that helpful. | 03:01 |
| abentley | But in packs, I would expect the prefix to change at least twice per revision. | 03:02 |
| lifeless | why? | 03:02 |
| abentley | If you read from the beginning. | 03:02 |
| lifeless | oh right | 03:02 |
| lifeless | currently on sftp I do four readv's per pack | 03:02 |
| lifeless | each readv linear sorted | 03:03 |
| lifeless | (for fetching this is) | 03:03 |
| abentley | Cool. | 03:04 |
| lifeless | that seems a reasonable tradeoff in simplicity/speed - it lets us keep the read revision, read inventory, read texts etc sequence | 03:04 |
| abentley | Oh, I see. | 03:04 |
| lifeless | which means we don't copy unreferenced data, can sanity check etc | 03:04 |
| abentley | But revisions and sigs are fulltexts, so it wouldn't hurt to read them at the same time as inventories. | 03:05 |
| abentley | No additional memory cost, at least. | 03:05 |
| lifeless | and transactional inserts into the repository means we can just flush to disk | 03:05 |
| lifeless | abentley: right, it can certainly be tweaked; howver the sigs and revisions are in different indices to the inventories | 03:05 |
| lifeless | so if we were trying to optimise memory more we would actually be dropping index content from memory after grabbing the data for that index | 03:06 |
| abentley | Yes, I suppose it makes sense to do each index in turn. | 03:06 |
| lifeless | I haven't had any breakthough thoughts about storage/repository; I will reply to the thread though and see if we can get a good compromise; I _do not_ want to prevent improvements | 03:07 |
| abentley | Even though we haven't agreed on the structure for Storage, I think that we can agree that an implementation of iter_files_bytes that reads each pack only once would be a win. | 03:08 |
| lifeless | abentley: oh for sure | 03:09 |
| abentley | So I'm going to look at restructuring the knit-building code to support that. | 03:09 |
| lifeless | abentley: great; I hope you'll find its already half way tere | 03:09 |
| lifeless | *there* | 03:09 |
| lifeless | I split out the 'get data' stuff to a KnitAccess helper a ways back | 03:09 |
| abentley | Oh, I've been wondering what that thing was. | 03:10 |
| lifeless | so PackAccess knows how to get stuff from an arbitrary key | 03:10 |
| lifeless | by mapping the key which is (index, key) | 03:10 |
| lifeless | through the index to get an actual pack file | 03:10 |
| lifeless | KnitAccess maps likewise but to a single file the .knit file | 03:11 |
| lifeless | this gives KnitData as simply providing the logic for combining hunks etc | 03:11 |
| abentley | Hmm. Somewhat different approach than I was thinking, but it could work. | 03:11 |
| lifeless | and KnitIndex maps into a combined index for packs, which filters out the fileid prefix | 03:12 |
| lifeless | so what I have been thinking about doing is | 03:12 |
| lifeless | adding a file id prefix to the standard knit code | 03:12 |
| lifeless | which the existing KnitIndex stuff would enforce as always being the file id the index is for | 03:13 |
| lifeless | and the pack index mapper would just stop filtering out the file id prefix | 03:13 |
| lifeless | thus giving the existing iter_versions etc stuff the ability to deal with many file ids at once | 03:14 |
| lifeless | anyhow, I'm rambling - this is what I had in my head, not the only way to do it :) | 03:14 |
| abentley | Well, it's interesting. | 03:14 |
| abentley | I basically already have the code to map a bunch of requested knit entries to their pack transport/name/offset/size. | 03:15 |
| abentley | So I was thinking about doing that part up front. | 03:16 |
| lifeless | the map code should a single index iter_entries query really :) | 03:17 |
| abentley | Basically via the iter_raw_items variation on get_data_stream. | 03:17 |
| abentley | Yeah, I like that. | 03:18 |
| lifeless | the thing I like about extending knit is that the combining logic does not get duplicated, or have to move | 03:19 |
| lifeless | so improvements there will still help anything thats roughly delta combining related | 03:20 |
| abentley | The downside is you can't retrieve everything in a single read. | 03:24 |
| lifeless | hmm? sure you can | 03:27 |
| lifeless | get_raw_records | 03:27 |
| lifeless | used by read_records_iter_raw | 03:29 |
| lifeless | so read_records_iter_raw is already multiple-file-id ready, as long as the _Access object it has been given is | 03:30 |
| abentley | By everything, I meant fetching files, revisions, inventories and signatures all at once | 03:33 |
| lifeless | oh right | 03:33 |
| abentley | You can achieve that by adding a prefix, I think. | 03:34 |
| lifeless | hmm, if we guarantee that the indices contain enough data | 03:34 |
| abentley | You then wind up with something very close it Storage.iter_raw_items. | 03:37 |
| lifeless | I like the idea of getting get_data_stream and insert_data_stream | 03:37 |
| abentley | s/it/to | 03:38 |
| abentley | lifeless: I think you were cut off: "I like the idea of getting get_data_stream and insert_data_stream" | 03:50 |
| abentley | But I'll mention that if we get the inventory first, we can do fetch and build_tree at the same time. | 03:58 |
| lifeless | yup | 03:59 |
| lifeless | fetch currently puts the inventory before all texts | 03:59 |
| lifeless | for locality of reference its grouped too | 03:59 |
| lifeless | not really cut off; just not finished | 03:59 |
| === lamont` is now known as lamont | ||
| Aloha | whats the difference between a branch and a trunk? | 08:51 |
| weigon | Aloha: one starts with a b, the other with a t. That's pretty much it. | 08:53 |
| Aloha | weigon, whats the point of differentiating? | 08:53 |
| weigon | Aloha: "trunk" is svn-speak for the main-development-branch | 08:53 |
| Aloha | weigon, so why have more than one branch? | 08:54 |
| fullermd | Trunk is a branch that you call trunk. | 08:54 |
| weigon | Aloha: release-branches, feature-branches, merge-branches, ... | 08:54 |
| weigon | in bzr-world everything is a branch, everyone has it's own repository. | 08:54 |
| Aloha | weigon, so whats the difference between feature branch and release branch? | 08:55 |
| weigon | Aloha: I think the best example is taking a look how the linux kernel-development works | 08:55 |
| fullermd | Pretty much the difference between a water glass and a milk glass... | 08:56 |
| Aloha | why would my project have more than one branch? different parts of it go in different branches? | 08:56 |
| weigon | Aloha: no, put sometimes you have to release something to users|customers | 08:57 |
| weigon | and they call you 6 month later about a bug and you are already working the next big release | 08:57 |
| Aloha | weigon, so you can pull up the source code from that release and work on the bug? | 08:58 |
| weigon | ... and fix it for that release to build a new release (1.0.1), while you are still doing your main-dev in "trunk" for the 2.0 release | 08:58 |
| weigon | if you want to implement a new feature and want to write a Proof-of-Concept you will commit it not to trunk, but to a feature branch. | 08:59 |
| weigon | if it works well and matures, you merge the new feature back into trunk | 08:59 |
| Aloha | weigon, so your source code that you edited would be in 1.0-dev branch and your release would be in 1.0.1-release? | 08:59 |
| weigon | if it doesn't work out, you only have to trash your work, not the work of others that are in the main-dev branch | 09:00 |
| Aloha | weigon, gotcha | 09:00 |
| weigon | if you do it right, the main-dev branch is always in release quality | 09:00 |
| weigon | everything unstable is in feature branches until it is well tested and can be merged over | 09:01 |
| Aloha | weigon, gotcha | 09:02 |
| weigon | Aloha: that means proper test-cases, unit-testing, ... | 09:03 |
| Aloha | weigon, do you have a seperate branch for debian packages? or do you make those from release tarball? | 09:04 |
| weigon | Aloha: debian packages are built aside anyway. | 09:16 |
| Aloha | weigon, aside? | 09:16 |
| weigon | Aloha: scroll down on http://packages.ubuntu.com/feisty/net/hostapd | 09:17 |
| weigon | Source Package: hostapd, Download: [dsc] [hostapd_0.5.5.orig.tar.gz] [hostapd_0.5.5-3.1.diff.gz] | 09:17 |
| weigon | it is always a the original tar + a diff that includes the build-files for debian | 09:18 |
| Aloha | weigon, i know but the files uses to build the original tarball, does anyone keep a debian branch knowing that that branch will only be used to build packages? | 09:18 |
| Aloha | s/uses/used/ | 09:19 |
| === doko_ is now known as doko | ||
| ubotu | New bug: #187593 in bzr-webserve "list index out of range" [Undecided,New] https://launchpad.net/bugs/187593 | 10:40 |
| === mrevell is now known as mrevell-lunch | ||
| === SteveA_ is now known as SteveA | ||
| ricardokirkner | hi. I just installed the bzr-svn plugin (I am running fedora core 7). However, when I try to check out an svn branch, I get an error telling me that the url is not a branch. The cmd 'bzr selftest svn' failed, but I cannot make out what the problem is. Can anyone help me out here, please? | 13:14 |
| ricardokirkner | the error I get is '_get_location_config() takes exactly 1 argument (4 given)' | 13:15 |
| === mrevell-lunch is now known as mrevell | ||
| ricardokirkner | ok, I found out the error. I relates to bzr-svn not being able (yet) to check out from webdab | 13:40 |
| ricardokirkner | webdav | 13:40 |
| jelmer | ricardokirkner: bzr-svn supports webdav yet | 15:01 |
| jelmer | ? | 15:03 |
| awilkins | Can anyone tell me the significance of .~1~ files in my BZR trees? | 15:18 |
| LeoNerd | They're files left behind by 'bzr revert' | 15:21 |
| LeoNerd | When you 'bzr revert' it moves your locally-changed file to .~1~ in case you wanted to keep it, before overwwriting it with a clean copy | 15:21 |
| awilkins | Aha, thanks | 15:21 |
| * awilkins executes ls -r -inc *.~1~ | rm | 15:21 | |
| === mw|out is now known as mw | ||
| dato | awilkins: there is bzr clean-tree --detritus, from the bzrtools plugin. try it with --dry-run first. | 15:28 |
| jelmer | info je | 15:56 |
| jelmer | info jelmer | 15:56 |
| jelmer | whoops | 15:57 |
| jelmer | sorry | 15:57 |
| === bigdo2 is now known as bigdog | ||
| alefteris | after i upgrade my launchpad branch using sftp://<username>@bazaar.launchpad.net/~username/project/branchname, what should i do to my local working copy? | 17:01 |
| beuno | alefteris, upgrade it too | 17:01 |
| beuno | and, reconcile both | 17:01 |
| beuno | bzr reconcile sftp://<username>@bazaar.launchpad.net/~username/project/branchname | 17:01 |
| alefteris | i was reading this http://beuno.com.ar/archives/48, it mentions that I should recogline only if there is a problem.. is reconcile a dangerous operation? | 17:03 |
| beuno | alefteris, oh, then I have to correct it | 17:03 |
| beuno | you *must* do reconcile | 17:03 |
| alefteris | :) | 17:03 |
| beuno | alefteris, no, it isn't | 17:03 |
| beuno | upgrade might be | 17:03 |
| alefteris | ok thanks | 17:03 |
| beuno | alefteris, I changed it a few hours ago, can you see if it's clearer now: http://beuno.com.ar/archives/48 | 17:04 |
| beuno | (upgrade, on the other hand, already does it's own backup before doing anything, so all operations are fairly safe) | 17:04 |
| synic | hey folks. does this mean anything to any of you? | 17:04 |
| synic | [projects]$ bzr branch bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main/ exaile | 17:04 |
| synic | bzr: ERROR: Could not install revisions: | 17:04 |
| synic | sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2 | 17:04 |
| beuno | synic, what version of bzr are you using? | 17:06 |
| synic | 1.0.0 | 17:06 |
| beuno | synic, you might want to use http to branch | 17:06 |
| beuno | (and, is that your user in LP?) | 17:07 |
| synic | well, I'm trying to branch because a pull failed with the same error | 17:07 |
| synic | yes, that's my LP user | 17:07 |
| alefteris | beuno, you used to have a "check" step before the upgrade, its not actualy needed? | 17:07 |
| beuno | alefteris, not really, if you have knits, it isn't required | 17:07 |
| beuno | I also moved reconcile to _after_ upgrading | 17:08 |
| beuno | it's million times faster | 17:08 |
| beuno | synic, let me try and branch it | 17:09 |
| synic | yeah, I just installed bzr 1.1 and same error | 17:09 |
| beuno | I get 0 revisions | 17:09 |
| synic | uh, there are a lot more than 0 revisions | 17:10 |
| beuno | hmmmm | 17:10 |
| beuno | LP is reporting problems with the branch... | 17:11 |
| synic | great. | 17:11 |
| beuno | synic, can you do: bzr reconcile bzr+ssh://arolsen@bazaar.launchpad.net/~exaile-devel/exaile/main | 17:11 |
| beuno | has the branch been upgraded lately? | 17:11 |
| synic | well, I didn't do it (I wouldn't even know how), but one of the other devs may have done something | 17:12 |
| beuno | synic, try and run reconcile, and I'll ask in #launchpad if anyone can help | 17:12 |
| synic | running it now | 17:12 |
| beuno | ah, you already did... | 17:13 |
| beuno | let's give reconcile a try first | 17:13 |
| synic | whew, reconciling isn't the speediest operation, heh ;-) | 17:23 |
| synic | beuno: ok, yeah, it's still broken. | 17:24 |
| beuno | synic, argh... I suspect it's a LP problem | 17:25 |
| synic | bummer | 17:25 |
| beuno | lifeless, jam, abentley, any ideas on why https://code.launchpad.net/~exaile-devel/exaile/main might be broken? | 17:26 |
| abentley | Broken how? | 17:27 |
| beuno | abentley, it doesn't branch | 17:28 |
| beuno | 0 revisions | 17:28 |
| beuno | and LP reports it has a problem | 17:28 |
| beuno | synic already ran reconcile on it | 17:28 |
| beuno | and still nothing | 17:28 |
| beuno | (nobody seems to be available in #launchpad) | 17:28 |
| beuno | I see there is a broken character in the last commit message | 17:30 |
| beuno | but I'm not sure if that can cause LP to go crazy | 17:31 |
| beuno | (codebrowse also breaks: http://codebrowse.launchpad.net/~exaile-devel/exaile/main/files) | 17:31 |
| synic | yeah, but on all the revisions, not just the last one (I don't know if that means anything) | 17:32 |
| beuno | synic, I think it basically mean LP can't ready from the branch either | 17:32 |
| synic | hrmm | 17:33 |
| abentley | Yeah, you can see the "branch has errors" thing on the page | 17:33 |
| beuno | abentley, so... how can this be solved? push --overwrite from a healthy copy? | 17:34 |
| abentley | It's also in format 5, which is a bit odd. | 17:34 |
| abentley | Did you upgrade it? | 17:34 |
| abentley | or did you push from an upgraded branch? | 17:34 |
| beuno | synic, can you find out what the last dev did? | 17:34 |
| synic | I'll have to wait until he gets online | 17:35 |
| abentley | But I can confirm that revision-history is empty, so Bazaar is correctly interpreting that. | 17:35 |
| synic | I'm not real excited to hear that :) | 17:36 |
| beuno | synic, maybe the branch was upgraded and not reconciled | 17:37 |
| beuno | do you have a healthy copy locally? | 17:37 |
| beuno | (even if a bit out of date) | 17:38 |
| synic | I have one at home. I've been trying to log in and get it, but I can't get in for some reason | 17:38 |
| * synic thinks of where there might be another | 17:38 | |
| synic | ah, I have one on exaile.org, but I'm not sure how old it is. | 17:39 |
| beuno | synic, just so we can check what storage format you have and narrow it down to "someone upgraded recently and broke stuff" | 17:39 |
| synic | ok, yeah, I found it. How do I check? | 17:41 |
| beuno | synic, bzr info -v | grep 'repository' | 17:41 |
| synic | bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n' | 17:42 |
| beuno | synic, ah, so it's packs. And you're using some old bzr version | 17:42 |
| synic | on exaile.org, yeah. It's 0.90 | 17:43 |
| synic | I'll upgrade, if it won't hurt anything | 17:43 |
| beuno | synic, I would recommend upgrading it to 1.0 (or 1.1 even) | 17:43 |
| synic | k, doing that now | 17:44 |
| beuno | you should try and get a hold on the last dev that uploaded | 17:44 |
| beuno | see if he can fix his locla copy | 17:44 |
| beuno | if not | 17:44 |
| beuno | find the latest healthy one you can find | 17:44 |
| beuno | to 'bzr reconcile; | 17:45 |
| beuno | s/;/' | 17:45 |
| beuno | and then add the changed files | 17:45 |
| synic | ok | 17:45 |
| beuno | commit | 17:45 |
| beuno | and move on :D | 17:45 |
| beuno | make sure everyone is using bzr 1.0+, and have upgraded their local branches | 17:46 |
| beuno | I just blogged on how to upgrade a few days ago: http://beuno.com.ar/archives/48 | 17:46 |
| abentley | beuno: I'm trying to get more info on this, but no luck so far | 17:46 |
| beuno | abentley, great, thanks! synic can you stick around for a while and see if we can dig a bit deeper? | 17:48 |
| synic | yeah | 17:48 |
| dacresni | how do i get bzr 1.0 on ubuntu? | 17:48 |
| synic | might be a bit before the other dev signs on | 17:48 |
| synic | if he does at all | 17:48 |
| synic | he's in australia, I'm in utah | 17:48 |
| dacresni | thanks | 17:48 |
| beuno | dacresni, you can get the latest from: https://launchpad.net/~bzr/+archive | 17:48 |
| synic | bzr info -v | grep repository repository: Packs containing knits without subtree support | 17:49 |
| synic | that's after the upgrade. | 17:49 |
| dacresni | i c | 17:50 |
| beuno | synic, good. I would run 'bzr reconcile' on it now | 17:50 |
| dacresni | thanks beuno | 17:50 |
| beuno | dacresni, no problem! :D | 17:50 |
| synic | beuno: it says "no repository present". Ack, it's a checkout, not a branch. Rats. | 17:51 |
| beuno | synic, you can use 'bzr unbind' to make it into a branch, although I'm not sure who it's parent is | 17:52 |
| synic | it's parent is the broken branch | 17:52 |
| beuno | synic, I believe unbind won't call the parent at all if it's a regular checkour | 17:53 |
| beuno | s/checkour/checkout | 17:53 |
| synic | heh, it's a --lightweight | 17:53 |
| beuno | aaargh | 17:53 |
| beuno | not your lucky day... | 17:53 |
| synic | no, no it isn't. | 17:54 |
| beuno | well, I'd find out what kind of beer abentley likes then :p | 17:54 |
| abentley | You could try doing bzr reconfigure --branch, though. | 17:54 |
| synic | in the checkout? | 17:55 |
| abentley | synic: yes. | 17:55 |
| synic | k | 17:55 |
| dacresni | I like irc so much more than forums, its so much harder to search for what you wnt | 17:55 |
| abentley | That assumes that upstream actually has the necessary revisions. | 17:55 |
| dacresni | c ya | 17:55 |
| abentley | bzr reconfigure replaces bind, unbind and remove-tree. | 17:56 |
| abentley | Though I suppose you probably want reconfigure --tree. | 17:57 |
| dacresni | hey, back | 18:01 |
| dacresni | had a bit of a "problem with the package | 18:02 |
| dacresni | well, i just wan'ted to fix my commit signing process | 18:03 |
| dacresni | it responded gpg: problem with the agent - disabling agent use | 18:05 |
| dacresni | bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']" | 18:05 |
| dacresni | is this a bzr issue or a gpg issue | 18:06 |
| dacresni | ? | 18:07 |
| dacresni | beuno are you still there? | 18:07 |
| beuno | dacresni, yes, although I haven't used gpg signing in bzr | 18:08 |
| beuno | have you signed any commits yet? | 18:08 |
| dacresni | i tried | 18:08 |
| dacresni | no i haven't | 18:08 |
| beuno | do you have your key setup with gpg? | 18:08 |
| dacresni | i think so | 18:09 |
| dacresni | i followed the instructions on the pgp site | 18:09 |
| dacresni | i mean gpg | 18:09 |
| dacresni | and those of the bzr site linked from bzrVSgit | 18:09 |
| dacresni | the one http://blogs.gnome.org/jamesh/2007/10/04/signed-revisions-with-bazaar/ | 18:10 |
| beuno | dacresni, and you've setup the email to use to sign commits? | 18:12 |
| dacresni | im using this localy | 18:12 |
| dacresni | so no | 18:12 |
| beuno | dacresni, does: gpg --list-keys print out your key? | 18:15 |
| dacresni | hmm | 18:15 |
| dacresni | yes | 18:15 |
| beuno | and that's the same email address you have configure in "bzr whoami"? | 18:16 |
| dacresni | pub something | 18:16 |
| dacresni | uid, my info | 18:16 |
| dacresni | accept for the comment | 18:16 |
| dacresni | o wait | 18:16 |
| alefteris | beuno, the upgrade prosedure at a launchpad branch sure takes a while :) | 18:16 |
| dacresni | ok, so i put my whole name | 18:16 |
| dacresni | thanks i guess ill be fixing that | 18:17 |
| beuno | alefteris, ah, yes, large branches + remote access are always fun to watch :D The upgrade is worth it though! | 18:17 |
| beuno | dacresni, np | 18:17 |
| dacresni | shouldn't it not use the comment? | 18:18 |
| dacresni | thats kind of silly | 18:18 |
| dacresni | i have 2 keys, one at home and one at work | 18:19 |
| beuno | dacresni, that's why you can specify your email on ~/bazaar/, so it can find the key you want | 18:19 |
| dacresni | i c | 18:20 |
| dacresni | ok, so i added the comment to my email, | 18:21 |
| dacresni | thats probibly going to screw up my patch emails should i use them in the future | 18:21 |
| dacresni | email not valid | 18:22 |
| dacresni | seriously, does anyone know how that works? does it really compare the entire line? or could it exempt the comment? | 18:23 |
| beuno | dacresni, I haven't used it really. jelmer, I believe I've seen you play around with signing commits? | 18:24 |
| dacresni | dang, i wonder if that came from intering the pass fraze to often | 18:29 |
| beuno | dacresni, sorry, everyone seems busy today | 18:30 |
| dacresni | 'ts ok | 18:30 |
| dacresni | it seems the probliem with pgp | 18:30 |
| dacresni | there seems to be a problem with the aigent | 18:31 |
| jelmer | beuno: yep, I'm signing most of my commits | 18:35 |
| dacresni | could you help | 18:36 |
| jelmer | dacresni: is there a particular reason you'd like to sign commits ? There is no way to verify signatures yet afaik | 18:36 |
| dacresni | well, | 18:36 |
| dacresni | i was trying to get my boss to use it | 18:36 |
| jelmer | dacresni: Should be a matter of setting "create_signatures = always" | 18:36 |
| dacresni | but first i need to get the security features workign | 18:36 |
| dacresni | o yeha | 18:36 |
| dacresni | thats already there | 18:37 |
| dacresni | otherwise it wouldn't be asking me to sign would it? | 18:37 |
| jelmer | dacresni: right, so what exactly is your question ? :-) | 18:37 |
| jelmer | that should be all there is to it. | 18:37 |
| dacresni | why isn't gpg working, sorry it seems to be a problem with the agent | 18:38 |
| jelmer | dacresni: Have you got gpg working outside of bzr ? | 18:38 |
| dacresni | just now, no | 18:38 |
| dacresni | i'll give you the error message | 18:38 |
| dacresni | gpg: problem with the agent - disabling agent use | 18:39 |
| dacresni | bzr: ERROR: Failed to gpg sign data with command "['gpg', '--clearsign']" | 18:39 |
| jelmer | dacresni: Did you create a key earlier? | 18:39 |
| dacresni | but first i need to find out yes | 18:39 |
| jelmer | dacresni: Also, there is no added security in signing revisions at this point.. | 18:39 |
| dacresni | yes i created the key | 18:39 |
| dacresni | oy, | 18:39 |
| jelmer | Does "gpg --clearsign <somefile>" on the command-line work? | 18:40 |
| dacresni | same issue | 18:40 |
| dacresni | gpg: problem with the agent - disabling agent use | 18:40 |
| jelmer | the agent is optional | 18:40 |
| dacresni | and then proseads | 18:40 |
| dacresni | well, this is kind of confusiong | 18:41 |
| jelmer | that's just a warning, it should work fine without the agent as well | 18:41 |
| dacresni | sorry | 18:41 |
| dacresni | confusing | 18:41 |
| dacresni | it did work, (im finding that i've already commited something" | 18:41 |
| dacresni | but bzr still exits with an error | 18:41 |
| jelmer | it does the signature after the commit | 18:41 |
| dacresni | was this resolved in later version? | 18:41 |
| dacresni | well let me see | 18:42 |
| jelmer | so if the sign fails you will still have a revision, it just won't be signed | 18:42 |
| dacresni | well | 18:42 |
| dacresni | i can't find the revision comment | 18:42 |
| dacresni | that IS a problem | 18:45 |
| jelmer | dacresni: it's not in "bzr log" ? | 18:46 |
| dacresni | nope | 18:46 |
| dacresni | has anyone else experienced this problem | 18:46 |
| dacresni | ? | 18:46 |
| jelmer | dacresni: What problem specifically? | 18:46 |
| jelmer | not being able to sign revisions? | 18:46 |
| dacresni | i will disable the signing but, not being able to comment revisions | 18:47 |
| dacresni | thats a problem | 18:47 |
| jelmer | dacresni: What do you mean with "comment" revisions? | 18:47 |
| dacresni | let me see if disableing signing allows my comments to be saved | 18:47 |
| jelmer | dacresni: Not being able to specify a commit message? | 18:47 |
| dacresni | well, | 18:48 |
| dacresni | theoreticly yes but, if its not saving my comments, it snot saving my revisions | 18:49 |
| dacresni | i want to know if this ever happened in a more recent version | 18:49 |
| dacresni | im using, just now, 1.1.0 sorry | 18:50 |
| dacresni | i thought i was using 094 like i was an hour ago | 18:50 |
| jelmer | dacresni: What do you mean with comments? commit messages? | 18:50 |
| dacresni | "the package gave me errors in debian" | 18:50 |
| dacresni | yes the commit messagese | 18:50 |
| jelmer | dacresni: Does it ask you for a commit message or do you specify one on the command line? | 18:51 |
| dacresni | its been fixed after signing was disabled | 18:51 |
| jelmer | ok | 18:51 |
| dacresni | it asked for a commit message | 18:51 |
| dacresni | this is interesting behavior no? | 18:51 |
| alefteris | beuno, upgrade finished, ole :) | 18:51 |
| jelmer | dacresni: It simply doesn't add a revision for me if the sign step failed | 18:52 |
| beuno | alefteris, yay! Now reconcile should be fairly quick | 18:52 |
| dacresni | thats what's happened for me | 18:52 |
| dacresni | i just didn't look at it like that | 18:53 |
| jelmer | dacresni: That's correct. | 18:53 |
| dacresni | so where is the branch where they are implementing the security? | 18:55 |
| dacresni | the revision signing? | 18:55 |
| jelmer | dacresni: Revision signing has been supported for a long time | 18:55 |
| jelmer | afaik nobody has started working on signature verification yet | 18:55 |
| dacresni | ps this didn't happen at home, on my mac. i dont think | 18:56 |
| dacresni | here im using ubuntu | 18:56 |
| jelmer | dacresni: what exactly didn't happen on your mac? | 18:56 |
| dacresni | at home, macports on a g5 | 18:56 |
| dacresni | it worked as normal | 18:56 |
| dacresni | i installed macgpg | 18:56 |
| dacresni | then added the line to my bazaar config | 18:56 |
| jelmer | dacresni: It's gpg that's misconfigured on your Linux machine | 18:56 |
| dacresni | then i signed some local commits, and it worked | 18:56 |
| dacresni | probibly | 18:56 |
| jelmer | I'm quite sure it is | 18:57 |
| dacresni | i do believe the probem was with gpg | 18:57 |
| dacresni | this is why i straddle between mac and linux | 19:01 |
| dacresni | linux you have democracy issues and mac you have monarchy issues | 19:01 |
| dacresni | like that dtrace issue... perhaps i should use solarus | 19:01 |
| jelmer | dacresni: There are more userfriendly frontends for gpg on Linux | 19:02 |
| dacresni | but how can any work if gpg has issues | 19:02 |
| jelmer | They can take of configuring gpg for you | 19:03 |
| dacresni | so what does that/ | 19:03 |
| dacresni | ? | 19:03 |
| jelmer | what do you mean? Examples of programs? | 19:03 |
| dacresni | yes, please | 19:03 |
| dacresni | first, whats this agent the error speaks of? | 19:07 |
| jelmer | dacresni: seahorse is one | 19:10 |
| jelmer | dacresni: gnupg's agent program | 19:10 |
| jelmer | dacresni: I don't use it but apparently you've got it configured | 19:10 |
| dacresni | but what is the agent in reference to gnupg | 19:10 |
| dacresni | and why did mine screw up | 19:11 |
| brink_ | Am I somehow getting Bazaar from the wrong universe? On Windows and OSX I'm at 1.1.0 On Ubuntu the most recent version from apt-get seems to be 1.0.0.candidate.1. Is my Ubuntu installation messed up? | 19:11 |
| jelmer | dacresni: You may want to ask in the gnupg channel | 19:11 |
| jelmer | dacresni: I suspect it's something similar to ssh-agent | 19:11 |
| jelmer | but for gpg | 19:11 |
| jelmer | dacresni: Still, why are you so keen on setting up signing revisions? There's no point in doing so at this time and Bazaar may have better integration with apps like seahorse in the future. | 19:12 |
| dacresni | i c | 19:12 |
| dacresni | well, i wanted to get some kind of security so that this app is comparable to git in some other way other than workflow flexablility | 19:13 |
| Peng | brink_: Get it from PPA. | 19:14 |
| Peng | brink_: https://launchpad.net/~bzr/+archive | 19:14 |
| jelmer | dacresni: revision signing won't get you any security at all at this point. it may help you verifying the integrity of now signed revisions in the future | 19:16 |
| dacresni | well, ok | 19:16 |
| dacresni | the only reason why i look at this project more closely than git is because it's all done in one language | 19:16 |
| dacresni | instead of 5 | 19:16 |
| jelmer | dacresni: I agree it's a useful feature though | 19:16 |
| dacresni | 1 being c | 19:16 |
| jelmer | dacresni: bzr is written in python... | 19:17 |
| dacresni | no i mean one of gits language being c | 19:17 |
| jelmer | ah, ok | 19:17 |
| brink_ | Peng: Thanks. I'll give it a try. | 19:21 |
| Peng | Wait, so signed revisions aren't verified? | 19:22 |
| dacresni | yup | 19:22 |
| Peng | That...sucks. | 19:22 |
| dacresni | i would like it if it varafied the integrity of the signature before its accepted to the tree on bzr servers | 19:23 |
| dacresni | i guess we'll have to settle for ssh | 19:23 |
| dacresni | not that that's a bad thing | 19:24 |
| * Debolaz still has a fondness for the simplicity of git's design. | 19:28 | |
| dacresni | hmm | 19:29 |
| dacresni | im curious of what that is | 19:29 |
| jelmer | Debolaz: in what way is git simpler than hg or bzr? | 19:29 |
| dacresni | i mean, simple is linus's style but how is git siimple | 19:29 |
| jelmer | the way the commands work? | 19:29 |
| dacresni | the security model itself | 19:30 |
| dacresni | ' | 19:30 |
| dacresni | ? | 19:30 |
| Debolaz | The commands are horribly complex. | 19:30 |
| dacresni | exactly | 19:30 |
| Debolaz | But the fundamental ideas that git is based on are very simple. | 19:31 |
| dacresni | and those are? | 19:31 |
| jelmer | Debolaz: I don't see that those ideas are so different from the ones in bzr or hg though | 19:31 |
| dacresni | the decentralization model bzr copy | 19:31 |
| jelmer | dacresni: bzr is older than git... | 19:31 |
| Debolaz | Everything is an object in a filesystem, named after its content. Every branch is simply a file pointing to an object. When you update, you just make new objects and write the name of the head tree object to the branch file. | 19:32 |
| dacresni | really? | 19:32 |
| dacresni | i didn't know that | 19:32 |
| Peng | Also, the DVCS model is older than either bzr or git.. | 19:33 |
| jelmer | Debolaz: The only thing that's different there is that bzr doesn't name a file after its contents but uses a pseudo random id | 19:33 |
| Debolaz | It could easily be reimplemented with a few shell scripts. Horribly inefficiently implemented, but still very simple in concept. | 19:33 |
| dacresni | ? git could be reimplemented in a few shell scripts? | 19:34 |
| jelmer | Debolaz: I still don't see what's so fundamentally different. | 19:34 |
| === mw is now known as mw|food | ||
| dacresni | so mw is out to lunch"? | 19:34 |
| jelmer | I think it's dinner, rather | 19:34 |
| dacresni | its only 1 | 19:35 |
| dacresni | o wait | 19:35 |
| dacresni | never mind | 19:35 |
| Debolaz | jelmer: Well, I never made the claim that it was fundamentally different. But it is different, and it is simpler. Granted, I know very little about bzrs internal workings, but even if what you say is the only big difference in storage, then that still increases complexity by some bit. | 19:36 |
| rcohen | some complexity is necessary to get efficiency and features | 19:37 |
| rcohen | git's original storage model was horribly space inefficient | 19:37 |
| Debolaz | Yes it was. But very simple. | 19:38 |
| jelmer | Debolaz: Using ids rather than file contents to identify files doesn't impact the complexity of the storage layer all that much | 19:38 |
| jelmer | Debolaz: And you've still failed to mention a reason why it's simpler. | 19:38 |
| rcohen | simple and unusable for the primary use case | 19:38 |
| rcohen | i'm not sure what's so admirable about simplicity if it doesn't do what you need | 19:39 |
| Debolaz | jelmer: You lose the ability for renames to be detected by design for instance. You have to track this differently somehow (Possibly using hashes, but then you're back at square one again). | 19:39 |
| dacresni | well, this has been the argument between git and bzr before, storage format | 19:39 |
| Debolaz | Let me again emphasize that I'm not saying anything bad about bzr here, I barely know bzr. :) | 19:39 |
| jelmer | Debolaz: bzr tracks renames explicitly rather than inferring them using complex algorithms that have to determine whether one file was a rename of another. | 19:39 |
| rcohen | it's highly debatable whether automatically detecting file renames is a good idea | 19:40 |
| dacresni | it might because not could cause duplicity | 19:40 |
| rcohen | it can do really bad things in the worst case, and a lot of effort is put into making sure that the worst case for a merge algorithm isn't all that bad | 19:41 |
| jelmer | Debolaz: Right, I'm not saying git is bad or there are no reasons for picking git over bzr either. I just don't understand why you claim git is simpler... | 19:41 |
| fullermd | CVS is simpler yet; we should switch :) | 19:41 |
| jelmer | rcohen: yeah, I agree. It's usually better if you can predict when it's not going to work | 19:41 |
| jelmer | fullermd: :-) | 19:42 |
| jelmer | rcohen: Finding the right way to track file identity is hard though | 19:43 |
| jelmer | rcohen: bzr uses file ids, but they only allow you to track renames, not e.g. copies | 19:43 |
| rcohen | i'm a big fan of doing it explicitly | 19:43 |
| rcohen | i don't think supporting copies is all that useful | 19:44 |
| rcohen | the point of doing it would be that whatever merge algorithm would be aware of it | 19:44 |
| rcohen | in my experience, a user would use the copy when they wanted to split a file | 19:45 |
| jelmer | copies can be useful when splitting files | 19:45 |
| fullermd | I'm a lot more interesting in splits and joins. But copies you can kinda get for free with those mechanisms, so... | 19:45 |
| rcohen | which, if you then tried to merge across it, would cause horrible conflicts and ambiguity | 19:45 |
| Debolaz | jelmer: Because I gave the complete description of how the fundamental of git works above, and I do not think bzr or hg can be described with as few lines. git is a simple design. Possibly at the cost of efficiency, userfriendlyness (Yeah, I agree about the commands being less than idea), and other things. Bzr might be better at those things and yes, I agree those things are a higher priority for most users. | 19:45 |
| jelmer | Debolaz: the description you just gave above almost matches bzr and hg | 19:46 |
| rcohen | Debolaz: the point is that in order to be useful even git has taken on extra complexity | 19:46 |
| rcohen | Debolaz: by comparing git "conceptually" to the implementations of bzr and hg you're comparing apples and oranges | 19:47 |
| Debolaz | jelmer: I know there are significant differences from it at least for hg. Simply naming a revision by a SHA1 ID is not the same thing as actually storing the content in a file with that name. The former might be a part of something significantly more complex. | 19:47 |
| Debolaz | But I guess we can agree to disagree, I don't want to make this turn into a flamewar. :) | 19:47 |
| jelmer | Debolaz: yeah, let's do that :-) | 19:48 |
| fullermd | Shucks. I was just making popcorn... | 19:48 |
| jelmer | rcohen: Yeah, merges would be an interesting problem for splits | 19:48 |
| jelmer | rcohen: but it would be awesome if we could get that working | 19:48 |
| rcohen | jelmer: believe me, i've thought a lot about it | 19:49 |
| rcohen | there be dragons | 19:49 |
| Debolaz | However, I would like to make a point about automatic detection, not neccesarily about renames. Whenever something isn't automatically detected, or enforced a certain way, users will screw it up. I think the most notable example of this is subversion branching. | 19:49 |
| jelmer | rcohen: :-) | 19:49 |
| jelmer | rcohen: even without proper merge support being able to represent copies would be nice though | 19:49 |
| jelmer | rcohen: since we get that data when we import from other version control systems | 19:50 |
| rcohen | jelmer: it's hard to say what should happen without merge support | 19:50 |
| rcohen | let's say your merge doesn't know anything about copies and the system pretends that the full history applies to both files | 19:50 |
| rcohen | now, you didn't really want a copy, you wanted a split | 19:51 |
| rcohen | so you go ahead and delete half of each file | 19:51 |
| rcohen | in another branch, someone modified the file | 19:51 |
| rcohen | then you merge that branch in | 19:51 |
| rcohen | suddenly, you've got a massive conflict in the file which deleted that section | 19:52 |
| jelmer | rcohen: ouch, yeah, that would be a problem | 19:52 |
| rcohen | now let's say you didn't want to split, you really wanted a copy (because you're into cutting and pasting, who knows) | 19:52 |
| jelmer | Debolaz: yeah, leaving out the concept of a branch really hurt Subversion | 19:52 |
| rcohen | someone in another branch modifies the file | 19:53 |
| jelmer | Debolaz: and it hurts bzr-svn now, since it has to guess what users consider a branch | 19:53 |
| rcohen | you merge that branch in, both files get the merge, but you only wanted the "original" to get the change | 19:53 |
| foom | is there a way to create a branch in an svn repository using bzr? | 19:54 |
| foom | i tried bzr push but it threw an error at me | 19:54 |
| jelmer | foom: try "bzr svn-push" | 19:54 |
| rcohen | one of the big problems is that there are conflicting use cases for copy | 19:54 |
| jelmer | foom: I haven't gotten round into implementing it in "bzr push" yet | 19:54 |
| foom | aha, thanks. :) | 19:54 |
| rcohen | i could make you even more afraid if you wanted to support a separate "split" command :) | 19:55 |
| dacresni | thats like telling telling a species with no eyes that something is red | 19:55 |
| jelmer | rcohen: I was about to suggest that :-) | 19:55 |
| jelmer | rcohen: Actually, we already have a split command, but it splits trees, not files | 19:55 |
| dacresni | thats only a little inefficient | 19:56 |
| rcohen | jelmer: let's take an easy case for split, the top and bottom halves of a file each go their own way | 19:57 |
| abentley | beuno: The error message we have is Could not install revisions: sasongko@gmail.com-20080129204555-7h0j46m8wwlpcff2 | 19:57 |
| rcohen | jelmer: what happens if in another branch someone adds content at the place where the file was split? | 19:57 |
| rcohen | jelmer: it gets worse if there are conflicts at the split point | 19:58 |
| abentley | beuno: I realize you've already seen something like that. | 19:58 |
| jelmer | rcohen: Representing that conflict in the file(s) would be the tricky bit. | 19:59 |
| rcohen | jelmer: it's not so much the problems with the merge algorithm and the UI | 19:59 |
| Debolaz | jelmer: I've had to extend git-svn for the same reason. It makes the ideological but foolish assumption that the subversion users know what they're doing. :) | 19:59 |
| rcohen | s/and the UI/as the UI/ | 20:00 |
| jelmer | rcohen: Perhaps create conflicts in both files, adding a conflict in both cases and a comment? | 20:01 |
| jelmer | rcohen: I see your point though | 20:01 |
| rcohen | jelmer: also remember that was the easy case :) files can be split in other bizarre ways which may not be detected properly or are partial copies, etc etc | 20:02 |
| jelmer | Aaron has also explained some other issues potential issues with merges after copy earlier | 20:02 |
| jelmer | Even without merge, I think copy could be still be quite useful though | 20:03 |
| jelmer | for "bzr log" and "bzr annotate" | 20:03 |
| * fullermd seconds. | 20:03 | |
| jelmer | and just for roundtripping | 20:03 |
| rcohen | so just an annotation in the history which says "this file was copied from that file"? | 20:03 |
| rcohen | but not actually used for anything | 20:04 |
| jelmer | rcohen: Well, only when looking at the history of a file | 20:04 |
| jelmer | rcohen: Do you know whether Subversion supports merges across copies? | 20:06 |
| rcohen | not offhand, though i doubt it | 20:06 |
| abentley | rcohen: A day after you expressed reservations about LCA not doing resolution against the base initially, a user found the problem with that; it doesn't emit conflicts when one side deletes a line, but the other changes it. | 20:06 |
| abentley | rcohen: But in my defense, knit gets that wrong too. | 20:06 |
| rcohen | abentley: ah, knit can be made to do that correctly :) | 20:07 |
| rcohen | there's a subtle difference in how cdv and bzr implement the algorithm | 20:07 |
| rcohen | in cdv, the annotations are on the space between the lines, which catches deletes | 20:08 |
| abentley | rcohen: Yeah, I know. | 20:09 |
| abentley | But even if you're even if you're versioning the lines, suitable historical info will let you catch that case. I'm pretty sure weave handled it, and I believe I can extend LCA to handle it, too. | 20:10 |
| rcohen | yes, weave should handle it | 20:10 |
| rcohen | if you are going to add annotation information to the pack format in the future, that may be worth keeping in mind | 20:11 |
| abentley | rcohen: Do you know offhand whether annotation of the lines can be cheaply transformed into annotation of the edges? | 20:12 |
| rcohen | i understand that there are practical tradeoffs to be made, you obviously don't want to show the between-line versioning to users when they use the "blame" command so it would be extra info | 20:12 |
| rcohen | i don't think so | 20:12 |
| rcohen | i haven't really looked into it, it may be possible to store a small set of differences and otherwise make it automatic | 20:13 |
| rcohen | abentley: if you have a fast way of determining whether i change came after another, then i think only the deletes would get lost | 20:15 |
| abentley | Pity deletes are the reason we're interested in edge annotation :-) | 20:16 |
| rcohen | yeah :) but storing the standard annotation plus a little extra deletion info might work | 20:16 |
| abentley | Anyhow, I'm interested in edge-base merging generally because I believe it can do moves within files, and between files. | 20:18 |
| rcohen | there be dragons | 20:19 |
| rcohen | i'm currently more interested in improving the UI for conflicts | 20:19 |
| rcohen | there are some conflicts which are difficult for users to resolve | 20:20 |
| rcohen | for instance, someone deletes a big section of code, someone else makes a 1 line change to it | 20:20 |
| fullermd | That one bits me with some regularity :| | 20:21 |
| rcohen | the poor merging user is left to stare at these 2 huge blocks of code and figure out what's different and why | 20:21 |
| dacresni | how does git handle it? | 20:21 |
| dacresni | i mean, thats what comments are for | 20:21 |
| dacresni | to tell why | 20:21 |
| dacresni | in both revision comments and inline comments to the code | 20:21 |
| abentley | rcohen: Oh, I certainly have bigger fish to fry than that. | 20:22 |
| fullermd | Comments don't help when I'm staring at 1 line of code, and 80 lines of code, where I took that one line from the 70-some that were on the other side last time, and have no idea which were added. | 20:22 |
| rcohen | abentley: i've come to consider UI a big fish | 20:22 |
| abentley | That is, I don't plan on implementing edge merging soon. | 20:22 |
| abentley | I agree that UI is more important. | 20:23 |
| abentley | You get quickly diminishing returns with merge algorithms. | 20:23 |
| rcohen | now, if your merge algorithm has annotation information, it should be possible to call out the 1 line which caused the conflict for the user | 20:23 |
| dacresni | it sounds like you can't tell when either line was added or subtracted or which | 20:23 |
| rcohen | abentley: absolutely agreed on diminishing returns, fun as it is to work on merge algorithms | 20:24 |
| rcohen | i've got another crazy idea about doing per-conflict virtual common ancestors | 20:25 |
| rcohen | i came up with it in the context of weaves, but it may be possible to fit it into other merge algorithms | 20:25 |
| brink_ | Is there a way that version-info could somehow be inserted into my code automatically? | 20:34 |
| brink_ | A revision number would be fine. | 20:34 |
| cliechti | i have a low power/low resources hardware where a wiki like moinmoin uses too much memory. so i thought i could use a bazar repository there, with a working copy on the server. i'd then run docutils over that copy to generate my HTMLs. so, is there an easy way to run update and a script when i push my local repo to the server. | 20:41 |
| cliechti | i could write a plugin, but is there a hook that is executed on the server when i do a push? | 20:42 |
| dato | cliechti: maybe you'd like to take a look at http://ikiwiki.info, a static wiki "compiler". it's recently gained (or is about to gain) bzr support. | 20:45 |
| cliechti | dato: ok, that's the direction i'm thinking of, but it seems that ikiwiki is using perl, so it is the wrong language with P for me ;-) and i'm having my nice ascii art to svg plugin in docutils :-) | 20:49 |
| dato | cliechti: I'm completely a python person myself, but am quite happily using ikiwiki for my personal site. ymmv. | 20:50 |
| beuno | abentley, did you find out anything about that broken branch (FYI, it's not really mine, I was just helping out and got curious) | 21:45 |
| abentley | Kinda. I'm on a call right now. | 21:46 |
| * synic perks | 21:46 | |
| beuno | abentley, no hurries | 21:49 |
| igc | morning | 22:36 |
| Rolly | Hi all. I keep getting an AttributeError: 'module' object has no attribute 'ssl' error when I try to branch any https:// url. Here's the bzr output: http://p.caboo.se/private/x2dbvkbelnrngdsscb9s1w | 23:04 |
| Rolly | does anyone have a clue? I have googled to no avail | 23:04 |
| beuno | Rolly, seems you're missing a dependency | 23:05 |
| Rolly | you think it's a python problem, or a bzr problem? | 23:05 |
| Rolly | I am clueless when it comes to python, I'm afraid | 23:06 |
| beuno | Rolly, neither, you're probably missing some package | 23:06 |
| beuno | let me check | 23:06 |
| Rolly | thanks :) | 23:06 |
| mwh | looks like your python doesn't have ssl support | 23:07 |
| mwh | which is a little strange | 23:07 |
| mwh | Rolly: what os are you on? | 23:07 |
| Rolly | yeah, I just saw this: http://paltman.com/2007/11/15/getting-ssl-support-in-python-251/ | 23:08 |
| Rolly | I'm on a debian etch box | 23:08 |
| Rolly | w/ python2.4 installed from apt | 23:08 |
| mwh | maybe you need to install python-ssl or something | 23:08 |
| beuno | yeap, svn2bzr doesn't seem to require any special dependencies | 23:08 |
| mwh | _however_ | 23:09 |
| mwh | in this case just branch from http://bazaar.launchpad.net/~niemeyer/svn2bzr/trunk | 23:09 |
| Rolly | cheers, I didn't think of that | 23:11 |
| mwh | that's what the url you were trying to access would have redirected you to | 23:12 |
| Rolly | installing the ssl 1.13 python package didn't work | 23:14 |
| Rolly | I would try to install python 2.5 from source, and use that. But I'm afraid to bork anything on this box that depends on python 2.4 :p | 23:14 |
| mwh | there's not usually much reason to install things from source on debian... | 23:16 |
| mtaylor | Rolly: install python2.5 packages? | 23:16 |
| Rolly | mtaylor: I did, but the system python (`which python`) remains my old 2.4 | 23:17 |
| Rolly | mwh: probably, but I'm mystified by the package system. For example, how would I go about reconfiguring my existing python 2.4 install? I have no idea | 23:18 |
| Rolly | mwh: actually, http://bazaar.launchpad.net/ redirects to https://bazaar.launchpad.net/ | 23:22 |
| Rolly | :( | 23:22 |
| cliechti | mwhudson: do you have something to do with lag.net (loggerhead homepage)? the last two development link at the bottom of the page do not work properly | 23:39 |
| mwhudson | no | 23:39 |
| === Rolly is now known as kumi | ||
| === kumi is now known as rolly | ||
| === mw|food is now known as mw | ||
| rolly | cool, I fixed my problem with just "apt-get --reinstall install python2.4" | 23:47 |
| rolly | :) | 23:47 |
| rolly | Hmm, there's a problem with svn2bzr. I have to comment out "import bz2", because that's part of Python now. But then bzr crashes with global name 'bz2' is not defined in lines like this: self._tree_cache[str(revno)] = bz2.compress(marshal.dumps(tree, 2)). | 23:52 |
| mtaylor | rolly: why do you need to comment out import bz2? | 23:53 |
| rolly | because if I don't, I get ImportError: No module named bz2 | 23:54 |
| mtaylor | rolly: that's because you don't have it then... | 23:54 |
| rolly | I think I read somewhere that bz2 is part of python | 23:54 |
| mtaylor | it is | 23:54 |
| bob2 | that would be because it is NOT part of python :) | 23:54 |
| mtaylor | but you still need to import it | 23:54 |
| mtaylor | to use it | 23:54 |
| rolly | Ah ok | 23:54 |
| mtaylor | mtaylor@solace:~$ python2.4 | 23:54 |
| mtaylor | Python 2.4.4 (#2, Jan 3 2008, 14:46:35) | 23:54 |
| mtaylor | [GCC 4.2.3 20071223 (prerelease) (Ubuntu 4.2.2-4ubuntu3)] on linux2 | 23:54 |
| mtaylor | Type "help", "copyright", "credits" or "license" for more information. | 23:54 |
| mtaylor | >>> import bz2 | 23:54 |
| mtaylor | >>> bz2.__file__ | 23:54 |
| mtaylor | '/usr/lib/python2.4/lib-dynload/bz2.so' | 23:55 |
| mtaylor | but that file is in the python2.4 package | 23:55 |
| mtaylor | what python is your bzr trying to use? | 23:55 |
| rolly | 2.4.1 | 23:55 |
| mtaylor | head -1 `which bzr` | 23:55 |
| rolly | #!/usr/local/bin/python | 23:56 |
| mtaylor | ah. installing python from source are we? | 23:56 |
| rolly | that's 2.4.1 | 23:56 |
| mtaylor | ok, so that python install doesn't seem to have bz2 | 23:57 |
| mtaylor | is your bzr also in /usr/local/bin - like, you build/installed it from source? | 23:57 |
| rolly | hmm... that is obviously not the python I just reinstalled via APT. That was 2.4.4 I'm sure | 23:57 |
| mtaylor | right | 23:57 |
| rolly | I did build bzr from source | 23:57 |
| mtaylor | that would be in /usr/bin/python | 23:57 |
| mtaylor | ok. | 23:57 |
| mtaylor | so that means it's also in /usr/local/bin/bzr, right? | 23:57 |
| rolly | correct | 23:57 |
| mtaylor | any particular reason for installing from source? or that's just the way you did it? | 23:58 |
| mtaylor | rolly: you're running debian testing, right? | 23:58 |
| rolly | and also correct that /usr/bin/python can import bz2 | 23:58 |
| rolly | :| | 23:58 |
| rolly | mtaylor: I don't think so. How do I check? | 23:59 |
| mtaylor | cat /etc/debian_version | 23:59 |
| rolly | 4.0 | 23:59 |
| mtaylor | apt-cache show bzr | grep Version | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!