| igc | morning | 00:00 |
|---|---|---|
| cjwatson | igc: fast-import is awesome | 00:02 |
| mwhudson | hello igc | 00:03 |
| cjwatson | igc: I'm importing an svn archive at the moment with a vendor-branch-like arrangement for upstream, and trying to arrange that the resulting bzr branch has native merge commits for each upstream merge. It's working amazingly well | 00:03 |
| cjwatson | (james_w gave me the last necessary clue in the form of import-marks) | 00:03 |
| james_w | cjwatson: I'm glad it's working for you | 00:04 |
| igc | thanks cjwatson | 00:11 |
| lifeless | jelmer: ping | 00:20 |
| jelmer | lifeless, ponggg | 00:20 |
| lifeless | bug 250480 | 00:20 |
| ubottu | Launchpad bug 250480 in bzr-svn "Doesn't preserve non-lhs parents for file texts" [High,Triaged] https://launchpad.net/bugs/250480 | 00:20 |
| lifeless | I agree with john that this is critical | 00:20 |
| lifeless | I don't understand quite where the issue is re non-lhs parents and the error | 00:20 |
| lifeless | from my analysis I thought that there were two inventories with different values and the same revid | 00:21 |
| lifeless | which is also known as 'corrupt distributed DB' | 00:21 |
| lifeless | but you seem to think its something else | 00:21 |
| lifeless | ? | 00:21 |
| jelmer | No, I agree with that analysis (for values == "file parent ids") | 00:22 |
| lifeless | parent ids are not stored in the inventory | 00:22 |
| lifeless | so I don't understand what you mean when you say you agree :) | 00:23 |
| jelmer | The actual error suggests that bzr can't find the revision of a file text | 00:24 |
| jelmer | however, that file text is a ghost in the branch fetched by bzr-svn | 00:24 |
| lifeless | so there are three revisions bzr will look for | 00:25 |
| lifeless | (and need) | 00:25 |
| lifeless | and some N that it will need when fetching IFF the revision is also present | 00:25 |
| lifeless | the three it needs are left/right/base | 00:25 |
| lifeless | but another possibility is that the change rev in the inventory in the target repo is actually bogus; its a change that the repository does have and can't get hold of | 00:26 |
| lifeless | or something along those lines | 00:26 |
| lifeless | back in 30, got to do some stuff here | 00:27 |
| lifeless | I guess I'm really saying: lets pin down *exactly* why bzr is asking for that revision, and whether there are *any* differences in data between the repositories | 00:27 |
| lifeless | *other* than ghosts. Ghosts are ok, different xml-inventories or revision-xml's etc are not. | 00:27 |
| jelmer | as far as I can tell, the particular revision it was asking for doesn't occur in svn or the svn-based branched *anywhere* | 00:30 |
| markh | I thought I heard that bzrtools has been incorporated into 1.6 - is that true, or only some parts have been incorporated? | 00:51 |
| markh | ultimately I'm trying to work out if the windows binary should package it? | 00:52 |
| Peng_ | Um, it hasn't been. | 00:53 |
| spiv | markh: it hasn't been incorporated, no. So please do package it. | 01:00 |
| markh | spiv: ok, thanks | 01:03 |
| igc | jam: wrt export masking, do you think plugins should use another pattern if they want their magic stuff exported? | 01:04 |
| igc | jam: I could put the rule in a function that plugins could monkeypatch over to tune it *but* that feels pretty fragile myself | 01:05 |
| lifeless | I think there are two use cases | 01:05 |
| lifeless | one is adding arbitrary data (e.g. version-info output) during export | 01:06 |
| lifeless | the other is masking data that shouldn't be in the user tree (e.g. .bzrignore) | 01:06 |
| lifeless | I'd *prefer* we fix the latter by just not putting in the users tree | 01:06 |
| lifeless | the former seems genuinely useful though | 01:06 |
| igc | lifeless: I'm not changing the former, just generalising the latter so that anything starting with .bzr is not exported | 01:07 |
| lifeless | igc: yes, I saw the patch. | 01:08 |
| jelmer | spiv: --rich-root is not an alias at the moment, were you assuming it was? | 01:09 |
| spiv | jelmer: | 01:10 |
| spiv | $ bzr init --help | grep -A1 -- "--rich-root " | 01:10 |
| spiv | --rich-root New in 1.0. Better handling of tree roots. | 01:10 |
| spiv | Incompatible with bzr < 1.0 | 01:10 |
| mwhudson | beuno: awake? | 01:11 |
| spiv | jelmer: so I wasn't just assuming, I checked :) | 01:11 |
| jelmer | spiv: that's not an alias, it's a knits-based format | 01:12 |
| spiv | Ah :( | 01:12 |
| jelmer | it may be a good idea to get rid of it though, in favour of an alias... | 01:14 |
| spiv | jelmer: thanks for noticing my mistake | 01:17 |
| beuno | mwhudson, yeap, evening' | 01:26 |
| beuno | just got home | 01:27 |
| lifeless | hi | 01:27 |
| mwhudson | beuno: hi, thanks for fixing loggerhead :) | 01:27 |
| beuno | mwhudson, I felt a bit responsible :) | 01:28 |
| mwhudson | beuno: so i am a little confused though | 01:28 |
| mwhudson | beuno: will the loggerhead we're running break with current bzr.dev ? | 01:29 |
| beuno | mwhudson, no, it works with bzr.dev | 01:31 |
| beuno | a few commits after b2 | 01:32 |
| mwhudson | beuno: good | 01:32 |
| beuno | when lifeless's enourmous patch landed it broke | 01:32 |
| mwhudson | so why did this method change? | 01:32 |
| mwhudson | oh right | 01:32 |
| mwhudson | then bzr.dev became more compatible again? | 01:32 |
| beuno | "versioned files" and the likes | 01:32 |
| beuno | compatible relative to what? :) | 01:33 |
| mwhudson | well | 01:33 |
| beuno | one of the things I was thinking of, is having that part patched in LH for a few versions, where it tried both methods | 01:33 |
| mwhudson | wasn't the patch you gave kiko reverting the change that was made to this method? | 01:33 |
| * mwhudson attempts to make sense | 01:34 | |
| mwhudson | the loggerhead we're running does this: | 01:34 |
| mwhudson | w = self._branch.repository.weave_store.get_weave(file_id, self._branch.repository.get_transaction()) | 01:34 |
| mwhudson | rather than existing_keys = self._branch.repository.texts.get_parent_map(possible_keys) | 01:34 |
| beuno | mwhudson, yes, because you're running b2 in code host | 01:34 |
| lifeless | mwhudson: the former won't work in b3 and abot | 01:35 |
| mwhudson | because .texts doesn't work with b2 | 01:35 |
| beuno | and it works from b3+ | 01:35 |
| mwhudson | <mwhudson> beuno: will the loggerhead we're running break with current bzr.dev ? | 01:35 |
| mwhudson | <beuno> mwhudson, no, it works with bzr.dev | 01:35 |
| beuno | mwhudson, ah, my mistake | 01:35 |
| beuno | it will | 01:35 |
| mwhudson | is this actually what you meant to say? | 01:35 |
| beuno | I warned matsubara | 01:35 |
| beuno | that it would | 01:35 |
| mwhudson | ah, ok | 01:35 |
| beuno | I misunderstood | 01:35 |
| beuno | I just bought a Wii and got distracted :) | 01:36 |
| mwhudson | ok, so this isn't ideal but at least i understand what's going on now :) | 01:36 |
| beuno | yeah, I offered to put together a patch that would probe one, and go to the other if it failed | 01:37 |
| beuno | but they chose reverting | 01:37 |
| mwhudson | okidoke | 01:37 |
| beuno | I still think it makes sense to do that for trunk | 01:38 |
| beuno | so we can be compatible with older bzr versions | 01:38 |
| mwhudson | yeah i guess so | 01:40 |
| * beuno is off to dinner | 01:43 | |
| tsculpt | anybody have trouble saving commit message with emacs as editor? | 02:00 |
| tsculpt | I get: vc-bzr-registered: IO error reading c:/bzrfun/home/main/.bzr/checkout/dirstate: Permission Denied, when tring to save | 02:01 |
| tsculpt | bzr 1.5 | 02:02 |
| lifeless | tsculpt: bzr will have an exlusive lock on the dirstate file | 02:04 |
| lifeless | tsculpt: sounds like some emacs thing is trying to read that file directly (not such a great idea btw :P) | 02:04 |
| tsculpt | well, just trying to use emacs as commit editor | 02:05 |
| tsculpt | bzr commit | 02:05 |
| tsculpt | emacs comes up with the modified listing | 02:06 |
| tsculpt | I write my message, and try to save, and I get the error. | 02:06 |
| tsculpt | The vc-bzr-registered part makes me think emacs is doing something with it's built in vcs stuff? | 02:07 |
| tsculpt | ah, I notice it loads vc-bzr | 02:10 |
| markh | hrmph - "bzr help commands" will list 94 commands by default on Windows!! | 02:36 |
| * igc lunch | 02:50 | |
| lifeless | igc: ping | 05:20 |
| igc | hi lifeless | 05:20 |
| lifeless | I'd like to chat about .bzrrules some | 05:20 |
| igc | fire away | 05:20 |
| lifeless | if you're up for it I could give you a ring | 05:20 |
| lifeless | or else drop you a mail | 05:21 |
| lifeless | or IRC works for me too | 05:21 |
| igc | email might be best today | 05:21 |
| lifeless | k | 05:21 |
| lifeless | I will drop some thoughts to you directly | 05:22 |
| igc | sure | 05:22 |
| gambler | I read that limbo post from http://bazaar-vcs.org/BzrVsGit and I realised thats a big problem for me | 07:01 |
| gambler | has anything been done about it in bzr? | 07:01 |
| luks | what is a big problem for you? | 07:02 |
| bob2 | which part? | 07:03 |
| bob2 | you can alias 'commit' to 'commit --strict' if you don't want to forget to commit new files | 07:03 |
| gambler | the files that remain in limbo...those in a directory that aren't explicitly added to the repo to track | 07:03 |
| gambler | bob2, yeah but i prefer to automate alot of that | 07:03 |
| bob2 | as in you want bzr to run 'bzr add .' before every commit? | 07:04 |
| gambler | i suppose | 07:04 |
| gambler | would that work? | 07:05 |
| gambler | <-- not a current bzrer | 07:05 |
| RAOF | gambler: That would work, but is probably not a good idea. | 07:11 |
| RAOF | gambler: | 07:11 |
| RAOF | gambler: In particular it would mean that you wouldn't want to build in your working tree, since subsequent commits would then add the results of the build (plus random autotools files, etc). | 07:12 |
| luks | you can `bzr ignore` those | 07:12 |
| bob2 | well, you would ignore that .o configure.ac etc | 07:12 |
| RAOF | bzr doesn't do globbing in .bzrignore, right? | 07:13 |
| bob2 | it does | 07:13 |
| luks | it supports full filenames, globbing and regexes | 07:14 |
| bob2 | it optionally does res | 07:14 |
| RAOF | Of course; my shell's being too smart for its own good. | 07:14 |
| gambler | so bzr add . bzr ignore *.class for my android project and I get automatic adds? | 07:14 |
| bob2 | no | 07:15 |
| luks | gambler: commit --strict is really a better idea | 07:15 |
| luks | automating things is nice and all that, but some things are better to review | 07:16 |
| bob2 | hey, you'll get a chance to review in the commit editor ;) | 07:16 |
| luks | that's way too late, IMO :) | 07:17 |
| gambler | luks: thats how it starts...then why dont I write some unit tests, and X and Y and Z....and my productivity drops like a rock | 07:17 |
| spiv | If you do bzr alias commit="commit --strict" then bzr will automatically tell you if there are new files you haven't added or ignored yet. | 07:17 |
| gambler | ok..maybe ill try that | 07:18 |
| spiv | At which point you can decide what to do about them, and get on with work. That satisfies the criterion for "automated" pretty well for me :) | 07:18 |
| gambler | meh, the problem with all VCS is that it would be nice if all their interfaces were pure method calls, then I could design my workflow around them instead of the other way | 07:19 |
| gambler | I could script but then you run into problems making it robust | 07:19 |
| gambler | i script now | 07:19 |
| spiv | More automatic would probably mean automatically guessing what to do with individual files, which wouldn't make me comfortable. I can imagine that working fine for some people, though. | 07:19 |
| spiv | Well, bzr is completely scriptable in Python. | 07:20 |
| gambler | hmmm good point | 07:20 |
| spiv | It's even pretty easy to write a plugin to add new commands or extend existing ones. | 07:20 |
| gambler | im looking at bzrlib now...but im not really a python dude | 07:25 |
| Ryan52 | Is there any way to go through a projects history and change my name everywhere? Right now it's just <email>, but I want it to be 'Name <email>'. | 07:35 |
| Jc2k | beuno: i hit a bug so i reverted | 07:36 |
| Jc2k | beuno: its not finding css/imagery again.. | 07:36 |
| luks | Ryan52: no, revisions are immutable | 07:37 |
| luks | Ryan52: something like that would need to create a completely new branch with different revision IDs | 07:38 |
| * Ryan52 thinks he would get in trouble for doing that :) | 07:38 | |
| Ryan52 | okay, thanks. | 07:38 |
| gambler | meh too much work | 07:42 |
| gambler | what is the status of the bzr plugin for eclipse...anyone here using it? | 07:42 |
| lifeless | it works quite well | 07:42 |
| lifeless | Verterok: is the main developer | 07:43 |
| Verterok | gambler: I'm about to release a new build (with bunch of improvements) | 07:43 |
| gambler | Verterok, will it mind my adding and deleting of files? | 07:44 |
| Verterok | gambler: it handle moves/deletes/renames | 07:45 |
| Verterok | gambler: but the delete is equivalent to 'bzr rm --keep' (to avoid removing non-recoverable files) | 07:46 |
| luks | (all files deleted by `bzr rm` are recoverable) | 07:47 |
| lifeless | yay firefoxfail | 07:49 |
| gambler | if you could add in auto-adding of files that would be pure sex | 07:49 |
| Verterok | luks: but if you have added (not yet committed) bzr rm --force delete them in a non-recoberable way :) | 07:51 |
| luks | ugh | 07:51 |
| luks | but why --force? | 07:52 |
| lifeless | I'm not entirely happy with rm today | 07:52 |
| lifeless | the basic tension is that unversion and rm are different operations | 07:53 |
| lifeless | but we only have one command, because people usually want both operations to be undertaken | 07:53 |
| Verterok | gambler: I don't fully understands the "auto-adding" thing :P | 07:53 |
| luks | I don't think rm should be handled by a VCS | 07:53 |
| luks | the old behavior (rm --keep) was my favorite | 07:54 |
| gambler | Verterok, auto-add any newly created files in the root directory, unless they are in the bzr ignore list. | 07:54 |
| gambler | Verterok, for renames....improvise :) | 07:55 |
| * fullermd has rm aliased to rm --keep. | 07:55 | |
| gambler | Verterok, actually you can tie into Eclipse->Refactor-Rename | 07:55 |
| luks | yeah, me too | 07:55 |
| Verterok | gambler: mmm, there was a bug/feature request some time ago (java specific), about auto-adding newly reated classes. | 07:56 |
| gambler | and? | 07:56 |
| Verterok | gambler: if I can provide an option so it can be enabled/disable, I'll be glad to add this feature | 07:56 |
| Verterok | but I don't want that behaviour as default | 07:57 |
| Verterok | gambler: renames are handled by the plugin | 07:57 |
| Verterok | :) | 07:57 |
| gambler | i will love you forever | 07:57 |
| gambler | cant wait to try it. i am an insane refactorer and I need that | 07:58 |
| Verterok | Verterok: if you find any glitches (or missing feature), please fill a bug so I can track and plan the features for the next milestone :) | 08:00 |
| Verterok | s/Verterok/gambler/ :P | 08:00 |
| gambler | np..when will you release your next version | 08:02 |
| Verterok | gambler: if all keep going as planned, in ~ 20hs :) | 08:03 |
| * Verterok need to sleep a few hours | 08:03 | |
| gambler | ok...no rush. i've written myself a note to download it | 08:04 |
| Verterok | I just finished a build from trunk, and testing it ATM | 08:04 |
| === RAOF is now known as ROAF | ||
| Verterok | all for today, seeya later | 08:15 |
| * Verterok heads to bed | 08:15 | |
| gambler | c u | 08:16 |
| * igc dinner | 08:31 | |
| === ROAF is now known as RAOF | ||
| cjwatson | igc: hmm, so having said that I had a really good import (an svn branch for a Debian package which I'm gluing onto the side of the existing bzr branch for upstream) with bzr-fastimport, I realised that all my file-ids are screwed | 10:25 |
| cjwatson | igc: is there any way to get fast-import to say "this commit has 'from' or 'merge', therefore all files added in this revision should take their file-ids from that other branch"? | 10:26 |
| igc | cjwatson: hi, I can't stay and chat sorry but a few things ... | 10:35 |
| igc | how did you generate the stream? By hand? | 10:36 |
| cjwatson | igc: slightly hacked version of svn-fast-export.py | 10:36 |
| igc | See the spec. You can certainly say 'get the file-ids' from another branch *assuminh* that branch is also in the stream already | 10:36 |
| cjwatson | (I stuck in a dictionary of commit identifiers to marks that I wanted to be merged) | 10:36 |
| cjwatson | hmm, did I miss it? I thought I looked | 10:37 |
| cjwatson | the other branch is not in the import stream; I'm referencing it by means of import-marks | 10:37 |
| james_w | fast-import won't look at the those revisions, it will just add the extra parents you request. | 10:38 |
| james_w | I believe we could extend fast-import to optionally look for them and import the file-ids. | 10:38 |
| igc | cjwatson: spec is http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html | 10:38 |
| cjwatson | yeah, I'm reading that | 10:39 |
| james_w | hi igc | 10:39 |
| igc | hi james_w | 10:39 |
| cjwatson | it seems to have a way to reference existing content from elsewhere, but not existing file-ids | 10:39 |
| igc | cjwatson: so I won't be around but james_w knows the fastimport code pretty well and it's pretty hackable imo | 10:40 |
| cjwatson | yeah, I certainly don't mind hacking it (and already have done), but wanted to know if this was in place already | 10:40 |
| cjwatson | if it's not, I can always beat it up until it is | 10:40 |
| cjwatson | it does seem like it's what you'd want to be the default behaviour when 'merge' commands are present in the stream though | 10:41 |
| james_w | cjwatson: for a quick hack, around line 513 of processors/generic_processor.py could be extended to also look at all the revision ids listed in the marks | 10:42 |
| james_w | _gen_file_ids_cache | 10:43 |
| cjwatson | hmm, right, might have to do something interesting in the case where you have file added in svn branch, then deleted and copied-over-the-top | 10:44 |
| cjwatson | since then there'll be multiple file-ids to choose from for a given path | 10:44 |
| james_w | yeah, the cache should actually be replaced with something else as I understand it | 10:44 |
| lifeless | personally; I'd just let bzr do all the heavy lifting | 10:45 |
| james_w | however, I think the replacement would actually be harder for you to hack to get what you want | 10:45 |
| james_w | hey lifeless | 10:45 |
| lifeless | but apparently there were performance implications in doing that | 10:45 |
| cjwatson | I have the feeling I want to special-case it at the cache user end, since I only want this check in the cases of certain commits | 10:45 |
| james_w | bzr_file_id_and_new | 10:46 |
| cjwatson | like bzr_file_id_and_new(self, path, sourcerev=None) | 10:46 |
| cjwatson | snap :) | 10:46 |
| nazgjunk | hi, do ignore files stack? I seem to have a global ignore file somewhere, can I assume that it'll still be checked when I add one to the branch I'm working in? | 10:49 |
| james_w | nazgjunk: ~/.bazaar/ignore, and yes | 10:49 |
| nazgjunk | thanks | 10:50 |
| lifeless | right | 10:57 |
| lifeless | bug fixed | 10:57 |
| lifeless | -> off | 10:57 |
| Jc2k | ahh that reminds me | 10:59 |
| * Jc2k goes to read gnome-bzr log | 10:59 | |
| === thekorn is now known as thekorn_ | ||
| === abentley1 is now known as abentley | ||
| === is_null_ is now known as is_null | ||
| lifeless | igc: got busy on a bug; I'll try to mail you tomorrow; or perhaps voice would work better then; something | 12:46 |
| lifeless | gnight all | 12:46 |
| igc | sure lifeless; night | 12:46 |
| === mars is now known as Guest65430 | ||
| === vednis is now known as mars | ||
| pfctdayelise | hi, I'm trying to use bzr on a shared webhost. 'python' -> 2.3.4, which has the bz2 module, but there is also 'python2.4' which does not. | 15:47 |
| pfctdayelise | can I get bzr to use python 2.3? or should i try to install the bz2 module? | 15:47 |
| dennda | Hi. How can I fix this? http://paste.pocoo.org/show/80707/ | 15:48 |
| dennda | Doesn't work with bzr push lp:~dennda/memaker/experimental either | 15:48 |
| dato | pfctdayelise: bzr will definitely not work with python 2.3 | 15:48 |
| andrea-bs | dennda: bzr launchpad-login "your-launchpad-id" | 15:49 |
| luks | dennda: bzr launchpad-login <your-username> | 15:49 |
| luks | or just use a ssh+bzr url directly | 15:50 |
| luks | bzr+ssh I mean | 15:50 |
| mlh | I suppose people have read http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation | 15:53 |
| mlh | ? haskell is moving away from darcs - interesting discussion of git vs hg vs bzr | 15:53 |
| jelmer | mlh, that page only lists git and mercurial as serious contenders | 15:55 |
| jelmer | do you know why that is? | 15:56 |
| luks | weird how 'Cherry-picking isn't very "native" to the data model' is a disadvantage of bzr, but not hg and git | 15:57 |
| mlh | jelmer: that's what one line says, but the rest of the page seems to contradict it | 16:04 |
| mlh | so .. not clear | 16:04 |
| * mlh sleeps | 16:05 | |
| gour | have you seen http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation ? | 16:10 |
| gour | new potential customer... | 16:11 |
| james_w | heh :-) | 16:12 |
| gour | ghc is not so small project and has (potential) influence on the whole haskell community | 16:14 |
| arnarl | what are the commands for resetting/changing related branches (as listed in bzr info) | 16:15 |
| arnarl | is it only available in locations.conf? | 16:17 |
| james_w | arnarl: you can either edit ~/.bazaar/locations.conf, or you can use --remember on the appropriate commands | 16:17 |
| james_w | so "pull --remember" will change the parent branch, "merge --remember" will change the submit branch | 16:18 |
| arnarl | james_w: thnx! :-) | 16:18 |
| jam | chadmiller: Ping, would you like to discuss the new issue privately? | 17:21 |
| chadmiller | Sure. | 17:21 |
| beuno | jelmer, around? | 18:59 |
| evanton | hello, how can one force bzr to make a file executable? | 19:27 |
| luks | chmod a+x file | 19:28 |
| evanton | luks: let me explain | 19:28 |
| evanton | I have to assume somebody submits a text file containing a python script from windows | 19:28 |
| evanton | when I check out the branch, that file has 644 permission | 19:29 |
| evanton | I would like it to have 755 instead, so there must be probably a way to tell bzr that it shall set certain permissions during a commit | 19:30 |
| luks | evanton: on windows it's more complicated, since bzr itself doesn't support it | 19:30 |
| luks | there is a plugin that can be used to swith the executable flag on windows | 19:30 |
| luks | https://launchpad.net/bzr-x-bit | 19:31 |
| evanton | do you think that chmodding the file in linux and commiting it into the branch from there instead would work? | 19:31 |
| luks | evanton: of course | 19:31 |
| evanton | thank you | 19:32 |
| rexbron | hey would any of the bzr-svn guys be able to look at bug 253376 | 19:51 |
| ubottu | Launchpad bug 253376 in bzr-svn "Crash when network goes down during a checkout" [Undecided,New] https://launchpad.net/bugs/253376 | 19:51 |
| jelmer | rexbron: just replied | 19:57 |
| rexbron | jelmer: As I mentioned, if you remove the dir your checking into and re-run the command, it will pick up where it left off. So it's not that serious. Perhaps it is worth a mention on the bzr-svn known issues section | 19:59 |
| jelmer | rexbron, I think it's worth mentioning, but rather in the bzr docs than in bzr-svn since neither the bug nor the workaround are specific to bzr-svn. | 20:06 |
| rexbron | ok | 20:06 |
| beuno | jelmer, I'm working on a branch to fix loggerhead's setup, can you take a look at it and see if you need anything changed for Debian? | 20:32 |
| beuno | lp:~beuno/loggerhead/fix_setup | 20:33 |
| jelmer | beuno, sure, give me a few minutes | 20:34 |
| beuno | jelmer, thanks :) | 20:34 |
| theuiguy | Is there any kind of plugin for bzr that allows you to modify history? Specifically, to change email/names of committers? | 21:29 |
| theuiguy | Or perhaps some way to modify check in dates? | 21:29 |
| NfNitLoop | theuiguy: not to my knowledge... modifying history is not really possible in a distributed system. | 21:30 |
| NfNitLoop | You could modify *your* history, but then you don't sync up w/ everyone else. | 21:30 |
| NfNitLoop | which could cause problems. | 21:30 |
| theuiguy | NfNitLoop: I see your point... in this particular case, there's only one branch right now | 21:30 |
| NfNitLoop | ah. Well then you could in theory do it, but my guess is that nobody has bothered to write/distribute code to do so for the above reasons. | 21:31 |
| james_w | theuiguy: there's nothing specifically for it | 21:32 |
| james_w | there's two things which could, but don't yet, bzr-rebase and fast-export/fast-import | 21:32 |
| theuiguy | How about a plugin to merge commits? | 21:32 |
| james_w | that would probably be the same tool | 21:33 |
| theuiguy | james_w: I was thinking bzr-rebase might do something like it, but I thought you needed to do it before your commit | 21:33 |
| james_w | interactive rebase can do the latter, I don't know if that's available yet though | 21:34 |
| theuiguy | Perhaps you could give me an alternative solution -- I'm told I can open source some code, but need to scrub email addresses that expose internal server names. | 21:36 |
| theuiguy | It already in bzr, with a relatively short revision history -- I think around 25 revisions. | 21:36 |
| theuiguy | I suppose I could just create a new branch with the latest code and go from there, but it's a shame to lose the history | 21:37 |
| james_w | theuiguy: ok, to change that I would suggest bzr-fast-export and bzr-fastimport. | 21:39 |
| james_w | you can export to a text file, sed the file to clean up the names as you wish, and then import again | 21:39 |
| james_w | it should work nicely | 21:39 |
| james_w | but the new branch will have absolutely no relation to the old one in bzr's eyes | 21:40 |
| james_w | it sounds like that shouldn't be a problem for you though | 21:40 |
| theuiguy | james_w: no, that sounds like it would work... just cleaning up the email addresses would be great. | 21:41 |
| theuiguy | Thanks! | 21:41 |
| mathiaz | Hi - I'm using the loom plugin to manage one my packaging branch. The HOWTO outlines how-to combine a thread (case where the code has been merged upstream), but I don't get how to delete a thread (the code is no longer relevant because upstream fixed it differently). How do I delete a thread ? | 21:54 |
| james_w | hey mathiaz | 21:55 |
| mathiaz | If I try to combine a thread, it still shows up in the thread above | 21:55 |
| mathiaz | james_w: Hi ! :) | 21:55 |
| james_w | I believe that's the same thing | 21:55 |
| james_w | you mean the code that you want to get rid of is still in the thread above? | 21:56 |
| mathiaz | james_w: I'm working on an openldap merge and the debian maintainer fixed a bug using a different patch | 21:56 |
| mathiaz | james_w: yes | 21:56 |
| lifeless | mathiaz: you un merge it | 21:56 |
| lifeless | mathiaz: go to the thread above and do bzr merge -r -1..thread: | 21:56 |
| lifeless | erm no | 21:56 |
| lifeless | go to the thread you want to cancel | 21:56 |
| lifeless | then do that | 21:56 |
| mathiaz | lifeless: ok - good to know for the next time. As of now, I've already combine the thread | 21:57 |
| mathiaz | lifeless: so I guess I'll have to fix it manually | 21:57 |
| james_w | you can resurrect the thread I assume | 21:58 |
| james_w | hey lifeless | 21:58 |
| mathiaz | also pushing the branch to LP doesn't work | 21:58 |
| === davi_ is now known as davi | ||
| mathiaz | I get the following message: http://paste.ubuntu.com/32335/ | 21:59 |
| lifeless | hi james_w | 21:59 |
| james_w | mathiaz: I think that's fixed if you update your loom plugin to a newer version | 22:00 |
| mathiaz | james_w: I just did that | 22:00 |
| mathiaz | james_w: that's when I started to see that message | 22:00 |
| mathiaz | I'm at revision 86 for the loom pluging | 22:02 |
| chadmiller | Hi all. A bzr user in my group complains that "annotate" is much slower in 1.6b4 than in 1.5. For his example file it goes from 19 sec to 645 sec. | 22:05 |
| AmanicA | which branch format? | 22:05 |
| AmanicA | (bzr info) | 22:05 |
| lifeless | ah damn I knew I'd forgotten something; get_matching_blocks acceleration | 22:10 |
| lifeless | chadmiller: I'll whip up a patch today | 22:10 |
| chadmiller | lifeless: Cool. Thanks! | 22:10 |
| rexbron | hey jelmer, I have a new problem related to the bug you looked at earlier | 22:11 |
| lifeless | chadmiller: make sure he is running with the C extensions though | 22:11 |
| lifeless | chadmiller: that will still matter even after my patch | 22:12 |
| chadmiller | Okay. I will. | 22:12 |
| mwhudson | mornings | 22:14 |
| beuno | goooooooood mornin' mwhudson | 22:14 |
| thumper | beuno: morning | 22:15 |
| thumper | beuno: I've been trying to marry the gnome-loggerhead with the new trunk | 22:15 |
| beuno | hey thumper | 22:15 |
| beuno | oh, cool, I was going to ping you about that | 22:15 |
| thumper | beuno: with limited success | 22:15 |
| cszikszoy | does anyone know what this error means: bzr: ERROR: Invalid url supplied to transport: "Host empty in: http://:8080/" | 22:16 |
| beuno | thumper, that's odd | 22:16 |
| thumper | beuno: I might push what I have and get you to look where it's screwing up | 22:16 |
| thumper | beuno: we have mixed css | 22:16 |
| cszikszoy | or possibly how to fix it? | 22:16 |
| beuno | thumper, have you changes anything to it, or is it what I originally pushed? | 22:16 |
| thumper | beuno: and I was trying to fit some loggerhead tabs into the gnome tab area | 22:17 |
| james_w | cszikszoy: hi, what command did you run to get that error? | 22:17 |
| thumper | beuno: there are changes | 22:17 |
| thumper | beuno: but fairly limited | 22:17 |
| beuno | thumper, ah, ok. If you can push or give me access to, I can resolve and re-push | 22:17 |
| cszikszoy | bzr branch lp:do-plugins | 22:17 |
| james_w | mathiaz: how are you finding using loom for packaging? | 22:18 |
| thumper | beuno: I'll actually spend some time writing up what has changed as ISTR there was some heading hackery | 22:18 |
| james_w | cszikszoy: oh, that's odd | 22:18 |
| thumper | beuno: so you might get something in the next 8 hours | 22:18 |
| thumper | beuno: but not too soon | 22:18 |
| lifeless | cszikszoy: thats very strange | 22:19 |
| mathiaz | james_w: well - up to now, I think it's ok - I classify it as yet-another-patch-system - but I like the merge help | 22:19 |
| cszikszoy | i thought so too :) | 22:19 |
| lifeless | cszikszoy: it means there is no hosy | 22:19 |
| lifeless | *host* | 22:19 |
| mathiaz | james_w: there are still some rough edges (such as unable to push to lp) | 22:19 |
| beuno | thumper, cool. Another thing you may want to try, is start from the gnome branch I pushed with the new theme, and merge into that one | 22:19 |
| mathiaz | james_w: and I've just figured out how to delete a patch rather than combine it | 22:19 |
| james_w | mathiaz: that's true, I guess it is another patch system, but hopefully a better one. | 22:20 |
| mathiaz | james_w: hopefully there will such a command added to the loom plugin soon | 22:20 |
| * thumper nods to what beuno says | 22:20 | |
| frej | hmm, i'm having problems with converting a cvs repo (cvsps) with filenames in latin1 encoding :/ | 22:20 |
| james_w | mathiaz: would you file a bug for that command? | 22:20 |
| mathiaz | james_w: it seems that the difference comes with the merging support | 22:20 |
| frej | is this supported in any wya? | 22:20 |
| james_w | mathiaz: also, "bzr -Derror push" would be useful to find out why you can't push. | 22:20 |
| lifeless | cszikszoy: cszikszoy it works for me | 22:20 |
| lifeless | cszikszoy: could you file a bug please, with a transcript? file it on launchpad-bazaar | 22:21 |
| mathiaz | james_w: there aren't many patch system that come with a proper merge support | 22:21 |
| beuno | sounds like a proxy tweaking things, doesn't it? 8080 port seems fishy | 22:22 |
| cszikszoy | i'm not behind any proxy that I know of | 22:22 |
| cszikszoy | unless my isp blocks it | 22:22 |
| cszikszoy | i'm in Germany, if it somehow matters | 22:22 |
| cszikszoy | but i didn't think that it would | 22:22 |
| james_w | mathiaz: yeah, hopefully it's a killer feature | 22:23 |
| cszikszoy | i'll file a bug report, as for a transcript, what would be helpful to include? | 22:26 |
| beuno | cszikszoy, can you re-run the command, and add -Dhpss | 22:27 |
| beuno | then, file the bug, attaching your ~/.bzr.log file | 22:27 |
| cszikszoy | will do, thanks | 22:30 |
| === Toksyuryel` is now known as Toksyuryel | ||
| cszikszoy | n | 22:40 |
| lifeless | I swear | 22:42 |
| lifeless | time to update my fail filters | 22:42 |
| jelmer | lifeless: 'morning | 22:45 |
| lifeless | hi jelmer | 22:46 |
| jelmer | lifeless: wrt backslashes - bzr will error out when trying to add a file with a backslash in the name | 22:46 |
| lifeless | yes | 22:46 |
| lifeless | this is deliberate | 22:46 |
| lifeless | we also error on 0x01 | 22:46 |
| lifeless | and many other characters | 22:47 |
| jelmer | you mention encoding - what sort of encoding? | 22:47 |
| jelmer | (bug 81844) | 22:47 |
| lifeless | you could urlescape it | 22:47 |
| lifeless | (for instance) | 22:47 |
| ubottu | Launchpad bug 81844 in bzr-svn "Handle backslashes in filenames more gracefully" [Low,Invalid] https://launchpad.net/bugs/81844 | 22:48 |
| jelmer | lifeless: that means an opportunity for paths to clash | 22:48 |
| jelmer | also, it means having to determine which paths were meant to be escaped when pushing back into svn | 22:49 |
| jelmer | bzr-svn currently just checks for backslashes and raises an exception if it encounters them | 22:49 |
| jelmer | which works pretty well, except that there are a few rare repositories out there that contain backslashes (the lintian one, for example) | 22:49 |
| jelmer | lifeless: is there any reason to not support \ other than the fact it means it won't be possible to create a working tree on Windows? | 22:54 |
| lifeless | so there are two groups of characters that we don't support: Those easy to support but undesirable; and those hard to support | 22:55 |
| lifeless | things that won't go into xml cleanly, or are separate characters for our disk formats makeup thelatter group | 22:55 |
| lifeless | For the former group, its mainly that they aren't really consistent with bring a sccs | 22:56 |
| lifeless | they're more 'be a unix file system' | 22:56 |
| lifeless | dunno | 22:57 |
| lifeless | I don't really have a strong opinion | 22:57 |
| james_w | http://technomancy.us/113 | 22:59 |
| lifeless | cool | 23:01 |
| === cody-somerville_ is now known as cody-somerville | ||
| lifeless | jelmer: does the file id limit matter to you as well ( the \\ is banned in ids because it would break on windows with early stores) | 23:05 |
| jelmer | lifeless: no, file ids are generated using a checksum if they contain certain characters or exceed a certain limit | 23:07 |
| lifeless | ok | 23:08 |
| jelmer | lifeless: the only two characters in filenames I'm aware of that are problematic when importing from svn are \ and newline | 23:09 |
| === oleavr____ is now known as oleavr_ | ||
| lifeless | jml: bit strange to close 124570 if I can't actually use it yet... | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!