| === JasonO_ is now known as JasonO | ||
| BlindWolf8 | Hello all | 05:08 |
|---|---|---|
| spiv | Hi BlindWolf8 | 05:09 |
| BlindWolf8 | I have a Bazaar for a team and they need to access the main branch. I know it's possible becaue I set this up a longt ime ago, but how can I make it so that the address they type is shorter? | 05:09 |
| BlindWolf8 | e.g., bzr+ssh://me@host/ vs bzr+ssh://me@host/.bzr/branches/trunk/ | 05:10 |
| spiv | You can use bzr_ssh_path_limiter from the contrib/ directory in bzr's source | 05:11 |
| BlindWolf8 | oh yeah, that rings a bell | 05:12 |
| spiv | See also http://doc.bazaar.canonical.com/plugins/en/bookmarks-plugin.html | 05:12 |
| spiv | Er, http://doc.bazaar.canonical.com/bzr.dev/en/admin-guide/simple-setups.html#using-a-restricted-ssh-account-to-host-multiple-users-and-repositories | 05:12 |
| spiv | (Although the bzr-bookmarks plugin is another approach to solving this problem) | 05:13 |
| BlindWolf8 | I'm going to login via SSH and look for bzr_ssh_path_limiter | 05:14 |
| spiv | http://bazaar.launchpad.net/+branch/bzr/view/head:/contrib/bzr_ssh_path_limiter | 05:16 |
| BlindWolf8 | Is there anything in the manual about bzr_ssh_path_limiter? | 05:16 |
| BlindWolf8 | I can't seem to find much | 05:16 |
| BlindWolf8 | oh, lemme take a look at that link | 05:16 |
| spiv | It's not in the manual yet :/ | 05:17 |
| spiv | It would be in the admin-guide link I pasted except the instructions on how to copy it out of the contrib/ directory to somewhere accessible to the command= directive in .ssh/authorized_keys was just a bit too complex compared to the advice that's currently there | 05:18 |
| BlindWolf8 | also, can you clarify soermthing for me? am I correct in assuming tha you can nly edit files via ftp, sftp and bzr+ssh protocols? | 05:18 |
| BlindWolf8 | it seems bzr only is just read only | 05:18 |
| spiv | (Which is to do something fairly similar, but with longer directives in the authorized_keys file) | 05:18 |
| spiv | I can, but first you'll have to clarify what you mean by "edit files" in this context :) | 05:19 |
| BlindWolf8 | edit = upload new/modified files | 05:19 |
| BlindWolf8 | (and delete files) | 05:19 |
| spiv | Which files are you referring to? Files in a working tree? | 05:19 |
| BlindWolf8 | files in a colocated branch | 05:19 |
| spiv | But that colocated branch is on a network file server rather than somewhere on your filesystem? | 05:20 |
| BlindWolf8 | that is correct. the colocated branch is on a server | 05:20 |
| BlindWolf8 | as far as I have researched, colocated branches are best for just one folder being versioned without the need for multiple branches | 05:21 |
| spiv | So, having a working tree on a server for a branch is uncommon. | 05:21 |
| BlindWolf8 | what is more common? | 05:22 |
| spiv | Because generally the workflow as a developer is "get a local branch, edit files and commit locally, push" (or "get a local checkout, edit files locally, and commit") | 05:24 |
| spiv | So in that scenario there's no reason to have a working tree on the server | 05:24 |
| BlindWolf8 | well, we only needed one branch, and it had to be on a server for sharing purposes | 05:24 |
| BlindWolf8 | so I thought colocated branch would be best | 05:25 |
| spiv | But if you're also using this as a mechanism to deploy changes to a website or something, then that can be done with plugins like bzr-upload or bzr-push-and-update. | 05:25 |
| spiv | (Or even just a cronjob that runs "bzr update" in that directory every 5 minutes or whatever) | 05:26 |
| BlindWolf8 | aren't those plugins not neded if you bind the branch? | 05:26 |
| BlindWolf8 | that is what I told my teammates to do | 05:26 |
| spiv | I think perhaps you're confused by the distinction between a "branch" and "working tree" | 05:26 |
| BlindWolf8 | most likely :-) | 05:26 |
| === r0bby is now known as robbyoconnor | ||
| bignose | BlindWolf8: the working tree is the files that you actually care about. the branch is the revision history and other metadata. | 05:27 |
| spiv | A branch is a thing you make other branches and checkouts from. | 05:27 |
| bignose | then there's the repository, which is where the revision data is stored. | 05:27 |
| spiv | Or, just see what bignose is saying :) | 05:28 |
| BlindWolf8 | have you guys consdiering updating the documentation? | 05:28 |
| BlindWolf8 | *considered | 05:28 |
| bignose | BlindWolf8: patches welcome :-) | 05:28 |
| BlindWolf8 | :-P | 05:28 |
| spiv | We do (that admin-guide section I linked to is fairly new for instance) | 05:29 |
| bignose | only half-joking. “you guys are way too close to the technical details to see what might be confusing to newbies. | 05:29 |
| BlindWolf8 | so...hmmm.... | 05:29 |
| BlindWolf8 | If i'm following you...the only thing I really want on the server is the repo | 05:29 |
| BlindWolf8 | ...right? | 05:29 |
| bignose | s//”/ | 05:29 |
| spiv | BlindWolf8: and the branch :) | 05:30 |
| spiv | BlindWolf8: http://doc.bazaar.canonical.com/bzr.dev/en/user-guide/index.html#team-collaboration-central-style | 05:30 |
| BlindWolf8 | yeah, since that has the files | 05:30 |
| bignose | BlindWolf8: if you don't want the working tree files in one location. configure that location with ‘--no-trees’ | 05:30 |
| BlindWolf8 | that's what I did with colocated branches | 05:31 |
| BlindWolf8 | I just made that on the server and told everytone to make them on their machines as well in a directory that they would work in | 05:31 |
| BlindWolf8 | then, they Pulled the info from the server and bound the branch | 05:31 |
| BlindWolf8 | and just commited like normal | 05:31 |
| spiv | BlindWolf8: Sounds good so far :) | 05:32 |
| BlindWolf8 | oh! | 05:32 |
| BlindWolf8 | guess I did everything right then | 05:32 |
| BlindWolf8 | :-) | 05:32 |
| BlindWolf8 | dunnoo...guess it just felt wrong to make a colocated branch on the server due to the name itself | 05:34 |
| BlindWolf8 | a server, to me, should be a shared repository | 05:34 |
| BlindWolf8 | sicne shared is in the name | 05:34 |
| spiv | Well, I probably would use regular branches in a shared repository rather than colocated branches on the server myself. | 05:36 |
| spiv | But I don't think there's any problem with using colocated branches like that. | 05:36 |
| BlindWolf8 | by regular, do you mean feature? | 05:36 |
| spiv | (And really that's just because that's what I'm used to.) | 05:36 |
| bignose | BlindWolf8: don't over-read the names of these things :-) | 05:36 |
| spiv | Um, I mean "not made with the bzr-colo plugin" | 05:36 |
| spiv | What do you mean by "colocated branch"? :) | 05:37 |
| bignose | the “shared” in “shared repository” refers *only* to sharing data between branches. | 05:37 |
| bignose | not between projects, not between users, not between anything else. | 05:37 |
| BlindWolf8 | yeah, I read about that on the site | 05:37 |
| BlindWolf8 | btw, I had an odd issue when I was working with Bazaar and my team | 05:43 |
| BlindWolf8 | they were all using Bazaar v2.3.1 Standalone | 05:43 |
| BlindWolf8 | and all on Windows machines, sans the Linux server | 05:43 |
| BlindWolf8 | I could not commit a file to the server larger than 37ish MB. | 05:44 |
| BlindWolf8 | the server has 512MB of RAM, and I threw Linux Mint on there | 05:44 |
| poolie | hi all | 08:10 |
| === jelmer_ is now known as jelmer | ||
| * jelmer waves | 08:13 | |
| vila | hey poolie | 08:13 |
| poolie | hi there | 08:14 |
| poolie | there's a meeting about lp bug states now in #ubunt-uds-mikszath | 08:14 |
| poolie | you know what i mean | 08:14 |
| poolie | hi vila, are you back? | 08:24 |
| poolie | oh ye | 08:24 |
| vila | yes | 08:24 |
| vila | no network available yesterday so I couldn't tell :) | 08:24 |
| vila | I was too busy to search for a net access anyway ;) | 08:25 |
| poolie | no problem | 08:27 |
| poolie | was it good? | 08:27 |
| vila | yes, on many counts | 08:29 |
| poolie | nijaba was just saying he saw you and raphael there | 08:29 |
| poolie | you looked busy :) | 08:29 |
| vila | wearing a new hat and speaking native revealed... too many details to summarize :) | 08:30 |
| poolie | :) | 08:31 |
| vila | but roughly, after a slow start searching my words (doh !) I had a lot of very interesting discussions on topics I'm not used to talk about anymore | 08:32 |
| vila | There were far more high-in-hierarchy people that I suspected and clearly things are moving in the right direction for FOSS | 08:33 |
| vila | Interesting feedback from the Gendarmerie Nationale too (~35.000 PC using Ubuntu/Open Office, tagetting ~80.000) | 08:34 |
| vila | (imbw on the numbers but the scale is correct) | 08:34 |
| vila | ..and some fun confidential details on *how* this all started :) | 08:35 |
| vila | let's just say that techies get their revenge against politicians :D | 08:35 |
| vila | I indeed say raphael and nijaba but was just able to say hi to nijaba (and couldn't even say bye ;) | 08:39 |
| vila | I talked a bit with raphael though (about hamster among other things which he said he's very happy with ;) | 08:39 |
| fullermd | 's good for people to get on Open Office just in time for it to fade away :p | 08:45 |
| vila | fullermd: hehe, but didn't Oracle say the light there ? | 09:00 |
| vila | s/say/saw/ | 09:00 |
| vila | worst typos make sense... | 09:01 |
| fullermd | The light of what? The Sun? :p | 09:01 |
| vila | hehe, got some weird stories about sunnies in Oracle too... | 09:02 |
| fullermd | 'see' would be the right conjugation there. | 09:02 |
| fullermd | I figure anything that happens in Oracle has to be weird... | 09:03 |
| vila | bbiab | 09:07 |
| === med_out is now known as medberry | ||
| poolie | mup poke warner | 09:25 |
| poolie | bah | 09:25 |
| poolie | jelmer, jam, vila, do you see any point in further discussion about python2.4? | 09:45 |
| poolie | i think we should just go to 2.6 | 09:45 |
| poolie | and start getting ready for 3 | 09:45 |
| vila | poolie: right, I re-read the thread yesterday as I thought there was some pending issues, but | 09:46 |
| vila | as long as we keep bzr-2.3 python-2.4 compatible, I think we're fine | 09:47 |
| vila | maxb: we already dropped hardy in the beta ppa right ? | 09:47 |
| vila | hmm, no :) | 09:48 |
| poolie | i think it's not going to be updated though | 09:48 |
| poolie | i think we will need python3 support well before the eol of rhel5 and lucid | 09:49 |
| poolie | and there seems a reasonable chance we cannot support both of them at the same time | 09:49 |
| poolie | vial, do you think we could set up a babune helper that runs with python2.6 -3? | 09:49 |
| poolie | or 2.7 | 09:49 |
| poolie | also, like we talked about a while ago, i'd really like to get some subset of builders that are reliably blue | 09:49 |
| vila | AIUI, people on rhel should be able to find a suitable python | 09:49 |
| vila | poolie: yeah, I was thinking about working on babune a bit again | 09:50 |
| vila | There is an open bug on jenkins for the 'fail to delete tmp file' that is the cause of most of the noisy failures these days | 09:51 |
| vila | I think they made a change in how the track the connection status between master and slave. This bug is the most obvious fallout and I hope it will make the other issues I had more obvious | 09:52 |
| vila | but they just released 1.411 without fixing it :-/ | 09:52 |
| poolie | :/ | 09:54 |
| poolie | is everyone using jenkins experiencing this, or is it something we're doing? | 09:54 |
| maxb | poolie/vila: There's been no discussion about ceasing hardy support in the PPAs | 09:56 |
| maxb | I startd a thread, but there was little reaction | 09:56 |
| maxb | We recently got a bug report from someone using the beta ppa on hardy | 09:56 |
| vila | poolie: I made a comment on an existing bug but ISTR that lp has also been experiencing it | 09:56 |
| vila | maxb: ha. So we have an issue then | 09:57 |
| maxb | We're only stepping to py2.5 for now, right? | 09:57 |
| vila | maxb: unless you intend to backport python-2.6 there ? :) | 09:57 |
| maxb | oh | 09:57 |
| maxb | apparently not | 09:57 |
| vila | maxb: yeah, that's why I re-read the thread, at first I thought we wanted to target 2.5 only too | 09:58 |
| maxb | Hmm. What would be really useful, is PPA download counts that exclude hits from the PPA buildds | 09:58 |
| vila | maxb: do you have the bug # for that hardy user ? | 09:59 |
| maxb | No bug, email on bazaar@, John Szakmeister | 09:59 |
| vila | maxb: I thought your thread about hardy in PPAs ended with: no SRUs so stick with 2.3 | 10:00 |
| vila | obviously I was wrong, but that still seem to be the most adequate plan no ? | 10:01 |
| maxb | The thread mysteriously conflated PPAs with SRUs for no apparent reason, and fizzled | 10:01 |
| vila | maxb: wow, just found this mail John Szakmeister, didn't realize he was still using hardy... | 10:03 |
| maxb | Hardy is already in limited support, which ends April 2013 | 10:04 |
| maxb | The only reason to keep it would be stubborn people still on LTS-1 | 10:04 |
| vila | hmm | 10:05 |
| vila | the stable ppa still carries 2.3.1, so we can decide to leave it at that when 2.4.0 is released, | 10:05 |
| ScottK | Even Dapper is still supported in Ubuntu (for another month) | 10:06 |
| vila | that leaves only people using the beta ppa for hardy in a weird state but if we stop at 2.4b2 for hardy there, they will just have to.... to what... | 10:06 |
| vila | ScottK: right, but people still using it *and* wanting recent versions of bzr are a bit schizophrenic no ? | 10:07 |
| poolie | maxb, ah, i did reply | 10:12 |
| ScottK | vila: Agreed. | 10:13 |
| ScottK | OTOH, I do have one server that there's no hardware support for past Hardy, so it will never run a later release. | 10:13 |
| poolie | maxb, nobody replied to say they want 2.4betas | 10:14 |
| ScottK | That is a narrow case however. | 10:14 |
| maxb | True | 10:14 |
| poolie | _my_ point about srus is that i think you (or we) would please more people by doing the 2.2 lucid sru | 10:14 |
| maxb | If we ditch hardy, we'll also ditch jaunty, which will mean we no longer have to support series that don't support debian source format 3.0, which is nice | 10:15 |
| * vila nods | 10:15 | |
| vila | maxb: for >= 2.4, we'll still support hardy and jaunty for 2.3 right ? | 10:16 |
| vila | by the way, I should cut 2.3.2 tomorrow and probably 2.1.4 next week | 10:17 |
| vila | s/I should/I planned but this may be revisited/ | 10:18 |
| maxb | Well, jaunty's already way past EOL | 10:19 |
| maxb | we're only supporting it still because the PPA buildfarm still does, and it's no extra effort so long as we support hardy | 10:19 |
| vila | maxb: no objection from me to drop jaunty | 10:19 |
| vila | err, I mean, whatever cost less, but the idea is to keep 2.3 supported where it's supported today while dropping hardy [jaunty] for 2.4 | 10:21 |
| maxb | that seems reasonable | 10:21 |
| vila | even karmic can be dropped for 2.4 if we want to clean things up | 10:21 |
| fullermd | Hm, cython thread. Maybe I need to try that again. | 10:23 |
| poolie | hi jam | 10:27 |
| poolie | are you coming next week? | 10:27 |
| vila | poolie: drizzle hits the same jenkins problem, just found back your email about it | 11:06 |
| poolie | oh really | 11:10 |
| poolie | is it specific to building things from bzr? | 11:10 |
| vila | I don't think so | 11:11 |
| vila | I can't think of a reason why it should even be remotely connected :) | 11:11 |
| poolie | hm | 11:22 |
| poolie | do you know why http://babune.ladeuil.net:24842/job/selftest-hardy/470/ failed for example? | 11:23 |
| vila | poolie: precisely this reason: http://babune.ladeuil.net:24842/job/selftest-hardy/470/console scroll down to the bottom | 11:29 |
| vila | hudson.util.IOException2: remote file operation failed: /tmp/hudson6106588248283886773.sh at hudson.remoting.Channel@1030a0f8:hardy32.local | 11:29 |
| poolie | right that's what i wondered | 11:32 |
| poolie | i wonder if we should do more stuff out of the recipe nightly builds | 11:33 |
| poolie | which will only help on ubuntu of course | 11:33 |
| poolie | but will reliably tell us if we break say lucid | 11:33 |
| poolie | of course there are some noise failures there too, but generally they seem to be real packaging failures, if not upstream bugs | 11:33 |
| vila | well, the recipes are intended to *build* something, running selftest there is a side-effect, nice one, but still a side-effect | 11:34 |
| vila | and without the ability to parametrize the selftest run | 11:34 |
| vila | I share the frustration about jenkins adding a lot of noise (especially lately) but I still think these jenkins bugs will be fixed and that spending time debugging them is not the best use of my time :-} | 11:35 |
| poolie | i agree with that | 11:36 |
| poolie | as long as we know they're upstream bugs not something about our deployment or bzr itself | 11:37 |
| poolie | then we can just ignore them | 11:37 |
| poolie | i guess better if we can all get an idea of what kind of pattern likely indicates a spurious faliure | 11:37 |
| vila | poolie: you just did :) | 11:40 |
| poolie | haha | 11:40 |
| poolie | i guess the lesson is just ask you | 11:40 |
| poolie | if it's not clear | 11:40 |
| vila | well, what I do is look at the failures, there are not a gazillion of failures that produces no test results | 11:41 |
| vila | the fact that *I* can delete these helps keep babune blue and if I was giving such access more liberally more people will learn | 11:42 |
| vila | I spotted the ability to use openID providers for authentification and I thought that would be a good idea for babune (less admin hassle for me too) | 11:42 |
| vila | but... I need to find a free slot in my schedule ;) | 11:43 |
| poolie | oh, you remove the build record? | 11:43 |
| poolie | that's an interesting idea | 11:43 |
| vila | when it's due to a jenkins bug ? Yes, otherwise the job history itself becomes noisy | 11:44 |
| vila | and that would be even worse | 11:44 |
| vila | but doing that is ~5mins/day at *most* (so no hamster for it ;) and roughly the only work I do on babune | 11:45 |
| jelmer | jam: hi | 11:48 |
| jam | hi jelmer | 11:49 |
| jelmer | jam: I'm looking at bug 146165 but wondering which of the WorkingTree APIs to actually use | 11:49 |
| ubot5 | Launchpad bug 146165 in Bazaar "smart_add uses _get_inventory, _write_inventory, but should not" [Medium,In progress] https://launchpad.net/bugs/146165 | 11:49 |
| jelmer | I originally started out calling WorkingTree.add(), but that doesn't work when there are e.g. files that have been converted to directories | 11:50 |
| jam | jelmer: ideally it would build up an inventory delta, and pass that in | 11:50 |
| jam | I don't know if all the apis are available | 11:50 |
| jelmer | jam: That'd make sense, I'll look into it | 11:53 |
| jelmer | thanks | 11:53 |
| poolie | vila, i was just forwarding that mail from someone at drizzle | 12:07 |
| poolie | can you reply to them | 12:07 |
| poolie | i'd like them to know it's now bzr's fault, if it's not | 12:07 |
| poolie | s/if/as | 12:07 |
| vila | poolie: you forwarded the body, no emails there :-. | 12:17 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| exarkun | I wonder if anyone can help me understand what the author of bzr+ssh://bazaar.launchpad.net/~morgan-s-reed/pyopenssl/mr-RSAadditions/ did (with respect to lp:pyopenssl) and if there's anything special I should do if I want to merge that branch. | 13:28 |
| * maxb fetches the branches | 13:31 | |
| maxb | exarkun: Looks like he just started a long time ago, did some work, then came back to it, and then gradually merged newer versions of trunk to get up to date | 13:34 |
| maxb | then did a little more work | 13:34 |
| maxb | So, there's nothing particularly special going on here. | 13:34 |
| spiv | exarkun: have you tried "bzr merge --preview $URL" in your local copy of lp:pyopenssl ? | 13:36 |
| exarkun | spiv: apart from the "--preview" part, yes | 13:36 |
| spiv | Or just s/--preview// and examine what what it does before you commit, yeah. | 13:36 |
| exarkun | I did that and 'bzr qlog' and the picture qlog drew confused me | 13:37 |
| spiv | Ok, so if the diff is fine I'd just commit it. | 13:37 |
| exarkun | well, there's also a ton of conflicts in every changed file, but that part I understand :) | 13:38 |
| maxb | exarkun: Well, given the branch last merged trunk two releases ago, that's not unexpected, is it? :-) | 14:08 |
| exarkun | maxb: nope | 14:10 |
| poolie | jam, spiv, vila, discussion of udd in #ubuntu-uds-kond | 14:31 |
| jam | poolie: that is an empty room | 14:32 |
| vila | jam: s/kond/ond/ | 14:33 |
| poolie | i think it is 'kond' | 14:34 |
| jam | poolie: kond is empty, and ond is talking about color schemes and the color picker | 14:36 |
| jam | poolie: maybe I typod it, I'm there now | 14:36 |
| poolie | jam, i think i did work on that | 15:05 |
| poolie | but quite a while ago | 15:05 |
| jam | poolie: https://bugs.launchpad.net/bzr/+bug/781168 | 15:08 |
| ubot5 | Ubuntu bug 781168 in Bazaar "WT.update_basis_by_delta checks the current tree state to determine InvalidDelta" [High,Confirmed] | 15:08 |
| vila | jam: ok, for osutils, didn't remember sha_strings et al. | 15:17 |
| jam | vila: Mr. Config Man, I have a config question for you. | 15:19 |
| jam | I'm looking into setting a config var for how our Pack code works | 15:20 |
| vila | hehe, shout | 15:20 |
| jam | something that sets max size, max pointer, something like that | 15:20 |
| jam | so people can tweak it to lower peak memory (in theory) | 15:20 |
| jam | however, VersionedFiles have no config available | 15:20 |
| jam | much less the GroupCompressor object | 15:20 |
| jam | where I really want the data | 15:20 |
| jam | (the value to be set) | 15:20 |
| jam | Even if I back up one higher, I end up at Repository, which at best can get LocationConfig(self.user_url) | 15:21 |
| jam | (which would then pass it down to the next levels) | 15:21 |
| jam | I *could* just put it in GlobalConfig | 15:21 |
| jam | and then access it at a very low level (ugly, but doable) | 15:21 |
| jam | vila: thoughts? | 15:22 |
| vila | you get it right :) | 15:22 |
| vila | today, I'd say just go with GlobalConfig | 15:22 |
| vila | ideally we probably want to provide the repo config down | 15:23 |
| jam | vila: but who checks GlobalConfig, the GCVersionedFile ? | 15:24 |
| jam | or the Repository? | 15:24 |
| vila | jam: the actual "style" is to build a GlobalConfig() when you need it | 15:25 |
| jam | vila: I don't really want to re-create a GlobalConfig each time I get a new block to create. | 15:30 |
| jam | I can do it per stream, but that's also a bit of overhead | 15:31 |
| jam | and there is a special case where we take an existing block and break it up into smaller blocks. | 15:31 |
| vila | jam: otp, but that's the actual design didn't help for that, bbiab | 15:31 |
| jam | I don't quite understand what you wrote there | 15:32 |
| jam | (and the object that does that isn't always created from a Repository, as it has a direct instantiation function from NetworkRecordStream) | 15:33 |
| poolie | hi vila, jam | 15:44 |
| poolie | two interesting ideas from the udd session | 15:44 |
| poolie | one by jelmer which is maybe having a merge helper that fixes up quilt metadata | 15:44 |
| poolie | rather than importing to looms, which seesm to have a long dependency chain | 15:44 |
| poolie | oh the other was, perhaps having a staging packgae importer would make us feel more comfortable changing it | 15:48 |
| jam | poolie: you can import_package --no-push I think | 15:49 |
| jam | which is meant to be "do the import, but throw away the results" | 15:49 |
| jam | not quite the same as staging, thoug | 15:49 |
| poolie | mm | 15:50 |
| poolie | perhaps it's enough | 15:50 |
| poolie | i guess you can test locally too | 15:50 |
| poolie | thinking about small fixes or investigations i did before, i would have found it reassuring to have a realistic but safe test | 15:51 |
| * vila back | 15:53 | |
| maxb | poolie: There's also the --local-branches option which allows for testing tweakage which requires the result branches actually get kept locally, and re-used on a second invocation | 15:53 |
| vila | jam: the actual design doesn't help with config sharing so we create config objects when we need them | 15:53 |
| poolie | py26 then hey | 15:54 |
| jam | poolie: yep, py2.6. All we really needed was a "JFDI" and we DI :) | 17:28 |
| === deryck is now known as deryck[lunch] | ||
| poolie | glad i could help | 17:35 |
| gholms | I tried fast-importing a git repository, but got a bunch of complaints about how it "Cannot import items of kind 'tree-reference' yet" and it tore my directory structure to shreds. Do I have any hope of making it work? | 18:07 |
| === deryck[lunch] is now known as deryck | ||
| TrentonDAdams | I'm confused by the bzr svn document in section "Merging trunk to your feature branch". It says that you shouldn't merge the trunk to your feature branch, but then it says to use merge later on. | 18:50 |
| TrentonDAdams | Is it simply saying that merging trunk should be avoided because of the risk of accidentally using push to get the branch back into trunk? If so, the wording should really be changed, because it sounds like it's saying don't do merging between trunk/branch, but then it says to go ahead and do that. | 18:52 |
| === medberry is now known as med_out | ||
| === Ursinha is now known as Ursinha-afk | ||
| BjornW | Quick question: I want to write a PHP lib for using Bzr, probably similar to PEAR VersionControl_Git and VersionControl_Svn and would like to discuss this with the bzr developers. Should this become a Blueprint or can I submit a mail to the developers mailinglist? | 20:28 |
| === lifeless_ is now known as lifeless | ||
| BjornW | Answering my own question: I will send an email :) | 20:54 |
| === r0bby is now known as robbyoconnor | ||
| === cinerama_ is now known as cinerama | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!