| === r0bby is now known as robbyoconnor | ||
| === r0bby is now known as robbyoconnor | ||
| === speakman_ is now known as speakman | ||
| === BasicPRO is now known as BasicOSX | ||
| === Ursinha is now known as Ursinha-afk | ||
| === vila_ is now known as vila | ||
| vila | hi all ! | 07:44 |
|---|---|---|
| === vila changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | 2.3.0 is officially out ! (RM: vila) | ||
| === soren_ is now known as soren | ||
| === abhinav_ is now known as abhinav- | ||
| geekosopher | immediately after I branch any lp repo to one of my hd partitions (outside /home), 'bzr st' shows all files of the repo in 'modified' category, and 'bzr diff' shows all file names with '(properties changed: -x to +x)' appended to them | 11:51 |
| Peng | Is this some fun file system? | 11:52 |
| geekosopher | the hd partition in question is set to automount by adding a line in fstab file | 11:52 |
| geekosopher | its vfat | 11:52 |
| Peng | Lovely. | 11:53 |
| vila | geekosopher: OS/version/file system involved ? This sounds like the underlying fs doesn't handle the exe bits properly | 11:53 |
| geekosopher | vila: kubuntu/10.10/vfat | 11:53 |
| geekosopher | Peng: that sounds like 'no' | 11:53 |
| geekosopher | *no solution | 11:53 |
| geekosopher | i tried changing the file system permissions, but either nothing or umask=0*** gives above error | 11:55 |
| maxb | I seem to recall seeing a bug about this? Yes, it's more or less expected behaviour for bzr on vfat on linux | 11:55 |
| geekosopher | and anything other than 0** causes inaccessibility | 11:56 |
| geekosopher | yes, this is typical of bzr only, git is working fine | 11:56 |
| maxb | Obviously it would be nicer if bzr ignored the modifications, but it's not behaving that unsurprisingly, given the underlying FS *has* modified the perms from what was in the repository | 11:56 |
| geekosopher | explicitly doing chmod is not working either | 11:57 |
| geekosopher | like 'chmod -x <repo directory> | 11:57 |
| maxb | Well, no, it wouldn't. The vfat fs is incapable of storing permission information. | 12:00 |
| geekosopher | >.< | 12:01 |
| * geekosopher wondering how bzr works on windows | 12:02 | |
| geekosopher | oh yes, windows wouldn't even have permissions stuff | 12:08 |
| Peng | Windows has the execute bit, which is all Bazaar tracks. | 12:10 |
| geekosopher | hmm | 12:10 |
| vila | geekosopher: not to mention symlinks... | 12:24 |
| Mez | is there anywhere a good into ro using bzrlib? I want to create a quick script that emails people about uncommitted changes in their branches. But would prefer to do it using bzrlib rather than system calls. | 12:27 |
| jam | hey vila, I haven't gotten a chance to /wave at you in your timezone yet :) | 12:35 |
| vila | jam: hey !!! | 12:36 |
| jelmer | :) | 12:38 |
| jelmer | 'morning jam, vila | 12:38 |
| jelmer | vila: welcome back, I hope you had a nice vacation :) | 12:38 |
| vila | jelmer: wonderful ! | 12:38 |
| jam | well, afternoon here, I hope :) | 12:39 |
| jam | either that, or I'm *really* confused | 12:40 |
| jelmer | jam: You're not :) | 12:41 |
| vila | :) | 12:41 |
| jelmer | Mez: I don't think there's anything like that, but this should get you started: | 12:41 |
| jelmer | Mez: from bzrlib.workingtree import WorkingTree; wt = WorkingTree.open("."); changes = wt.changes_from(wt.basis_tree()) | 12:42 |
| Mez | jelmer: yeah - had just found that in the documentation. | 12:43 |
| Mez | Though for some reason, taht doesn't show files that have been created, but not added. | 12:43 |
| jelmer | Mez: wt.unknowns() will list those files | 12:44 |
| jam | geekosopher: on Windows, we know that we can't trust the fs, so we use the executable bit from the basis inventory. We don't have a good way to know that the FS is vfat, AFAIK. | 12:44 |
| jelmer | jam: We could add a check to see if we can set the executable bit correctly, like we do with case sensitivity | 12:45 |
| vila | jelmer: +1 | 12:45 |
| jam | jelmer: case sensitivity only has to stat an existing file with a different path | 12:45 |
| jam | not actually do a mutation operation | 12:46 |
| jam | like chmod | 12:46 |
| jam | consider readonly systems | 12:46 |
| jam | It might be reasonable to check that during update, though | 12:46 |
| Mez | jelmer: what are delta.unchanged and delta.uncommitted for / | 12:46 |
| jam | I don't really want to do it on every 'bzr status' | 12:46 |
| jelmer | jam: fair enough | 12:46 |
| Mez | sorry, delta.unversioned | 12:46 |
| jam | Mez: unchanged == files that are versioned that have not changed | 12:46 |
| jam | only available if you pass include_unchanged | 12:46 |
| jelmer | jam: Perhaps just a setting in .bzr/checkout/checkout.conf that gets autoset upon checkout creation? | 12:47 |
| vila | jam: you can't have a wt on a readonly fs and run into the problem geekosopher is mentioning (IIUC) | 12:47 |
| jam | unversioned are files that exist, but have been marked for removale (such as with 'bzr rm') | 12:47 |
| jam | vila: I can do the checkout onto vfat, and you can run bzr st | 12:47 |
| jam | and you'll very likely have the problem | 12:47 |
| jam | because vfat only has 1 global user and group | 12:47 |
| jam | for the whole mount | 12:47 |
| jam | because linux fakes it | 12:47 |
| vila | jam: but that's not readonly then | 12:47 |
| jam | vila: it *is* readonly for you | 12:48 |
| jelmer | jam: We could rely on the fact that vfat always sets +x, and we never normally set it on e.g. .bzr/format, but that is.. dubious | 12:48 |
| jam | jelmer: right, a setting that gets set during a write operation would be ok for me | 12:48 |
| jam | jelmer: it doesn't, it sets the files to whatever you set in /etc/fstab | 12:48 |
| jam | I think the default includes +x | 12:48 |
| jam | but I often reset it to 0644 | 12:48 |
| jam | because I don't want everything to be +x | 12:48 |
| jelmer | ah, I didn't realize you could override it | 12:48 |
| jam | user, group, mode bits are all mount-time flags | 12:49 |
| vila | jam: right, but that's not what geekosopher is encountering | 12:49 |
| jam | jelmer: https://code.launchpad.net/~dmitrij.ledkov/bzr-keywords/more-keywords/+merge/23626 are you just proxying for him? | 12:49 |
| vila | jelmer: the problem with a setting in a conf file is that it won't be updated if the whole tree is copied on a different fs (well, until the next update...) | 12:50 |
| jam | vila: my point is that there are a lot of remaining edge cases | 12:50 |
| jam | doing it 1 time during "initialize()" would handle a lot ofthem | 12:50 |
| jam | doing it during mutating operations would handle most of the rest | 12:50 |
| jam | so "bzr revert" could detect it. | 12:50 |
| jelmer | jam: I don't think I follow, I was just commenting on the MP. | 12:50 |
| jam | jelmer: I got an email "You have been requested to review the proposed merge of ..." with your name on it | 12:51 |
| jam | I was trying to figure out wether you were proposing it for him, or what | 12:51 |
| jelmer | jam: ah | 12:51 |
| jelmer | I added bzr-core as reviewer, as Ian was previously the owner of lp:bzr-keywords | 12:51 |
| jam | jelmer: https://code.launchpad.net/~jelmer/bzr/blackbox-upgrade-formats/+merge/51297 | 12:53 |
| jam | for that one, I approved, but didn't look too closely | 12:53 |
| jam | I assume it is the same tests, just switching to knits, and adding one that upgrades from a fake format | 12:53 |
| jelmer | jam: Yeah, though changing the existing one that tested upgrading from a non-metadir format to a metadir format rather than adding a new one. | 12:54 |
| vila | jam, jelmer: Except for my huge mail backlog, are there events/decisions I should be aware of ? | 12:55 |
| jelmer | jam: There were already tests for e.g. just repository format upgrades | 12:55 |
| jelmer | vila: not that I recall | 12:55 |
| jam | vila: poolie was gone 2 weeks ago, and is gone again this week, so not a lot of big policy decisions going on | 12:57 |
| jam | We have a couple "Critical" bugs now, poolie was kind enough to set one and then leave :) | 12:58 |
| jam | I'll probably work on the repack inventories one soon. | 12:58 |
| jam | Just trying to finish getting my launchpad+loggerhead stuff flushed out of the pipe, first | 12:58 |
| vila | ok, thanks for the summary ! | 12:58 |
| === Ursinha-afk is now known as Ursinha | ||
| jam | jelmer: I'm getting OOPS trying to send email to launchpad. I'll try to submit to you directly. | 13:20 |
| jelmer | jam: ok | 13:23 |
| jam | jelmer: I think that is everything except for the repository_vf check_reconcile tests | 14:01 |
| jam | I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos. | 14:01 |
| jam | so it sounds more like some missing abstractions. | 14:01 |
| jelmer | jam: Thanks! | 14:07 |
| * maxb grimaces at python-central deprecation notice | 14:08 | |
| maxb | that's going to make PPA builds fun | 14:08 |
| jelmer | jam: All of our current reconciliation seems specific to VersionedFiles, so while I think reconcilation would apply to e.g. Subversion repositories it would be for completely different issues. | 14:08 |
| jelmer | maxb: Yeah - for everything except Natty (and Maverick?) | 14:08 |
| maxb | I wonder if we drop Hardy support once Natty is out. It'll be at partial-EOL state then (server only0 | 14:10 |
| maxb | Still, someone probably still wants bzr core for it | 14:10 |
| jam | maxb: so is that python-central vs python-support? | 14:10 |
| maxb | python-central vs. dh_python2 | 14:11 |
| jam | which itself was from python-support way back when | 14:11 |
| maxb | the latter being something new that I have not learnt about yet | 14:11 |
| jam | something like dapper | 14:11 |
| jam | which did, indeed, cause some large headache in its time | 14:11 |
| jam | lovely we get to revisit them | 14:12 |
| jelmer | at least we now have a single python module support mechanism rather than 2 | 14:13 |
| kyleN | Hello. I seem to have a lock file on LP that prevents me from pushing a branch. Can anyone assist me? | 14:28 |
| kyleN | I have tried bzr break-lock locally before pushing and running it with a bzr+ssh:// url to the server branch. still cannot push. | 14:28 |
| Peng | It's always possible someone really is using the branch, of course. | 14:29 |
| Peng | If not, "bzr break-lock bzr+ssh://..." should take care of it. | 14:29 |
| kyleN | it has been locked since Saturday and I think I am the only one working on the branch right now | 14:29 |
| vila | jam: why is bug #716777 against bzr ? Did you mean loggerhead or history-db instead ? | 14:29 |
| ubot5 | Launchpad bug 716777 in Bazaar "history-db should handle OperationalError: database is locked" [Critical,Confirmed] https://launchpad.net/bugs/716777 | 14:29 |
| jam | vila: it should be against loggerhead, yes | 14:41 |
| jelmer | jam: did you have any thoughts on the per_repository_vf MP? | 15:38 |
| jelmer | (the one that is a prerequisite for the check_reconcile MP) | 15:38 |
| jam | (3:00:52 PM) jam: jelmer: I think that is everything except for the repository_vf check_reconcile tests | 15:38 |
| jam | (3:01:11 PM) jam: I'm a bit concerned that while the existing tests may not apply, we *should* still support some sort of reconciliation and checking on those repos. | 15:38 |
| jam | (3:01:19 PM) jam: so it sounds more like some missing abstractions. | 15:38 |
| jam | maybe I missed a patch in there, though | 15:39 |
| jelmer | jam: I mean https://code.launchpad.net/~jelmer/bzr/per-repository-vf/+merge/51150 rather than https://code.launchpad.net/~jelmer/bzr/per-repository-vf-reconcile/+merge/52283 | 15:39 |
| jam | jelmer: locally, the diff is empty | 15:39 |
| Peng | /1/6 | 15:40 |
| jam | but seems to be populated in the web ui | 15:40 |
| Peng | eep | 15:40 |
| jelmer | Peng: Hi :) Or whatever the proper response to that is :) | 15:40 |
| Peng | The peroper response is "Peng, learn how to type your aliases properly!" | 15:41 |
| Peng | Hi, but I was just checkin' IRC before giving the laptop -- and maybe myself -- some sleep. Bye. <3 | 15:42 |
| jelmer | g'night | 15:42 |
| jam | jelmer: It seems ok, but since you aren't removing any tests, I'm not really sure what it is getting you. Just the precursor to moving stuff over? | 15:44 |
| jam | the config is all correct | 15:44 |
| jelmer | jam: It's moving a couple of tests to per_repository_vf, so those will no longer run against bzr-svn/bzr-git/bzr-hg | 15:44 |
| jam | jelmer: there are no '-' lines that would indicate that | 15:45 |
| jam | at least, that I can see | 15:45 |
| jam | certainly it does add some tests | 15:45 |
| jam | but none are removed from elsewhere to be "moved" | 15:45 |
| jam | anyway, time to pick up my wife. I *think* things are ok, but I think I also need to think about implications in the long term. | 15:46 |
| jam | I'm a bit worried about us expecting new functionality is working, only to have the tests not testing against all implementations they should be, etc. | 15:46 |
| jelmer | jam: Those tests need to be moved rather than copied, I'll update the MP. | 15:47 |
| jelmer | jam: That's one of the reasons I've added the format attribute tests and made the format attributes default to None, so format implementations explicitly have to indicate whether they support something. | 15:47 |
| jelmer | I'm not sure what to do about code that relies on functionality that is a part of the VersionedFileRepository API but not of the smaller Repository API, it would be nice to somehow check that sort of thing. | 15:48 |
| jelmer | s/it would be/I agree it would be/ | 15:49 |
| === seiflotfy__ is now known as seiflotfy | ||
| tgall_foo | users of bzr-git : what's the syntax to pull from a branch of a remote repo (IE from other than master) | 16:38 |
| jelmer | tgall_foo: That's not possible at the moment, as there's no UI in Bazaar for addressing colocated branches | 16:39 |
| jelmer | It's high on my todo list to finish that work. In the mean time, you can import all branches in a repository using "bzr git-import" | 16:39 |
| tgall_foo | thanks jelmer | 16:40 |
| tgall_foo | jelmer, followup, I guess I was expected bzr git-import then to do an effective bzr branch for all the remote git branches.. after the bzr git-import least down the new refs directory it's empty | 16:46 |
| jelmer | tgall_foo, it creates workingtree-less branches | 16:46 |
| jelmer | tgall_foo, try running "bzr log" in one of them | 16:46 |
| jelmer | tgall_foo, you can pull from them, or create a working tree by running "bzr checkout ." | 16:46 |
| tgall_foo | thanks jelmer | 16:48 |
| teamgbc | hey all | 17:09 |
| jelmer | hi teamgbc | 17:09 |
| teamgbc | i'm new to bzr | 17:09 |
| teamgbc | and i want to do something simple, but for i'm having trouble | 17:10 |
| teamgbc | i got bzr installed on 2 machines.... and one is supposed to be server | 17:10 |
| teamgbc | but i can't connect ( get a project source) from the server | 17:10 |
| teamgbc | i'm reading through some documentation, but i'm getting lost in the links | 17:10 |
| teamgbc | i've gone through the setup tutorial | 17:12 |
| teamgbc | when i do bzr push --create-prefix sftp://localhost/teamgbc/ | 17:12 |
| teamgbc | i get bzr ERROR not a branch '/home/teamgbc/" | 17:13 |
| teamgbc | just wondering if there is some tutorial somewhere | 17:13 |
| teamgbc | that exists for almost complete newbies | 17:13 |
| jelmer | teamgbc, have you seen http://doc.bazaar.canonical.com/bzr.dev/en/? | 17:14 |
| teamgbc | i guess i was thinking that i placed the trunk inside var/www | 17:15 |
| teamgbc | if i, i should be able to access the files via http... | 17:15 |
| teamgbc | Jelmer, yup i've gone through it a little, and ended up starting it all with bzr explorer | 17:16 |
| teamgbc | and followed the tutorial for that | 17:16 |
| teamgbc | i guess i should just start over eh? | 17:17 |
| jelmer | sorry, distracted there for a bit | 17:25 |
| jelmer | teamgbc: pushing to sftp://localhost/teamgbc/ will push to /teamgbc on your local machine | 17:25 |
| teamgbc | so how am I supposed to reach my server then? | 17:25 |
| teamgbc | i'm going to go back through the initial tutorial and do everything via the command line | 17:26 |
| teamgbc | then i'll come back if i have issues, better than waste anyone's time | 17:26 |
| jelmer | teamgbc: well, localhost is your local machine :) | 17:26 |
| teamgbc | cheers jelmer, much appreciated | 17:26 |
| teamgbc | sorry | 17:26 |
| teamgbc | haha | 17:26 |
| teamgbc | i mean i was trying /192.168.1.107 | 17:26 |
| teamgbc | which is the server in the local network | 17:27 |
| jelmer | teamgbc: it'll push to the /teamgbc directory on that machine, are you sure that's where you want to push? | 17:27 |
| teamgbc | interesting, no, that doesn't make much sense | 17:28 |
| teamgbc | hah | 17:28 |
| teamgbc | ok, i'm going to run through the command line tutorial. I though the GUI would be easy enough to just create the trunk in a specified directory | 17:29 |
| teamgbc | and then type in that director location in the remote machine | 17:29 |
| teamgbc | to access the source or open the remote location | 17:29 |
| teamgbc | thanks jelmer | 17:30 |
| dpm | hey jelmer, around? | 17:45 |
| jelmer | dpm: Hi David | 17:45 |
| dpm | jelmer, thanks a lot for merging my branch | 17:46 |
| dpm | I was wondering if you've got a few minutes if we could set up translations in the LP project | 17:46 |
| jelmer | np, thanks for adding i18n support in the first place | 17:46 |
| jelmer | dpm: Sure | 17:46 |
| === deryck is now known as deryck[lunch] | ||
| dpm | ok, cool, so it's basically here -> https://translations.launchpad.net/bzr-gtk/+configure-translations . The first thing is to set permissions, focus, and a couple of other things. My recommendations: | 17:48 |
| dpm | * Launchpad | 17:48 |
| dpm | * trunk | 17:48 |
| dpm | * launchpad-translators | 17:48 |
| dpm | * Restricted | 17:48 |
| jelmer | what's the difference between Launchpad and Ubuntu translators? | 17:49 |
| dpm | The reason I suggest to assign it to the Launchpad Translators group is simply because bzr-gtk is not an Ubuntu-specific project, so Launchpad Translators makes more sense | 17:50 |
| dpm | they are simply two translation groups | 17:50 |
| dpm | a translation group contains translation teams, one per language | 17:50 |
| dpm | and they take care of translating particular projects | 17:50 |
| dpm | Launchpad Translators is an umbrella for translating any project hosted in Launchpad for translation | 17:51 |
| jelmer | ah, ok | 17:51 |
| dpm | Ubuntu Translators, the same, but for any project specific to Ubuntu, or for the distro itself | 17:51 |
| jelmer | Thanks - I've configured that page with the settings you suggested | 17:51 |
| dpm | cool, let me see what the next step is, probably translation imports | 17:52 |
| dpm | ah, yeah, imports for the trunk branch | 17:53 |
| dpm | So here: https://translations.launchpad.net/bzr-gtk/trunk/+translations-settings I'd suggest simply choosing "Import template files" | 17:54 |
| dpm | That will import the bzr-gtk.pot template in the branch and expose it in the UI every time you update it and commit it | 17:55 |
| dpm | I'd also recommend updating it and committing it at least a few days before a release, so that translators see the latest strings and have time to translate it | 17:56 |
| dpm | (but that's got nothing to do with the settings, just a suggestion) | 17:56 |
| jelmer | dpm: done | 17:58 |
| dpm | cool thanks, so now for the final step: automatic exports, to get translations committed automatically to a branch of your choice | 17:58 |
| dpm | You simply have to choose the branch where you want them committed here: https://translations.launchpad.net/bzr-gtk/trunk/+link-translations-branch - you can have a separate branch (if you want to keep it separate and merge it back to trunk regularly) or the main branch (if you just want to let LP do the right thing and forget about committing translations, and if you don't mind having automatic commits in the tree) | 18:01 |
| dpm | * A caveat: you might hit bug 407260 when trying to choose the branch, but it's got an easy workaround: "At the moment, team-owned branches don't work as expected. To work around this, make yourself the owner of the branch, set it as the translations branch, and then make the team the owner of the branch again." | 18:02 |
| ubot5 | Launchpad bug 407260 in Launchpad itself "Translations export branch can't be team-owned" [High,Triaged] https://launchpad.net/bugs/407260 | 18:02 |
| jelmer | hmm | 18:04 |
| jelmer | for the moment I'm more comfortable with a separate branch | 18:04 |
| dpm | sure, just laying out the options. You should choose the workflow that best suit your needs | 18:05 |
| dpm | suits | 18:05 |
| jelmer | dpm: Cool - set | 18:05 |
| dpm | then I think we're all done \o/ | 18:05 |
| dpm | I'll be testing it in the next few days, thanks! | 18:05 |
| jelmer | you - thanks for adding i18n support to bzr-gtk :) | 18:06 |
| jelmer | s/you/you too/ | 18:06 |
| dpm | no worries, my pleasure :) | 18:06 |
| jelmer | dpm: I guess it's still an issue that bzr itself doesn't support i18n? I.e. errors and warnings may come directly from bzr | 18:07 |
| dpm | oh, yeah, I hadn't thought of that. I'd be happy to help on that as well, but I'm not sure there are any plans to i18n'ize bzr? | 18:08 |
| dpm | Has this ever been discussed at all? | 18:09 |
| jelmer | I'm not aware of any. There's an open bug somewhere.. | 18:09 |
| dpm | At least SVN is internationalized, we could aim to beat that as well :) | 18:09 |
| jelmer | https://bugs.launchpad.net/bzr/+bug/83941 | 18:10 |
| jelmer | with a comment from myself from 2007 :) | 18:10 |
| jelmer | it's been discussed offline a couple of times. From what I recall the main concern is that adding i18n support should not have a performance impact | 18:11 |
| jelmer | blindly gettexting all strings that might be user visible will add a significant overhead, as some of those get raised pretty often but are then not shown to the user | 18:13 |
| jelmer | it's not impossible but needs some thought | 18:13 |
| dpm | yeah, that's what I thought that'd be the main concern. AFAIK, gettext is really fast, so I don't think it should incur a performance drop, but only tests can tell | 18:13 |
| dpm | well, I'll be happy to have a go at it and submit a MP for i18n'izing bzr itself, and then you guys can have a look. | 18:15 |
| jelmer | that'd be awesome | 18:15 |
| dpm | I don't know when though, but I'll definitely look into it | 18:15 |
| vanguard | is there some way to save push/merge locations with a name like "origin" like one can in git? | 18:38 |
| jelmer | I think the bzr-bookmarks plugin is intended to work like that | 18:39 |
| vanguard | jelmer: k, I'll check it out | 18:50 |
| === deryck[lunch] is now known as deryck | ||
| vanguard | can I check out some revision without loosing everything after that revison? | 19:42 |
| maxb | sure | 19:45 |
| LeoNerd | The version that a checkout is at doesn't have to be the head revision in a branch... | 19:49 |
| vanguard | LeoNerd: So I do it the same way as in git, with a checkout command? | 19:51 |
| LeoNerd | bzr co -r123 | 19:52 |
| * LeoNerd dosen't know git | 19:52 | |
| LeoNerd | I find it odd... people in here asking abuot git, people in #vim asking about emacs... | 19:52 |
| LeoNerd | You can't just presume that people in #{$TOOL} would understand references to $OTHERTOOL :) | 19:53 |
| vanguard | LeoNerd: People asked about some distro in #kubuntu ... that is the way it works. And where should I go if I want to get optinions from people who have experience with bzr and git? | 20:01 |
| LeoNerd | Ah, well one -and- the other, is a different problem again | 20:02 |
| === mwhudson_ is now known as mwhudson | ||
| jasonlife | How can I update my module to a old revision ? "bzr update -r xxx" doesn't work.. | 20:49 |
| maxb | jasonlife: doesn't work? | 20:50 |
| jasonlife | yes.. | 20:50 |
| maxb | explain | 20:50 |
| jasonlife | after I do this, I just checked revno, but it is still same.. | 20:50 |
| jasonlife | "bzr revno" show the same as before | 20:51 |
| jasonlife | and bzr log shows all the logs too.. | 20:51 |
| maxb | please pastebin a transcript of the commands and responses | 20:51 |
| jasonlife | maxb: so, "bzr update -r xxx" should work.. right? | 20:52 |
| maxb | yrs, it should | 20:52 |
| maxb | yes, even | 20:52 |
| jasonlife | I will try this again and I will paste them again.. | 20:52 |
| jasonlife | ok.. thanks.. | 20:52 |
| maxb | though it's a relatively new feature | 20:52 |
| maxb | what is your bzr version? | 20:53 |
| jasonlife | oh | 20:53 |
| jasonlife | 2.1.0 | 20:54 |
| mtaylor | given two branch urls, is there an _easy_ way to determine if one is contained within another? | 20:54 |
| jasonlife | "bzr --version" shows 2.1.0 | 20:55 |
| jasonlife | it happens on both 2.1.0 and 2.1.1 | 20:58 |
| jasonlife | when I run "bzr update -r xxx" , it actually revert the files to old revision, but "bzr revno" and "bzr log" shows the current revno and logs.. | 20:59 |
| knighthawk | help I'm trying to prevent having to go back to svn. My team has been adapting pretty well to bzr however we have 3 party programmers who aren't used to bazaar and are running into major problems. at the heart of my problems is that they are using eclipse and the eclipse plugin doesn't seem to work all that well. | 21:38 |
| knighthawk | I guess I'm looking for idea's on the best way to handle this. (I don't want to go backwards) but I may have to set something up so that the 3rd party can use subversion. I keep hearing about a svn-bzr bridge will this help me any? | 21:39 |
| knighthawk | how hard is it to move a bzr repo over to hg? | 22:03 |
| beuno_ | knighthawk, pretty easy | 22:04 |
| beuno_ | there's a bzr-hs plugin | 22:04 |
| beuno_ | *bzr-hg | 22:04 |
| beuno_ | and there's fastimport, which is probablt best for a one-time import | 22:04 |
| knighthawk | thanks. I don't really know hg but it looks like if I switch now. I might be able to keep all the things I like about bzr and use their eclipse plugin. | 22:06 |
| jelmer | bzr-hg isn't really useful for bzr->hg, only for hg->bzr | 22:06 |
| fullermd | jasonlife: 'bzr revno' shows the revno of the _branch_; 'update' affects the _working tree_. Try 'bzr revno --tree'. | 22:34 |
| jasonlife | fullermd: thank you very much | 22:46 |
| jelmer | lifeless: hi | 23:25 |
| lifeless | hi | 23:25 |
| jelmer | lifeless: I've been meaning to move get_{branch,workingtree,repository}_transport from ControlDir to BzrDir, as they don't really make sense for foreign formats. | 23:26 |
| jelmer | lifeless: Do you think that would that make sense? John mentioned you might have had another goal with them other than using them for metadir component initialization / opening. | 23:27 |
| lifeless | I have no idea | 23:27 |
| lifeless | check plugins all work as part of your pre-proposal-qa, and I'm sure you'll find any issues | 23:28 |
| jelmer | lifeless: of course | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!