| === cinerama_ is now known as cinerama | ||
| === pjdc_ is now known as pjdc | ||
| thomi | Hi, I'm trying to get bzr to sign my commits, and it seems to work *sometimes*. Other times it prints: | 00:27 |
|---|---|---|
| thomi | You need a passphrase to unlock the secret key for <key details> | 00:27 |
| thomi | but doesn't launch gpg-agent or ask me for the passphrase | 00:27 |
| thomi | and then completes the commit without signing it. | 00:28 |
| thomi | any ideas? I've had it work once, right after logging in... | 00:28 |
| lifeless | how do you know it does not sign it? | 00:32 |
| thomi | lifeless: uhhhhh... that's a good point. That message seems like a warning | 00:43 |
| thomi | how do I tell? | 00:43 |
| thomi | I thought it would show something in the log. | 00:43 |
| lifeless | if bzr gets a error back from gpg it will cancel the commit | 00:46 |
| lifeless | I'm not sure of the current state for showing what is or isn't signed | 00:47 |
| caravel | hmm, annotate is fine with utf-16le, but qannotate entirely fails :/ (and kate or others, have no issues). Even if forcing the encoding, qannotate seems to try using utf32 or something, that results in two lines for a 300k file .) | 01:02 |
| caravel | Interestingly, forcing utf16-be looks "almost great" (except it's kinda in the wrong order) :D | 01:03 |
| caravel | in qlog, view or show differnce say the file is binary :/ | 01:08 |
| mgrandi | is the file binary? | 01:08 |
| caravel | mgrandi: no :D it's utf16-le (little endians) | 01:10 |
| mgrandi | does bzr (command line) say the diff is binary? | 01:11 |
| mgrandi | or the file is | 01:11 |
| caravel | (and kate or others, have no issues) | 01:11 |
| caravel | mgrandi: no, bzr annotate is fine | 01:11 |
| mgrandi | interesting | 01:11 |
| mgrandi | i thought explorer would use the bzr api so it should be the same | 01:11 |
| mgrandi | report a bug! | 01:11 |
| caravel | yep, hence my surprise :) I was hoping someone would know that bug, it's very late and I'm falling :) | 01:12 |
| * caravel is on gmt+2 at the moment | 01:13 | |
| mgrandi | i feel like | 01:14 |
| mgrandi | its just trying to decode the file using utf-8 + other encodings | 01:14 |
| mgrandi | and when it fails its saying "oops its binary" | 01:14 |
| caravel | mgrandi: yep | 01:16 |
| mgrandi | wait | 01:17 |
| mgrandi | in qlog | 01:17 |
| mgrandi | there is an 'encoding' dropdown | 01:17 |
| mgrandi | did you try seeing if there is utf16le? | 01:17 |
| mgrandi | err qdiff | 01:17 |
| caravel | mgrandi: yes, there is :) first guess was utf-8 actually | 01:18 |
| mgrandi | does that make it show the diff properly? | 01:18 |
| caravel | mgrandi: I knew the format so I tried drop-down, fan cooler did spin :) | 01:19 |
| caravel | mgrandi: nope, diff says its binary | 01:19 |
| caravel | well, qdiff | 01:19 |
| caravel | let me try diff :) | 01:19 |
| caravel | standard `file`cli gets it right too : Little-endian UTF-16 Unicode C++ program text, with CRLF line terminators | 01:19 |
| mgrandi | well i meant | 01:20 |
| mgrandi | did qdiff show it properly when you selected utf16le? | 01:20 |
| mgrandi | or did it still say it was binary | 01:20 |
| caravel | bzr log seems ok | 01:20 |
| caravel | mgrandi: sorry I'm tired, wasn't clear in my communication | 01:21 |
| caravel | log and annotate are fine | 01:21 |
| caravel | qlog and qannotate are not, it's only the qt toolset | 01:22 |
| caravel | so, qannotate first did autoselect utf-8 (but I'm not sure if it guesses anything, it days it's default) | 01:23 |
| mgrandi | its probably not QT itself, just the qannotate and qlog programs | 01:24 |
| caravel | forcing encoding in qannotate drop-down, or via cli parameter, fives the same result | 01:24 |
| caravel | mgrandi: oh yes, I'd doubt the whole qt libs wold have such a bug :) I run under KDE and use quite a few apps based on qt :) | 01:24 |
| caravel | so, and other bzr q* tools don't seem to permit changing the format, they just say it's binary | 01:26 |
| mgrandi | wierd | 01:26 |
| caravel | mgrandi: according to Kate, file has no BOM (Byte Order Mark), not sure what q* tools rely on ? I've known the early days of Unicode, that was a big thing at the time :) | 01:27 |
| mgrandi | utf-16 require a byte order mark. | 01:28 |
| mgrandi | requires* | 01:28 |
| caravel | mgrandi: hmm are you sure ? last time I felt asleep on unicode.org was a long time ago :) Kate says there is none, but is happy with it | 01:30 |
| caravel | mgrandi: well, optional or not, actually it *is* there ! Just open the file in okteta, I can recognize the thing as if I had invented it myself | 01:33 |
| mgrandi | it should have one because it can be either big or little endian and without it , it has no way to tell | 01:33 |
| caravel | (so, for some reason Kate says there is none, but there is one, it's only a checkbx anyway in Kate/Tools menu) | 01:33 |
| caravel | mgrandi: yes right | 01:34 |
| mgrandi | weird | 01:34 |
| * caravel is a strong advocate of putting a BOM everywhere even if not needed, but hey, RECs are full of must, should and might ^^ | 01:35 | |
| caravel | anyway, FFFE it is so it's 100% correct :) | 01:36 |
| mgrandi | *nods* | 01:36 |
| caravel | mgrandi: fyi : « Clause D98 of conformance (section 3.10) of the Unicode standard states, "The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian." » https://en.wikipedia.org/wiki/Byte_Order_Mark#UTF-16 | 01:40 |
| caravel | mgrandi: but anyway, that's off-topic now, sory :) | 01:40 |
| caravel | sorry* | 01:40 |
| mgrandi | so, file a bug against bazaar explorer =P | 01:40 |
| caravel | mgrandi: yes :) will do tomorrow. | 01:41 |
| caravel | mgrandi: unfortunately, I can't easily test later versions (running 2.x as latest on Fedora repos) | 01:41 |
| * caravel meant 2.4.x, as opposed to 2.5 if there were any q* updates since | 01:44 | |
| mgrandi | ah | 01:45 |
| caravel | ok that's qbzr 0.21.1 (sorry, I'm "landing" really, never looked at these details before, only used all this) | 01:46 |
| mgrandi | go to bed =) | 01:48 |
| caravel | .bug 668850 | 01:51 |
| ubot5 | Launchpad bug 668850 in QBzr "`bzr qdi --encoding xxx` is broken" [Medium,Confirmed] https://launchpad.net/bugs/668850 | 01:51 |
| caravel | well no, it doesn't look related :/ | 01:53 |
| caravel | ..bug 416645 | 01:55 |
| ubot5 | Launchpad bug 416645 in QBzr "better support for UTF-16 in qdiff, qannotate, qcat" [Medium,Confirmed] https://launchpad.net/bugs/416645 | 01:55 |
| caravel | yeah ! | 01:55 |
| caravel | that0s the limits of the "guessing by contents" strategy I guess (didn't know, and wouldn't have guessed that it was dong so !):D | 01:57 |
| caravel | good night mgrandi and all, thanks for answering anyway | 01:58 |
| mgrandi | night =) | 01:59 |
| * caravel Long Life to the BOM !!!! | 02:01 | |
| === r0bby_ is now known as robbyoconnor | ||
| awpti | Hi folks. I've just started using Bazaar <like, half an hour ago>. Been searching since then on how to setup bazaar explorer to work with LaunchPad, but I can't find any tutorials or info on how to tell it what to connect to (let alone a config option that implies such). Only one I've found that's remotely similar abruptly switching to some ubuntu client half way through the tutorial. What am I | 05:18 |
| awpti | missing? | 05:18 |
| bob2 | likely you just want to clone an lp url | 05:23 |
| bob2 | and that's about it | 05:23 |
| awpti | I'm trying to push code to a new repo | 05:29 |
| awpti | There is no documentation on how to do any of this.. at least, that's useful. I figured out through trial and error that it's lp:~user/proj/trunk, but now it wants me to do some launchpad-login stuff, can't find anything on it for windows. | 05:30 |
| fullermd | I dunno if there's a lp-login interface in explorer. But you can always just run it from the CLI I imagine. | 06:03 |
| vila | hi all | 06:47 |
| vila | awpti: dunno about explorer (I don't use myself), but from the command line it's 'bzr launchpad-login <launchpad-username>' | 06:48 |
| vila | awpti: more on that: https://help.launchpad.net/Code/UploadingABranch and https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 06:51 |
| mgz | morning | 08:19 |
| fullermd | Oh. Must be bedtime. | 08:19 |
| mgrandi | haha | 08:19 |
| mgrandi | exactly. | 08:19 |
| mgz | :D | 08:20 |
| mgrandi | mgz: the #bzr alarm clock | 08:22 |
| vila | morning mgz | 08:30 |
| Larsibarsi | Hi, I need a hint for a correct workflow setting: me and Peter work together from two different offices. We work on a CMS driven website, both on the files and the mysql db that is hosted on the host server - this is why a local version of the project is not working. I can access the host server via FTP, and I want to put these files under version control. How can I do this with bazaar? | 09:57 |
| Larsibarsi | I have red the tutorial, but I could not fit this setting to any setting that was described in the doc. | 09:58 |
| LeoNerd | Aaaand once again bzr up breaks my branch. Is there a way to ask for bzr up to keep the old behaviour, wherein it would just abort on divergent history? Now, it rearranges for a pending merge. I dislike this immensely | 09:59 |
| LeoNerd | I want to rebase it in that case | 09:59 |
| mgz | use pull? | 10:00 |
| mgz | Larsibarsi: nothing in your story sounds like a problem, you and peter probably just want a branch you collaborate on that's seperate from the actual deployment over ftp | 10:03 |
| mgz | if you're interacting only on the live code, that's asking for breakage if you need to resolve conflicts | 10:04 |
| Larsibarsi | mgz: I'm not sure if I understand you right: you propose that we collaborate on a branch that is not the live code branch? Then we wouldn't see the results of our coding, unless it is committed and pushed to the live code branch, did I get that right? | 10:09 |
| mgz | right, I'd suggest you have deployment as a seperate step | 10:10 |
| mgz | so, you've got one branch you can both merge to, and then on agreement (or just whenever the merge is clean), you then use bzr-upload or similar to make it live | 10:11 |
| Larsibarsi | for a real live system this would be very 'healthy'. In our case we are working on the same development system so we don't need this extra step yet (later for sure). | 10:13 |
| Larsibarsi | Having a branch to collaborate sounds like "we both have our own development system with database and files" to make our little changes in the HTML and CSS, and if we have a change, we do it locally, commit it and then it is exchanged, right? | 10:15 |
| mgz | not nessersarily | 10:15 |
| mgz | I mean, you're doing text editing locally right? | 10:15 |
| Larsibarsi | But we have only one central development system where the files can be changed... | 10:15 |
| mgz | so having a copy of all the code is something you've got, just not any test setup? | 10:16 |
| Larsibarsi | We copy the file locally, change it locally, and upload it after saving. | 10:16 |
| mgz | well, you can do that, with the risk that you can break it each other (which I guess happens anyway) | 10:16 |
| Larsibarsi | :) We are good in avoiding these break dangers. | 10:17 |
| mgz | the only complication is you can't just push over ftp | 10:17 |
| mgz | you need to push, and update the working tree, or do those two things as seperate operations | 10:18 |
| Larsibarsi | How would I make a change in a file, e.g. adjusting a CSS-margin from 15pt to 18pt? I change it locally, commit it locally, push it to the server (somehow) and now I can see the result? This is how I understand it right now... | 10:21 |
| mgz | right, so that's correct, but the push needs to be in two bits | 10:21 |
| mgz | one to update the branch so when peter pulls he sees your change | 10:21 |
| mgz | and one to update the css file itself | 10:22 |
| mgz | you can combine with some automation | 10:22 |
| mgz | also, the case where you and peter have both made changes, the second guy to push will get an error (good thing, you don't lose work) and will need to merge in the other changes before pushing | 10:24 |
| mgz | with two people that's not overly painful, there are better ways of structuring work when there are more simultanious edits | 10:24 |
| Larsibarsi | yup... But actually this is to much steps for a little change (and try and error)... Is it possible to work on the server, change the css file on the server, and when the change is done I commit the file on the server to the branch on the server somehow via ftp? | 10:25 |
| mgz | heh. | 10:25 |
| mgz | yes, but only having ftp makes that hard. | 10:25 |
| mgz | also having two people maybe doing that at once is also complicated. | 10:26 |
| mgz | so, reversing it, | 10:26 |
| Larsibarsi | Well, I guess Peter won't do that so often since I am the IT guy and he is the designer... :) | 10:26 |
| mgz | (the normal way would be) your branch -> production branch -> deployment | 10:27 |
| Larsibarsi | preparing some lock mechanism will be not too hard, I guess... | 10:27 |
| mgz | you could do instead: deploy -> your branch -> production branch | 10:27 |
| mgz | so, you cowboy things via ftp on the server, copy down any changes you make to your local branch, commit, and push to a shared location | 10:28 |
| Larsibarsi | the shared location to push to would be the production system when it works, right? | 10:29 |
| mgz | nope. it's what you'd export to deploy to production. | 10:31 |
| mgz | you need a shared location so peter can pull your changes into his local branch, rather than getting out of sync as the scratch deployment is altered with your changes. | 10:32 |
| Larsibarsi | Ah, okay... And I commit my changes and Peter commits his changes, and the local branches are in sync over the shared location push... And if Peter doesn't like this approach I can still do it on my own... | 10:36 |
| Larsibarsi | I thank you very much for your time and your thoughts, mgz, it was enlightning! :) | 10:37 |
| mgz | right, so you (as you'll find it easier) just need to merge from the shared location when peter commits something | 10:37 |
| vivekimsit | I have an error doing the bzr commit --local | 12:42 |
| vivekimsit | bzr: ERROR: Selected-file commit of merges is not supported yet: files sale_order.py | 12:43 |
| vivekimsit | how can I recover from it? | 12:43 |
| vila | vivekimsit: the error message seem to imply you did 'bzr commit --local file' that's not supported if there are pending merges | 13:13 |
| vivekimsit | vila: Ya! how to undo my merge proposal? | 13:13 |
| vila | vivekimsit: 'recover' can have several meanings there, what is your working tree status ('bzr st'), how did you get there | 13:14 |
| vila | and where do you want to go | 13:14 |
| vila | you mean 'merge attempt' ? | 13:14 |
| vivekimsit | vila : actually I did the bzr commit which led me to this, and I have checkout a branch I have done changes on it. And now its showing my latest rev as a merge! | 13:16 |
| vila | pending merge, right, that is indeed probably what you want, | 13:17 |
| vivekimsit | doing bzr status shows: unknown: | 13:17 |
| vivekimsit | bzr_log.Py3GXe | 13:17 |
| vivekimsit | bzr_log.Py3GXe.save | 13:17 |
| vila | !paste | 13:17 |
| ubot5 | For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic. | 13:17 |
| vila | can you paste 'bzr info -v' ? | 13:18 |
| vivekimsit | vila: I don't want any merge, I just want to do push, I have did it several times but only this time I commit this mistake | 13:18 |
| vila | if you want to push, you'd better not use a checkout but a regular branch no ? | 13:18 |
| vila | if you can't push, it means someone else did, so you can't just push your changes, you need to merge the other changes first | 13:19 |
| vivekimsit | vila: ok! so now I just have to run the command bzr push location | 13:20 |
| vila | no, you need tp get your working tree/branch clean first | 13:20 |
| vila | to get | 13:21 |
| vila | can you paste 'bzr info -v' ? | 13:21 |
| vivekimsit | vila: http://bpaste.net/show/7H7ARDebXu3XkgtjDmwH/ | 13:24 |
| vila | right, so since you created your working tree from lp:~synerpgy/synerpgy-projects/destock_dev/, someone else pushed something there | 13:25 |
| vila | now, you're trying to commit | 13:25 |
| vivekimsit | yes! | 13:25 |
| vila | bzr checks that your checkout is up-to-date, it's not | 13:25 |
| vivekimsit | vila: help me what to do? | 13:26 |
| vila | so it made your local commit a pending merge and pulled the other change | 13:26 |
| vila | just 'commit' no --local | 13:26 |
| vila | meh | 13:26 |
| vila | you can't commit because you made a checkout with http://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/ instead ofbzr+ssh://bazaar.launchpad.net/~synerpgy/synerpgy-projects/destock_dev/ | 13:27 |
| vila | http doesn't provide write access which is needed to commit | 13:27 |
| vila | paste 'bzr config' ? | 13:28 |
| mgz | probably just need to do `bzr launchpad-login` | 13:29 |
| vivekimsit2 | vila: till now u told everything correct! It says unknown command "config" | 13:31 |
| vila | well, the push_location is set, so probably launchpad-login was done in the past | 13:31 |
| vila | urgh, 'bzr version' ? | 13:32 |
| vivekimsit2 | vila: what command I should type now? | 13:33 |
| vila | bzr version | 13:33 |
| vila | 'version' is a bzr command | 13:34 |
| vivekimsit2 | vila: its 2.2.4 | 13:34 |
| vila | hmpf | 13:34 |
| vila | what os are you using and can you upgrade to a more recent version (2.2 is.... old, 2.5 is the current stable) | 13:34 |
| vivekimsit2 | vila: hm, see I can't upgrade just now! is there any alternative? | 13:35 |
| vivekimsit2 | one more thing there is more serious problem | 13:36 |
| vivekimsit2 | when I push I get : http://bpaste.net/show/OPRCzXjGFsm7MFxySYaY/ | 13:36 |
| vila | vivekimsit2: it's harder for me to debug such an old version, I'm can't remember which bugs where not fixed there ;) | 13:37 |
| vila | s/I'm/I/ | 13:37 |
| vila | wow, can you 'ssh -vv bazaar.launchpad.net' ? | 13:37 |
| vivekimsit2 | vila: http://bpaste.net/show/rdTWWVZngtEOl3q6VKy2/ | 13:39 |
| vila | vivekimsit2: there you go, ssh should succeed first, here you seem to not be able to even reach b.l.net | 13:44 |
| vivekimsit2 | vila: hmm | 13:44 |
| vivekimsit2 | vila: what should I do now? | 13:44 |
| vila | is your lp id vivekimsit2 ? If not, use ssh -vv <your-lp-id-here>@bazaar.launchpad.net | 13:45 |
| vivekimsit2 | vila: I am getting the same error | 13:48 |
| vivekimsit2 | vila: don't know but till yesterday everything was working fine | 13:50 |
| vila | vivekimsit2: it's related to your network connection | 13:50 |
| vivekimsit2 | vila: hmm.. | 13:51 |
| vila | given you 'bzr info' output, bzr use ssh to connect to lp, you can reproduce (and debug) that with 'ssh -vv', hence, bzr is not the culprit there | 13:53 |
| vila | it's (like you) the victim :-/ | 13:53 |
| hbeck | I'm trying to merge into my bzr copy of a svn repo (I 'forked' their repo) using "bzr merge svn+https://poco.svn.sourceforge.net/svnroot/poco/poco/trunk" but the merge preview is looking like it is doing an entire delete/add replacement of every file...what's up there? | 13:59 |
| mgz | hbeck: you didn't keep a clean copy of the upstream locally? | 14:01 |
| mgz | might be useful to just branch it and look at the history to see if the issue is present there or just related to the merge. | 14:02 |
| hbeck | mgz: you mean a copy of the initial point at which I created the bzr repo from my checkout of the svn repo? | 14:02 |
| mgz | right. | 14:02 |
| mgz | I suspect that was a one-time import, rather than a normal branch? how did you do it? | 14:03 |
| hbeck | unfortunately I wasn't the one who did the initial import...is there a way to see what command was used in the log somehow? | 14:03 |
| mgz | if so, that generated a bunch of file-ids, which are not the same as what bzr-svn uses when just doing a branch | 14:04 |
| mgz | hbeck: in the log on the machine that did it. otherwise, it can probably be inferred from the details of the revisions | 14:04 |
| mgz | but you're probably best off posting to the mailing list about it | 14:05 |
| hbeck | anything enlightening in this? http://dpaste.com/754228/ | 14:06 |
| hbeck | revision vs svn revno seems important somehow | 14:06 |
| mgz | hbeck: compare the output of `bzr version-info --include-file-revisions LOCATION` on both your local branch, and the remote one | 14:10 |
| mgz | hbeck: will be big, pipe it to a file | 14:11 |
| hbeck | mgz: saw that after I ran it, heh | 14:12 |
| hbeck | mgz: I still get mixed up with bzr terminology, when you say local and remote branch, you mean...? I have a checkout of our bzr repo I am using to try to do this merge with the svn trunk | 14:14 |
| mgz | right, once on your bzr repo, and once on the svn trunk | 14:15 |
| hbeck | ok | 14:15 |
| mgz | if it doesn't work on svn trunk directly, `bzr branch` it locally, then run it on that | 14:15 |
| hbeck | ok | 14:15 |
| frathgeber | afternoon, all | 14:29 |
| hbeck | morning :) | 14:29 |
| frathgeber | is there a known way to make bzr fast-im/export properly recognize ancestry relationships? | 14:29 |
| mgz | frathgeber: eyes glazing over, try asking on the mailing list for a useful answer | 14:31 |
| frathgeber | scenario is: a bzr shared repo i.e. collection of related branches and i want to make that interoperable to a git repository | 14:31 |
| frathgeber | problem is: any changes made in git lose their ancestry relationships when pushed back to the bzr shared repo | 14:33 |
| frathgeber | mgz: ok, i'll try that. i appreciate that's not an easy problem | 14:33 |
| frathgeber | but i think it's crucial to make the fast-import format meaningful | 14:34 |
| frathgeber | if it only works at a per-branch level it's rather useless | 14:34 |
| mgz | sounds basically the same as hbeck's issue, an import to bzr generates file-ids | 14:34 |
| mgz | but bzr-git doesn't know about what those were, right? | 14:34 |
| hbeck | mgz: really? didn't think mine would be that complex. What's weird with what I'm seeing right now is that we've done a merge with the same command I put above before, and it behaved ok | 14:35 |
| mgz | so you can't then use it to move revisions between the bzr and git repos | 14:35 |
| mgz | hbeck: you might be lucky then, and was just bzr-svn specific | 14:36 |
| mgz | anyway, really needs some jelmer expertise and he's not around today. | 14:37 |
| frathgeber | just /joined, so will have to read up in the logs | 14:37 |
| frathgeber | but they seem to lag behind quite a bit | 14:37 |
| mgz | yeah, only updated every hour | 14:37 |
| hbeck | mgz: no I mean literally the same - we did the initial bzr repo 'creation' and then used that command to merge from the svn repo. Not sure why it's behaving differently now...but again I didn't do that merge either so lacking the previous experience | 14:38 |
| mgz | well, a problem solved is a solved problem :) | 14:39 |
| vila | frathgeber: as far as I understand it, if you use bzr (and bzr-git) you can interoperate with git repositories, you seem to be doing the opposite (push to bzr repos from git) | 14:39 |
| frathgeber | exactly, i'm using git-bzr-ng (which is unfortunately horrendously unstable) | 14:40 |
| frathgeber | it works by keeping a shared bzr repo and mirrors the git repo back and forth using fast-im/export | 14:40 |
| frathgeber | and that's when i'm hitting the issue i.e. when i push to bzr and sync back it doesn't recognize commits are shared between branches | 14:41 |
| frathgeber | it always rewrites revision id's on export it seems | 14:42 |
| mgz | right, I think the ids aren't deterministic, so I'd be suprised if that worked | 14:42 |
| frathgeber | incidentally it also doesn't preserve timestamps | 14:42 |
| frathgeber | mgz: yep, that's what i suspected | 14:42 |
| mgz | they just get generated on the import/export, unlike bzr-git which has a scheme | 14:42 |
| frathgeber | which imho essentially means fast-im/export is broken for anything but single branch use cases | 14:43 |
| mgz | they're not designed for repeated use as I understand it, no | 14:44 |
| mgz | there was some other git-to-bzr thing as well, I forget what it was called | 14:44 |
| frathgeber | hmm, that gets me thinking: can i use bzr-git "backwards"? | 14:46 |
| frathgeber | that should work, shouldn't it? | 14:46 |
| mgz | yup. | 14:46 |
| mgz | as in, operate on git branches locally and push to bzr. | 14:46 |
| mgz | hbeck: did you get the version-info output for both branches, and they had the same fileid then? | 14:48 |
| frathgeber | i do an intial import using fast-import and then instead of pushing from git to bzr via fast-export (which is what git-bzr-ng does), i pull to a bzr repo using bzr-git | 14:48 |
| frathgeber | oh, but how do i pull changes into the git repo then? that won't work | 14:48 |
| hbeck | mgz: working on it, having to bzr branch from the svn repo and it is being extremely slow | 14:48 |
| frathgeber | tricky... | 14:48 |
| vila | frathgeber: you push to git with bzr-git (or dpush) | 14:50 |
| frathgeber | ah, ok, that may work then | 14:52 |
| frathgeber | so for the initial setup | 14:52 |
| frathgeber | can i also create the git repo via push from a bzr branch? | 14:53 |
| frathgeber | so assuming i have a shared repo with loads of related branches | 14:54 |
| frathgeber | can i create the git repo by pushing from trunk? and then push all the other branches into that git repo as well? | 14:54 |
| frathgeber | so essentially the git repo wouldn't actually be aware it's "fed" from bzr? | 14:55 |
| vila | frathgeber: that's my understanding (but for full disclosure, I have no first hand experience there) | 14:55 |
| frathgeber | vila: cool, i'll just try it out | 14:55 |
| vila | no, AIUI, the git server thinks it's talking to a git client | 14:55 |
| vila | the bzr-git client takes care of the needed housekeeping (which, again AIUI, is achieved by dpush which does: push to git, get the revisions back, replace the pushed revisions by the pulled ones) | 14:56 |
| vila | I don't remember precisely if dpush should still be used or if it has been integrated with the core push | 14:57 |
| vila | frathgeber: jelmer is authoritative and will correct me if/where I'm wrong (but he's in vacations these days) | 14:58 |
| frathgeber | ok. does is work in reverse? i.e. can a git-enabled bzr repo receive pushes from git? | 15:00 |
| frathgeber | vila: how do you mean? jelmer is allowed vacation? ;) | 15:01 |
| vila | frathgeber: yeah, I don't get it either ;) | 15:02 |
| frathgeber | you should bzr branch him before he leaves next time ;) | 15:03 |
| vila | frathgeber: I don't know the git eco-system enough to tell you what is the equivalent of the bzr-git plugin, I'm not sure it even exist | 15:03 |
| vila | hehe, branching him will only give us his history, what we really want is his working tree ;) | 15:03 |
| frathgeber | LOL | 15:04 |
| vila | (the one populated with all his clones ;) | 15:04 |
| frathgeber | vila: the closest thing to bzr-git i could find is https://github.com/termie/git-bzr-ng, but it's fundamentally broken in that it uses fast-import | 15:04 |
| vila | yup | 15:05 |
| frathgeber | and as you pointed out that is that not the right tool for the job (TM) | 15:05 |
| vila | well, for some value of 'fundamentally broken' in 'limited features' | 15:05 |
| LeoNerd | bzr on sshfs to a remote FreeBSD machine == slooooow :( | 16:44 |
| LeoNerd | Not quite sure why.. does it do lots of temporary stuff via the local filesystem? | 16:45 |
| mgz | don't do that then? :) | 16:45 |
| LeoNerd | Well it's either this or try to install bzr on the FreeBSD box without being root | 16:45 |
| mgz | you just want to put the branch on the bsd box? | 16:46 |
| LeoNerd | No, I'm developing code there. | 16:46 |
| mgz | I'd install bzr for my user if trying to version things on a remote machine | 16:47 |
| mgz | get the 2.5.1 tarball, unpack, python setup.py install --user | 16:47 |
| mgz | then not mess around with dodgy network filesystem things | 16:47 |
| mgz | then again, bsd is weird, maybe life is more painful, fullermd would know. | 16:48 |
| fullermd | I don't know anything particular that would make it unexpectedly slow. I wouldn't think sshfs would need much help to be slow in that sort of usage. | 17:08 |
| fullermd | As a user, I wouldn't install bzr, I'd just run it out of the tarball. Simpler. | 17:09 |
| fullermd | But better for the admin to just install it. I don't maintain the port just for my health, y'know :p | 17:09 |
| mgz | fullermd: right, the health benefits are are bonus | 17:17 |
| mgz | right, four day weekend time | 17:17 |
| vila | LeoNerd: With my RM hat on (but not involved downstream), using the FreeBSD port of bzr is a good as it can be, you'll get the stable series and dot releases in due time. | 18:23 |
| vila | LeoNerd: And quite frankly, using sshfs, no matter how good it can be, is just asking too much. bzr use different strategies for local and remote fs to take latency into account so there is no way you can beat bzr+ssh with bzr+sshfs | 18:25 |
| vila | LeoNerd: You'll have to update your remote wt though, but bzr-push-and-update should take care of that for you | 18:28 |
| vila | LeoNerd: if you need to uncommit, don't forget push --overwrite | 18:28 |
| fullermd | push-and-update won't help if there's no bzr on the remote end, which is kinda the premise of the whole discussion :p | 18:34 |
| === yofel_ is now known as yofel | ||
| LeoNerd | There is indeed no bzr on the other end, which is why I was doing this. bzr co / update / etc... over sshfs | 19:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!