[00:01] No. I'm speaking about providing a port number when none was explicitly given in the URL to credential stores and for the authentication section matching process. [00:01] using the system's services database is not an ideal solution [00:01] allowing the transport handlers to provide it a reliable solution [00:02] ultimately, somewhere, something will open a socket to a specific IP address using a specific transport layer on a specific port. That information should always be available. [00:02] jfroy: no, you were talking about making transport convert port=None to the /etc/services one, which mwhudson is referring as *bad* because it will not respect .ssh/config [00:02] Now, granted, if the transport layer is an external process, it gets messy. [00:03] and that's only one case, I don't remember the specifics but there were other [00:03] vila: I agree with that [00:03] just thought I'd let you guys know.. restarting terminal fixed my problem [00:07] jfroy: look at "bzr log -m 'default port'" for previous attempt and when it was abandoned (with references to bugs that may provides better information than my failing memory :) [00:08] vila: yeah I intend to. Pragmatically speaking, I wrote a patch way back when for the http transport handlers to provide a port number. [00:08] And since the credential stores are ignored the the ssh transport layer, that may be a pragmatic approach to fix part of the problem. [00:09] Or I may just move the fallback to the keychain store and tell people to not specify a port for default port http sections. [00:09] *are ignored for the ssh transport layer [00:11] jfroy: http is different from other protocols regarding authentication as it's the only one where the socket is opened *before* authentication is attempted, but for the general case you can as well, use getservbyname in your wrapper when port==None [00:11] vila: yes, but it's highly unlikely the keychain store would be useful for anything else than http. [00:12] I'm interested in covering the 90% case :p [00:13] jfroy, then better do that without requiring a bzr modification :-P [00:14] *grumbles* [00:14] I don't disagree there :p [00:15] But, if a simple patch can allow other people to benefit, why not? [00:15] (assuming it ends up being a simple patch) === abentley1 is now known as abentley === montywi is now known as montywi|zzz === abentley1 is now known as abentley [00:43] jelmer: ever seen a sha1knitcorrupt error ? :( [00:49] rocky, yeah [00:52] jelmer: i'm getting that on one of my branches that came from a bzr-svn branch [00:53] rocky, created with lp:bzr-svn ? [00:53] not sure [00:53] could have been [01:03] jelmer: i'm running a script i found that is supposed to clean up some sha1 corrupt issues but it's reporting not being able to find an inventory.kndx ... ever seen that? [01:03] rocky, that looks like a bzrlib issue [01:04] right now i'm just trying to salvage a few important revs but even bzr diff is failing [01:05] it sounds like a clean "bzr clone" would fix it [01:06] so what's the diff between "bzr branch" and "bzr clone" then? [01:09] there is no difference [01:11] i branched into a new repo and there's still no inventory.kndx ... === KnightWhoSaysNi is now known as UdontKnow [01:24] rocky: current formats do not use kndx files [01:25] lifeless: ah [01:25] jelmer: when i run "bzr check -v" on a repo i get "7 inconsistent parents" is that typical? [01:25] that repo works fine btw [01:26] actually i'm getting 1 ghost revision, 1 revision missing parents in ancestry, and 7 inconsistent parents === abentley1 is now known as abentley [01:28] jelmer: this is on a fresh new repo and checking out svn+https://dev.serverzen.com/svn/cluemapper/ClueBzrServer/trunk :( [01:28] jelmer: i guess that svn repo has legacy corrupted bzr trunk problems ;( [01:29] rocky, the check results you mentioned aren't problems [01:29] jelmer: bzr reconcile blows up [01:29] rocky, how? [01:31] jelmer: http://paste.plone.org/26841 [01:33] mwhudson: try bbc again, with updated branches; should be faster still [01:33] rocky, you've hit bug 336749 [01:33] Launchpad bug 336749 in bzr-svn "reconcile raises a KeyError on a fresh branch" [High,Invalid] https://launchpad.net/bugs/336749 [01:33] jelmer: looks related to bug #336749 [01:33] lol yeah [01:46] jelmer: I would have to build baz myself, I think ... that is, it isn't in Debian anymore. [01:48] jelmer: anyway, I doubt I have room to do a full arch->git conversion of emacs myself, so I guess the point is moot ;-) [01:56] vila: thanks for the review, I can address some of those. [02:03] jfroy: np [02:05] I didn't update the netrc plug-in tests because I considered them outside the scope of the patch. [02:05] * SamB wonders how jelmer will deal with bug 340195 [02:05] Launchpad bug 340195 in bzr-svn "NoSuchRevision: KnitPackRepository('file:///home/naesten/hacking/fbug/.bzr/repository/') has no revision ('svn-v4:e969d3be-0e28-0410-a27f-dd5c76401a8b:branches/readme.txt:249',) during bzr svn-import --incremental --keep http://fbug.googlecode.com/svn/ fbug " [Undecided,Fix released] https://launchpad.net/bugs/340195 [02:05] I dislike "grab bag" patches that change a bunch of unrelated things. [02:06] SamB, already fixed :-) [02:06] oh [02:07] what did you decide to do about it? [02:07] it was a one-line patch [02:07] (I assume that readme.txt was being moved into a branch?) [02:08] SamB, no, it was just a file appearing in a place where bzr-svn expected a branch [02:08] oh, was that all ? [02:08] then why did it fail a few revisions later than 249 ? [02:08] * SamB puzzled [02:08] because it was a bug :-) [02:09] bzr-svn was only some of those cases [02:14] lifeless, what does your latest patch fix? [02:15] jelmer: oh, when does the tag import happen? [02:18] SamB, at the end [02:19] jelmer: does only svn-import do it ? [02:19] SamB, bzr branch / bzr pull too [02:20] jelmer: more specifics please [02:21] lifeless, exactly [02:21] jelmer: oh, and I think you don't emphasize enough that `bzr svn-import' creates the same kind of branches as `bzr branch' [02:23] jelmer: I don't know what my latest patch is [02:23] lifeless, The one with the few details :-) [02:23] lifeless, "Tada!" [02:23] hah [02:24] SamB, I'm not sure, branches are branches [02:25] jelmer: well, you make it sound too much like a static conversion tool, I guess [02:26] lifeless, did you see my reply to your comment about default-rich-root [02:26] might just be the name [02:27] but, well, the wikipage is so sparse that there isn't much else to gather information from [02:28] jelmer: it does what the subject said :) [02:28] jelmer: subjects are often displayed by mail clients:) [02:28] * SamB wishes the SVN protocol weren't so danged slow for imports [02:28] jelmer: I don't think I saw your comment, no [02:28] SamB, which bzr-svn version are you using? [02:29] lifeless, I guess I should rephrase [02:29] jelmer: I pulled it a few minutes ago from lp:bzr-svn [02:29] lifeless, what things does it fix? [02:29] the SVN protocol just wasn't designed for streaming revision history, that's all [02:30] (well, especially not over HTTP, I guess ...) [02:30] jelmer: it makes the flag on the format be accurate [02:31] lifeless, it doesn't e.g. help with texts with ghost parents in pack repos? [02:31] jelmer: no idea; it was inconsistent, I'm fixing it [02:31] lifeless: ah, thanks [02:38] lifeless, I was hoping it fixed the text ghost parent issue [02:49] * SamB wonders why bzr tags needs a branch [02:51] SamB: because tags are stored on a branch [03:10] * SamB wonders why he isn't seeing any tags in his putty import [03:58] mwhudson: ping [03:58] lifeless: hi [04:00] lifeless: log -v --short is much quicker in this bzr-gc-chk255 branch now :)_ [04:02] lifeless: like maybe twice as fast as --1.9 === arjenAU2 is now known as arjenAU [04:17] mm, a bit less than twice as fast [04:17] but a lot faster :) [04:22] mwhudson: so how is loggerhead [04:23] lifeless: i haven't tested it specifically yet, been hacking on it in other ways today === abentley1 is now known as abentley [04:37] today, i will mostly be stabbing firefox [04:37] How can I tell what files Bazaar *is* tracking? [04:37] gotgenes: "bzr inventory", I guess [04:38] Peng_: Yep, that works. Thanks. [04:38] gotgenes: also ls --versioned [04:42] mwhudson: that works too. thanks [04:42] (i think commands like inventory, ignored, unknowns are gently deprecated in favour of ls --option) [04:43] gotgenes: i'd be lost without my "bzr ls --versioned --null | xargs -0 grep dsadas" commands :) [04:49] mwhudson: 'bzr search' [05:32] mwhudson: I think I have your conversion issues fixed [05:32] mwhudson: pushing soon, once this test completes === abentley1 is now known as abentley [05:38] lifeless: cool [05:42] Is there a way to get colorized output from bzr commands? [05:42] bzrtools has cdiff [05:42] in general no [05:45] bob2: fair enough [05:48] I want to share my dot-files (.vimrc, etc) across all my machines. what do you think the best way of doing this is? [05:49] bzr! [05:51] elben: That's what I do. [05:51] Create symbolic links from your home directory to a branch directory [05:51] you just set up a repo with your home folder being the root folder? [05:52] elben: naw [05:52] that gets messy [05:52] @gotgenes: hah that just came to mind! [05:52] it doesn't get very messy [05:52] bob2: bzr status gets messy [05:52] I've been doing that for 4 years or so [05:53] hum.. the machines at my univ doesn't have bzr installed =( [05:53] elben: if they have Python, you should be fine [05:59] alright, i'll try it out [05:59] thanks for the tips [06:00] mwhudson: pull groupcompress [06:01] mwhudson: it plus the preior fix I gave you (with a curret bbc branch) will probably be enough [06:01] lifeless: do i need to scrap my half-done branch, or can i pull on top of that? [06:01] mwhudson: scrap it [06:04] lifeless: what was the fix you gave me again? [06:04] or at least, which file was it in\ [06:04] repository.py [06:05] hm [06:05] can you pastebin the diff? [06:05] or tell me the line number [06:06] actually that fix is not relevant now, you need: [06:07] james_w: could you land my patch in https://bugs.edge.launchpad.net/ubuntu/+source/python-crypto/+bug/337073 or prod it along? [06:07] Ubuntu bug 337073 in python-crypto "python-crypto uses sha module that's deprecated in python2.6" [Medium,Confirmed] [06:08] poolie: I can't land it, but I can make sure it is in the correct place [06:10] http://paste.ubuntu.com/129110/ [06:14] mwhudson: you probably want to pull 1000 revisions at a time [06:14] mwhudson: we're uhm, a little too efficient at the moment :P [06:21] jam: http://paste.ubuntu.com/129110/ [06:29] Hello #bzr, looknig for guidance on where to push the 1.13rc1 for release? I'm "stuck" on step #7, submitting changes to PQM. Any help? [06:30] BasicOSX: hey, there is no branch yet, Robert is on it [06:30] BasicOSX: however, it's a bit more tricky as your key isn't known to PQM [06:30] BasicOSX: if you make your branch available somewhere I will submit it on your behalf [06:31] Let me push it to my local area, back in a couple [06:35] james_w: ok, push underway, will /poke you when complete [06:43] does bzr have an "outgoing" type command to see what commits would be applied in a push? [06:43] schmichael: "bzr missing --mine-only" [06:44] spiv: perfect! thanks! [06:54] james_w: prepare-1.13 here => http://bazaar.frostmage.org/prepare-1.13/ [06:55] thanks [06:56] Shall I continue with the announcement or should I wait for PQM ? [06:57] I'll submit now, but it may take some time, so you can work on other things in the meantime [06:59] lifeless: global name 'key' is not defined :( [07:00] * mwhudson changes it to 'keys' [07:00] and finally 'chunks' [07:10] mwhudson: diff please [07:13] hi, I´m trying to get rid of this ¨Server does not support bazaar protocol 3, reconnecting¨. I´m using the latest bzr in the Debian Lenny repo. Is there any sane way I can either upgrade the server or force clients into Protocol < 3 so that the password doesnt have to be entered twice? (*very annoying) [07:14] Are there up-to-date debs for Debian? The Ubuntu ones would probably work, but.. [07:15] i have no idea. which bzr version did network protocol 3 come in? [07:15] * devilsadvocate is not sure if its a configuration issue [07:16] i have 1.5-1.1 [07:17] which is probably bzr 1.5 [07:17] hm [07:18] devilsadvocate: 1.6 will solve this. [07:18] 1.12 is current, 1.13 is entering rc as we speak :) [07:19] * devilsadvocate grumbles about debian stable [07:19] lifeless, thanks [07:19] i´ll look into trying to install it manuall [07:19] manually* [07:19] devilsadvocate: also, using an SSH key agent will save you typing in your password so often. [07:20] devilsadvocate: but I believe the bzr PPA has packages that should work on debian stable. [07:20] spiv, i use ssh keys, but i´ve got 60 people who dont know the first thing about version control and ssh keys to train, so.. [07:21] spiv, is it possible to use ssh keys from windows? im using the bzr+ssh transport and the windows binary installer for bzr [07:21] mwhudson: ping [07:21] devilsadvocate: there's a key agent for putty IIRC. "pagent"? [07:23] spiv, hm. I´m not sure what ssh agent is being used. let me find a vanilla windows install and try that out. I dont think putty is being used anywhere... installing bzr + tortoise seemed to have installed some ssh agent as well [07:24] lifeless: hi [07:25] mwhudson: pastebin the changes you made? [07:25] lifeless: 'key' only appears once in _inventory_xml_lines_for_keys [07:26] mwhudson: got that, and fixed [07:26] that's all the changes i made [07:26] pull -r 1000 worked [07:26] oh chunks comment was unrelated? [07:26] pull -r 2000 is still grinding away [07:26] lifeless: i changed key to chunks [07:26] as the other things i tried didn't work [07:27] mwhudson: I need to see a diff [07:27] mwhudson: as I don't understand [07:27] lifeless: http://pastebin.ubuntu.com/129129/ [07:28] ah, -r 2000 completed [07:28] * mwhudson kicks off -r 3000 [07:28] grar [07:28] oh [07:28] right, yes, record.key[-1]is the right incantaiton [07:29] mwhudson: after it finishes, do 'bzr pack' [07:30] bzr: ERROR: Revision {('dirstate.py-20060728012006-d6mvoihjb3je9peu-1', 'mbp@sourcefrog.net-20070401013825-zggofbeun985u2ri')} not present in "". [07:30] again :/ [07:31] oh, didn't pack first [07:32] mwhudson: thats odd and shouldn't have happened [07:37] Can someone with ops please update the topic to '1.13rc1 released 10 Mar' [07:38] lifeless: maybe you should try it :) [07:39] mwhudson: I am [07:39] 2.4G of output so far [07:40] hum [07:40] maybe i did something wrong then [07:40] lifeless: I have submitted the changes to the 1.13 branch and PQM seems to have ignored it. I got no email, and there is no new revision, and nothing in its queue apparently. Is there any way to debug this? [07:40] mwhudson: did you delete the repository you were fetching into? [07:40] many times [07:40] i don't know if i did this very last time [07:40] james_w: you probably haven't managed to get the mail out of your laptop [07:40] I have [07:44] woo way to go BasicOSX! [07:47] Attempting to update pypi and "Server response (403): You are not allowed to store 'bzr' package information" anyone have auth to give me privs to update? === montywi|zzz is now known as montywi|meeting [07:47] BasicOSX: http://pqm.bazaar-vcs.org/ <- merging now, sorry for the delay [07:48] james_w: np, ever sit on hold with a "normal" commercial software vendor? Service here is amazing! [07:48] heh :-) === spiv changed the topic of #bzr to: Bazaar version control system | 1.13rc1 released 10 Mar | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | http://planet.bazaar-vcs.org/ [07:49] BasicOSX: topic updated [07:50] spiv: ty [07:50] Congrats on the release (candidate), BasicOSX & everyone. :) [07:51] 1.13 should go smoother as now my feet are wet and I did not drown on my first attempt :-) [08:11] hi is there a good gui for bzr ? [08:16] d-b: there are several. [08:17] yes ? [08:17] any that i can use to link into konqueror / nautilus gui ? [08:26] d-b: there's a qbzr plugin (which tortoise-bzr on windows uses, I believe), and bzr-gtk has optional nautilus integration. [08:27] i have got bzr-gtk ... i wanted a gui manager ^^ [08:33] d-b: try the nautilus integration bzr-gtk. There's a readme about it in the source. [08:53] i'm craving a quick review of https://code.edge.launchpad.net/~mbp/bzr-email/335332-starttls/+merge/4331 [08:53] hm needs diffs [08:54] lifeless: ^^ diffs added, really easy [08:59] mwhudson: it converted for me [08:59] 37MB total [09:01] my friend tries bazaar from windows and getting this error message [09:01] any clues ? [09:01] lifeless: i don't know what i'm doing wrong then [09:01] C:\Python25\Scripts\racetrack1.0>bzr launchpad-login jwgreen [09:01] bzr: ERROR: Connection error: curl connection error (SSL certificate problem, ve [09:01] rify that the CA cert is OK. Details: [09:01] error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify faile [09:01] d) [09:01] on https://launchpad.net/%7Ejwgreen/%2Bsshkeys [09:01] lifeless: can you upload it to rookery or something? [09:01] mwhudson: sure [09:28] mwhudson: upload bandwidth sucky, will upload overnight [09:28] mwhudson: 37MB is 27MB [09:29] bah, 3 in the second part :P [09:29] ciao [09:29] lifeless: cool, it's not like i'm going to do anything tonight :) === kiko is now known as kiko-afk [11:26] anyone working on 13rc1 packages for bzr-beta-ppa yet? If not I'll start === lamont` is now known as lamont [11:52] hello [11:52] johnf: doit [11:53] beginners question: is it safe to remove a branch's directory after merging it into the main line? [11:55] shled, yeap, should be [11:55] beuno: thanks! [11:56] * beuno waves at lifeless from Cape Town [11:56] * shled happily frees some disk space [12:04] New to bzr. I just set up a master branch on a server, I branched it locally. Doing some code changes, commit it. Now it's commited to my local main branch, right? So to push it back to the master branch I do a push? [12:05] After I've done a push, the master branch server needs to do an update to get the changes. That's why there is a push-and-update plugin, right? Is there any other way of doing it, or is that "the" way of doing it? [12:07] beuno: nice [12:08] thecookie: generally you don't need to have a up to date tree on the master for other people to pull from it [12:09] lifeless: Well, the project I'm working with is a web page, and the same server hosting it is also hosting the page via http. That's why I want to update it. Maybe the post commit hook is triggerd on a push? [12:10] thecookie: for that, most folk use the 'bzr-upload' plugin I think [12:10] thecookie: the post-tip-branch-change hook is fired on the server after a push if you are using bzr+ssh [12:12] I'm using bzr+ssh, yeah. But it seems to be a bit of overhead. First I push changes to the server, then I upload them too? [12:14] I didn't read up on the upload plugin tho. Maybe I should :) [12:15] lifeless: At some stage I'll need write access to the lp:~bzr/bzr/packaging-hardy is it possible to get access to those as a bzr-beta member? Or should I just create my own branches and propose merges? [12:15] Yeah, seems to work like I thought. Seems stupid to upload the changes twice [12:16] I guess push-and-update fits me thetter then, just wanted to check if there was a "correct" way to do it [12:18] wg /8 [12:18] grr [12:21] thecookie: in general update can fail because of local edits; bzr-upload kind of fits the model better; anyhow - as long as you're happy thats great [12:22] johnf: we can fix permissions on tha tbranch - move it to ~bzr-beta-ppa or whatever [12:22] johnf: let me know tomorrow ;P [12:22] lifeless: ok cool [12:22] Jc2k: :) [12:22] lifeless: The master server will never have local edits [12:23] It's pretty much just the "main branch" hosted for others [12:51] is it possible to cancel a pending merge? [12:51] on this branch it looks like someone has done a local ci and then done an up [12:51] so the changes are showing as pending merge but I just want to remove them [12:52] Whats the best way to do this? [12:52] OllieR, bzr revert [12:54] jelmer: thanks [13:19] can someone test http://inodes.org/johnf/debs/bzr_1.13~rc1-1~bazaar1~intrepid1_i386.deb before I upload to the beta ppa? [13:45] if i merge from branch A into branch B ... and later on i merge from branch B into branch C ... how does the history on branch C reflect the original changes from branch A ? [13:46] i mean does it show up as a merge commit coming from A ? [14:04] lifeless: don't suppose you know if the streaming feature for bzr push to a bzr url works over bzr+http:// as well? [14:21] * SamB wonders why jelmer did a release of bzr-svn that depends on an unreleased version of bzr [14:22] SamB: latest release of bzr-svn should work with released bzr-1.13rc1 no ? [14:22] rocky: oh, that's a release ? [14:22] bazaar release notes says it is [14:22] i haven't actually downloaded it tho [14:22] nevermind then [14:42] hi, how do I change the "parent branch", this one is deleted and I want to set the parent branch to the submit branch [14:43] funny - as soon as i send my request it works 0o === nevans1 is now known as nevans === kiko-afk is now known as kiko [16:03] SamB, the API is frozen now there's a RC out [16:03] SamB, that's always a good moment to release bzr-svn, otherwise people need to wait for one after 1.13 is released === kiko is now known as kiko-fud === bac is now known as bac_lunch [16:48] Hi [16:48] How to clean the history of a branch after doing a "bzr split" ?? [16:49] I want to strip out all unrelated log history === kiko-fud is now known as kiko [17:18] Hokay, so. I'm in both this and Mercurial's room and am asking the same question in both places. Why should I choose Bazaar over Hg at this point in time for new projects? [17:19] (With the continued improvements I've seen on both sides, the BzrVsHg comparison is out of date.) [17:19] I've been using Git for a while now, but in a mixed environment (Windows) it is hard(/impossible) to justify using it. [17:36] I'm wondering if there is a command to remove all *.~1~ backup files that got created on accident? I forgot to add the --no-backup argument to the bzr revert command [17:39] I personally chose bzr over other DVCSs because: I know it will run anywhere python will run, it has good support for a lot of different workflows, bzr devs are constantly working on better merging and more efficient storage, and support by ubuntu/launchpad [17:40] eferraiuolo: bzr clean-tree might help. Or, there's always plain old find. [17:40] find . -regex '.*\.~[0-9]+~$' -execdir rm {} \; [17:40] ;-) [17:40] Tak: thanks for your comments. Is there any particular workflow that stands out? [17:41] (I'm coming from Git, needing something that runs as a non-second-class citizen on Windows) [17:41] for me, no particular one by itself, but every project has its own workflow [17:41] I think the point about workflow is that if you want to pretend you're still using a centralized SCM, you can? [17:41] and I've yet to find one that is uncomfortable with bzr [17:42] I am trying to train centralized out of the rest of the team in baby steps. [17:43] maxb: thanks [17:44] KangOl, History isn't really changable. [17:45] Tak: heavy rebasing / cherry-picking doesn't work very well with bzr [17:45] ok [17:46] Tak, there are loads of them [17:46] * Tak shrug [17:46] nathanhammond, best of luck doing that [17:46] "I haven't found any" != "They don't exist" ;-) [17:47] Tak, nathanhammond : theres always _some_ part of the team thats wants to do thing "the other way" [17:47] it's true [17:48] I've spent years migrating my dept from (vault||nothing) => svn [17:48] devilsadvocate, Tak: fortunately, there are two camps they're coming from: svn locally, and the "copy a folder, edit" approach [17:48] globally there isn't anything [17:48] and that is one of my responsibilities [17:48] is it too late to murder the copy/edit group? [17:48] Pieter, Cherrypicking only works well with darcs unfortunately :-/ [17:49] Tak, you'd be killing off half your team, if not more [17:49] be nice! web developers, the lot of 'em. [17:50] SCM-managed websites seems to be a kinda new thing [17:50] nathanhammond, you and i have a very unenviable job. the hope is that the univers shall one day repay us [17:51] devilsadvocate: I'm simply hoping that things aren't so entrenched that it is possible to get people to buy in [17:52] the problem is that the team actually has decent incremental hourly backups that has been serving as their version control. [17:52] "why do I need SCM when..." [17:53] in any case, I'll figure it out. [17:53] nathanhammond, its not so much entrenched in a different camp, its more of a "is this really worth my time and effort as this really great effort" [17:54] *really gread programmer" [17:54] great* [17:54] * devilsadvocate really needs sleep [17:54] heh [17:55] if you ask me, the easier way would be to let it bite them in the face one day and let take it up voluntarily [17:55] that worked at the last job [17:56] rm -rf is not a friend [17:56] :D [17:56] rm -rf is the lesser of devils [17:57] a simple backup will do the job, you dont need version control [17:57] old job: no backups [17:57] git's distributed SCM to the rescue on 3 of 4 projects (since I set them up) [17:57] no, the fun time comes when its time to deliver and you realize different parts of the groups were working on different code, as in, different checkouts from a no-exisiting tree and that they all dont work together [17:58] fourth project lost a week, since that was the last time it got pushed live [17:58] ouch. no thanks. === bac_lunch is now known as bac [18:22] hi all! are symlinks added in the bzr repo? if they are how can I remove them, I tried with bzr remove but that didn't work [18:30] sanity check: bzr versions directories as first-class objects, right? I mean, that's how it's always appeared to me, but I want to make sure I'm not missing any gotchas. [18:30] yes [18:30] luks: thanks [18:30] directories are just a different kind of 'inventory items' [18:37] alefteris: yes, they are added. There is some trouble in removing them; for instance see: https://bugs.launchpad.net/bzr/+bug/236149 . I have added there a link to a workaround [18:37] Ubuntu bug 236149 in bzr ""Error: Not a branch" when trying to revert a symlink" [Low,Triaged] [18:44] clemente, thanks. another thing: with the symlink added, will I be able to check out to a windows machine? [18:58] alefteris: I don't know that; I suppose yes, you can, but I don't know what will be checked out. Maybe the same file twice? [19:01] (however, some messages in the Internet speak about getting just an error...) [19:05] clemente, ok thanks a lot === kiko__ is now known as kiko [19:44] I got the following message when doing a checkout of a branch on over HTTP: [19:44] Got a 200 response when asking for multiple ranges, does your server at localhost:8080 support range requests? [19:45] Will bzr still function if the server doesn't support multiple range requests? [19:45] i.e. will my branch be fine even though bzr wrote that message during the checkout? [19:48] yes [19:48] it's a performance thing, not a correctness thing [19:48] mwhudson: thanks for the insight [19:50] hello [19:50] reboot, brb [19:55] I am working on the bazaar-based audit script that watches some various dirs for changes and commits the to the repo. [19:56] Is there any way tor relocate repository (.bzr) from working dir using bzrlib ? [19:57] hello [19:57] does bzr have a command to copy files? [19:59] no [20:04] :( [20:05] afaik only svn does [20:05] hg does too [20:06] what are the semantics in hg? [20:06] for merge, and log? [20:06] Spaz: does a copy get updated with changes on the copied from? [20:06] not in hg. [20:06] you can make a symlink though [20:07] which effectively does the same thing. [20:07] what's the point then? :) [20:08] Spaz: iirc, afaik, the semantics of copy never became crystal clear [20:08]