[00:02] http://libwilliam.wordpress.com/2008/08/01/anjuta-bazaar-plugin-v010/ [00:11] cool [00:21] jam: Is it possible the branch you were having issues with is a loom? [00:21] Odd_Bloke: no [00:22] It happened *after* the process finished [00:22] not at the beginning [00:23] jelmer: he gave a lot of caveats and problems, but he didn't really say what it was supposed to do [00:23] Is this the xml-rpc service? [00:23] Or is it a different UI ? [00:23] Ah, I guess anjunta is another IDE [00:23] I hadn't heard of it before [00:23] jam: yeah, it is [00:23] it's a GTK+ based on [00:23] e [00:24] jam: Hmm, OK. No ideas remain. :) [01:52] Why does TreeDelta have an unchanged field? [01:52] It makes it very hard to implement an optimized version of it since knowing what was unchanged requires retrieving full contents rather than an actual delta :-( [01:53] treedelta is very old [01:53] I'd look at changing whatever needs it to not need it :) [03:40] is there an - err - canonical version of bzr.png anywhere? [03:41] markh, something like http://bazaar-vcs.org/LogoOptions ? [03:42] jelmer: something very much like that - thanks! [03:43] interesting - the copy of bzr.ico there is different than in bzr.dev - bzr.dev doesn't have a transparent background, which I was looking to "fix" [03:50] Dear me, loggerhead looks _so_ _much_ better_. Good job! [04:06] new loggerhead? [04:06] * evarlast updates [04:38] evarlast: There isn't a new release, but the trunk is very nice. https://code.launchpad.net/~loggerhead-team/loggerhead/trunk [04:39] I was just looking at the loggerhead on edge. [04:43] Is it just me, or could a bunch of the branches on https://code.launchpad.net/loggerhead be marked as Merged? [05:00] bzr upgrade over sftp is not a lightning-fast operation. [05:00] :( [05:01] Thinking of which, would it be possible to have a nice big "upgrade this branch to $DEFAULT_FORMAT" button on launchpad? [05:05] I like that idea. I guess you should file a bug. [05:11] What's codehosting's tracker? [05:11] I'd throw it in launchpad-bazaar, but I might be wrong. [05:12] Yeah, that sounds right. [05:14] That is right [05:31] bug #254135 filed. Feel free to comment/triage. [05:31] Launchpad bug 254135 in launchpad-bazaar "Add UI to upgrade a hosted bzr branch" [Undecided,New] https://launchpad.net/bugs/254135 [07:46] <^mo> morning [07:58] <^mo> mornign [07:58] <^mo> uh [07:58] <^mo> morning :) [07:58] ^mo: Morning. :) [08:02] <^mo> guys [08:02] <^mo> i am currently looking into misusing Bazaar (and other DRCS) [08:03] <^mo> the idea is to use a DRCS to backup and synchronize my files on multiple machines. mostly photos, binary documents (office), you name it. [08:04] <^mo> it's a shame there is no good dedicated tool to do that. so i thought about building one on top of a DRCS [08:05] <^mo> the idea is to monitor specified directories for changes, auto-commit them into a local repository, and auto-sync that to other repositories, either on my server or to other machines directly. [08:08] <^mo> so, i'm evalutating different DRCS for that [08:08] <^mo> unfortunately i seem to be the only one considering this "misuse" [08:49] ^mo: rsync is doing the big part of that [08:54] <^mo> but it doesn't do revisions, does it? [09:30] hey guys. Quick question, is there something like merge --preview but for a heavyweight checkout? As in, preview the changes before updating. === davi_ is now known as davi [10:18] scorpioxy_: sorry no [10:18] scorpioxy_: should be straight forward to do if you'd like to file a bug [10:44] lifeless: so you think this is something that other people might want? My use case is for a looking at changes first instead of reverting later... [10:46] lifeless: if you say that it is straight forward to do, then i'll try and implement it myself. [10:49] scorpioxy_: /away [10:49] scorpioxy_: I think its something that other folk might use yes [10:49] and it makes sense to offer 'dry run' style things for commands where we can [10:49] robtaylor: excellent [10:50] lifeless: yes, i thought so too...thank you [10:53] Hm. So, one of the problems with the crazy-long bzr upgrade-over-sftp process is that it appears that people can try to branch the repo while it's happening, and get not-particularly-helpful error messages for their trouble. [11:03] RAOF: yes [11:04] lifeless: Is there a bug already filed about that? [11:05] RAOF: its kindof by design [11:05] RAOF: I don't think there is an explicit bug; be worth having one [11:06] Kindof by design that people can try to branch from a repo in the process of being upgraded? [11:06] we don't have read locks on branch or repository [11:07] nor a thing to check to see if someone is doing operations like reconcile/upgrade [11:07] what's the ETA for 1.6? [11:07] and we wouldn't want one that is costly/problematic [11:07] Where are my CDs dissappearing to? Now I can't find Eternal Nightcap or White Blood Cells. Grr [11:07] But a bug to sit around and track that it's a real problem isn't a bad thing. [11:07] gour: soon; don't know exactly [11:08] I've already filed a bug that, if implemented, would almost eliminate this problem - a Launchpad button for upgrade. [11:08] RAOF: doesn't eliminate the problem at all [11:08] No, but it makes it vastly less likely that someone will hit it. [11:09] RAOF: not really [11:09] RAOF: there are many people that host their own branches over sftp [11:09] But they will often/mostly have shell access to the host box? [11:10] RAOF: if they are hosting over sftp no [11:10] It makes it vastly less likely that _I_ will hit it. [11:10] well only you can assess that :) [11:10] why are you hitting it? LP has a public mirror that should protect you from hitting it on other peoples branches [11:11] It wasn't me who hit it, but I was upgrading the do trunk and someone tried to pull and got a missing revision error. [11:12] Since the upgrade took somewhat in the order of an hour, there seems to be a nice big window for breakage. [11:12] I can hunt down the exact error message if it'd be helpful. [11:13] no [11:13] upgrade is roughly [11:13] backup [11:14] delete the repository [11:14] make a new one [11:14] fetch from the backup [11:15] ...so, bzr-svn will follow 1.6 shortly [11:16] I don't know [11:16] jelmer (is he the author) told so [11:18] is there any 'bzr-idiom' for naming feature branches in shared repo for e.g. project 'prj' ? [11:19] I don't understand the question [11:21] a shared repo is just disk usage optimisation, doesn't change naming or anything [11:23] right, but if I have shared repo for the project named 'prj' any idea how to name a branch based on 'prj' which reprsents work on certain feature/bug-fix etc. ? [11:26] I'd name branches after the feature or bug fix [11:26] without 'prj' in the name? [11:26] entirely up to you [11:27] but if you have the project name in the url already, its a bit redundant to have it in the branch basename as well [11:27] it's a 'local' project - my study notes [11:28] thanks for the input [11:30] np [11:30] just pulled latest code from your search plugin ;) [11:32] lifeless: hmm, what's this - http://rafb.net/p/2UMbPn85.html [11:33] that branch needs 1.6b4 [11:34] when was 1.6b4 released? [11:34] i built bzr from repo yesterday, r3596 [11:36] you sure you are using that bzr? [11:36] bzr 1.6b3 on python 2.5.2 (linux2) [11:36] arguments: ['/usr/bin/bzr', 'index'] [11:37] lifeless: see http://rafb.net/p/tbz8zT49.html [11:38] that says 1.6b3 [11:39] r3596 [11:40] no [11:40] hmm [11:40] 3596 is after 1.6b4, you have not installed that [11:41] built and installed yesterday [11:41] clearly not! [11:41] find the directory you have 3596 in [11:41] run ./bzr --version [11:41] [root@nitai gour]# ls -al /var/abs/local/gaur/bzr-bzr-3596-1-x86_64.pkg.tar.gz [11:41] -rw-r--r-- 1 gour gour 4141984 2008-08-01 14:58 /var/abs/local/gaur/bzr-bzr-3596-1-x86_64.pkg.tar.gz [11:42] i got nothing for ./bzr [11:44] i'll remove that pkg and re-build [11:48] robertc@lifeless-64:~/source/baz/bzr.dev$ ./bzr version --short [11:48] 1.6b4 [11:48] robertc@lifeless-64:~/source/baz/bzr.dev$ ./bzr revno [11:48] 3596 [11:48] re-built the package and now I get 1.6.b4 and same r3596...strange :-/ [11:50] hmm, commiting one patch takes quite loooooong [11:54] when i'm finished with the feature or bug-fix and merge changes into 'trunk', i can safely dismiss feature/bug-fix branches ? [11:57] yup [11:57] once it's merged the revisions are linked in to another branch, so you can delete the one that you created them in, without risk of losing them [11:58] with darcs one had to be careful if some patch went 'out' and then it was rm-ed in another repo [12:00] james_w: it looks someone listened and tried with newer bzr - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation?action=diff&version=59 [12:00] ;) [12:00] well, that's an improvement [12:02] right. i did not got any reply from JaffaCake after sending him some bzr-ad-info, but maybe he took a look [12:02] still too slow to downloads 90MB of data [12:02] *download [12:03] having ghc switch from darcs will impact the whole haskell community. it may happen that the whole hackage.haskell.org will adopt something else [12:03] based on that wiki page, it looks that cherry-picking is the major Cons of bzr [12:04] that is what I don't understnad, because git and hg are no better in that area [12:05] luks: have you seen that page? [12:05] yes, somebody posted the link here a few days ago [12:05] you can add (as guest) some more relevant info [12:06] heh, no I won't :) [12:06] why not? [12:06] git/hg users do the same [12:06] I just don't promote things, unless they are really good [12:07] bzr isn't? [12:07] I don't think so [12:07] i'd say it is on the level of hg and being simpler/safer than git [12:08] I'm not saying it's worse than git or hg, it's better IMO, but it's not "really good" [12:08] well, that's not pragmatic...we have to live with what we have NOW [12:08] and project are switching to new VCSs NOW, not sometime in the future [12:08] I do live with what we have now, so I use bzr, but I'm not going to promote it :) [12:09] you know [12:09] * gour promotes things which he uses NOW [12:09] that git - bzr difference is around about the size difference in groupcompress [12:10] ...and i'm sure bzr will catch those performance issues to not be issues any longer [12:11] anyway, here is the url for anyone inspired to add some objective info to it - http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation [12:12] guest/guest are credentials [14:57] jelmer: hey... when i bzr checkout a svn trunk, and make commits to it directly and then run bzr update, it pulls down the same commits i just made to be committed again [14:57] am i doing something wrong? [14:58] rocky, that doesn't sound right [14:58] what version of bzr, bzr-svn? [14:58] bzr 1.5 [14:58] lemme check bzr-svn [14:59] bzr-svn 0.4.10 [15:00] rocky: Can you pastebin some example output of doing a commit and an update? [15:02] trying... [15:02] bzr commit's to svn are still very very slow [15:04] that should be a fair bit better with 0.4.11 [15:04] jelmer: http://cluebin.appspot.com/pasted/561 [15:07] rocky, how slow is slow? [15:07] seconds, minutes? [15:07] well, to do that commit of that recurring item takes about 50sec or so [15:08] wow, ok [15:09] I'm trying to figure out what's going wrong [15:10] give me a few minutes [15:10] beuno, pin [15:10] g [15:19] hehe, k [15:35] http://rafb.net/p/2SLT6g34.html <-- I get that traceback from bzr [15:35] what should I do [15:35] what I did was: [15:35] bzr rm util-linux-ng [15:36] then bzr st crash with that error [15:36] AnMaster: I think that error might be fixed in bzr.dev [15:37] spiv, well how do I get my repo working again [15:37] I need it working now [15:37] how can I restore it to working order [15:37] spiv, I need help with that! [15:38] spiv, how can I get the repo working again!? [15:38] AnMaster: so if you're comfortable running a copy of bzr.dev (just "bzr branch http://bazaar-vcs.org/bzr/bzr.dev", then run bzr from the bzr.dev directory), I'd try that. [15:38] spiv, is that the only way? [15:38] to restore the repo [15:38] AnMaster: your repo is fine, as is your branch [15:39] AnMaster: the only part that's having a problem is the workingtree [15:39] AnMaster: "mkdir util-linux-ng; bzr add util-linux-ng; bzr st; bzr rm util-linux-ng" fixes it I believe [15:39] james_w, not sure... [15:40] AnMaster: so another thing you can do is "bzr branch . ../new-copy" and resume work from that [15:40] it looks very strange now [15:40] http://rafb.net/p/ji2wT482.html [15:40] that is a bit odd [15:40] spiv, ah thanks that worked [15:40] Not really, "bzr add" adds new files. [15:41] If you want to restore old files, use "bzr revert" (or potentially bzr add --file-ids-from). [15:41] spiv, bzr revert did also crash [15:41] actually not crash first time: [15:41] bzr: ERROR: No such file: u'/home/anmaster/abs/standard-recompiled/util-linux-ng/cryptoloop-support.patch' [15:41] when I tried to revert [15:42] anyway branch worked [15:42] That's probably caused by the same bug, I'd guess. [15:42] AnMaster: that's good news [15:42] It's late here, so I'm off to bed. [15:42] AnMaster: please file a bug with that traceback and if possible information to help us reproduce [15:43] spiv, hm I got no idea how to reproduce, I can't even manage to reproduce myself [15:43] AnMaster: ok, just the traceback is fine then. [15:44] hm ok [15:44] spiv, bug tracker is on launchpad right? [15:44] AnMaster: I suspect we may already have that bug in our bug tracker (and possibly even have it fixed for the upcoming 1.6 release), but it's good to make sure we're not missing things. [15:44] Right. [15:44] hrrm then to figure out if it exists [15:44] (Especially bugs that are hard for non-experts to recover from!) [15:45] AnMaster: if you're not sure, if it takes too long to figure out if it's already report, just quickly file a new bug anyway. [15:45] you got a few with the same text "Could not find target parent in wt" but I got no clue if they have the same cause [15:45] AnMaster: it's quite easy to mark a bug as a duplicate, it's harder to take a bug report and say "oh and the 'me too' in comment 11 is actually a different bug that just looked similar" :) [15:46] actually I think I used normal (non-bzr) rm on some files that I did bzr add on but hadn't commited [15:46] then did bzr rm on the directory that I added and didn't commit [15:46] where those files were located [15:46] spiv, can you reproduce that way? [15:47] AnMaster: I'm sorry, I'm actually nodding off (it's past midnight here) [15:47] AnMaster: it sounds plausible, though [15:47] unable to reproduce that way [15:47] AnMaster: thanks for your patience, and I'm glad we got you going again. [15:47] * spiv -> bed [15:48] ah no I need to commit after adding [15:48] then it crashes [15:52] https://bugs.launchpad.net/bzr/+bug/254220 [15:52] there [15:52] Launchpad bug 254220 in bzr "Crash on rm on file, bzr rm on directory and then bzr st" [Undecided,New] [15:53] jelmer: You there? [15:53] dwt, hi [15:53] Super. [15:53] I talked to you some days ago about bzr-svn always crashing on startup on my mashine [15:53] (mac, leopard, fink) [15:53] Well, I found the problem [15:54] (well one of the problems :) [15:54] But I'm not sure what the right way to fix it would be [15:54] The problem is, that on os x with fink [15:54] the subversion libraries are in /sw/lib/svn15 [15:54] instead of /usr/lib where setup.py is setup to expect them [15:55] (while the headers reside in /sw/include.... [15:55] ) [15:56] This caused setup.py to link against an old version in /usr/lib which caused the crash [15:56] (subversion 1.4 there) [15:57] dwt, subversion 1.4 should work as well though [15:57] hm. [15:57] it used libapr in the latest version from fink though [15:57] maybe that was the reason for the crash then? [15:58] dwt, yeah, I guess conflicting aprs may be a problem [16:00] What do you think would be the best solution to this problem? I'd rather use the fink installed libraries than the apple provieded (those ar always very old) [16:01] But looking at the setup.py (and me not knowing a lot about it) I see no simple way to just tell it to look at a specific point in my filesystem for it's libraries [16:01] and headers [16:06] it will try to find the apr-config utility [16:06] make sure the apr-config instance it should use is first in your $PATH [16:06] yeah, that works and is correctly overridden by fink [16:07] That doesn't work for subversion though [16:08] (or maybe I'm missing something) [16:12] dwt, one sec, I'll add some magic for that [16:12] jelmer: cool! [16:12] jelmer: svn libraries are in /sw/lib/svn15, while headers are in /sw/include/subversion-1 [16:13] I've added a SVN_PREFIX environment variable [16:13] (0.4 branch of bzr-svn) [16:13] does that account for an (IMO dumb) name choice like svn15 for the library dir? [16:13] instead of just svn? [16:19] jelmer: well it almost works, just a small copy'n'past error [16:20] === modified file 'setup.py' [16:20] --- setup.py 2008-08-02 15:12:53 +0000 [16:20] +++ setup.py 2008-08-02 15:17:57 +0000 [16:20] @@ -95,8 +95,8 @@ [16:20] svn_prefix = basedir [16:20] break [16:20] if svn_prefix is not None: [16:20] - return ([os.path.join(basedir, "include/subversion-1")], [16:20] - [os.path.join(basedir, "lib")], []) [16:20] + return ([os.path.join(svn_prefix, "include/subversion-1")], [16:20] + [os.path.join(svn_prefix, "lib")], []) [16:20] raise Exception("Subversion development files not found. " [16:20] "Please set SVN_PREFIX environment variable. ") [16:20] [16:20] (I believe) [16:20] Other than that, I've just got to solve the problem of my package manager insisting to put the svn libraries in a folder called svn15 instead of just svn [16:20] yep [16:20] thanks [16:27] jelmer: I was able to build it by doing a second patch: [16:27] === modified file 'setup.py' [16:27] --- setup.py 2008-08-02 15:20:48 +0000 [16:27] +++ setup.py 2008-08-02 15:25:44 +0000 [16:27] @@ -96,7 +96,7 @@ [16:27] break [16:27] if svn_prefix is not None: [16:27] return ([os.path.join(svn_prefix, "include/subversion-1")], [16:28] - [os.path.join(svn_prefix, "lib")], []) [16:28] + [os.path.join(svn_prefix, "lib/svn15")], []) [16:28] raise Exception("Subversion development files not found. " [16:28] "Please set SVN_PREFIX environment variable. ") [16:28] [16:28] However I don't think that this could go into the repo [16:28] yeah, indeed [16:29] What do you think would be the most 'not ugly' solution to this? [16:29] Another environment variable seems very wastefull [16:29] though I honestly don't know of any alternative [16:29] maybe having SVN_LIB_DIR and SVN_INCLUDE_DIR would be a bit better? [16:31] Is bzr really the only VCS that lets you work over S/FTP? [16:34] no [16:34] jelmer: Success! Now I get an exception in check_subversion_version() in __init__.py :) [16:34] dwt: patches are welcome :-) [16:35] jelmer: :) I'm looking into it [16:35] regarding the setup.py [16:35] would you accept a patch with two environment variables that are preffered if set? [16:36] bob2: which other VCSs support it? [16:39] jelmer: Do I need to run anything else besides make to build a fully functional svn plugin? [16:39] dwt, no, that should be sufficient [16:39] because the error is that it cannot load the client module [16:39] ImportError: cannot import name client [16:40] dwt, can you pastebin the full backtrace perhaps? [16:40] Pilky: arch! [16:40] in __init__.py on line 98 [16:40] sure [16:40] any paste preffered? [16:40] dwt, never mind, it was the line number I was after [16:40] :) [16:40] dwt, make should've built a client.so or something in the bzr-svn directory [16:41] jelmer: well it did, and it also seems as if it is linked up correctly [16:41] dwt@dwcp ~/.bazaar/plugins/svn % ll client.so [16:41] -rwxrwxr-x 1 dwt dwt 196728 2 Aug 17:37 client.so* [16:41] dwt@dwcp ~/.bazaar/plugins/svn % otool -L client.so [16:41] client.so: [16:41] /sw/lib/svn15/libsvn_client-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) [16:41] /sw/lib/svn15/libsvn_subr-1.0.dylib (compatibility version 1.0.0, current version 1.0.0) [16:41] /sw/lib/libapr-0.0.dylib (compatibility version 10.0.0, current version 10.12.0) [16:41] /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) [16:41] /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.1) [16:42] bob2: ah, well it's still a surprisingly rare feature given how useful it is, I'm surprised more isn't made of it [16:42] dwt, perhaps it's some MacOSX-specific feature :-( [16:42] s/feature/problem/ [16:42] :) [16:43] lets, see [16:43] what is the easiest way to get pyton to give me a debugger at that point? (I'm still not very good at python myself sadly) [16:45] not sure if you need a debugger here, probably just a python prompt [16:46] you should be able to get one by simply running "python" [16:46] :) [16:46] jelmer: don't suppose you saw anything blatantly wrong with the paste i showed earlier? where it was recommitting the same thing? [16:46] rocky, sorry, I got distracted while I was looking into that [16:47] rocky, There's nothing obviously wrong [16:47] hehe [16:47] uhm... importing client.so from python directly works extremely fine. [16:47] rocky, can you perhaps file a bug so it at least doesn't get forgotten? [16:47] right [16:48] I still intend to have a look at it soon, since I presume this blocks you from actually using bzr-svn? [16:48] jelmer: trying from bzrlib.plugins.svn import client however gives an error [16:49] dwt, you need to tell bzr to load its plugins first [16:49] -> the same that happens in the scrept [16:49] e.g. "from bzrlib.plugin import load_plugins; load_plugins()" [16:49] I'l try [16:49] still the same error [16:50] well not really [16:50] interestingly if I try "from bzrlib.plugins.svn import client" [16:50] it goes through __init__.py [16:50] and dies there at the same line that it dies when loading the plugin in bzr [16:51] (that is line 98) [16:51] if I change that to drop the "from bzrlib.plugins.svn" [16:51] it works [16:52] (that is, it throws at a similar line further into the script [16:52] ) [16:53] jelmer: It seems it somehow doesn't think of itself as 'bzrlib.plugins.svn' [16:53] when being in place [17:05] jelmer: Do you have any idea why that might happen - or am I completely on the wrong ship here? [17:05] dwt, No idea, sorry [17:05] :) Ah well. [17:05] dwt, you could try removing the "bzrlib.plugins.svn." prefix everywhere it comes up [17:05] since it should work as well with relative imports [17:06] but I have no idea what's going on that's breaking it [17:06] just a second [17:06] same here [17:06] :) [17:08] does anyone has knowledge about the bzr webserve plugin ? It seems to exist a branch wich support collections ala hgwebdir. Did anyone ever tried that ? [17:09] i mean : https://code.launchpad.net/~fdivbug/bzr-webserve/collections [17:11] kiorky, any particular reason you're looking into webserve rather than loggerhead? [17:11] jelmer: publishing a bunch of repositories [17:11] I don't think webserve is maintained very actively anymore [17:11] ok [17:12] jelmer: ha, i may be wrong with webserve usage [17:12] jelmer: can i clone over "webserve" ? Because that is what i was thinking. [17:12] kiorky, afaik not [17:12] jelmer: to do something similar of hgwebdir [17:13] jelmer: like http://hg.minitage.org [17:13] kiorky, something like http://bzr-playground.gnome.org/? [17:13] jelmer: To sum up, my goal is to achieve that, with bzr [17:14] kiorky, it's probably worth asking the loggerhead developers about [17:14] jelmer: yep [17:16] jelmer: the page you gave me is a loggerhead thing, isnt it ? [17:16] yeah [17:18] is a hg "repository" along the lines of a bzr branch? [17:18] jelmer: i cliked on a tag, to http://bzr-playground.gnome.org/gnome-doc-utils/trunk/, then i can branch that. What i want to ask: are the modules in the same repo or there are multiple repos ? [17:18]