[00:00] hm [00:00] I probably meant 1k [00:00] beuno: internally, bzr log will be traversing the whole list, as will 'bzr revision-info' if it gets a non-mainline commit [00:00] beuno: so calling it 1 time with a lot of revisions [00:00] should be a lot faster than calling it lots of times. [00:01] jam, I shoulds absolutely go down that path then [00:02] I wonder how hard it would be to change the current code... [00:07] in what contexts is bzr-git intended to be presently usable? [00:16] nDuff: proof of concept, afaik [00:16] bzr fast-import is the recommended way to convert from git [00:16] bzr-git probably has some bitrot, etc. [00:17] I think it could run 'bzr log' on a git repository [00:19] bob2: I believe that was working as well [00:19] because it could run "bzr viz" at the time [00:24] yes, my first fraft at EP2006 did that :P === mw is now known as mw|out [02:06] abentley, ping [02:06] rockstar: pong [02:07] You seem to be close to my timezone, and I'm rather interested in getting into Bazaar hacking, probably outside of Canonical time. I was wondering if we could arrange a mentoring situation. [02:08] I promise to stay out the way as much as possible. [02:08] rockstar: Sure, I'd be happy to. [02:08] Did you have a task in mind? [02:09] Not really. I looked at the bug list, and I'm not really sure I know enough to say "That's a good starter bug" [02:09] There are actually a few that are tagged that way. [02:10] * rockstar looks again [02:10] Look for the "easy" tag. [02:11] Ah, 23 of them. [02:11] Also "trivial". [02:12] I can't guarantee that the assessment is right-- some are probably only "easy" until you actually try to fix them... :-) [02:13] abentley, yea, that's what I gathered out of some of the trivial bugs. Didn't see the easy ones === kiko is now known as kiko-zzz [02:14] Alright, I'll just take one of these, and start exploring. Be prepared to be harassed. [02:16] If you let me know which one you're doing, I can give you some starting points. [02:17] I was thinking this one: https://bugs.edge.launchpad.net/bzr/+bug/200575 [02:17] Launchpad bug 200575 in bzr ""Address already in use " crashes smart server" [Medium,Triaged] [02:18] rockstar: It seems there's already a patch attached to that bug. [02:19] Ah, bugger [02:19] https://bugs.edge.launchpad.net/bzr/+bug/89570 [02:19] Launchpad bug 89570 in bzr "unknown format exception could be clearer" [Low,Confirmed] [02:22] rockstar: I'm not sure what more needs to be done there. [02:23] Newer formats do indicate the minimum Bazaar version in their format strings. [02:23] But people still get thrown from time to time. [02:24] Of course, it's impossible for Bazaar to guess what version is required for an unknown format. [02:24] Alright. How 'bout I take an hour or so and find a few of them, and them come back to you. :) [02:25] Sure. [02:47] poolie: ping [02:48] thumper: poolie on an leave today [02:48] s/an/on/ [02:48] igc: thanks [02:48] igc: are you up for a call? [02:49] I guess so [02:49] you sound so enthusiastic ;-) [02:49] well - I'd need to know what's its about [03:45] * igc lunch [04:26] BB is temporarily down while I update the machine. [05:02] out to a medical appointment - bbl === mwhudson_ is now known as mwhudson [06:44] BB back. Failed to install Hardy. [06:44] eep [06:45] abentley: Upgrading from what to Hardy? [06:45] Peng: Feisty [06:46] Oh. [06:46] Now, it's a Xen box, so not your standard install target. But still ... [06:47] Gutsy to Hardy was trivial for me, but then, that server (VPS) didn't have much of anything installed at the time. [06:48] Peng: The stuff failing was pretty basic stuff, like initramfs-tools [06:50] You did go through gutsy, right? [06:50] RAOF: Yep. Gutsy was where the problems started. [06:51] Eh. [06:51] I'm not sure if I've never had problems updating or whether I just don't remember them ;) === doko_ is now known as doko [07:10] i see that opensolaris uses bzr-0.7 when evaluating and it looks speed was their concern for 'cons' [07:11] same with mozilla... [07:13] 'cons'? [07:13] opposite of 'pro' [07:13] ah [07:13] 0.7? [07:13] thought it might be run by lisp nerds [07:14] gour: Bzr has gotten a lot faster, of course, (and better in every other way) but it still has problems with huge projects. [07:14] gour: that is true, but then when they were evaluating bzr 0.7 was all that was out. Personally I think they were short sighted in their decision, but it is difficult to fault the "set criterion and then pick the one that scores best" approach. It's called "engineering" :) [07:15] i do not plan to use bzr for such big project(s), but i'm more interested to hear about other kinds of problem i had with darcs-1 like doppleganger bug and exponential time [07:15] 0.7? That's older than what's in Gutsy. [07:15] hi AfC [07:16] It's unfortunate, because the Bazaar project lost out on a significant adoption opportunity there. While no one really cared about OpenSolaris, as such, it was obvious that whatever they picked would be adopted by the Java Engineering team at Sun, which in turn is propagating out via Open Java rapidly. [07:16] rockstar: see http://www.opensolaris.org/os/community/tools/scm/bzr-eval/ [07:17] james_w: hey James. Been a while. I hope you're well. [07:17] I'm good thanks, how are you? [07:18] AfC: with mozilla it was similar situation? [07:18] james_w: Just about to go for a run, actually. Thought I would chime in before I set off. [07:18] so you're ready to make a quick exit [07:22] so, bzr probably does not have 'doppelganger' problem by design? [07:23] gour: not that we know of [07:24] that's nice...i was bitten by it in darcs several times... [07:24] gour: if you're talking about http://research.operationaldynamics.com/blogs/andrew/software/version-control/red-giant-bugs.html then, no, Bazaar doesn't have that problem [07:25] gour: let me put it this way. If you are doing work with Bazaar and you have a project that is so large or a use pattern that is so unusual so as to cause Bazaar problems, I can only suggest that you will likely find interest here and likely will find that if you can offer your repository to the Bazaar hackers to work with that they will be able to use it in their tests and optimizations. [07:26] here it is in more detail - http://wiki.darcs.net/DarcsWiki/ConflictsFAQ [07:27] AfC: thanks. i had similar experience with darcs (droundy was inspecting my repos), but, unfortunately not easy to fix those design-issues [07:27] gour: otherwise, asking "is it fast enough" is all a bit silly, really. If it wasn't, there wouldn't be so many people here using it quite happily. Could it be faster? Probably, but that's the wrong question. Does it work reliably? Does it prevent you from shooting yourself in the foot and thereby loosing data? Does it have a clean and consistent user interface? are far more relevant. [07:27] another nice thing i see in bzr is bzr-svn (i might soon switch to NixOS and they stil use svn) [07:27] gour: as I noted, we used Darcs for years, loved it, and miss it still. [07:27] gour: Yeah, bzr-svn rocks. [07:28] AfC: right. git is like automatic gun to shoot your foot all the time :-D [07:28] and fast like a greased fox [07:29] AfC: my 'speed' argument was just in the light of bzr vs. hg for solaris and mozilla [07:29] for me it's not so important - finally, that's why we use dvcs ;) [07:29] gour: but Bazaar is an improvement in many other areas, so we swallow our impatience with the less-then-Darcs user interface and abysmal lack of cherry picking support in favour of having a robust tool with a vibrant and intelligent group of hackers working on it. [07:31] AfC: so far (reading user manual etc.) i like bzr, today i'll try with some tests...interface looks nice (i won't even compare it to git's surprises) [07:31] * gour --> breakfast. bbs [07:31] AfC: maybe I can convince you to hack on bzr-interactive ? :p [07:31] Pshaw. git's interface makes perfect sense if you follow a few simple steps. [07:32] First, you become Linus... [07:32] fullermd: no, you've got to learn Finnish first. [07:35] Ah, no wonder it doesn't work right. I keep mixing up those Scandinavian countries. [07:35] % git de bork bork bork [07:35] git: 'de' is not a git-command. See 'git --help'. [07:37] * AfC goes out === weigon__ is now known as weigon [08:51] What is the version of bzr-svn you have to have to work with bzr 1.4? [09:03] AfC: there isn't one that works with 1.4, as far as I know [09:10] 0.4.10 is compatible with 1.4 and 1.5 [09:10] * igc dinner === mario_ is now known as pygi [09:50] i see that bzr help formats shows plethora of different formats...will this trend to continue or is it reasonable to expect bzr to settle on some proven one? [10:09] gour: Well, they probably thought they were going to settle on each one as they created it. [10:09] gour: But yes, it should go down. [10:10] Peng: the 0.92 format is that git-like 'pack' format? [10:11] gour: I'm sure the implementation is different, but it's the same idea, yeah. [10:11] gour: BTW, there are 5 or 6 more hidden formats! ;) [10:12] only? [10:12] :-D [10:13] gour: Whenever they've changed the branch, repository or working directory format, they've added a new format to the formats list, and pretty much all of them are still supported. [10:14] gour: E.g., I think dirstate is just knit with a different working tree format. dirstate-tags is just dirstate, only the branch supports tags. pack-0.92 uses the same branch and working tree formats as dirstate-tags, but an entirely new repo format. [10:16] in any case, 0.92 is default now and recommended one? [10:16] gour: Also, there are now multiple variations of the same base format: There's pack-0.92; rich-root-pack, which is the same but supports slightly more meta data; and pack-0.92-subtree, which has experimental support for stuff similar to svn:externals. [10:16] gour: pack-0.92 is. [10:17] gour: They want to switch the default to a rich-root format soon, which will simplify things somewhat. (Rich roots are perfectly stable, but you can't downgrade from a rich-root format to a non-rich-root format.) [10:30] Peng: in 1.6 ? [10:31] gour: Maybe. [10:31] it would be nice [10:44] bzr: ERROR: Transport error: Server refuses to fullfil the request [10:44] 'sup with that? [10:47] elmo: Are you the guy from the mailing list? [10:47] Peng: err, i don't know? if you mean, have I posted about this problem on the mailing list, then no [10:47] I only ran into it 10 seconds ago [10:47] elmo: Then, someone else has the same issue on the mailing list. :) [10:47] ok [10:47] apparently it's a 1.4 regression too [10:48] someone else with 1.3 claims it WF him [10:48] I'll try downgrading [10:48] elmo: Run bzr with -Dhttp -Dtransport and pastebin the relevant section of your .bzr.log (warning, really long). [10:48] elmo: Are you experiencing this with the same branch? [10:48] Peng: same branch as what, sorry? [10:51] wow, it really does work with 1.3 [10:52] elmo: I presume this isn't python-apt--debian-sid from mvo's people.debian.org you are trying to grab? [10:53] it's http://bzr.debian.org/da-tools/da-tools/userdir-ldap-common [10:53] 1.4 seems to a POST? [10:53] which gets 403ed [10:53] did 1.3 -> 1.4 have the addition of probing for the smart server? [10:53] ah, yes, it seems so. [10:54] elmo: I think nosmart+http:// is the transport that forces that off, which should allow you to work around this. [10:54] james_w: 'apt-get install bzr/hardy' is good too :-) thanks [11:01] filed as #230223 [11:03] thanks === mwhudson__ is now known as mwhudson [11:19] jam: Ping? [11:48] Hi, I'm having a rather small Mercurial repo, and need to move it to Bazaar.. So, I'm using fast-import: bzr init-repo new.bzr ; hg-fast-export.py --repo=../old.hg | bzr fast-import - .. I copied first all files from old.hg.. but, it says "bzr: ERROR: No WorkingTree exists for" ... I'm missing a step somewhere? [11:49] Kemurii: init-repo doesn't make a branch or a tree [11:49] try bzr init-repo new.bzr; bzr init new.bzr/import-branch; cd new.bzr/import-branch [11:49] then the same commands again [11:49] ah, mm [11:51] Kemurii: Just out of curiosity, why move from hg to bzr? [11:51] same question here as well [11:51] Peng: company policy, I'm sticking with Mercurial for personal stuff [11:52] Kemurii: Oh. That sucks. [11:52] At least the company policy isn't VSS or something. [11:52] well, 'company policy', nothing says I have to do it in bzr, but well.. :) [11:53] mwhudson: hehe, that somehow worked :) thanks! [11:53] Kemurii: no worries [11:55] Kemurii: Oh, good. [11:55] mtaylor: here? [11:59] woohoo, pushed to parent, nice nice [12:01] now I have to learn typing 'bzr' instead of hg or bk [12:04] * awilkins proposes the evil solution of aliasing hg and bk to something that mocks and ridicules you [12:04] random-insult.sh should do [12:05] Kemurii: Your company policy is highly enlightened. I know shops that are still using VSS and moving to TFS [12:05] (blech) [12:06] Kemurii: because my prompt knows what vcs I'm using, I am tempted to start using 'vcs' as the command and let my shell sort it all out for me :-) [12:07] awilkins: not sure it's policy yet, just 1st option for VCS now [12:07] Kinnison: now that's an idea :) [12:09] At least in SVN shops you can still use bzr. [12:09] I'm the svn server admin here, and I use bzr these days. [12:10] vcs () { if [ "x$_VCS" = "x" ] then bzr "$@"; else $_VCS "$@" ; fi } [12:10] that should do the trick for me [12:10] hehe [12:12] TFS? [12:14] anyway, thanks again guys, back to work, I mean lunch, cheers [12:20] Team Foundation Server (with all new VSS! Blech!) [13:35] dato: I'm still failing at accessing that repo over http. I'm using your exact command too. [13:47] Is there some way to suppress the deprecation notice output when running bzr? [13:50] Hi, I was wondering if there was an issue with bzr-svn using authentication.conf ? I'm using 1.3.1-1 [13:51] lamby: odd [13:51] lamby: tried from another host? [13:57] dato: Ah, that seems to have helped. I'll poke a little more. [14:03] kaaloo: I'm not sure it even uses authentication.conf [14:04] Is there way to define location 'bookmarks', in the same way that the launchpad plugin lets you reference lp: ? [14:06] e.g. so I can define the 'mine' refers to bzr+ssh://example.com/bzr, and subsequently use bzr branch mine:trunk [14:07] pickscrape: THere's a bzr-bookmark or bzr-bookmarks plugin. Not sure how exactly it works. [14:08] Oh, cool [14:53] lamby: What bzr version are you using? [14:53] 1.4. [14:55] Now this is interesting, can reproduce on 1.5~rc1 from a different host. [14:56] Would you like a login? It's a testing machine anyway. [14:56] lamby: hi [14:56] Good afternoon. [14:56] sorry, I missed the start of this [14:56] is this a problem with http? [14:57] This started on pkg-bazaar-maint.. So the testcase is "bzr get http://bzr.debian.org/pkg-bazaar/trac-bzr/unstable/ trac-bzr". [14:58] ah yeah, I saw that [14:58] is there a difference in whether pycurl is installed on these machines? [14:59] Heh, psychic debugging.. Installing pycurl made it work. [15:00] I was going to suggest that yesterday, but thought it might be _too_ psychic to be right. :p [15:00] bug 230223 may be relevant then [15:00] Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223 [15:01] Ah yes, seems to be the same bug. tcpdump is confirming that only the POST is attempted, which 403s. [15:03] hopefulls spiv or vila will be able to find a fix soon. [15:04] Subtle ping. [15:04] jelmer: bzr-gtk just uploaded with DM-Upload-Allowed: yes. I'm still seeing the breakage when visualising via `olive-gtk` (when `bzr viz` works fine). Did you try a fix? Shall I file a bug? [15:05] james_w: well, there is already the workaround of nosmart+http:// [15:06] jam: true [15:06] james_w: you got the targets right :-) My plate is already pretty full so I'm not sure I can fix it quickly. But I think the diagnosis points to hpss probing, also bug #229076 is pretty similar [15:06] Launchpad bug 229076 in bzr "'Connection reset by peer' error when branching repository" [Undecided,New] https://launchpad.net/bugs/229076 [15:06] hehe, nice point jam, indeed nosmart for the win :) [15:06] phoen [15:07] * dato marks "upload bzr-gtk" off his TODO :) [15:07] vila: yeah, I think that's what it is. It also appears to be a difference in the handling of 403 response between urllib and pycurl. [15:08] * abentley really hopes we can get rid of pycurl soon. [15:28] sigh, I forgot to push to the bzrtools packaging branch again [15:33] Hey, is there a bazaar equivalent to git-archive? I'd like to spit out a tarball of all the files that are in version control. [15:34] export [15:34] "bzr export []" [15:34] location can end with .tar.gz to make a gzipped tarball [15:34] note that it exports the last revision, not the working tree, so uncommitted changes won't be included. [15:37] that's exactly what I want. Thanks! :D [15:38] vila, james_w: there also seems to be a problem where you get the 403 a long time after you started downloading [15:39] At least, that is what Ben Finney's logs seem to indicate [15:39] I'm guessing a permissions issue, but I'm not positive === kiko-zzz is now known as kiko [15:39] jam: yeah, I saw that just now, I was going to look at the permissions on the directory that you pointed to, but I'm currently locked out of that machine. [15:40] jam: I've been having some success with your service plugin as a backend for bzr-eclipse [15:41] hi, what is the best way to configure bzr over http with authentication? fastcgi or mod_python? or something else? [15:42] jam: I had to change it to threads rather than forks because the library implements ForkTCPServer with fork() (duH). No forks on Windows. [15:42] awilkins: I will warn you that bzrlib isn't particularly thread safe [15:42] jam: It should all be single-threaded access. [15:42] and you can fork under cygwin, so it *is* possible, but AIUI they had to jump through a lot of hoops to get it to work [15:43] jam: Yeah, I mean "the os module in CPython doesn't do fork()" [15:44] For the purpose I'm using it for, thread isn't so bad ; it gives charge of the process to the Eclipse instance with no extra steps involved. [15:45] Dammit, IO blocking again [15:46] awilkins: I would just mention that you probably want a plain TCPServer not a Forking* or a Threading* [15:46] I believe if you use the base class, you will get a single-threaded server [15:46] which is what you need anyway. [15:47] Perhaps I'll change it down one then... [15:49] It so annoying ; it works lovely when you run the tests one-class-at-a-time... then it blocks on IO when you run them as a block [15:50] Is JUnit multithreaded? [15:51] awilkins: I don't know about Junit, but enforcing multithreaded test running without requesting it seems like bad mojo [15:52] Or bad "juju" for JUnit :-) [15:53] awilknis: thanks, I'll check the code, maybe there is a fix [15:53] I am trying to set up a bzr repo for my project, which I migrated from svn. the bzr stuff is working ok, but I need to be able to checkout/checkin through http so as to mimick the previous setup. checkout through http is ok, but in order to commit, do I need webdav or anything like that? (I dont want to give the apache user full write permission to my repository) [16:02] ok, I managed to checkout my branch using bzr+http and mod_python... now a strange thing happened... if I try to check out a normal branch, it complains about KnitpackRepository is not compatible with RemoteRepository, but if I checkout a lightweight branch, then it works... [16:02] is this a feature or a bug? [16:02] "checkout a lightweight branch"? I'm not sure what you mean, "checkout --lightweight"? [16:03] yes [16:03] and yes, there are two options, bzr+http with write access, or webdav. I've not used either, so I don't feel confident to explain the pros and cons. [16:03] ricardokirkner: you converted from svn [16:03] which means you need to use 'bzr init-repo --rich-root-pack' locally [16:03] yes :$ [16:04] the problem is that the RemoteRepository is hiding the "real" versions on each side to give you a clearer error [16:04] you can also do "bzr upgrade --rich-root-pack" in your local repository [16:04] and things should work [16:04] ricardokirkner: I would probably recommend using bzr+http with write access, but I would *probably* do it as bzr+https: and make sure you have proper authentication at the http layer [16:04] jam, but then every developer will have to know that the project originally started in svn, and prepare a local repository by hand? isn't that a bit of counterproductive? [16:05] ricardokirkner: bzr-svn "jumped the gun" and started using some development formats [16:05] supported, but not default [16:05] we are working on making it the default format for 1.6 [16:06] jam, ok I think I understand. the correct behaviour should be that the bzr server tells the client which format that branch is, so that the client can create the repository in the correct format instead of assuming the default format. am I right? [16:07] ricardokirkner: you did 'bzr init-repo' on the local side first [16:07] if you did not do that [16:07] then doing "bzr branch" would preserve the source format [16:08] 'init-repo' is a good thing, but 'bzr branch' isn't going to upgrade your repo for you [16:08] as if you are using a specific format, there may be a reason [16:08] (old clients, etc.) [16:08] no jam, I did not issue init-repo on the local side first [16:08] I have a repo on the server side, but I just did a bzr co [16:08] ricardokirkner: hmm... that seems a bit weird, I'll try to check the code for a sec [16:09] ok, update on my bzr-svn problem, of it not using authentication.conf, actually pycurl was not installed, now I'm getting a "certificate verification failed" error from pycurl, which is actually true since I had to deal with that using svn co, but here pycurl simply fails [16:10] jam, if I try a bzr branch, then I get a traceback [16:10] ricardokirkner: ok, it does seem to be a problem with the RemoteRepository not reporting the right source format, I can reproduce it here trivially [16:10] ricardokirkner: interestingly 'bzr branch' works fine [16:10] ricardokirkner: can you paste your traceback [16:10] !paste [16:10] pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) [16:10] just a sec [16:13] jam, http://paste.ubuntu.com/12071/ [16:13] anyone uses fish shell? i just noticed it does not have bzr-completion :-( [16:15] ok this is an old bug that hasn't been fixed in pycurl : https://bugs.launchpad.net/bzr/+bug/82086 [16:15] Launchpad bug 82086 in bzr "pycurl transport causes tracebacks if the server's SSL cert cannot be verified." [Medium,Confirmed] [16:18] jam: your latest import cleanup to stats broke things... http://dpaste.com/49901/ [16:19] dato: update to trunk, you are using the wrong one [16:19] lp:bzr-stats is the official trunk [16:19] not the one on bzr.arbash-meinel.com [16:19] I'll try to fix my branch [16:20] hm [16:20] ok, sorry for the noise. [16:21] dato: you aren't the first one, I was just being lazy about my branch [16:21] I'll redirect it to launchpad [16:21] I supposed update-mirrors now lives in... lp too? [16:22] dato: actually, I don't know if I ever moved that one, I should [16:22] haha [16:22] dato: some old code there :) [16:22] I believe Jelmer was interested in helping with stats, so I moved it to lp: [16:22] dato: I haven't touched update-mirrors since 2006-06-19 [16:22] so almost 2yrs ago [16:23] I'm amazed it still works properly [16:23] I guess we have at least *some* api stability [16:23] *g* [16:23] it certainly does work, against 1.5 even [16:25] dato: can you try doing an update/pull/branch from my bzr.arbash-meinel.com/plugins/stats ? [16:26] I believe it should redirect you to lp:///bzr-stats now [16:26] stray \n in location, I'd say [16:27] dato: try again [16:28] works :) [16:29] dato: does it give you any indication, or just "work" but point at a different location when it is done [16:29] my understanding is it just works, but if you do "bzr info" you will find out it went somewhere else [16:30] yes, it changes your url [16:37] hmm, unfortunately the pycurl http transport implementation doesn't seem to use AuthenticationConfig as does the urllib2 implementation :( [16:50] http://paste.pocoo.org/show/50195/ <-- Urg, what's wrong? [16:51] (This is arch linux) [16:52] The very same command works well on my ubuntu box [16:53] bzr 1.3 [16:53] ok, I think I see what's happening, the svn repository is being accessed through WebDav over https, and it requires authentication to checkout a revision. Running bzr branch https://... is not getting through to bzr-svn because of the authentication issue, when starts to check the branch format, it coughs on a 401. On the other hand running bzr branch svn+https://.. tries to go through the svn smart server protocol which of course fails [17:01] dennda: it's something to do with paramiko. [17:02] if you search for the error string you should find the bug report. [17:59] how would I undo a merge? === kiko is now known as kiko-fud [18:00] revert? uncommit..? [18:01] mxpxpod: bzr revert [18:01] merge backwards? [18:01] if you didn't commit [18:01] asabil_: revert still leaves pending merges in the status [18:01] ah, wait [18:01] n/m... I was doing bzr revert * [18:02] bzr revert --forget-merges [18:02] only reverts the merge status [18:02] nice, thanks [18:12] mxpxpod: "revert" with no arguments will forget the merge status. Supplying arguments prevents that. [18:12] abentley: thanks :) [18:12] (revert with no arguments reverts all files too) [18:27] ricardokirkner: the exception shown here: http://paste.ubuntu.com/12071/ is a bug in 1.2.0 which has been fixed in later releases. You can get 1.5rc1 from http://launchpad.net/~bzr/+archive, or we can try to work out something else. [18:27] dennda: this is actually an interaction with a newer paramiko [18:27] if you use paramiko 1.7.2 you don't have that problem [18:28] paramiko 1.7.3 causes the "no attribute "get_name"" traceback [18:28] jam, thank you for your help. what version do you suggest me to use? I was using 1.4 previously, but downgraded due to some issues with that version too.. what is the most stable version (with a good amount of support for svn) for use in production right now? === kiko-fud is now known as kiko [18:57] jam: uff, I doubt I can install the older version through pacman that easily [19:08] Is there some sort of push-history in bzr? [19:43] ricardokirkner: sorry, about the delay, I have a sick child here. [19:43] anyway, what problem were you having with 1.4? [19:43] dennda: push-history? [19:51] jam: bzr stores the last push location [19:51] I wonder if it stores the last N locations [19:51] accessible via push N [19:52] I will drop the net now, brb [20:20] hello [20:20] i want to use bzr for backups, to version a folder on a different hard disk, is there a way not to have the entire repository on both disks? [20:21] i would like to minimize disk space [20:21] so if i could have JUST the repo on the backup disk and JUST the working copy on my normal disk it would be ideal [20:21] is that possible? [20:21] Stavros, maybe something along the lines of a lightweight checkiut [20:22] but, if you have large binary files, it might not be a good idea to use bzr [20:22] beuno: hmm, yes, how do i do that? [20:22] hmm [20:22] i have large binary files but they don't change much [20:22] they're mostly pictures and such [20:22] Stavros, bzr uses a lot of ram for binary files [20:22] i'd use git for backup (is that better for binaries?) but its windows support is lacking [20:22] oh [20:22] hmm [20:22] is this going to be one way syincing? [20:22] yes [20:23] mostly added files [20:23] no changed ones [20:25] Stavros, bzr will use aprox 3x the file size in RAM [20:25] sounds like a job for rsync or rsnapshot [20:25] just so you can calculate what it will take [20:25] but yeah, rsynce sounds like a better candidate [20:25] i do use rsync, i wanted a better solution because rsync takes ages === juliank0 is now known as juliank [20:28] thats odd, rsync should be rather fast since it's only checking file size and modification time (iirc) [20:30] hmm, indeed [20:30] maybe it's because around 10 mb === fullermd_ is now known as fullermd [21:37] hi, I've been around asking this a long time ago, but what is the best way to have a central repository with LDAP based authentication? [21:42] basically, we looked at bzr+http earlier, but there were some open bugs concerning those, so we left it at that... this was around 1.0 [22:37] brilliantnut: you could use 'bzr+ssh' and have ssh use pam+ldap for authentication [22:37] I believe you can even put ssh keys into ldap [22:38] Anyone know the bzr-svn syntax for subversion.conf for explicitly specifying the branches in the svn repository? [22:39] bzr svn-branching-scheme --set is crashing for me [22:42] incidentally, this was the exact suggestion we got the last time around, but we came back to bzr+http for some reason... We really need to bzr+http to work... [22:44] jam: we have followed instructions on http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi === c1|freaky_ is now known as c1|freaky [22:56] brilliantnut: I'm not sure what your current state is. You followed the instructions and it didn't work? [23:02] jam: yes. We followed the instructions on the link that I just posted. [23:03] /home/tech-admin/data/bzr is the repository, and is mapped to http://ourserver/bzr, /home/tech-admin/data/bzr/HEAD is the root branch. [23:04] bzr branch http://@ourserver/bzr works just fine [23:06] actually scratch that [23:07] bzr branch http://@ourserver/bzr/HEAD works just fine [23:07] bzr branch bzr+http://@ourserver/bzr/HEAD gives an error: bzr: ERROR: No repository present: "bzr+http://@ourserver/bzr/HEAD/" [23:10]