| spiv | There's a bug open about that, https://bugs.launchpad.net/bzr/+bug/569361 I think. | 00:51 |
|---|---|---|
| ubot5 | Launchpad bug 569361 in Bazaar "Remembering an URL different from the one the user entered is surprising (affected: 3, heat: 18)" [Wishlist,Confirmed] | 00:51 |
| TresEquis | Anybody seen bzr-svn create bogus tags when pushing to SVN after merging from another bzr-svn branch? | 03:54 |
| spiv | TresEquis: I haven't, sounds like a good bug to file. | 04:10 |
| TresEquis | spiv: I would file it if I could figure out how to reproduce it | 04:19 |
| TresEquis | happened twice to me yesterday, but I'm not sure why /how | 04:19 |
| TresEquis | This checkin was a push from a local bzr branch to the bzr-svn checkout :parent | 04:24 |
| TresEquis | https://mail.zope.org/pipermail/checkins/2010-June/047200.html | 04:24 |
| TresEquis | followed immediately by creation of bogus tags: | 04:24 |
| TresEquis | https://mail.zope.org/pipermail/checkins/2010-June/047201.html | 04:24 |
| TresEquis | https://mail.zope.org/pipermail/checkins/2010-June/047202.html | 04:25 |
| TresEquis | etc | 04:25 |
| spiv | Hmm. :( | 04:25 |
| spiv | Does your local bzr branch have tags with those names in the 'bzr tags' output? | 04:25 |
| TresEquis | none of those tags ever existed in that project, nor any such releases | 04:25 |
| TresEquis | spiv: hmm, I think I wiped out the local checkout ;( | 04:25 |
| TresEquis | yup ;( | 04:26 |
| TresEquis | I have a half-baked theory that bzr might have been confused by an attempt to merge an unrelated branch | 04:27 |
| TresEquis | which didn't actually make any changes in my working tree | 04:27 |
| spiv | Oh, yes, that does sound plausible off the top of my head. | 04:27 |
| TresEquis | but maybe it messed up the tags bookkeeping? | 04:27 |
| * spiv takes a peek at the code | 04:27 | |
| * TresEquis crosses his fingers | 04:28 | |
| spiv | Hmm. | 04:28 |
| spiv | Yes, that does seem plausible, if you managed to get bzr to go as far as fetching revisions from the other branch into this one. | 04:29 |
| TresEquis | it seemed to try, then give up claiming "no common revisions" or something | 04:30 |
| spiv | Hmm, that doesn't sound right then. | 04:31 |
| spiv | I'm pretty sure tags are only updated after fetching the actual revision objects, and that can only happen after determining the revisions to fetch, which is when that error would happen. | 04:32 |
| spiv | It's possible there's a code path I'm not noticing, of course. | 04:32 |
| TresEquis | if it matters, the two trees both point back to the same SVN repository | 04:32 |
| TresEquis | just to different project areas in it | 04:32 |
| spiv | I wouldn't expect that to matter, directly. Well, that's presumably what allows bzr to know that it can even create those tags (because the revisions from the other repo are there), but doesn't address the mystery of why bzr/bzr-svn is mixing tags from an unrelated project. | 04:35 |
| TresEquis | all the branches (bzr-svn checkout, local branc) were inside a shared repo, if that matters | 04:35 |
| TresEquis | anyway, I will post a bug with as much information as I have | 04:40 |
| TresEquis | even though reproducing it seems wicked | 04:40 |
| spiv | That would be good, I suspect jelmer may be able to guess the bug :) | 04:41 |
| spiv | I don't suppose anyone knows much about configuring apache to use active directory? If you do, https://answers.launchpad.net/bzr/+question/113185 could use your help. | 04:45 |
| TresEquis | Posted here: https://bugs.launchpad.net/bzr-svn/+bug/589514 | 04:46 |
| ubot5 | Launchpad bug 589514 in Bazaar Subversion Plugin "Bogus tags created after failed merge attempt (affected: 1, heat: 6)" [Undecided,New] | 04:46 |
| TresEquis | Thanks for the sounding board, spiv | 04:54 |
| poolie | spiv, thanks for the import test and patch | 05:19 |
| lifeless | spiv: poolie: you guys might benefit by lurking in #ubuntu-devel, amongst other channels. Just had a query about udd reliability there - I don't think most folk having bzr related things go wrong will think to come here in the first instance. | 05:21 |
| spiv | Hmm, I'm usually in there. I need to poke irssi harder to make that stick I guess. | 05:22 |
| poolie | yeah likewise | 05:36 |
| poolie | thanks for the reminder and for catching it | 05:36 |
| spiv | It's very wet today. | 05:45 |
| poolie | mm it is | 05:45 |
| lifeless | uhuh | 05:45 |
| === oubiwann is now known as oubiwann_ | ||
| parthm | poolie, lifeless: regarding ignore handling. while i prefer 'fail early' i am ok with warning for 'ignore', 'ignored', 'ls' and 'st' as these command don't change anything. | 05:52 |
| parthm | doing a warning for 'add' seems scary to me as the user might end up adding unwanted stuff to the repo. | 05:53 |
| parthm | he could revert but then he may not notice and just add more revisions. | 05:53 |
| parthm | we have seen tickets like thing regarding whoami guessing and .moved files being added. | 05:54 |
| parthm | i was hoping to catch jam but i guess its late in his timezone. | 05:54 |
| poolie | i think if you explicitly try to add an invalid file that should certainly fail | 05:55 |
| lifeless | poolie: spiv: check my facebook feed - not wet today :) | 05:56 |
| mwhudson | it's been very nice here today too | 05:56 |
| lifeless | poolie: not invalid file; invalid .bzrignore making the regex compilation fail | 05:56 |
| mwhudson | you have better mountains though | 05:56 |
| lifeless | you're in a mountain! | 05:57 |
| poolie | i think one interesting case is having a file with a bizarre name generated by a build process that you can't change | 05:57 |
| poolie | ah sorry, different bug | 05:57 |
| parthm | poolie: i am thinking if user does 'bzr add foo', it should work irrespective of bad ignore pattern. however a 'bzr add' should fail if there is a bad pattern in ignore files. | 05:57 |
| poolie | in that case i think it's within the person's power to fix it before doing anything else? | 05:57 |
| lifeless | poolie: certainly bad files in the tree shouldn't stop bzr being usable as long as they aren't versioned | 05:57 |
| lifeless | poolie: well thats what I've been arguing | 05:58 |
| poolie | parthm, right with 'add foo' (foo not a directory) we shouldn't need to even think about ignores | 05:58 |
| poolie | well that's nice we agree then :) | 05:58 |
| lifeless | jam and vila have expressed an interest in just warning and not stopping | 05:58 |
| lifeless | poolie: so you and I agree, jam and vila appear to agree with each other ;P | 05:58 |
| poolie | and they're both asleep... | 05:59 |
| parthm | poolie: if a user is hoping to ignore 'x.zz' and it gets added. he may not notice and end up adding a few more revisions. | 05:59 |
| poolie | ... so ... _-) | 05:59 |
| lifeless | there is discussion in the bug | 05:59 |
| lifeless | personally, I've said my bit - and any improvement over a backtrace is an improvement | 05:59 |
| lifeless | so, I'm -> loom stuff for a bit more, then EOD | 06:00 |
| poolie | incremental improvements and working code generally get my approval | 06:00 |
| lifeless | parthm: what time is it for you, now ? | 06:00 |
| poolie | ok | 06:00 |
| poolie | i'm going to concentrate on reviews for a bit | 06:00 |
| parthm | its 10:30 am ... i am planning to start working on a new patch for the ignore pattern issue. | 06:01 |
| lifeless | you should look at my scenery porn first :) | 06:01 |
| lifeless | poolie: ^ | 06:01 |
| * poolie coughs | 06:01 | |
| poolie | that is very pretty though | 06:01 |
| lifeless | hmm, facebook seem to discard lots of resolution. | 06:02 |
| poolie | interesting choice of foreground | 06:02 |
| lifeless | it *was* a 4K by 3K | 06:02 |
| poolie | oh from what camera? | 06:02 |
| lifeless | I have some others without anything but water in foreground | 06:02 |
| lifeless | coolpix s8000 | 06:03 |
| lifeless | has a 10x optical zoom, which is pretty nice | 06:03 |
| lifeless | nothing compared to your beasty | 06:03 |
| lifeless | but I wanted something I can hold for extended periods | 06:03 |
| lifeless | the other ones though aren't as dramatic on the mountains | 06:04 |
| lifeless | and I thought the prosaic foreground item was fun | 06:04 |
| mgz | morning all. | 06:09 |
| poolie | hi mgz | 06:12 |
| poolie | spiv, btw, you're pilot next week | 06:13 |
| poolie | i'm going to empty it a bit today if possible | 06:13 |
| spiv | Thanks :) | 06:13 |
| poolie | mgz, thanks for your review of the walkdirs patch | 06:35 |
| mgz | happened to be something I'd just been looking at from the other end in testtools, and before that with vila in bazaar.tests._rmtree_temp_dir | 06:36 |
| mgz | if we've got a function that wants to guarentee unicode (or utf-8) outputs, and has a posix filesystem as its input, something has to give | 06:37 |
| mgz | throwing a clear error like in the merge proposal is an improvement | 06:39 |
| poolie | yes | 06:39 |
| mgz | ah, that's what I was doing, commenting on one of you bugs about this | 06:45 |
| * mgz finishes typing that | 06:45 | |
| poolie | i wonder if i have some still unpushed developer docs about handling unicode | 06:51 |
| poolie | we could try to explain the general approach more | 06:52 |
| mgz | did I write anything for my nonc bits... | 06:53 |
| mgz | hm, just: | 06:53 |
| mgz | +No API should take '``str`` or ``unicode``' expecting to use ``isinstance`` to | 06:53 |
| mgz | +tell them apart. Text that may need to include non-ascii characters on some | 06:53 |
| mgz | +platforms, such as filenames or error messages, should be decoded to unicode | 06:53 |
| mgz | +at the earliest opportunity. Much of this will also need looking at carefully | 06:53 |
| mgz | +when considering a py3k port. | 06:53 |
| mgz | which isn't all that useful. | 06:54 |
| poolie | mgz, "use instance to tell them apart ... without a very good excuse" :-) | 07:00 |
| poolie | such as coping with a platform api that can return either | 07:00 |
| mgz | right. | 07:00 |
| mgz | we have to cope with such problems, don't want to propogate them | 07:00 |
| poolie | i've been meaning to write a tool that auto-fixes filenames | 07:02 |
| poolie | by guessing what encoding they're in and changing them to utf-8 | 07:02 |
| poolie | there are libraries to do the guessing | 07:02 |
| poolie | maybe such a tool exists | 07:02 |
| mgz | also foreign branches, I filed a bug against bzr-git the other day while trying to track down a different issue | 07:03 |
| mgz | a sensible guess is the right thing sometimes. | 07:03 |
| poolie | lifeless, so what did we finally agree about sphinx in pqm? we'll try to backport it? | 07:04 |
| mgz | bug 587074 it twath. | 07:04 |
| ubot5 | Launchpad bug 587074 in Bazaar Git Plugin "Branching tree with non-ascii filenames fails (affected: 1, heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/587074 | 07:04 |
| vila | hi all | 07:11 |
| parthm | hi vila | 07:13 |
| poolie | hi there vila | 07:13 |
| vila | \o/ | 07:13 |
| poolie | are your machines feeling better? | 07:13 |
| vila | yes, and an additional disk for backups is on its way | 07:14 |
| vila | Of course I had a kernel panic on OSX yesterday just to keep me on my toes, but I ignored it because enough is enough :) | 07:15 |
| poolie | good idea :) | 07:15 |
| poolie | i'm still waiting for my rebuilt machine | 07:15 |
| vila | poolie: errr, when did it broke ? | 07:16 |
| poolie | wow, two weeks ago now | 07:16 |
| poolie | but it took a while to conclude what was wrong | 07:16 |
| vila | wow, I was lucky enough to get mine so quickly then | 07:17 |
| vila | yeah, the diagnosis for mine went a bit fast because it was locking quite fast | 07:18 |
| vila | but in retrospect, I'm now convinced that the failure started manifesting itself long ago, but only once in a while (like once a month) | 07:18 |
| vila | I'm toying with the idea of using a remote log facility for cases like that (fullermd mentioned raid but I can't do that on the imac) | 07:19 |
| vila | But that's low priority, backups are better :) | 07:20 |
| poolie | so vila if we started testing python2.4 only in babune, do you think that would be fairly safe? | 07:21 |
| vila | Sure, let me check hardy's default version | 07:21 |
| vila | Unfortunately lucid doesn't support 2.4 anymore... | 07:22 |
| mgz | one concern I've got about that is Vincent's too good at just fixing things. when pqm fails, the patch submitter sees the fallout so there's some community learning about what isn't 2.4 safe. | 07:23 |
| poolie | that's true | 07:23 |
| vila | hmm, 2.5 is the default | 07:23 |
| poolie | yes | 07:23 |
| vila | hehe don't make me blush, | 07:23 |
| poolie | however we could make him put coding-style additions up when he fixes something | 07:24 |
| vila | The thing is it's still faster to fix things than finding the time to configure email sending on errors | 07:24 |
| poolie | i think fixing them is fine | 07:25 |
| poolie | but it should be visible somehow | 07:25 |
| vila | so hardy's default is 2.5, I can either add a specific run for 2.4 or just force 2.4 on hardy (but that feels wrong since it's not the default config used by hardy's users and that's wht I want to test primarily) | 07:25 |
| vila | I try to at least file bugs with a babune tags when I fix such things | 07:26 |
| vila | s/tags/tag/ | 07:26 |
| poolie | if you put up a mp adding to doc/developers/coding-style.txt and say why you need the addition | 07:26 |
| poolie | that will help | 07:26 |
| poolie | someone did that | 07:26 |
| poolie | recently | 07:26 |
| poolie | i'd care more about getting 2.4 on hardy than i would about retesting 2.5 on both hardy and jaunty | 07:27 |
| vila | ha no, the best solution for python2.4 is to add a centos/redhat slave | 07:27 |
| poolie | what's 'selftest-matrix' again? | 07:27 |
| poolie | oh that would be better | 07:27 |
| poolie | i'm not paying for a RHEL licence though :) | 07:27 |
| vila | the old way to run on all slaves which was confusing as all tests were consolidated there | 07:28 |
| vila | I will delete it once I get a blue babune including windows | 07:28 |
| vila | It's unfortunate that the default view is the 'all' one which by definition includes all jobs whether they are relevant or not (debug-* for example have a specific focus by definition) | 07:29 |
| vila | And by the way, there are tooltips on the colored icons | 07:29 |
| vila | hmm, no example there, but grey can mean either disabled or aborted | 07:30 |
| vila | selftest-matrix is disabled because it's obsolete | 07:30 |
| mgz | and here I was thinking you were testing bzr on human batteries | 07:31 |
| vila | template-selftest is disabled because it's not intended to be run but is used by selftest-<slave> to keep some definitions unique | 07:31 |
| vila | mgz: what did I tell you about rule #1 ? | 07:31 |
| mgz | there's no such thing as babune? | 07:32 |
| mgz | or was that rule #2... | 07:32 |
| vila | thre is no such thing as human batteries powered selftest :) | 07:36 |
| === radoe_ is now known as radoe | ||
| lifeless | poolie: I don't know what the consensus was | 08:11 |
| poolie | if you're talking about sphinx then i think it was that we'd try the backport | 08:18 |
| spiv | That was my impression too. I don't recall anyone objecting to that suggestion, at least. | 08:26 |
| poolie | lifeless, i don't want to be snarky but pqm failures now seem unreadable | 08:45 |
| poolie | since they lose the crlf distinction | 08:45 |
| poolie | i guess i should write an alternate encoding | 08:45 |
| mgz | subunit thing? what kind of unreadable? | 08:49 |
| mgz | I guess I need to try out my new powers and see what sort of mail sends soonish. | 08:50 |
| mgz | anyway, if it's because of \r in test output I might squash that at the testtools level | 08:50 |
| mgz | because it's a good way to break terminal output too. | 08:51 |
| mgz | >>> raise ValueError("\rgotcha!") | 08:52 |
| mgz | Traceback (most recent call last): | 08:52 |
| mgz | File "<stdin>", line 1, in ? | 08:52 |
| mgz | gotcha!ror: | 08:52 |
| lifeless | poolie: the fix is coded, see the lp rt queue for the request to deploy it | 09:04 |
| lifeless | poolie: (fix here meaning to send as an attachment) | 09:05 |
| lifeless | mgz: there is a bug open on subunit to use a more robust framing | 09:05 |
| mgz | right, but my point was random control characters are bad anyway | 09:05 |
| poolie | lifeless, that's nice | 09:07 |
| poolie | this is rt39555? | 09:08 |
| poolie | well, obviously | 09:08 |
| lifeless | poolie: something like that, I can look it up if needed, but it should be pretty obvious | 09:09 |
| lifeless | poolie: aaron wrote a sketch for me @ UDS, I polished and prepped, needs deployment | 09:14 |
| poolie | ok, i bumped it up for attention | 09:15 |
| lifeless | a better protocol would be nice | 09:17 |
| lifeless | so would a summary in the body of the mail; but I figured getting the terrible bahviour sorted was the high priority | 09:17 |
| bignose | The ‘bzr-buildpackage’ tool is capable of doing the equivalent of an export, but taking the current uncommitted files from the working tree. | 09:18 |
| bignose | is that a capability of the export command? | 09:18 |
| bignose | I want to be able to export the current what-would-be-committed working tree state. | 09:18 |
| poolie | there was a bug for that | 09:19 |
| poolie | i think someone fixed it? | 09:19 |
| poolie | but maybe not | 09:19 |
| bignose | $ bzr version | head -n 1 | 09:20 |
| bignose | Bazaar (bzr) 2.1.1 | 09:20 |
| bignose | $ bzr export --help | grep uncommitted | 09:20 |
| bignose | $ | 09:20 |
| poolie | i might sign off soon | 09:28 |
| lifeless | mgz: so | 09:49 |
| lifeless | mgz: matchers; did you look at the exception matcher in testrepository ? | 09:49 |
| vila | urgh argh eeerk, ssl fingerprint do not match wth ! | 09:54 |
| vila | fetchmail: despite my thanks for your wonderful support all those years: I hate you! | 09:54 |
| lifeless | ayan: hi | 10:07 |
| lifeless | ayan: what timezone are you in ? | 10:08 |
| lifeless | well gnight y'all | 10:46 |
| mgz | darn, came back too late | 10:58 |
| mgz | will have to catch lifeless in another cycle. | 10:59 |
| jelmer | mgz: 'morning Martin | 11:01 |
| mgz | morning jelmer. | 11:01 |
| parthm | what does the '?' indicate in 'bzr status'? i am getting a status of '? .bzrignore' for a test output. | 11:31 |
| jelmer | parthm: unknown file (not versioned, not ignored) | 11:32 |
| parthm | jelmer: thanks :) | 11:32 |
| bignose | parthm: ‘bzr help status-flags’ | 11:34 |
| parthm | bignore: neat. i didn't know about that. | 11:35 |
| parthm | sorry. i meant bignose :P | 11:35 |
| bignose | you may also want to know about nick completion in your IRC client :-) | 11:35 |
| parthm | bignose: yes. i think i should start using it :) | 11:35 |
| parthm | yup. it works :) | 11:36 |
| bignose | heh | 11:36 |
| bignose | parthm: for more interesting topics, ‘bzr help topics’ | 11:36 |
| parthm | bignose: yes. i have used that one. somehow i missed status-flags. | 11:37 |
| parthm | thanks. | 11:37 |
| peitschie | hi everyone | 11:44 |
| peitschie | does anyone know if there is an official policy for how bzr deals with ghost revisions? | 11:45 |
| jelmer | hi peitschie | 11:46 |
| jelmer | peitschie: Can you expand? Ghost revisions are just there (or rather, they aren't ;-) | 11:46 |
| peitschie | hi jelmer :) | 11:46 |
| peitschie | i'm chasing up 3 crashes that happen in qbzr tools... all related to ghost revs | 11:47 |
| peitschie | most of the time bzrlib throws errors if the revision doesnt exist | 11:47 |
| peitschie | in some cases i think this behaviour is incorrect (e.g., in repository.py def _get_revisions(self, revision_ids) for example) | 11:48 |
| peitschie | but just wondering if there was any disctussion about better ways of dealing with these? | 11:48 |
| peitschie | in some cases... qbzr can't possibly work around the iszsue, because it is calling a low-level bzrlib call with a bunch of revisions, which may or may not be ghosts | 11:49 |
| jelmer | peitschie: in general the policy is to raise exceptions when you ask for a single revision that doesn't exist | 11:49 |
| jelmer | peitschie: for calls that return multiple revisions such as get_revisions() it should probably either yield None or ignore the revision altogether if it's not present | 11:49 |
| jelmer | peitschie: you shouldn't be calling _get_revisions directly though | 11:50 |
| peitschie | jelmer: sorry... ur right... it is calling get_revisions :) | 11:50 |
| peitschie | jelmer: would it be bad in your opinion to return a partially filled Revision object with a special "missing=True' property? | 11:55 |
| jelmer | peitschie: In that case I'd opt for a GhostRevision object or something like that | 11:58 |
| peitschie | jelmer: ah.. That's a good idea! I'll introduce one of those | 11:59 |
| === Meths_ is now known as Meths | ||
| === nailuj24_ is now known as nailuj24 | ||
| amanica | has any body seen the following? (google doesn't know anything about it): ErrorFromSmartServer: Error received from smart server: ('error', 'Internal check failed: Cannot add revision(s) to repository: missing chk node(s) for id_to_entry maps') | 14:01 |
| amanica | I did a reconcile on the server but that didn't help :( | 14:03 |
| peitschie | amanica: are you using bzr-svn? | 14:14 |
| amanica | not in this case | 14:14 |
| amanica | do you think the plugin interferes? | 14:14 |
| peitschie | amanica: not unless you're mirroring from an svn repo :). how many revs in your repo? | 14:15 |
| amanica | in my branch 200, in my repo much more | 14:16 |
| amanica | I'm gonna try to upgrade the bzr on the server from 2.0.1 to 2.1.2 maybe that helps.. | 14:16 |
| mgz | hey marius! | 14:17 |
| mgz | how are you? | 14:17 |
| amanica | hey buddy mgz, I'm good thanks and you? | 14:17 |
| mgz | not too bad, sun is shining and lunch awaits. | 14:18 |
| amanica | I'm trying to get some work done, but things just keeps getting in my way :( | 14:18 |
| amanica | mgz: btw. congrats with being granted pqm access | 14:27 |
| bignose | Bazaar offers me a command to break a lock, but using the command doesn't work. | 14:31 |
| bignose | “If you're sure that it's not being modified, use bzr break-lock chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock | 14:31 |
| bignose | but: | 14:31 |
| bignose | $ bzr break-lock chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock | 14:31 |
| bignose | bzr: ERROR: Unsupported protocol for url "chroot-13269072:///bzr/collab-maint/comixcursors/comixcursors.debian/.bzr/branch/lock" | 14:31 |
| bignose | so presumably Bazaar should either gain the ability to do what it's offering to do, or not offer it. | 14:32 |
| jelmer | bignose: please file a bug | 14:33 |
| mgz | amanica: I have yet to try it out though, need to get one of your merge requests ready to land so I can break it :) | 14:33 |
| mgz | bignose: this is on launchpad, right? | 14:34 |
| bignose | I don't (yet) have a Launchpad account, I'd appreciate someone filing it on my behalf. | 14:34 |
| bignose | mgz: no, on Alioth | 14:34 |
| amanica | mgz: cool, will do :) | 14:34 |
| mgz | oh. you can still un-root the path to something you can access right? | 14:35 |
| mgz | I think I did that when I had a similar issue on launchpad | 14:35 |
| mgz | ...or maybe I deleted the branch and pushed again, don't recall. | 14:35 |
| bignose | I can work around the problem. but presumably the lock will remain until broken. | 14:35 |
| bignose | the bug is rather that the error message suggests a command that will never work. | 14:35 |
| mgz | what I mean is, can you give break-lock that url in a form it understands? | 14:35 |
| mgz | I'm not disputing that the message is a bug. | 14:36 |
| jelmer | bignose: try using ' bzr break-lock' on the URL you originally used to access the branch | 14:36 |
| bignose | mgz: hmm. you're suggesting that the problem is the error message is displaying the wrong URL, and a correct URL could be used? | 14:36 |
| mgz | right. | 14:36 |
| bignose | jelmer: does it need to go all the way to the ‘…/.bzr/branch/lock’ file? | 14:36 |
| jelmer | bignose: no, that's not necessary (both should work) | 14:37 |
| bignose | or could I just refer to ‘:bound’? | 14:37 |
| jelmer | perhaps, I'm not sure | 14:38 |
| jelmer | worth a try :-) | 14:38 |
| bignose | (the reason I'm asking, rather than trying it, is that I've already broken the lock by SSH onto the remote machine. so I can't test these questions.) | 14:38 |
| jelmer | I wasn't even aware the smart server over plain tcp worked on alioth these days.. | 14:38 |
| bignose | “plain TCP”? it's over SSH, I'm not sure if that's different from what you're saying. | 14:39 |
| jelmer | it's different, I meant bzr:// | 14:39 |
| jelmer | as opposed to bzr+ssh:// | 14:39 |
| bignose | okay. I've never tried the plain TCP protocol on Alioth. | 14:40 |
| bignose | nope, Alioth doesn't provide Bazaar plain TCP protocol. | 14:44 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| shrini1 | team | 16:52 |
| shrini1 | is there any way to rescue the disconnected "bzr branch" command? | 16:52 |
| shrini1 | i have disconnecting net onnection | 16:52 |
| maxb | I don't think it's possible to resume bzr branch | 17:11 |
| beuno | shrini1, use a shared repositoru | 17:11 |
| beuno | repository even | 17:11 |
| beuno | it will save the revisions to it, and will continue branching just from the ones it doesn't have | 17:12 |
| === IslandUsurperAFK is now known as IslandUsurper | ||
| === ericmoritz\0 is now known as Guest33830 | ||
| csgeek | how would I checkout out a particular revision of a bzr repo? (I've already pulled the branch and should have all the history ) | 20:46 |
| lifeless | csgeek: bzr revert -r xxx | 20:53 |
| lifeless | or if you want to make a new branch at an old revision, bzr branch -r xxx . ../b2 | 20:53 |
| csgeek | thanks | 20:55 |
| csgeek | nah.. just wanted to look at a particular revision. Just need to confirm something. Thank you | 20:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!