| nDuff | oh -- I'll hazard I put the check in at the top of my commit() method, *before* the paranoia bits. *sigh*. | 00:02 |
|---|---|---|
| lifeless | that would explain it | 00:05 |
| nDuff | ...so -- while I can edit it, I don't think I have access to close that ticket. Should I modify it to refer to the dirstate issue, or let someone with appropriate access close it and file a new/better ticket? | 00:08 |
| lifeless | that ticket is fine | 00:08 |
| lifeless | I don't believe in churning bug reports, just editing them to be clearer ;) | 00:09 |
| nDuff | so, part of what I don't grok here -- if we store 'a' entries for things which are deleted in the current working tree, why does DirState._get_entry(0, fileid_utf8=file_id) return (None, None) when called from DirState.add(), rather than the entry indicating that the deleted file is absent? | 00:17 |
| lifeless | well 'a' is absent | 00:17 |
| lifeless | but the row can only go entirely if the name,id pair is not present in any tree | 00:17 |
| lifeless | so _get_entry could be the cause of the bug here, but I haven't looked into the bug in detail myself | 00:18 |
| nDuff | ...oh. | 00:20 |
| lifeless | so the add should be changing the 'a' to 'd' or 'f' rather than adding a new row | 00:20 |
| nDuff | just read through _get_entry, and its explicit behavior is to return (None, None) on 'a' cases... which makes sense for add()'s normal behavior, but makes it impossible to tell whether something is being introduced for the first time or "undeleted" (possibly in a new location) | 00:21 |
| lifeless | there are other helpers IIRC, lower level | 00:22 |
| * nDuff realizes that the first sentence of his last line could have been read as imperative... s/^just/I just/ | 00:24 | |
| mrooney | How might I un-add a file that I added accidentally? I don't want to remove the file, just un-add it from VC | 00:25 |
| lifeless | mrooney: bzr revert file | 00:26 |
| nDuff | mrooney, bzr rm --keep | 00:26 |
| mrooney | lifeless: I can try that, I haven't committed yet so I wonder what revert will do | 00:26 |
| lifeless | mrooney: revert because you want to put it back to the state it had before | 00:26 |
| jelmer | does Bazaar still use the Launchpad blueprint system? | 00:27 |
| lifeless | sporadically | 00:28 |
| lifeless | jelmer: so, what is the trunk for bzr-svn these days? | 00:37 |
| lifeless | jelmer: I don't think I've ever understood how you manage it :) | 00:38 |
| jelmer | lifeless, lp:bzr-svn | 00:38 |
| jelmer | lifeless, that points at 0.5 at the moment | 00:38 |
| jelmer | I've removed trunk because it kept confusing people | 00:38 |
| lifeless | have you merged my threadsafe and is_locked patches? | 00:40 |
| Peng_ | It's not thread-safe? | 00:41 |
| lifeless | Peng_: well, it triggered thread safety asserts in sqlite when I made loggerhead work on svn directly | 00:42 |
| Peng_ | Ehhm, I hope bzr-svn never comes into play on my Loggerhead install then. | 00:42 |
| jelmer | lifeless, yeah, those have long been merged | 00:42 |
| lifeless | well, it only would if you did e.g. bzr checkout --lightweight svn://... and then pointed logerhead at that | 00:42 |
| lifeless | jelmer: ok, I'll pull overwrite | 00:43 |
| Peng_ | Alright. | 00:43 |
| lifeless | Peng_: its not having bzr-svn installed, its using loggerhead to examine svn repositories directly :) | 00:43 |
| lifeless | Peng_: and as jelmer says, the patches are emrged | 00:44 |
| Peng_ | :) | 00:44 |
| jelmer | ok, I registered the duck-branches spec, will expand it a bit more tomorrow | 00:56 |
| lifeless | jelmer: what we mainly do is discuss on the list | 00:58 |
| lifeless | and send patches to doc/developers/ describing things agreed on | 00:58 |
| jelmer | lifeless, yeah, I'll post it there when I've expanded it a bit more | 00:58 |
| jelmer | it's a bit too sparse right now, seems pointless to bore the list with it before necessary | 00:59 |
| lifeless | well, discussion can be about concepts not actual prose :P | 00:59 |
| lifeless | I find sending in prose too early results in a very static, early-framed discussion | 01:00 |
| jelmer | it's already been discussed a bit earlier | 01:00 |
| jelmer | it's basically a follow-up of my local-branches plugin | 01:00 |
| lifeless | ok | 01:00 |
| lifeless | that was while I was away I think | 01:00 |
| jelmer | Yeah, I think so | 01:00 |
| jelmer | lifeless: it basically implemented local branches (git-style branches, if you will) by adding .bzr/branches/ and symlinking .bzr/branch to one of the branches in that directory | 01:01 |
| lifeless | spiv: oh, that reminds me, make sure your stream fetch stuff supports sending/requesting many start points. Repository.fetch doesn't - and that is a bug | 01:02 |
| spiv | Many start points? | 01:02 |
| lifeless | yeah | 01:02 |
| lifeless | think multipush | 01:03 |
| spiv | I think I know what you mean, but let's make sure I do :) | 01:03 |
| jelmer | moin poolie | 01:03 |
| spiv | Right. multipush would want to transmit many heads. | 01:03 |
| lifeless | well they may not be heads :P but tips, yea | 01:04 |
| spiv | lifeless: oops, right. | 01:04 |
| spiv | At the moment I'm just working on the stream of records to push, so not (yet) changing the negotiation/calculation of which records. | 01:05 |
| spiv | But that goal is worth keeping in mind, thanks. | 01:05 |
| igc1 | spiv: re your --no-plugins patch, why is this line needed? | 01:08 |
| igc1 | args = ['--no-plugins'] + args | 01:08 |
| === igc1 is now known as igc | ||
| lifeless | jelmer: did the url-syntax for colocated branches disucssion get finished? | 01:18 |
| spiv | igc: just refreshing my memory | 01:20 |
| poolie1 | with no context i'd guess it's so that they're not loaded inside a subprocess bzr | 01:21 |
| spiv | igc: so that subprocesses spawned by the test suite don't load plugins. | 01:22 |
| poolie1 | :) | 01:22 |
| spiv | igc: which makes sense if you ran "bzr --no-plugins selftest ..." in the first place. | 01:22 |
| spiv | igc: maybe not so good if you didn't pass --no-plugins to the original process... | 01:22 |
| igc | spiv: but why is that line unconditional? | 01:23 |
| spiv | For lack for a good condition ;) | 01:23 |
| spiv | I think ideally it'd be "if <selftest was run with --no-plugins>:", but I'm not sure there's a good way to spell that. | 01:24 |
| jelmer | lifeless, no, that's still an open issue (in the spec as well) | 01:24 |
| lifeless | looms want this | 01:25 |
| lifeless | spiv: bzrlib.plugin.SOMETHING | 01:25 |
| jelmer | (duck-branches are colocated branches, btw) | 01:25 |
| jelmer | hmm, colocated is actually a pretty good name for these things... | 01:30 |
| poolie1 | i think colocated is good | 01:40 |
| poolie1 | i think calling them threads might be good, if it doesn't cause too much confusion with looms | 01:41 |
| poolie1 | or twigs :) | 01:41 |
| === abadger19991 is now known as abadger1999 | ||
| poolie1 | jam, if you're still here | 01:47 |
| poolie1 | spiv wants to change bdecode so that it decodes list types as tuples | 01:47 |
| poolie1 | for easier use with keys | 01:48 |
| lifeless | jelmer: why not just use the current find_branches() api ? | 01:54 |
| jelmer | lifeless, that's what I mean | 01:55 |
| jelmer | lifeless, it doesn't know about colocated branches though (yet) | 01:55 |
| lifeless | well you talk about a new container object | 01:55 |
| jelmer | lifeless, isn't find_branches() supposed to find all branches under a particular directory, not just the colocated ones? | 01:56 |
| * igc lunch & off for the afternoon - see everyone tomorrow | 01:56 | |
| lifeless | jelmer: yes | 01:58 |
| jelmer | lifeless, so that seems to make it very hard to iterate over all colocated branches without opening those branches *and* all non-colocated branches under the dir | 01:59 |
| lifeless | fair enough | 01:59 |
| lifeless | anyhow, I need to think on it a bit I suspect | 01:59 |
| lifeless | I'd like to get the url thing sorted | 01:59 |
| lifeless | that is key to making things better IMO | 01:59 |
| jelmer | Yeah, the URL bit is important to resolve, though I don't think the decision there will influence the rest of the spec very much. | 02:01 |
| === Mario__ is now known as pygi | ||
| Peng_ | beuno: FWIW, I think your Loggerhead ideas sound very interesting, as long as the interface for the JavaScript-impaired is still decently usable. | 02:30 |
| beuno | Peng_, I will promise to do my best :) | 02:31 |
| beuno | ideally, LH would be cheap enough to open up to googlebots and the likes | 02:32 |
| beuno | so I do want to expose as much information as possible | 02:32 |
| Peng_ | beuno: I do open mine up to Googlebot. :P | 02:34 |
| beuno | Peng_, that's why you're my favorite ;) | 02:35 |
| Peng_ | :D | 02:37 |
| hotdog0031 | AssertionError: no parent entry for: Trip back east/DDSCF0001.JPG in tree 0 | 02:42 |
| hotdog0031 | HALP | 02:42 |
| hotdog0031 | seems to have deleted the parent folders without removing what was inside | 02:42 |
| lifeless | interesting | 02:44 |
| lifeless | is that on commit? what version of bzr do you have? | 02:44 |
| hotdog0031 | No, that's on bzr check, which is why I'm rather panicked at the moment. I have bazaar 1.6.1 right now- the one shipped with ubuntu. Should I try with a newer one? | 02:45 |
| lifeless | hotdog0031: that will be checking the local tree on disk I think. Can you do: | 02:47 |
| lifeless | python | 02:48 |
| lifeless | import bzrlib.workingtree | 02:48 |
| lifeless | t = bzrlib.workingtree.WorkingTree.open('.') | 02:48 |
| lifeless | t._check() | 02:48 |
| === Toksyuryel` is now known as Toksyuryel | ||
| hotdog0031 | No handlers could be found for logger "bzr" | 02:51 |
| hotdog0031 | strange. | 02:51 |
| lifeless | ok | 02:53 |
| lifeless | can you file a bug please | 02:53 |
| lifeless | with the output from check - and from ~/.bzr.log for the check - just delete that file before running check | 02:54 |
| lifeless | don't panic though, I would be amazed if you have managed to get bzr to record something unusual in the history of your project | 02:54 |
| lifeless | oh also, if you have enough disk space handy you could do this to test: | 02:54 |
| lifeless | bzr branch . /tmp/clean; cd /tmp/clean; bzr check | 02:54 |
| hotdog0031 | Ok. Thank you for your help, lifeless. | 03:01 |
| Leefmc | Question: I have a branch, and a working directory. Now i have made a 2nd branch to test some code, but how do i change my working directory from branchA to branchB? | 03:07 |
| nDuff | Leefmc, I think "bzr switch" (from the loom plugin) should do that. | 03:08 |
| lifeless | nDuff: switch is builting now | 03:09 |
| Leefmc | originally i got my working directory by checkout out branchA, but if i try to checkout branchB it gives me an error about .bzr already existing, etc. | 03:09 |
| Leefmc | nDuff: I need a plugin just to change branches? | 03:09 |
| lifeless | Leefmc: just 'bzr switch branchB' | 03:09 |
| lifeless | Leefmc: no, its in bzr core | 03:09 |
| Leefmc | ah, k | 03:09 |
| Leefmc | ty | 03:09 |
| lifeless | the loom plugin extends the switch command to work with looms as well | 03:10 |
| Leefmc | Interesting, is it a bug that if you switch to a branch which has 0 revisions (no commits yet) that bzr leaves all the code from the previous branch in your working directory? | 03:13 |
| lifeless | Leefmc: did it output anything at all? | 03:14 |
| Leefmc | lifeless: In regards to the switch? iirc, yes | 03:15 |
| lifeless | Leefmc: I'd guess it errored in fact:) | 03:15 |
| Leefmc | lifeless: I did it multiple times, its not a singularity | 03:15 |
| lifeless | Leefmc: sure | 03:16 |
| Leefmc | lifeless: At first i thought it was not working as i had assumed, because it was not removing the code from the previous branch. But then i made a commit to branchB and then everything worked fine. No problems really, just noting the fact :) | 03:16 |
| lifeless | Leefmc: uhm, file a bug ? :P I've not got anywhere near enough info at this point to say if its a bug thoough | 03:16 |
| lifeless | it may be refusing to operate or something | 03:16 |
| Leefmc | Boy i love DVCS' | 03:17 |
| Leefmc | what did i do before them.. | 03:17 |
| Leefmc | now i refuse to even work without them :D | 03:17 |
| nDuff | yay! | 04:30 |
| * nDuff has a working patch for his current pet bug. | 04:31 | |
| nDuff | (well, working for the single, simple test case he's running against right now, anyhow) | 04:31 |
| === Mario__ is now known as pygi | ||
| poolie1 | which one? | 04:46 |
| poolie1 | and congrats | 04:46 |
| nDuff | bug 314251 | 04:47 |
| ubottu | Launchpad bug 314251 in bzr "InconsistentDelta by recreating a known ID in a new location " [High,Confirmed] https://launchpad.net/bugs/314251 | 04:47 |
| nDuff | happened across it by doing something really stupid yesterday, then realized today that I could hit it through less-contorted use cases. | 04:47 |
| poolie1 | i thought that might be it | 04:53 |
| poolie1 | well done | 04:53 |
| lifeless | time for me to call-the-day in a few minutes poolie | 04:55 |
| * fullermd hopes this one is called Barbara. | 04:55 | |
| lifeless | well its more 'gee our early history was dirty' | 04:58 |
| lifeless | my repo appears to have some significant differences in the early-early-early merge output results. I smell weave glitches that I've never repaired | 04:58 |
| lifeless | so I've been migrating branches across to bzr.dev 'clean' versions :P | 04:59 |
| poolie1 | ah good | 05:03 |
| poolie1 | we're looking at streaming rpc requests | 05:03 |
| lifeless | cool | 05:04 |
| lifeless | well, I'm off see you tomorrow | 05:04 |
| lifeless | oh, I updated groupcompress to the 1.10 apis | 05:04 |
| lifeless | tests pass but thats about all I'm sure of :) | 05:04 |
| poolie1 | oh, are you? | 05:05 |
| poolie1 | off to see me tomorrow i mean | 05:05 |
| lifeless | metaphorically | 05:05 |
| lifeless | I meant, I'll be here working tomorrow :) | 05:06 |
| nDuff | is selftest expected to run clean on bzr.dev? I'm seeing some errors which look like they shouldn't have anything to do with my patch. | 05:07 |
| lifeless | nDuff: we use pqm, so yes selftest runs clean | 05:07 |
| nDuff | ...hrm, that's odd... oh, I think it may be testing my installed plugins. | 05:08 |
| * nDuff reruns with --no-plugins. | 05:08 | |
| lifeless | yes it will be | 05:09 |
| fullermd | I know I've always had a couple trivial failures. | 05:10 |
| fullermd | But it's been forever since I ran it. | 05:10 |
| poolie1 | andrew and i are just talking about whether streaming code should expose the chunking to the client/server | 05:10 |
| poolie1 | ie is it a stream of bytes that happen to be chunked, or is it a stream of chunks with possibly meaningful semantics | 05:11 |
| nDuff | Is it OK if I do a blackbox test case for this, or is it strongly preferred that it be aware of/inspect the dirstate innards? | 05:25 |
| poolie1 | one in workingtree_implementations would be nice | 05:27 |
| poolie1 | but blackbox would be better than none | 05:27 |
| nDuff | ahh; I hadn't seen workingtree_implementations | 05:30 |
| spiv | Hmm, I thought at some point the *_implementations directories were going to be renamed per_*. | 05:35 |
| * nDuff sends his patch off into the wild blue yonder^Wmailing list. | 05:50 | |
| nDuff | Should a new version of a patch be sent to the ML in a new thread or as a reply? | 06:35 |
| * nDuff doesn't know if bundle-buggy (or accepted etiquette) is particular about such things. | 06:35 | |
| Peng_ | nDuff: Replies work. | 06:38 |
| nDuff | Peng_, thanks. | 06:38 |
| vila | hi all | 07:01 |
| * fullermd distracts vila with a pink elephant and rifles through his pockets for loose change. | 07:01 | |
| * vila search online dictionaries for "rifles through his pockets for loose change" 8-/ | 07:02 | |
| * vila feed its own pink elephant in th mean time | 07:03 | |
| fullermd | How do you kill a blue elephant? | 07:03 |
| mwhudson | with a blue elephant gun? | 07:04 |
| fullermd | Pfft. Take all the fun outta it, why doncha :p | 07:04 |
| mwhudson | just practising my regression to child hood | 07:05 |
| fullermd | Well, that's what we have version control for. | 07:05 |
| fullermd | bzr branch -rgrade:3 ... | 07:06 |
| === beaumonta is now known as abeaumont | ||
| === asac_ is now known as asac | ||
| === thekorn_ is now known as thekorn | ||
| fdv | is bzr upgrade (from rich-root-pack to 1.9-rich-root) a heavy / slow command, and are there significant benefits of doing it? | 11:53 |
| fdv | wow, shelf doesn't map to shelve anymore. that was.. surprising | 12:24 |
| asabil | fdv: according to a mail from the mailing list, upgrading is very fast | 12:46 |
| fdv | asabil: great, thanks! | 12:49 |
| asabil | fdv: http://article.gmane.org/gmane.comp.version-control.bazaar-ng.general/50718/match=upgrade | 12:50 |
| === vednis is now known as mars | ||
| Oli`` | Trying to figure out why my files aren't showing up on my server. I've done (all locally): bzr init; bzr add; bzr push bzr+ssh://address/dir; bzr bind bzr+ssh://address/dir; bzr commit -m "init" | 13:46 |
| luks | what files are you expecting to show up? | 13:46 |
| Oli`` | there is a new /dir directory on the server (and it has its own .bzr dir) but apart from that, it's empty =\ | 13:46 |
| Oli`` | I've got half a dozen files added locally | 13:46 |
| luks | that's the way it works | 13:46 |
| luks | you can run "bzr checkout ." on the server and use the push-and-update plugin to keep it up to date | 13:47 |
| Oli`` | I'm trying to push the files onto the server... | 13:47 |
| luks | but having a working tree is rarely a good idea | 13:47 |
| luks | er, I eam working tree on a server | 13:47 |
| Oli`` | checkout! | 13:47 |
| Oli`` | that's what I was forgetting! | 13:47 |
| === menesis1 is now known as menesis | ||
| === bac_afk is now known as bac | ||
| vila | looks like PQM is blocked again... that's so 2008... I thought that upgrading bzr there had solved the issue but obviously not :-/ | 14:52 |
| === menesis1 is now known as menesis | ||
| fullermd | vila: It's still confused from the leap second :p | 15:42 |
| === menesis1 is now known as menesis | ||
| Emmanuel | Hi, i am using bzr 1.10 and everytime i first push a repository on a network shared i get "bzr: ERROR: Could not acquire lock" , any idea what i do wrong? | 16:09 |
| rocky | what's everyone's favourite way to mirror (pulling-only) an hg branch into a local bzr branch these days? | 16:34 |
| rocky | bzr-hg looks non-updated | 16:34 |
| jelmer | rocky: fast import is probably the best choice at the moment | 16:37 |
| jelmer | I hope to update bzr-hg at some point, but bzr-git / bzr-svn have more priority for now | 16:38 |
| Jc2k | jelmer: :) | 16:41 |
| Jc2k | when bzr-darcs ;) | 16:41 |
| jelmer | hey Jc2k | 16:41 |
| jelmer | bzr-darcs would be interesting :-) | 16:41 |
| fullermd | Eek. | 16:41 |
| fullermd | That's probably more dangerous than the LHC. | 16:41 |
| jelmer | In particular, given that they have no particular ordering of history and we do | 16:42 |
| jelmer | fullermd: LHC? | 16:42 |
| Jc2k | large hadron thingy | 16:42 |
| fullermd | Yah. | 16:42 |
| fullermd | The thing that'll open a large rift in space-time and let face-eating dragons in to destroy the world. | 16:42 |
| * jelmer fears that if he ever starts on bzr-darcs he'll end up rewriting bzr in haskell | 16:42 | |
| fullermd | Or rewriting haskell in python. | 16:43 |
| jelmer | fullermd: haskell >> Python >-) | 16:43 |
| fullermd | That's why it's a challenge :P\ | 16:44 |
| === ja1 is now known as jam | ||
| * awilkins rewrote Haskell in Haskell and it disappeared up it's own bottom | 16:48 | |
| enigma42 | Greetings all. | 19:04 |
| enigma42 | If I'm using bzr-svn 0.4 on some clients and 0.5 on others, is the metadata from 0.5 going to confuse the 0.4 clients? | 19:04 |
| jelmer | enigma42: yes | 19:30 |
| jelmer | enigma42: confuse in the sense that they will not be able to parse that metadata and will probably ignore it | 19:31 |
| igc | morning | 20:40 |
| === mw_ is now known as mw | ||
| seb_kuzminsky | "bzr shelve foo.c" is giving me a new error: | 21:33 |
| seb_kuzminsky | bzr: ERROR: This tree contains left-over files from a failed operation. | 21:33 |
| seb_kuzminsky | Please examine /home/seb/work/bioserve/bionet2.bzr/trunk/.bzr/checkout/limbo to see if it contains any files you wish to | 21:33 |
| seb_kuzminsky | keep, and delete it when you are done. | 21:33 |
| seb_kuzminsky | this is with 1.10 | 21:33 |
| seb_kuzminsky | all other bzr commands (up, diff, commit, etc) all work fine | 21:33 |
| seb_kuzminsky | the limbo dir is empty | 21:33 |
| seb_kuzminsky | i remove limbo, and it complains about pending-deletions/ in the same place | 21:36 |
| seb_kuzminsky | that's also empty | 21:36 |
| seb_kuzminsky | when i remove pending-deletions, it recreates limbo and complains about it, and leaves behind a lock... | 21:37 |
| lifeless | are you on windows? | 21:38 |
| lifeless | also, I'll brb grabbing food | 21:38 |
| seb_kuzminsky | this is on intrepid | 21:39 |
| seb_kuzminsky | see you after food ;-) | 21:39 |
| seb_kuzminsky | if i break the lock, then remove both limbo and pending-deletions, it complains the file i'm trying to shelve is not versioned | 21:40 |
| seb_kuzminsky | but bzr log and i both think it is ;-) | 21:40 |
| jam | lifeless: ping | 21:41 |
| jam | seb_kuzminsky: You need to remove both limbo and pending deletions at the same time | 21:41 |
| seb_kuzminsky | i tried that ^^^ | 21:41 |
| jam | ah, I missed the final part | 21:42 |
| jam | so... is the file versioned? Are you sure the name is correct? was it recently added, etc? | 21:42 |
| seb_kuzminsky | it's in the repo, the name is correct | 21:42 |
| seb_kuzminsky | it's got a couple of commits on it, as shown by "bzr log" | 21:42 |
| jam | seb_kuzminsky: what does "bzr st" say about it? | 21:43 |
| seb_kuzminsky | modified: | 21:44 |
| seb_kuzminsky | hab/alsa/cb-stream-subscription.c | 21:44 |
| jam | oh, are you in "hab/alsa" directory and just giving "bzr shelve cb-stream..." ? | 21:44 |
| seb_kuzminsky | oh, shelve works if i do it from the checkout root | 21:44 |
| seb_kuzminsky | yes | 21:44 |
| jam | I think there may have been a bug in 1.10 where 'bzr shelve' didn't handle relative paths properly | 21:44 |
| jam | I'm pretty sure that is fixed in bzr.dev | 21:45 |
| jam | and 1.11rc1 is this Friday | 21:45 |
| seb_kuzminsky | ok great! | 21:45 |
| seb_kuzminsky | yay for short development cycles! | 21:45 |
| seb_kuzminsky | thanks bzr guys! | 21:45 |
| beuno | seb_kuzminsky, you can use the bzr nightly PPA if you want bzr.dev in a nice package | 21:45 |
| nDuff | Friday? hmm... | 21:46 |
| seb_kuzminsky | right-o, i think i'll do that | 21:46 |
| * nDuff wonders if his patch [bug#314251] is likely to make it through the review/merge cycle in time. | 21:47 | |
| Haffi___ | Hi | 21:59 |
| lifeless | jam: pong | 22:00 |
| Haffi___ | if there are a few people in separate locations (some using Windows, some Linux) working with a few python files, is bazaar a good choice as a vcs? | 22:00 |
| beuno | Haffi___, it's a fantastic choice | 22:01 |
| Haffi___ | beuno: Should I keep the files on a server and let the users access them via SSH/sFTP? | 22:02 |
| igc | nDuff: I'll take a look today if lifeless or someone else doesn't | 22:02 |
| beuno | Haffi___, yeap, that's probably the best way to do it | 22:03 |
| Kobaz | what's the plugin that you can select individual blocks of a file to be part of a commit | 22:03 |
| Haffi___ | beuno: OK, thanks. I think the five minute tutorial pretty much covers this then! | 22:04 |
| beuno | Haffi___, awesome. Let us know if we can help with anything. | 22:04 |
| Haffi___ | beuno: Thanks very much, this seems like a very friendly community | 22:05 |
| Peng_ | Kobaz: bzr-interactive, IIRC | 22:08 |
| Peng_ | Kobaz: But you can also shelve and unshelve the changes. (bzrtools, and now built-in) | 22:09 |
| poolie | hi | 22:12 |
| beuno | hiya poolie | 22:12 |
| poolie | hello | 22:12 |
| jam | lifeless: it looks like vila was able to wedge pqm again by submitting a branch from lp | 22:17 |
| jam | As near as I can tell, it finished with "success" but then hung, as it hasn't started processing the rest of the queue | 22:18 |
| lifeless | jam: have you grabbed a LOSA? | 22:18 |
| jam | I don't even know what one is | 22:19 |
| lifeless | spm/mthaddon etc | 22:19 |
| jam | Though I've seen the acronym before | 22:19 |
| spm | jam: we're wonderful people :-) | 22:19 |
| mthaddon | speak for yourself | 22:19 |
| spm | wedged pqm? chasing. | 22:19 |
| spm | herb and myself are wonderful. mthaddon is simple *AMAZINGDUDEs!* | 22:20 |
| * fullermd would campaign for a new job title if he were a losar... | 22:20 | |
| mthaddon | hey, we campaigned hard for that job title... | 22:21 |
| lifeless | jam: while I can fix, I'm kindof a second-tier for pqm; if they can fix it they should: because they do nice things like logging issues, maintaining the machines etc | 22:21 |
| jam | sure | 22:23 |
| spm | jam: is unwedged. vila may(?) need to resubmit 'Rev 3924: (vila) Fix 313498...' | 22:23 |
| jam | Though I thought you might be interested in the fact that vila has repeatedly wedged things by submitting branches from lp | 22:23 |
| spm | talented? | 22:23 |
| fullermd | PQM doesn't like htpp:// branches? | 22:25 |
| james_w | it's got a childish mind and just giggles when it sees one | 22:27 |
| jam | fullermd: that would be hhtp, vila doesn't do htpp :) | 22:27 |
| fullermd | I think I'll claim "I knew that", and merely mismistyped it... | 22:28 |
| Haffi___ | Hi, I'm having some trouble with publishing my branch via sftp, I guess this is not strictly a problem with bazaar because I get the error message: Connection refused | 22:31 |
| Haffi___ | Does anyone know of a way to circumvent this? | 22:31 |
| beuno | Haffi___, what command are you running to push the branch? | 22:32 |
| luks | well, the first obvious question is: is there a ssh/sftp server running? | 22:32 |
| Haffi___ | luks: Yes, and I have checked the dependencies, they are all there | 22:32 |
| Haffi___ | I can access the server remotely, but not from inside (if that makes sense to you) | 22:33 |
| beuno | Haffi___, what command are you running to push the branch? | 22:33 |
| spiv | "Connection refused" sounds more like a network configuration issue than a software dependency issue. | 22:33 |
| nDuff | Haffi___, you should have the SFTP URL using an address you can use at the ssh command line | 22:33 |
| Haffi___ | bzr push --create-prefix sftp://haffi@[my_ip]/~/Code | 22:33 |
| nDuff | Haffi___, ...if you can't use the address you're trying to deal with from inside your network [a NAT issue, maybe?], then you should work with your IT folks to get an address you *can* use from where you're working. | 22:34 |
| Haffi___ | nDuff: Yes, I'll have to check that out. This is actually just a server running in my home :) | 22:35 |
| mwhudson | grar | 22:35 |
| * beuno -> home | 22:35 | |
| mwhudson | when will bzr info bzr+ssh://.. not say | 22:35 |
| mwhudson | Repository branch (format: unnamed) | 22:35 |
| Haffi___ | Sorry you guys, I was just using the wrong IP address | 22:36 |
| Haffi___ | should of course have used the internal one instead of the external one... | 22:37 |
| NfNitLoop | Hmm. So someone decided to make a portion of SVN /trunk read-only (because it has been relocated to another repository). | 22:39 |
| NfNitLoop | I figured, fine... I'll just bzr co http://svn/trunk; cd trunk; bzr merge ../mybranch; bzr rollback read-only-dir; | 22:40 |
| NfNitLoop | I bzr commit; to my local repo, make sure that no files in read-only-dir were changed in that revision... | 22:41 |
| NfNitLoop | then try to bzr push back into svn/trunk. | 22:41 |
| NfNitLoop | But I get an error message regarding accessing some file in read-only-dir. | 22:41 |
| NfNitLoop | I'm assuming, to set some svn:prop on it? | 22:41 |
| NfNitLoop | any way to avoid that? | 22:42 |
| NfNitLoop | (oops. 'revert', not 'rollback'. sorry, been touching SQL) | 22:44 |
| Haffi___ | One more question for you guys; if the branch is published via SSH, should I make an account for every user that is working on the files or can they all use the same username? | 22:46 |
| nDuff | Haffi___, just from a sysadmin best-practices perspective, it'd probably be better to make separate accounts -- that way you can revoke just one user's access if someone is fired / leaves the project / whatever, without needing to distribute a new password | 22:47 |
| nDuff | Haffi___, that said, nothing about bzr inherently dictates one policy or the other. | 22:48 |
| NfNitLoop | Oh, Google had my answer for me: bzr dpush | 22:49 |
| Haffi___ | nDuff: Thanks, there are only three of us working on this, so if bazaar doesn't care if there are many people using one username then that is simpler for me :) | 22:49 |
| Haffi___ | nDuff: Well, then again, it's impossible to track who did what... | 22:50 |
| spiv | You can also use the script in contrib/bzr_access to limit access of particular SSH keys. | 22:50 |
| nDuff | Haffi___, if everyone is well-behaved and sets their identities through "bzr whoami", that information will be attached to the changesets | 22:50 |
| spiv | Even better, if everyone is *really* well-behaved their revisions will be gpg-signed. | 22:51 |
| nDuff | spiv++ | 22:51 |
| Haffi___ | nDuff: Oh, that's nice. I thought the ssh/linux username was used for that | 22:51 |
| nDuff | Haffi___, I'm presuming that they're doing the actual work on their own, remote systems, running "commit" there, and just pushing up to the central server; their identity on the system where they did the commit is attached to that commit, wherever it may be pushed later. | 22:52 |
| fullermd | And if everyone is poorly-behaved and fakes their whoami identities, the system account that added the revs isn't stored anywhere so it wouldn't matter anyway. | 22:52 |
| spiv | Haffi___: it'll default to username@hostname if it isn't set explicitly -- but the whoami info is only used when generating a revision, which wouldn't be happening on a remote system anyway. | 22:53 |
| Haffi___ | nDuff: Your description is quite accurate... | 22:53 |
| NfNitLoop | Hrmm. Even dpush is failing... | 23:07 |
| NfNitLoop | SubversionException: ("CHECKOUT of (file in read-only-dir) : 403 Forbidden | 23:08 |
| NfNitLoop | why would it need to be checked out? it's already been 'bzr pull'ed into the local repo, and no local changes exist... | 23:08 |
| enigma42 | jelmer: Does bzr-svn look at the "bzr:*" properties for the most recent revision, or does it look at the value of the properties in past revisions? | 23:25 |
| enigma42 | jelmer: A related question: Is there a clean way of removing all the bzr metadata from an existing svn repo and starting over? | 23:27 |
| Haffi___ | Hi again, just a silly question. I have created a test project, added some files, edited some and commited the changes. When I try to branch from another computer I just get an empty folder but not the contained files. What am I doing wrong? | 23:35 |
| beuno | Haffi___, did you run "bzr add"? | 23:36 |
| Haffi___ | beuno: yep | 23:36 |
| Haffi___ | on the server that is | 23:37 |
| beuno | Haffi___, are you pushing to the other PC, or branching? | 23:37 |
| Haffi___ | I'm trying to fetch the newest versions of the files to the other computer | 23:38 |
| beuno | Haffi___, so you're running "bzr push"? | 23:39 |
| Haffi___ | yes, I ran that command on the server | 23:39 |
| beuno | Haffi___, pushing to a remove location doesn't create a working tree (the actual files), it just creates the repository (a .bzr directory) | 23:40 |
| beuno | if you branch *from* it, you will get the files | 23:40 |
| beuno | also, if on the server you run "bzr checkout .", it will create the working tree for you | 23:40 |
| beuno | bare in mind that it won't update the working tree every time you push | 23:41 |
| Haffi___ | it says that the .bzr file exists | 23:41 |
| beuno | Haffi___, maybe it's just "bzr checkout" | 23:42 |
| beuno | I forget :) | 23:42 |
| Haffi___ | that actually gave the same results... | 23:42 |
| NfNitLoop | haha, yes. just 'bzr checkout' | 23:42 |
| NfNitLoop | `bzr checkout .` says to check it out ... into the current directory. | 23:43 |
| Haffi___ | Ok, I went into another directory and ran bzr checkout ../Code (where the files are). I just get an empty folder | 23:44 |
| lifeless | Haffi___: what does 'bzr log ../Code' show? | 23:47 |
| Haffi___ | lifeless: nothing | 23:48 |
| === edcrypt is now known as edcrypt_ | ||
| === edcrypt_ is now known as edcrypt__ | ||
| === edcrypt__ is now known as edcrypt | ||
| lifeless | Haffi___: you haven't committed, or you haven't pushed | 23:50 |
| Haffi___ | Ok, let's say I'm on my PC. I create a project (bzr init), I add a file, I edit it, run bzr add, and run bzr commit. Then I push this project via sftp to my server. with 'bzr push --create index sftp://...' | 23:52 |
| Haffi___ | *--create-index | 23:52 |
| Haffi___ | then I check the server to see which files are there, and there's just the directory, no files | 23:52 |
| === edcrypt is now known as edcrypt_ | ||
| Haffi___ | Can anyone spot what I'm doing wrong? | 23:54 |
| NfNitLoop | Haffi___: you're doing nothing wrong. | 23:54 |
| NfNitLoop | when you push over (S)FTP or HTTP... | 23:54 |
| NfNitLoop | bzr doesn't construct the "working copy" of your files, because that would double (or more) the network traffic required. | 23:55 |
| NfNitLoop | all it does is update the revisions in the .bzr directory. | 23:55 |
| NfNitLoop | now if you bzr branch from that sftp location to your local computer, a working copy will be created on your local filesystem. | 23:55 |
| NfNitLoop | If you *want* a working copy on the server, you can ssh to the server and do 'bzr checkout .' | 23:56 |
| NfNitLoop | (in that dir) | 23:56 |
| nDuff | Haffi___, it creates a .bzr directory that contains everything you pushed; it's all there, but hidden. | 23:57 |
| spiv | In short: "bzr push" pushes branches, not working copies. | 23:57 |
| Haffi___ | yep, I noticed that | 23:57 |
| nDuff | Haffi___, folks can branch or checkout from it, so you should be all good. | 23:58 |
| NfNitLoop | Haffi___: the nice bit is that the .bzr directory is compressed, so it's smaller than a working copy too. :) | 23:58 |
| Haffi___ | Ok, now it works | 23:59 |
| Haffi___ | Well, I can go to sleep then :) | 23:59 |
| Haffi___ | Thanks you guys, this is an excellent community, very friendly and helpful. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!