| poolie | like having no register_command() call, just looking up bzrlib.commands.$foo? | 00:00 |
|---|---|---|
| jam | that sort of thing | 00:02 |
| jam | and then falling back to some other place | 00:02 |
| jam | but honestly, it doesn't really matter | 00:02 |
| jam | and this is better than what we have today | 00:02 |
| GaryvdM | Hi igc | 00:05 |
| GaryvdM | Night all | 00:05 |
| igc | hi garyvdm | 00:05 |
| GaryvdM | Must get some sleep... | 00:06 |
| poolie | hello spiv | 00:08 |
| poolie | jam, that might be nice, but it seems to hit some snags with aliases etc | 00:08 |
| poolie | i'll try to keep going on it | 00:08 |
| poolie | being able to actually test that it's working and does not regress is very nice | 00:08 |
| poolie | if i say so myself | 00:08 |
| poolie | jam, spiv, don't forget to organize your travel btw | 00:08 |
| spiv | *nod* | 00:10 |
| codebloc | I'm consistently getting "out of memory" errors migrating my huge svn repos to bzr. Any way to get 64-bit bzr on windows? | 00:31 |
| poolie | codebloc: if you install a 64-bit python and then install from source that should do it | 00:32 |
| codebloc | poolie: thanks, and I almost got that going, but failed when zlib was missing | 00:33 |
| poolie | hm | 00:33 |
| poolie | i would have thought that would be included with python | 00:33 |
| codebloc | "bzrlib/_chk_map_pyx.c(32) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory" is the error | 00:33 |
| codebloc | i read it's statically linked with python | 00:34 |
| poolie | ah ok, you're trying to compile it? | 00:34 |
| codebloc | but even if it's included, the header file isn't | 00:34 |
| codebloc | don't I have to compile it, to install from sources? | 00:34 |
| poolie | you can run the pure python version | 00:34 |
| poolie | but that will be slower, which might be bad if you have a huge project | 00:34 |
| poolie | igc is working on windows build stuff | 00:35 |
| codebloc | I tried adding "--allow-python-fallback", as an option to setup.py build, but that wasn't recognized as a valid option | 00:35 |
| poolie | it may ring a bell with him | 00:35 |
| codebloc | i'm absolutely willing to use the slower pure python option if it gets me over this hump | 00:35 |
| codebloc | i'm trying to convince executives to switch to bzr from svn | 00:35 |
| poolie | hm | 00:36 |
| poolie | what happens if you just run 'bzr' from the source directory? | 00:36 |
| codebloc | hmm. it seems to run at least well enough to display usage | 00:37 |
| codebloc | let me try to run the convert command line from here | 00:37 |
| igc | codebloc: are you converting using svn-ipmort or fastimport? | 00:37 |
| codebloc | I read svn-import was faster, so that's what I'm trying | 00:38 |
| igc | codebloc: you might want to try the --incremental option and convert the repository in batches | 00:39 |
| codebloc | ok, so I tried what poolie suggested, and did a 'python bzr svn-import', but it reports the svn-import command is unknown, which I imagine is due to the warning it also issues saying some compiled extensions could not be loaded | 00:40 |
| codebloc | i'm willing to try batches as a one-time thing if that'll work | 00:40 |
| codebloc | but here's my concern | 00:40 |
| codebloc | some of the revisions in this repos include changes to a ~100MB binary file | 00:41 |
| codebloc | when I tried converting those revisions with mercurial, which I realize is somewhat different, the process jumped to nearly 2GB of memory and crashed almost right away | 00:41 |
| poolie | that will probably fit | 00:41 |
| codebloc | is it realistic to expect 32-bit windows bzr binaries to handle a few hundred MB files? | 00:41 |
| poolie | especially if you're using bzr 2.1 and going to a 2a repository | 00:41 |
| poolie | imbw | 00:41 |
| codebloc | i am | 00:42 |
| codebloc | ok, I'll try to do it incrementally | 00:42 |
| poolie | i'd try it | 00:42 |
| lifeless | codebloc: memory overhead for a X MB file is ~ 3X | 00:42 |
| lifeless | codebloc: some operations are a lot better, some few are worse. | 00:42 |
| poolie | there is a | 00:42 |
| poolie | bug, https://bugs.edge.launchpad.net/bzr-windows-installers/+bug/331342 that you can subscribe to/vote for | 00:43 |
| ubottu | Ubuntu bug 331342 in bzr "bzr python-based installer requires 32-bit python on windows; unclear message" [Medium,Confirmed] | 00:43 |
| codebloc | yeah, i saw that bug. i'll definitely subscribe to it | 00:43 |
| codebloc | i'll try the incremental approach | 00:43 |
| codebloc | thanks for the help | 00:43 |
| codebloc | if I run into more trouble i'll be back | 00:44 |
| poolie | codebloc: oh also https://bugs.edge.launchpad.net/bzr/+bug/545637 thanks for pointing that out | 00:54 |
| ubottu | Ubuntu bug 545637 in bzr ""setup.py build --allow-python-fallback" doesn't work; need build_ext" [Medium,Confirmed] | 00:54 |
| codebloc | poolie: no problem. I'll subscribe to/vote for that one too | 00:56 |
| fullermd | Speaking of bugs, which we weren't, am I somehow missing the blindingly obvious way to see the list of affects-me-too bugs? | 00:57 |
| poolie | https://bugs.edge.launchpad.net/malone/+bug/283539 does claim to be fixed... | 01:00 |
| ubottu | Ubuntu bug 283539 in malone "Make it possible to search for bugs affecting me" [Medium,Fix released] | 01:00 |
| poolie | fullermd: there is an option hidden 3 pages down in the advanced bug search page :/ | 01:04 |
| fullermd | Yes, but it doesn't show me all the bugs that I set affect on. | 01:05 |
| poolie | ! | 01:05 |
| poolie | i think you're right | 01:05 |
| fullermd | I search for any status, affects me, and I get 7 results, but bug 374734 (which I hit Affects on) doesn't show up. | 01:06 |
| ubottu | Launchpad bug 374734 in bzr "upgrading many branches is tricky" [High,Confirmed] https://launchpad.net/bugs/374734 | 01:06 |
| fullermd | And the list it does give is kinda weird. Some of them I filed, but it's not all the ones I filed. I'm pretty sure I didn't click affects on at least some of them... | 01:06 |
| fullermd | Owell. Just wondered. If I'm gonna be puzzled, I might as well be puzzled in company 8-} | 01:15 |
| poolie | i commented | 01:17 |
| poolie | you can too :) | 01:17 |
| fullermd | I would, but I set that it affects me, and now I can't find it again O:-> | 01:18 |
| mwhudson | james_w: now what's happening? http://pastebin.ubuntu.com/400307/ | 01:25 |
| igc | poolie ping | 01:30 |
| poolie | hi | 01:30 |
| igc | I need to run in a few minutes | 01:30 |
| igc | while I'm gone ... | 01:30 |
| igc | is there any chance we can rebuild the desolution instance? | 01:31 |
| igc | or whatever the term is | 01:31 |
| igc | there's new windows updates and some new software (sphinx) installed there | 01:31 |
| igc | poolie: it keep asking me to reboot but I'm not sure if we need to rebundle first or not? | 01:32 |
| poolie | on phone, we'll do it when you get back? | 01:32 |
| poolie | we can rebuild it but i don't want to rush | 01:32 |
| igc | poolie: sure | 01:32 |
| igc | poolie: it may reboot itself (thanks to Windows updates) while I'm gone anyway | 01:33 |
| igc | ok - got to go | 01:33 |
| * igc back in a few hours | 01:34 | |
| fullermd | Oh bother. | 02:23 |
| meoblast001 | fullermd: looks like someone's having client issues? | 02:46 |
| SamB_XP | or is an evil bot | 02:47 |
| naoki^ | fmm... zlib124dll.zip doesn't contain zlib.h | 03:22 |
| naoki^ | Windows installer fails. | 03:22 |
| james_w | mwhudson: I think the package hadn't built yet | 03:38 |
| wgrant | How do I resolve a 'path conflict'? | 03:39 |
| wgrant | Ah, looks like if I just resolve the target it works. | 03:40 |
| igc | back | 05:16 |
| poolie | hi igc | 05:19 |
| igc | hi poolie | 05:19 |
| GaryvdM | Morning all. | 05:33 |
| GaryvdM | I'm trying to use lazy imports in qbzr more. | 05:33 |
| GaryvdM | I've run in to a problem I'm not sure how to solve. | 05:34 |
| GaryvdM | I get this error on all os.path.xxx calls: | 05:34 |
| GaryvdM | bzrlib.errors.IllegalUseOfScopeReplacer: ScopeReplacer object 'path' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory | 05:34 |
| GaryvdM | But no where am I lazy importing os or os.path | 05:35 |
| GaryvdM | Any ideas ? | 05:35 |
| igc | hi GaryvdM - no ideas from me sorry | 05:36 |
| * GaryvdM smacks forhead | 05:36 | |
| GaryvdM | did have a lazy import of os.path - sorry all | 05:37 |
| lifeless | :) | 05:39 |
| lifeless | EODing | 05:44 |
| bjacques | When I commit a bunch of changes to my local branch, and then I 'bzr push' to a remote branch, which of the commit messages will be shown primarily? | 06:07 |
| bob2 | all of them | 06:09 |
| bob2 | since push will only work if the remote branch has no new commits | 06:09 |
| bjacques | ah, I thought that | 06:11 |
| bjacques | bzr would show a "tree of commits", like what you see when you look at the output of bzr log --include-merges | 06:12 |
| poolie | are you talking about push -v or something? | 06:13 |
| bjacques | sorry, I should have been clearer | 06:14 |
| bjacques | what I was thinking of was the commit notification emails that other people receive. (I might be incorrectly using the word "commit" here.) | 06:14 |
| bjacques | but it also shows in the output of 'bzr log', without --include-merges, it shows sort of a "parent" commit summary, and if you specify --enable-merges you see the individual commits that happend before the person merged and, presumably, subsequently pushed their branch. | 06:15 |
| bjacques | s/--enable-merges/--include-merges/ | 06:16 |
| bjacques | so, basically, what I'm trying to do is this. bzr branch remote local; (make change); bzr commit -m "minor change 1"; (make change); bzr commit -m "minor change 2"; bzr push -m "Summary of changes: ..." remote | 06:18 |
| bjacques | at least, it is my understanding that is roughly how a bzr workflow should look... | 06:19 |
| RAOF | bjacques: There is no message on the push. | 06:19 |
| RAOF | If you want something like that, you can do it. | 06:20 |
| bjacques | Well, obviously I also want to show people the big picture rather than a long list of incremental changes. | 06:20 |
| bjacques | So how would I do something like that? | 06:21 |
| RAOF | So, what you want to do is make a merge commit. | 06:21 |
| RAOF | You can't do that remotely, but that's ok. | 06:21 |
| RAOF | You'd do something like bzr branch remote trunk; bzr branch trunk mychanges; ... hack in mychanges, committing as much as you like ...; cd trunk ; bzr merge ../mychanges ; bzr ci -m "Summary of what the mychanges merge does" ; bzr push remote | 06:22 |
| bjacques | ah, cool, will try that | 06:23 |
| poolie | spiv, you might like to update hydrazine to get a fix for bug 541586 | 06:23 |
| ubottu | Launchpad bug 541586 in hydrazine "feed-pqm should match subject to avoid breaking threads in gmail" [Medium,Fix released] https://launchpad.net/bugs/541586 | 06:23 |
| poolie | or to tell me it's not fixed :) | 06:23 |
| spiv | poolie: hmm, I did run 'bzr pull' just before using it | 06:30 |
| spiv | Oh, the fix is very new, ok :) | 06:34 |
| spiv | poolie: FWIW, mutt already threaded them just fine :P | 06:36 |
| bjacques | RAOF: that did the trick, thanks! | 06:36 |
| spiv | poolie: (I think because Launchpad automatically sets the In-Reply-To header for those messages?) | 06:38 |
| GaryvdM | poolie: with --profile-imports, can I turn it off at a certin check point. I want it show me all the imports before a gui window shows, not after | 06:54 |
| poolie | spiv, i know, it's really a gpg bug | 07:01 |
| GaryvdM | poolie: Figured it out. | 07:02 |
| poolie | GaryvdM: what did you do? | 07:02 |
| poolie | spiv: s/gpg/gmail | 07:02 |
| GaryvdM | I insert this at the point that I want to view: | 07:03 |
| GaryvdM | import profile_imports; import sys; profile_imports.log_stack_info(sys.stderr) | 07:03 |
| GaryvdM | (it assumes that profileing is on) | 07:03 |
| GaryvdM | poolie ^ | 07:04 |
| poolie | ok | 07:09 |
| vila | hi all | 07:24 |
| vila | GaryvdM: still there !!! Hi ! | 07:24 |
| poolie | hi vila | 07:24 |
| poolie | how are things | 07:24 |
| GaryvdM | hi vila, at work | 07:25 |
| vila | GaryvdM: pfew, so you had some sleep, good :) | 07:25 |
| vila | poolie: pretty well, I'm working on bug #375898 | 07:26 |
| ubottu | Launchpad bug 375898 in bzr "bzr merge fails: bzr: ERROR: No final name for trans_id 'new-1'" [High,Confirmed] https://launchpad.net/bugs/375898 | 07:26 |
| vila | I think I roughly understand what is happening and will try to write a small enough test for it, | 07:27 |
| vila | but ISTM that what is really wanted is nested trees and I don't expect to fix that :-( :-) :-? | 07:27 |
| vila | So I'll try to see if a simple fix can be devised and investigate possible workarounds (including fixing bzr-merge-into) | 07:28 |
| vila | And I'll try to keep up with the patch pilot stuff but I've lowered my expectations there :-/ | 07:30 |
| * vila afk | 07:47 | |
| poolie | vlia, thanks for looking at that one | 07:56 |
| poolie | and for telling me | 07:56 |
| poolie | night all | 08:05 |
| spiv | vila: review sent your way | 08:23 |
| * spiv is done for the night | 08:24 | |
| igc | night poolie, spiv | 08:36 |
| igc | hi vila | 08:36 |
| * igc dinner | 08:36 | |
| mvo | hello! is there a known problem with upgrading branches from the LP ui? I'm trying to upgrade https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu so that I can merge my changes from trunk into that branch but it does not work, upgrading via cmdline downloads ~30mb and then tells me backup.bzr is already there. deleting that via sftp (I'm sure it was gone) does not help, got the same error again. I'm on lucid, bzr 2.1 | 08:41 |
| * vila back | 08:43 | |
| parthm | mvo: maybe you can upgrade via web ui. the branch owner will see an "upgrade" link on the page https://code.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu | 08:43 |
| vila | hi spiv, igc | 08:43 |
| mvo | parthm: thanks, I tried that first, I see a "upgrade in progress" box then for some minutes and when it vanishes the branch format has not changed (both on the web-ui info and from bzr info -v bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/synaptic/ubuntu/) | 08:44 |
| mvo | I wouldn't bother much, but it prevents me from merging from my other branches because the formats are not compatible :/ | 08:45 |
| vila | spiv: hehe, the test scenarios went through multiplesss iterations, I'll check your remarks and will try to explain why I went this route, | 08:53 |
| vila | spiv: the principal intent was to be able to define the scenarios right before the tests instead of in load_tests() | 08:54 |
| vila | spiv: these tests are unusual in that their setup is far more complex than our usual tests | 08:54 |
| vila | spiv: but as always when focused on a given task, and exploring various ways, reviews are usually raising interesting points so I'll look into that carefully | 08:56 |
| vila | spiv: thanks for the review anyway | 08:57 |
| spiv | vila: I don't have much time right now, but part of my concern is that hopefully we don't need multiple ways of defining scenarios | 08:57 |
| vila | spiv: there is one reason here: each scenario needs to be mirrored so that merges are tried in both directions *and* resolutions are tried for both sides | 08:58 |
| spiv | vila: the APIs for it are already a bit esoteric | 08:58 |
| vila | yeah, it was hard to get there so there is certainly ways to improve that | 08:58 |
| spiv | I don't understand why the mirroring requires special support | 08:58 |
| spiv | As opposed to e.g. scenarios = scenarios + mirror_scenarios(scenarios) | 08:59 |
| vila | spiv: may be I missed a simplification at one point, but when I introduced mirror_scenarios, multiply_scenarios wasn't doing the right thing | 09:00 |
| spiv | My gut reaction is that it can be simpler. | 09:01 |
| vila | spiv: hehe, you should look at some previous versions :-D | 09:01 |
| spiv | But if you need a more advanced scenario-construction API, then TestCases aren't the tool for it. | 09:01 |
| vila | spiv: but I'm all for simpler tests :) | 09:01 |
| spiv | I can take a stab at simplifying tomorrow if you like. | 09:02 |
| vila | TestCases allowed me to keep some locality which make tests simpler to understand | 09:02 |
| vila | spiv: if I don't find the time to push anything until tomorrow, you're warmly welcome ! | 09:02 |
| vila | spiv: I'll try to answer your review at least | 09:03 |
| spiv | I seems to me you have a base set of scenarios, and then you wish extrapolate a bunch of other scenarios from that basis. | 09:03 |
| spiv | And that's something you ought to be able to express directly with the scenarios themselves. | 09:03 |
| spiv | Maybe the scenarios should have less keys but richer objects in them? | 09:04 |
| spiv | Not sure, I have a few rough ideas I can explore. | 09:04 |
| spiv | Maybe inspiration will strike while I sleep :) | 09:04 |
| spiv | Actually, I'm not sure I get the point about locality either. | 09:04 |
| vila | spiv: I'm not confident I've found the right hooks yet (not the right infra for that matter), I've discovered many details why translating the test (from back to white boxes) | 09:04 |
| vila | spiv: have a look at the history, things may be clearer that way | 09:05 |
| spiv | AFAICT, you're essentially just keeping the components of a scenario local with itself? | 09:05 |
| spiv | I don't see why inheriting from TestCase helps there. | 09:05 |
| vila | err, by TestCase you mean TestParametrizedResolveConflicts ? | 09:06 |
| spiv | I know you want to define custom methods like assertion methods, but that can be done pretty easily in a plain scenario dict without grouping the scenario parts in a TestCase definition. | 09:06 |
| spiv | Er, right. | 09:06 |
| spiv | That's not a TestCase? | 09:06 |
| vila | oh wait ! You need to look at lp:~vila/bzr/537956-parent-loop-incomplete ! | 09:07 |
| vila | spiv: I've changed many things in the test infra there ! | 09:07 |
| spiv | I see no prerequisite-branch on the merge proposal :P | 09:07 |
| vila | that's because I changed things *after* this branch and this branch is a pre-requisite of the following one :) | 09:08 |
| vila | spiv: https://code.edge.launchpad.net/~vila/bzr/537956-parent-loop-incomplete/+merge/21224 | 09:08 |
| spiv | Well, a comment about this would have been handy, at least :) | 09:08 |
| spiv | Feel free to tell me if I missed one, of course! :) | 09:08 |
| vila | spiv: sorry about that :( | 09:08 |
| spiv | Ok, I'll take a look at that tomorrow. Thanks for the pointer. :) | 09:09 |
| vila | spiv: I didn't realize this when we started this discussion :( | 09:09 |
| spiv | Me either ;) | 09:09 |
| parthm | mvo: i tried the upgrade locally and it worked. http://pastebin.com/8iZrsJGb | 09:10 |
| parthm | mvo: i am using bzr 2.1 on karmic | 09:10 |
| spiv | vila: so, a final thought before I go for the night | 09:10 |
| vila | spiv: And I don't remember exactly what I backported from one branch to the other, I'll re-read everything carefully | 09:10 |
| spiv | vila: I can see the attraction of using the class statement to construct a complex scenario | 09:10 |
| spiv | vila: but does that class actually need to inherit from TestCase -- or anything else? | 09:11 |
| parthm | i get a large set of "can't start new thread" error on 'bzr --no-plugins selftest --parallel=fork' http://pastebin.com/AbQ8G0Ge is this expected? | 09:12 |
| spiv | Also, I wonder if a hugely complex scenario is a smell. I think probably they are unavoidable for genuinely complex situations, but I'm not sure... | 09:12 |
| spiv | vila: anyhow, good night, and thanks for fixing bugs and improving the test coverage :) | 09:12 |
| vila | spiv: one final remark before you go to sleep too :) : I consider this a work in progress, there are still tests that needs to be translated and there are still *no* tests involving several conflicts... So I'm definitely open to enhancements but I don't want to to delay landing fixes either | 09:13 |
| parthm | mvo: i am not too sure how launchpad branches work but you branch seems upgradable to me :) | 09:13 |
| mvo | parthm: thanks, locally I can upgrade too, its the remote end I want to upgrade. what is the most efficient way? or some reason bzr+ssh errors out with "backup.bzr" already exists (even if I delete it with nautilus on the server). and the LP webui upgrade does nothing for me. I'm trying sftp:// upgrde now, but it appears to be really slow | 09:13 |
| mvo | (locally I have upgraded already :) | 09:13 |
| vila | spiv: yeah, the complex setup allows to use pdb with the right simple context in the right place, that's the goal, this smells, but I don't want to cheat too much either, building the conflicts "manually" with their associated wt.... yells "brittle" far too loud to my ears :) | 09:15 |
| vila | spiv: thanks for feedback anyway, this is hard stuff and I'm glad to be able to discuss it | 09:16 |
| parthm | mvo: fwiw, bzr 2.2dev allows multiple backup.bzr folders as backup.bzr.~N~ so that particular error will go away. you could try using lp:bzr | 09:16 |
| parthm | mvo: https://bugs.launchpad.net/bzr/+bug/300001 i am not sure how that plays with launchpad though. | 09:18 |
| ubottu | Ubuntu bug 300001 in bzr "existence of backup.bzr blocks running upgrade a second time" [High,Fix released] | 09:18 |
| mvo | parthm: thanks, I check the new bzr out now and will try that | 09:19 |
| mvo | parthm: thanks for your help (much appreciated). I solved it now the cheap way by renaming the lp branch and pushing my local upgraded one as a new branch | 09:26 |
| parthm | mvo: that sounds good to me :) | 09:27 |
| * mvo is *so* happy to be able to commit again | 09:27 | |
| panta | hi everyone | 09:47 |
| panta | I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging | 09:48 |
| bialix | hello all | 09:50 |
| panta | I've read "Contributing to Bazaar", but I'd like to know if they could be considered interesting | 09:50 |
| bialix | they? | 09:50 |
| parthm | bialix: ^ quote "I've implemented some new hooks for bzr, and I'd like to know if I should propose them for merging" | 09:54 |
| parthm | from panta | 09:55 |
| bialix | ah, ok | 09:57 |
| jelmer | panta: Please send an email to the list about them | 09:59 |
| jelmer | panta: If they're generic enough I think we'd be interested in them. | 09:59 |
| panta | jelmer: ok, thanks. Should I include a preliminary patch? | 10:02 |
| jelmer | panta: yeah, please do | 10:03 |
| panta | jelmer: ok, thanks for the info. | 10:05 |
| shane_ | Hey, im getting a strange error when committing http://pastebin.ubuntu.com/400482/ | 10:15 |
| === shane_ is now known as fagan | ||
| fagan | I got it when I did a bzr commit | 10:16 |
| fagan | I have my ssh and pgp key set up but I only did it an hour ago. (I did a fresh install so I made new keys) | 10:18 |
| bob2 | shane_: you can't commit via http | 10:19 |
| fagan | Why is it trying that then? | 10:20 |
| bob2 | presumably you have bound your branch to another branch via http | 10:20 |
| bob2 | 'bzr info' oughta show you | 10:20 |
| fagan | bob2: can I change it to https? | 10:21 |
| bob2 | you probably can't commit via https either | 10:21 |
| bob2 | is this an lp project? | 10:21 |
| fagan | Yep its planet-ubuntu | 10:22 |
| fagan | Im just updating my hackergotchi :) | 10:22 |
| bob2 | well, bind to the bzr+ssh url | 10:23 |
| fagan | bob2: I figured out what was wrong | 10:25 |
| fagan | It hadnt logged me into bzr yet :) | 10:25 |
| bob2 | that you had bound to a http url | 10:25 |
| bob2 | and you can't commit via http :) | 10:25 |
| bob2 | ah, launchpad-login | 10:25 |
| fagan | bob2: yep I have it working now | 10:27 |
| bob2 | excellent | 10:27 |
| fagan | Thanks | 10:27 |
| fagan | Got to run | 10:27 |
| u-foka | hy! i'm get this: "ERROR: exceptions.IndexError: list index out of range" when I try to bzr fast-import my.fi new-repo/trunk | 11:06 |
| u-foka | what I doing wrong? | 11:06 |
| u-foka | new-repo is created with init-repo before, and it's empty, using bzr 2.1.0 | 11:06 |
| bialix | u-foka: use just `bzr fast-import my.fi new-repo` | 11:11 |
| bialix | if it does not work you need to file a bug | 11:11 |
| u-foka | same error :S | 11:13 |
| bialix | u-foka: pastebin output of `bzr -Derror fast-import my.fi new-repo` | 11:13 |
| u-foka | 1 sec | 11:13 |
| bialix | how you have created my.fi? | 11:14 |
| u-foka | bzr fast-export old_repo my.fi | 11:14 |
| u-foka | old repo need to be altered | 11:14 |
| u-foka | but the unaltered fi makes the same error | 11:15 |
| bialix | pretty odd | 11:19 |
| bialix | are you on windows? | 11:19 |
| u-foka | http://pastebin.com/hCy75EpM | 11:21 |
| u-foka | I'm on lucid | 11:21 |
| bialix | u-foka: I don't know what the version of fastimport you have. You may want to try to use the latest version from trunk | 11:24 |
| bialix | but there is definitely error in fastimport plugin | 11:24 |
| bialix | please, file a bug, and specify the version of the plugin | 11:24 |
| u-foka | okay, thanks! | 11:24 |
| u-foka | the same fi imported on the karmic machine fine | 11:25 |
| bialix | definitely the bug | 11:26 |
| bialix | use fastimport as of version on karmic then | 11:26 |
| u-foka | fastimport 0.9.0dev | 11:28 |
| u-foka | it seems to me that this already reported as bug #287767 | 11:31 |
| ubottu | Launchpad bug 287767 in bzr-fastimport "fastimport from git fails" [Undecided,Fix released] https://launchpad.net/bugs/287767 | 11:31 |
| mgedmin | bzr rm file1; bzr ci file1 -> "paths are not versioned: file1" | 11:34 |
| mgedmin | huh? | 11:34 |
| mgedmin | sorry, my bad | 11:35 |
| mgedmin | bzr st prints filenames relative to branch root, not to my $PWD :( :( :( | 11:35 |
| spiv | mgedmin: https://bugs.edge.launchpad.net/bzr/+bug/520662 | 11:41 |
| ubottu | Ubuntu bug 520662 in bzr "Add option to output relative paths" [Medium,Confirmed] | 11:41 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| igc | night all | 14:28 |
| === BasicPRO is now known as BasicOSX | ||
| nlisgo | why is sftp so slow. I tried bzr+ssh and I was worried when it had finished so quickly. I thought perhaps it didn't send the commits to the repo. But it had!! | 15:42 |
| NfNitLoop | sftp has to do everything via file reads over the network. | 15:44 |
| NfNitLoop | bzr+ssh spawns a remote bzr instance that can do those file reads on the server. | 15:44 |
| NfNitLoop | so it's faster. | 15:44 |
| NfNitLoop | but sftp works even if you don't have bzr installed remotely. | 15:44 |
| vila | jelmer: ping | 15:46 |
| jelmer | vila: 'lo! | 15:46 |
| vila | jelmer: hi ! | 15:46 |
| vila | bzr-loom is currently broken because BranchFormat.open got a new 'name' keyword arg, rings a bell ? | 15:47 |
| jelmer | vila: ah, yep | 15:47 |
| jelmer | vila: It's documented under "API CHANGES" in NEWS ;-) | 15:47 |
| vila | jelmer: long story short, that means bzrlib API needs to be bumped :-/ | 15:47 |
| jelmer | vila: I'll submit a aptch to bzr-loom | 15:47 |
| vila | jelmer: thanks ! Not a big deal for loom (I just added the name arg in a hurry as I couldn't use my loom anymore), but bumping the API will have more consequences... | 15:48 |
| vila | (for other plugins that is) | 15:49 |
| vila | jelmer: the related patch in only in bzr.dev right ? | 15:49 |
| jelmer | vila: yep | 15:49 |
| * vila checks 2.2 release date | 15:49 | |
| jelmer | vila: this is all work done towards colocated branches | 15:49 |
| vila | jelmer: I know, I know, good work ! :D | 15:50 |
| vila | rats, 2.2b1 expected in 8 hours | 15:50 |
| vila | jelmer: could you propose a patch with the API bump so that poolie wont miss it ? | 15:51 |
| jelmer | vila: ok | 15:51 |
| === salgado is now known as salgado-lunch | ||
| jelmer | vila: Whoa, I wasn't aware 2.2 was already that close | 15:51 |
| vila | jelmer: thanks a ton ! | 15:51 |
| vila | jelmer: well, that's what https://edge.launchpad.net/bzr/2.2 says (I have a bit of mail backlog but I'm pretty sure poolie announced it) | 15:52 |
| jelmer | vila: Thanks | 15:53 |
| === IslandUsurper is now known as IslandUsurperAFK | ||
| === beuno is now known as beuno-lunch | ||
| === IslandUsurperAFK is now known as IslandUsurper | ||
| dash | hmm. no jelmer... guess i won't talk about my bzr-svn bug yet. :) | 16:56 |
| === salgado-lunch is now known as salgado | ||
| MvG | Hi! What's the easiest way to find the first mainline revision integrating a given revision using the command line? In other words, how do I find out when a given revision actually got merged? | 17:02 |
| vila | MvG: bzr log <revno>.. -l<max_merge_depth> | 17:02 |
| dash | -l? or -n | 17:02 |
| vila | -l == --limit | 17:03 |
| dash | oh i see what you mean now | 17:03 |
| MvG | Missing -r. | 17:04 |
| vila | The idea is to start log at the revision you're interested in until the tip limiting the output to at least the merge depth of the revision | 17:04 |
| vila | MvG: argh, yeah, sorry | 17:04 |
| MvG | Otherwise it gives me "bzr: ERROR: Start revision not found in left-hand history of end revision." | 17:04 |
| vila | MvG: double-argh, yes add -n0 | 17:05 |
| MvG | No luck either: "bzr log -r 4056.2.1.. -l3 -n0" for the bzr.dev branch prints the same as "bzr log -l3 -n0". No indication of the merge point for 4056.2.1 | 17:24 |
| === beuno-lunch is now known as beuno | ||
| MvG | vila: by max_merge_depth, what number did you have in mind there? | 17:25 |
| vila | MvG: meh, that's a bug | 17:26 |
| MvG | vila: i still don't see how your approach is supposed to work either. | 17:27 |
| MvG | I understand the -r part, and I see I'd like the last mainline rev printed by that output. I don't see the role of the -l there. | 17:28 |
| MvG | vila: Oh, a --forward does help. | 17:28 |
| vila | MvG: it's to avoid displaying all the revisions you don't care about, ha rats, yeah, damn, 2 args good out of.. 5 ? :-/ | 17:29 |
| MvG | "bzr log -r 4056.2.1.. --forward -l1 -n0" looks pretty good. I guess I'll define an alias. | 17:29 |
| vila | yeah, the result is correct, no bug here, sorry | 17:29 |
| === deryck is now known as deryck[lunch] | ||
| rellis | Is there a way to merge two distinct revisions from one branch into another branch? | 18:05 |
| rellis | Trying to do it in one command, and it is not a range of commits. | 18:06 |
| beuno | rellis, no, not in one command if they are not sequential | 18:06 |
| rellis | gotcha, thanks | 18:07 |
| === radoe_ is now known as radoe | ||
| === deryck[lunch] is now known as deryck | ||
| mwhudson | Peng: have you looked at https://code.launchpad.net/~tseaver/loggerhead/sphinxify/+merge/21948 at all? | 19:43 |
| jelmer | mwhudson: thanks for the review of my pygpgme branch | 20:39 |
| jelmer | mwhudson: do you know if there's any eta on mirrored branches/vcs imports for packaging branches? | 20:39 |
| mwhudson | jelmer: i think it's mostly a matter of having a ui to be able to create them now | 20:40 |
| jelmer | mwhudson: does that mean there's already a API to create them ? >-) | 20:40 |
| mwhudson | jelmer: ah, no, probably not | 20:41 |
| mwhudson | the internal apis probably need to be cleaned up a bit | 20:41 |
| mwhudson | but mostly around creation i think | 20:42 |
| mwhudson | if you could magic one into existence it would mostly work i think | 20:42 |
| codebloc | the windows installer version of bzr 2.1.0 runs out of memory doing "bzr svn-import" on my repository due to the presence of a single change to a 250MB file | 20:54 |
| codebloc | this on a 64-bit windows machine with 12GB of RAM | 20:54 |
| codebloc | I have created a test SVN repository that can reproduce this problem | 20:54 |
| codebloc | I'd like guidance as to whether this should be a separate bug, or just another manifestation of https://bugs.launchpad.net/bzr/+bug/109114 | 20:54 |
| ubottu | Ubuntu bug 109114 in bzr "[master] bzr holds whole files in memory; raises MemoryError on large files" [Wishlist,Confirmed] | 20:54 |
| codebloc | if it is another instance of 109114, is there any hope of this bug getting a higher importance? I can't use bzr as long as it has this limitation | 20:55 |
| jelmer | mwhudson: hmm, I might then :-) | 21:03 |
| jelmer | codebloc: it's just another manifestation of that bug | 21:05 |
| jelmer | codebloc: I'd recommend asking for a higher priority on that bug report | 21:05 |
| === salgado is now known as salgado-afk | ||
| andreasheintze | Hi! Is there anybody here? | 21:49 |
| jelmer | hi andreasheintze | 21:49 |
| andreasheintze | Hi there! I'm having a question about bazaar and I thought maybe someone here can help me? | 21:50 |
| dash | andreasheintze: usually :) | 21:50 |
| andreasheintze | I'm new to bazaar so... anyway. I have set up a repository of our intranet at work, wich I'm developing in PHP and javascript. | 21:51 |
| andreasheintze | I have access to the whole site, but I got another developer that is responsible for everything under one folder in this site. | 21:52 |
| andreasheintze | How can I limit him to just be able to update the files and folders inside that folder? | 21:53 |
| andreasheintze | I don't want him to able to commit and merge changes of files outside of that folder. Can I do this? | 21:54 |
| andreasheintze | If anyone has a link or can guide me in the right direction, it would be great! | 21:57 |
| thumper | andreasheintze: normally this would be done by having separate branches | 22:04 |
| thumper | I'm pretty sure that bzr doesn't have a restriction like this for a single branch | 22:05 |
| Peng | mwhudson: Um, probably not. I've been AFK. :D | 22:06 |
| andreasheintze | Ok, I thought so, but how? If I make a new branch of my main branch it will create the whole site, not just that folder. | 22:06 |
| Peng | mwhudson: I'll get to it later -- no guarantees I'll do any more than think "hmm, that looks complicated -- I'll let mwhudson handle it". :P | 22:07 |
| bmm | I've posted a bug for bazaar hookless-mail, but I'm not sure anybody will read it as I'm the only one who is subscribed: https://bugs.launchpad.net/bzr-hookless-email/+bug/546431 Is this bug going to just die? | 22:07 |
| ubottu | Ubuntu bug 546431 in bzr-hookless-email "[whishlist] Support for multiple e-mail adresses" [Undecided,New] | 22:07 |
| jelmer | mwhudson: another thing, newer versions of bzr-svn should be able to handle the KDE repository - it'd be nice if we can get a newer version on Launchpad before the rollout | 22:10 |
| mwhudson | jelmer: i think that got integrated when i did the incremental import thing | 22:12 |
| mwhudson | Peng: well fair enough | 22:12 |
| jelmer | ah, nice | 22:12 |
| thumper | bmm: appropriate prodding here should get some bzr developers to at least look :) | 22:12 |
| lifeless | thumper: perhaps | 22:13 |
| thumper | andreasheintze: you could split out the subfolder - look at the split command | 22:13 |
| lifeless | hookless-email - best to send something to the list I think | 22:13 |
| lifeless | bmm: ^ | 22:13 |
| andreasheintze | split, ok I'll take a look at it. Thanks! | 22:13 |
| bmm | I have small projects with friends and I have like two to three people per project I want to mail.. so I would like to be able to add just a single address in most cases :) | 22:14 |
| bmm | lifeless: ^ | 22:14 |
| lifeless | bmm: sure, but I don't think anyone here as seen the code for the hookless-email at all | 22:16 |
| lifeless | I think the developer is on the bzr mailing list though | 22:17 |
| lifeless | anyone else see'Exception RuntimeError: 'maximum recursion depth exceeded in __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored | 22:17 |
| lifeless | ' | 22:17 |
| lifeless | running the test suite ? | 22:17 |
| bmm | lifeless: Thanks for the tip! | 22:19 |
| jelmer | lifeless: no - is this with or without plugins? | 22:19 |
| lifeless | jelmer: without | 22:20 |
| jelmer | moin poolie | 22:25 |
| poolie | hi jelmer | 22:40 |
| mtaylor | lifeless: hey - wanna see something purty? http://hudson.drizzle.org/job/drizzle-build-spare-macos/84/console | 22:43 |
| lifeless | purty | 22:44 |
| lifeless | bug filing time | 22:44 |
| mtaylor | lifeless: (I'm going to upgrade bzr there right now - I just thought I'd paste it in...) | 22:44 |
| lifeless | its a dupe | 22:44 |
| mtaylor | lifeless: that's running bzr 1.18 | 22:44 |
| lifeless | oh | 22:44 |
| lifeless | hm | 22:44 |
| mtaylor | :) | 22:44 |
| codebloc | assuming i somehow work around the memory issues with importing my svn repository, i have an issue with access control that i'd need to solve with bzr | 22:45 |
| lifeless | thats an issue mtaylor - we didn't intend to break compat like that | 22:45 |
| mtaylor | lifeless: oh good! | 22:46 |
| * mtaylor is helpful | 22:46 | |
| codebloc | let's say my company has a product with two bits of code. one is '/boring', and another is '/cool'. we can't build the product without both /boring and /cool, and /boring depends upon the output of the build of /cool | 22:46 |
| codebloc | we have overseas developers working on /boring | 22:46 |
| codebloc | but our onshore dev team works on /cool | 22:46 |
| codebloc | with svn it's pretty easy to limit access for some devs to just /boring, and let the rest access everything | 22:47 |
| codebloc | what is the idiomatic way(s) in bzr to solve this problem? | 22:47 |
| mtaylor | codebloc: ssh | 22:47 |
| bob2 | separate repositories, ssh, unix groups | 22:47 |
| mtaylor | what bob2 said | 22:47 |
| codebloc | but if the repositories are separate, that complicates building and branching, doesn't it? | 22:47 |
| codebloc | let's say I want to do a build | 22:48 |
| bob2 | no | 22:48 |
| bob2 | it is unrelated to building | 22:48 |
| codebloc | i need /boring and /cool | 22:48 |
| codebloc | and I want to create a label for that build | 22:48 |
| codebloc | or see a unified history for prepping release notes | 22:48 |
| codebloc | maybe this is my svn mindset, thinking in terms of a monolithic repository | 22:48 |
| bob2 | yes | 22:49 |
| mtaylor | lifeless: do you need any of the .bzr.log from me / want me to file/update anything? | 22:49 |
| codebloc | if so, do you know of any (preferably large scale) projects that use multiple repositories i could look at to try to understand | 22:49 |
| bob2 | you're conflating "repositories" and "projects" | 22:49 |
| codebloc | yes, i suspect I am | 22:49 |
| codebloc | i'm trying to imagine how my team would work if we had one svn repos for our driver code, another for our daemons, another for our UI, etc | 22:50 |
| codebloc | it would be a mess | 22:50 |
| codebloc | i guess that's not so with dvcs's like bzr? | 22:50 |
| bob2 | well, I can only think of two cases where it matters: you need to do more than one check out, and your build process needs to remember more than one rev no | 22:51 |
| codebloc | well, in our particular case our build numbers correspond to the svn revision number of the working copy used to do that build, so obviously that assumes a unified repository | 22:53 |
| codebloc | but we also have some code in, say, 'libraries', that code in, say, 'gui' depends on. With one big checkout, we can assume the 'libraries' project has a certain path relative to 'gui' so the project file can specify that relative path explicitly | 22:54 |
| codebloc | with multiple repositories the developer would have to make sure to arrange his working copies so as to preserve this relationship | 22:54 |
| codebloc | and if he did the equivalent of an 'svn switch', he'd need to do so for every working copy | 22:55 |
| codebloc | not the end of the world, but also not what any of them are used to. | 22:55 |
| codebloc | is that just something teams using bzr or git or hg are used to doing? | 22:55 |
| mtaylor | codebloc: you may want to check out bzr-builder | 22:56 |
| mtaylor | codebloc: it allows you to create "recipes" for how you pull stuff from different bzr branches | 22:56 |
| codebloc | interesting | 22:57 |
| mtaylor | codebloc: a lot of the dvcs world is modeled around how open source stuff works anyway - as in, I might depend on libgcrypt, but those guys aren't part of my project - so I either grab a tarball release from them, install a deb or I pull from their bzr repo | 22:57 |
| codebloc | hmm | 22:58 |
| codebloc | let's take canonical for example | 22:58 |
| codebloc | each ubuntu release is obviously a huge build process | 22:58 |
| codebloc | even though most of it is probably packages from other projects, there's still got to be a fair bit of ubuntu artifacts | 22:58 |
| codebloc | how to they use bzr to manage that? | 22:58 |
| mtaylor | so - all of that is much easier when you don't add the "make this bit private" element :) | 22:59 |
| codebloc | hehe, yeah, presumably | 22:59 |
| mtaylor | and ubuntu doesn't solve all of that problem with bzr | 23:00 |
| codebloc | but at the same time that's pretty common in commercial software shops like mine | 23:00 |
| mtaylor | large portions of it are solved inside of the debian repository and the debian packaging | 23:00 |
| codebloc | hmm | 23:00 |
| mtaylor | but that's what I'm saying - if you draw organizationally from how that's done, right? | 23:00 |
| codebloc | yeah, I get what you're saying | 23:00 |
| mtaylor | have the display-driver folks actually cut and release a lib that you can install and other groups can consume | 23:00 |
| codebloc | that's how large-ish software companies tend to work | 23:01 |
| codebloc | perhaps it's time we start working that way too | 23:01 |
| codebloc | maybe then we wouldn't have this massive svn repos that bzr can't seem to ingest ;) | 23:02 |
| mtaylor | it's a bit of an uphill the first time ... but it has nice payoffs | 23:02 |
| mtaylor | codebloc: :) | 23:02 |
| mtaylor | codebloc: also - check your versions of svn and python-svn | 23:02 |
| mtaylor | codebloc: I know there was a memory leak bug in python-svn at one point | 23:02 |
| mtaylor | which I believe has since been fixed | 23:02 |
| mtaylor | codebloc: heck - if you wanna get really crazy- have each component actually release and install debs :) | 23:03 |
| codebloc | mtaylor: whoa! let's not get carried away ;) | 23:03 |
| jelmer | mtaylor: to add to the confusion, we never actually used python-svn, only python-subversion (yes, they're two different things) | 23:05 |
| codebloc | mtaylor: libsvn is 1.6.5. python-svn is not installed, which is making me wonder how it works | 23:06 |
| jelmer | and we're now using python-subvertpy, which should not have any memory leaks | 23:06 |
| codebloc | jelmer: aha, that explains it. | 23:06 |
| mtaylor | codebloc: sweet! listen to jelmer - he knows all | 23:06 |
| codebloc | i'm running python-subvertpy 0.6.9-1 on my 64-bit ubuntu box | 23:06 |
| * jelmer fails to make a bad pun about subversion or somesuch | 23:07 | |
| codebloc | neither python-svn nor python-subversion are even installed | 23:07 |
| codebloc | so sounds like I don't have the memory leak bug | 23:07 |
| jelmer | codebloc: you shouldn't need either, just subvertpy | 23:07 |
| codebloc | just the 'feature' whereby memory is consumed until it is exhausted ;) | 23:07 |
| jelmer | codebloc: you just posted that link to the example repo on the bug right? | 23:07 |
| codebloc | yes, that was me | 23:08 |
| poolie | hi | 23:10 |
| poolie | thanks for giving an example there | 23:11 |
| codebloc | poolie: no problem. believe me when I say, I WANT bzr to work for us. if I have to do another svn merge I'll very likely pop a blood vessel | 23:12 |
| jelmer | codebloc: I'll have a look at it once I figure out how to unpack a 7zip file :-) | 23:13 |
| lifeless | jelmer: install the package ;P | 23:14 |
| codebloc | jelmer: 7zip is the future! :) | 23:14 |
| codebloc | jelmer: the deb package is p7zip, iirc | 23:14 |
| * jelmer growls | 23:16 | |
| jelmer | in my time we used arj on floppies and it worked just fine | 23:16 |
| hazmat | jelmer, i thought all the leaks in py svn bindings were fixed as of 1.6 | 23:17 |
| mtaylor | 7zip? | 23:18 |
| === _thumper_ is now known as thumper | ||
| mtaylor | "Open source Windows utility for manipulating archives" | 23:19 |
| codebloc | jelmer: when I was coming up you paid for a pkzip license like a good little prole. Thankfully time marches on | 23:19 |
| mtaylor | ewwww | 23:19 |
| * mtaylor == apt-get install tar gzip | 23:19 | |
| codebloc | i used it because it usually gets better compression ratios than zip, rar, or gzip | 23:19 |
| codebloc | in this particular case my test data are random byte sequences so there was obviously not much compressing going on | 23:19 |
| codebloc | i may as well have just tar'd it for all the space savings I got | 23:20 |
| jelmer | hazmat: possibly - we switched to subvertpy before 1.6 | 23:20 |
| lifeless | so | 23:20 |
| lifeless | tar + xz ~= 7zip | 23:21 |
| jelmer | rzip ftw! | 23:21 |
| jelmer | codebloc: so, it looks like the memory usage isn't particularly related to the fact that you're importing from svn | 23:22 |
| jelmer | Bazaar deals with full files in a couple of places at the moment, so I guess it's a nontrivial amount of work to fix that bug. | 23:22 |
| codebloc | jelmer: that was my suspicion, especially since I can repro it with a repos that only has a few revisions | 23:22 |
| codebloc | jelmer: i get that, but what I couldn't understand was why a 250MB file can exhaust available memory | 23:22 |
| codebloc | even if it stores 4 whole copies in mem, that's only 1GB | 23:23 |
| codebloc | a 32-bit process under 64-bit windows has 4GB of addressable memory to work with | 23:23 |
| jelmer | codebloc: Importing that test repo uses max 1.8 Gb here | 23:23 |
| jelmer | and I'm on 64bit | 23:23 |
| codebloc | jelmer: yeah, why do you suppose that is? Doesn't that seem high given the relatively small quantity of data involved? | 23:23 |
| jelmer | codebloc: probably needless memory duplication | 23:25 |
| jelmer | when generating delta's serializing to disk, etc | 23:25 |
| codebloc | jelmer: i see. meaning it's probably not an easy or forthcoming fix... | 23:25 |
| spiv | We currently expect to hold up to 3 copies of file in memory. | 23:25 |
| spiv | (which is still rather bad for large files, obviously) | 23:25 |
| codebloc | jelmer: is that to say all the teams using bzr simply never deal with binary files even as small as 250MB? | 23:26 |
| spiv | I'm not sure why you're seeing even worse than that, but it's probably a bug :) | 23:26 |
| jelmer | codebloc: probably, I don't think I've personally ever dealt with a file larger than 10Mb in a VCS | 23:27 |
| codebloc | jelmer: so if I'm to use bzr I'll need to exclude from revision control any binary files over, let's say, 100MB in size, and version them some other way | 23:29 |
| codebloc | back on the subject of how large teams use dvcs, here's another scenario i'm puzzling over | 23:45 |
| codebloc | let's say I want to use the best practice of feature branches to isolate my work on a new feature while maintaining sync with trunk | 23:46 |
| codebloc | what do teams do when the feature they're working on spans multiple repositories? | 23:46 |
| codebloc | eg, you're adding a feature that involves a change to a web service, and also a change to a couple of GUI projects to expose this new feature to users | 23:47 |
| codebloc | does bzr have any features that allow you to somehow maintain one feature branch with changes to both repositories, and merge that back in to the respective repositories when the time comes? | 23:47 |
| codebloc | or do you just create two separate feature branches in two separate repositories and try to remember to merge them both back at the same time? | 23:48 |
| spiv | codebloc: yes (separate branches) | 23:48 |
| codebloc | spiv: in practice doesn't that get a bit confusing? particularly if it's not two repositories but three or four or five? | 23:49 |
| spiv | codebloc: I think some of the tools like bzr-builder that help assemble a group of related branches also have some facility to update that collection in synchrony (by assembling a new recipe at least) | 23:50 |
| codebloc | spiv: ah, interesting. | 23:50 |
| jelmer | codebloc: if you have a couple of branches like that that are very closely related,are you sure you don't just want one branch? | 23:50 |
| codebloc | jelmer: actually I do, but remember I need some code to be accessible only to onshore teams, while other code is also accessible to offshore developers, so based on my earlier irc conversation i got the message that the way to do that was separate repositories with ssh and unix groups to control access | 23:51 |
| spiv | codebloc: yes, it gets confusing sometimes, but usually not very. i.e. just "that's a funny failure -- oh, I need to update branch Y as well, duh" | 23:51 |
| spiv | codebloc: how confusing it will be for you will depend on how often you need to do it, and how tightly/loosely coupled your different components are, etc. | 23:52 |
| codebloc | spiv: i see | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!