| * SamB wishes bzr-gtk packages could depend on bzr in a way that reflected the API version they require from it | 00:01 | |
| SamB | ... I think they could do a bit better than "bzr (>= 1.12~)", though | 00:02 |
|---|---|---|
| Peng_ | beuno: Upgrading your branches of Loggerhead to 2a, or just other stuff? | 00:05 |
| glyph | jml: erm | 00:09 |
| glyph | jml: I think maybe there's a problem with the latest release | 00:09 |
| glyph | http://codepad.org/lxIt1U1g | 00:09 |
| glyph | oh | 00:09 |
| glyph | whoops, is this exactly what SamB is talking about? | 00:09 |
| SamB | glyph: say ... what ? | 00:10 |
| * SamB looks | 00:10 | |
| SamB | glyph: oh, not exactly | 00:11 |
| SamB | I did get that one a few days back though, I think | 00:11 |
| SamB | so I guess it's probably just that my bzr knows it doesn't provide that version of the API and yours doesn't know? | 00:12 |
| * SamB wonders why python-dulwich wants to reinstall Python 2.4 for him :-( | 00:13 | |
| rellis__ | Is there a convenient way to have bzr execute an arbitrary shell command after a commit to a given project/branch? | 00:17 |
| SamB | rellis__: there's some shell-hook plugin | 00:20 |
| SamB | see the plugins page on the wiki | 00:21 |
| SamB | should be listed there | 00:21 |
| rellis__ | nice | 00:21 |
| rellis__ | thanks much sir | 00:21 |
| SamB | you're welcome | 00:22 |
| SamB | I don't have a clue why that's not integrated with bzr ... | 00:22 |
| Peng_ | Propose it for merging in bzr 2.0! :D | 00:24 |
| rellis__ | So bzr plugins i.e. shell-hooks run on developer machines not my bzr server right? | 00:24 |
| rellis__ | i should say they run wherever the bzr command itseld is executed | 00:25 |
| SamB | rellis__: well, unless you install the plugin on the server and the plugin provides hooks of a kind that would get run as part of the smart-commit process | 00:25 |
| rellis__ | hmmm | 00:26 |
| rellis__ | im trying to integrat hudson with bzr | 00:26 |
| rellis__ | and the hudson bazaar plugin doesnt work with hudson slaves | 00:27 |
| SamB | hmm ? | 00:27 |
| rellis__ | so i need a different mechanism to launch builds after commit | 00:27 |
| * SamB wishes jelmer were about so he could complain about this python2.4 dependancy on the python-dulwich package | 00:30 | |
| resolve | hi folks. i'm new to bzr, and I just pushed a branch to lp, commited a change, and pushed again, and I end up with a "stacking branch" | 00:30 |
| resolve | which appears as a separate entry in launchpad. I just wanted to push my latest changes. is push the wrong command? | 00:30 |
| * SamB remembers he can file debbugs even if he knows where the maintainer hangs out on IRC ... | 00:30 | |
| SamB | resolve: did you push to a different name the second time ? | 00:31 |
| resolve | ah. what happened is my first push was to name x, but I made a typo so deleted and specified name y | 00:31 |
| resolve | i thought it would remember name y but it remembers name x | 00:32 |
| SamB | resolve: bzr push --remember y | 00:32 |
| resolve | thanks. all good now. | 00:34 |
| beuno | lifeless, Peng_, other stuff. Branches from the office | 00:37 |
| beuno | all cleared by jam now | 00:38 |
| Peng_ | I kind of want to upgrade my Loggerhead repo to 2a, just for "fun", but I can't since I have a corrupt revision. :D | 00:39 |
| beuno | I think we should upgrade to 2a | 00:45 |
| beuno | it should be easy since we're in rich-root already | 00:45 |
| Peng_ | LH itself is still compatible with bzr 1.13. The 2a format isn't. :D | 00:50 |
| Peng_ | Eh. I'm just reluctant to upgrade because I'd have to move to a new repo. | 00:51 |
| lifeless | beuno: you should be able to locally | 00:52 |
| lifeless | beuno: just init a new 2a repo and branch in any lh branches you want | 00:55 |
| bignose | I'm attempting to migrate a CVS repository to Bazaar | 00:55 |
| bignose | (a particular branch in that repository, anyway) | 00:55 |
| bignose | I've used cvs2git (from the cvs2svn project) to create two separate files | 00:56 |
| bignose | a dump file and a blob file | 00:56 |
| bignose | what do I need to use to import those into a Bazaar branch? | 00:57 |
| lifeless | bzr-fast-import | 00:57 |
| lifeless | thought IIRC it wants inline format | 00:57 |
| bignose | ‘bzr fast-import foo.fi-blob’ succeeds but says there are no revisions | 00:57 |
| bignose | ‘bzr fast-import foo.fi-dump’ crashes with a traceback | 00:58 |
| bignose | neither of them seems to create any branch | 00:58 |
| beuno | lifeless, right. Maybe I should just do that. | 00:58 |
| beuno | now, if only bzr moved to 2a as well | 00:58 |
| beuno | I could have a shared repo again in the bzr-devel dir :) | 00:58 |
| wgrant | How's the Launchpad 2a trial going? | 00:59 |
| bignose | ah! on the cvs2git web page it suggests the two can simply be catted together and fed to git as a stream. should that work too for bzr fast-import ? | 00:59 |
| beuno | wgrant, much better than expected, although there are some stacking bugs that still need ironing out | 01:00 |
| beuno | it's amazing how much faster it is | 01:00 |
| lifeless | bignose: I guess :) | 01:00 |
| bignose | cat foo.fi-{blob,dump} | bzr fast-import - | 01:01 |
| bignose | that worked fine | 01:01 |
| wgrant | beuno: I guess you have many tens of thousands of revisions? | 01:02 |
| bignose | maybe someone could look at <URL:http://cvs2svn.tigris.org/cvs2git.html> and update <URL:http://bazaar-vcs.org/BzrFastImport> to connect the two | 01:02 |
| bignose | (someone with an accounton the wiki, that is.) | 01:02 |
| beuno | wgrant, I think it's around 60k | 01:07 |
| bignose | the help for merge says: | 01:12 |
| bignose | By default, bzr will try to merge in all new work from the other | 01:12 |
| bignose | branch, automatically determining an appropriate base. If this | 01:12 |
| bignose | fails, you may need to give an explicit base. | 01:12 |
| bignose | but doesn't say how to "give an explicit base" | 01:13 |
| bignose | any clues? | 01:13 |
| james_w | -r | 01:19 |
| james_w | "-r 7" will merge in just up to revision 7, "-r 7.." will use 7 as a base, "-r 4..7" will cherry-pick | 01:20 |
| bignose | okay. and those revision numbers are for the other branch, yes? | 01:21 |
| james_w | correct | 01:21 |
| bignose | hmm. okay, it seems I need to hack a bit. | 01:23 |
| bignose | I originally grabbed a source tarball, imported those files into a new branch, and committed revision data from that point on | 01:23 |
| bignose | subsequently, I have gained access to the upstream CVS repository, and have imported that history to a different branch. | 01:24 |
| bignose | but of course as far as Bazaar is concerned, the two branches share no ancestor. | 01:24 |
| bignose | how can I best tell Bazaar that the head of the CVS-imported branch represents the origin of the from-scratch Bazaar branch? | 01:24 |
| bignose | so the history is intact and consistent | 01:25 |
| bignose | james_w: thanks for the assistance | 02:00 |
| bignose | probably what I want to do (convince Bazaar that one file imported separately in two different histories are actually the same file) can't be done | 02:01 |
| lifeless | what you need is a form of history editing | 02:02 |
| lifeless | the fast-import could in principle be done to match the file identities of your tarball branch | 02:03 |
| lifeless | two ways to do that: have an option to fast import 'get-ids-from-<branch>' | 02:03 |
| lifeless | -or- | 02:03 |
| lifeless | do a transform on the result of the fast-import branch | 02:04 |
| bignose | interesting | 02:04 |
| lifeless | a longer term solution is for us to support file copies | 02:04 |
| bignose | well, I encounter this use case not infrequently, so I suspect others would as well | 02:04 |
| lifeless | because the symmetry there gives file joins as well, and then you can just tell bzr after the fact 'oh, this became that' | 02:04 |
| bignose | yes. | 02:05 |
| bignose | that's exactly the place my mind was at after merging with a specified base | 02:05 |
| lifeless | yah. its important to me | 02:05 |
| lifeless | but not top of the stack yet, sadly. | 02:05 |
| bignose | all the files got moved out of the way, and I wanted to say "no, each one of these became one of those" | 02:05 |
| bignose | okay, that's good enough for me | 02:06 |
| bignose | thanks for the insight into upcoming features :-) | 02:06 |
| poolie | hello all | 02:07 |
| * bignose checks the weather in Sydney | 02:07 | |
| poolie | are you in sydney bignose? | 02:07 |
| poolie | it's kind of grey | 02:07 |
| bignose | Melbourne | 02:07 |
| bignose | you two (poolie and lifeless) visited my workplace a while back | 02:08 |
| bignose | Cybersource | 02:08 |
| bignose | now home to a raving mob of Darcs pushers :-/ | 02:08 |
| dash | man, darcs. | 02:09 |
| bignose | man: No manual page for darcs. | 02:09 |
| dash | yes exactly | 02:09 |
| bignose | speaking of which, does anyone have any good *canonical* references for | 02:10 |
| poolie | jam, i'm trying to work out kerguelen for you | 02:11 |
| bignose | speaking of which, does anyone have any good canonical references for manpage *roff markup? | 02:11 |
| poolie | i can't recall where it is but there's some documentation in the man library for groff/troff | 02:12 |
| poolie | man 5 something | 02:12 |
| bignose | but is that specific to Linux only? I'm curresponding with someone who wants to know more Unix-wide conventional practice. | 02:13 |
| poolie | well, the location of the manual is gnu-specific | 02:14 |
| poolie | i think the syntax is fairly standard | 02:14 |
| poolie | jam, kerguelen works for me | 02:22 |
| lifeless | poolie: look at the calendar :) | 02:28 |
| lifeless | in other news, why does evolution hate me | 02:28 |
| poolie | lifeless: give me another clue? | 02:29 |
| poolie | are you saying it's too late for john? i'm not counting on him talking back :) | 02:30 |
| lifeless | poolie: no, just that its saturday:) | 02:30 |
| lifeless | sunshine; people; loife! | 02:31 |
| lifeless | or liff | 02:31 |
| lifeless | my laptop fan has died | 02:31 |
| lifeless | :( | 02:31 |
| lifeless | poolie: I'm trying to encourage you to stop working, to shore up my failing willpower to also stop workingish | 02:32 |
| poolie | ah ok | 02:32 |
| poolie | just trying to keep him unblocked | 02:32 |
| poolie | though, since it's now friday night it's moot | 02:32 |
| cyberixae | What does --fixes do? | 03:09 |
| Peng_ | cyberixae: Adds a little meta data saying "this revision fixes bug X". | 03:12 |
| cyberixae | How can I see that metadata? | 03:13 |
| cyberixae | I mean I'd like to verify that it succeeded | 03:13 |
| Peng_ | cyberixae: Well, you could use "bzr cat-revision". Recent (trunk) versions of Loggerhead also show 'em. | 03:14 |
| cyberixae | thanks | 03:23 |
| jam | poolie: kerguelen worked ok, I got the packages built | 04:29 |
| jam | It just took a while | 04:29 |
| jam | didn't work in the morning | 04:29 |
| jam | worked by the afternoon | 04:29 |
| bignose | I'm vaguely aware of discussion about tags not surviving some operations | 04:35 |
| bignose | what's the status of that? | 04:35 |
| bignose | and what should I read to know which operations do or don't preserve tags? | 04:35 |
| SamB | bignose: apparently, patch queue managers tend to eat them | 04:44 |
| Peng_ | bignose: It's not like they get eaten; PQM just doesn't/didn't propagate them to the target branch. | 04:46 |
| bignose | so if I branch, or checkout, or merge; do the tags come across with the revision data from the other branch? | 04:51 |
| bignose | (obviously checkout, forget that one) | 04:51 |
| Peng_ | bignose: Yes. | 05:03 |
| bignose | thanks. | 05:05 |
| bignose | according to ‘bzr tag --help’: | 05:05 |
| bignose | Tags are stored in the branch. Tags are copied from one branch to another | 05:05 |
| bignose | along when you branch, push, pull or merge. | 05:05 |
| Peng_ | bignose: There isn't some huge tag problem. It was one bug in PQM that (according to someone in that thread) was fixed. | 05:05 |
| bignose | good enough for me. | 05:05 |
| bignose | Peng_: okay, that puts it in context. | 05:05 |
| bignose | thanks again. | 05:05 |
| Peng_ | bignose: The discussion was also about how PQM makes tagging difficult. You can only tag a revision after it's created. In PQM's case, you usually want to tag the revision created by PQM. If you don't have direct write access to the branch, this means you have to put the tag in some other branch that PQM merges in the future. Kind of a pain, no? | 05:08 |
| Peng_ | Hmm, pqm-submit could tag some --tag argument. | 05:08 |
| === bob2_ is now known as bob2 | ||
| === bob2 is now known as Guest90262 | ||
| === Guest90262 is now known as bob2 | ||
| === zarq- is now known as zarq | ||
| AfC | Any of the bzr viz hackers here? | 10:12 |
| === vxnick-AFK is now known as vxnick | ||
| abosamoor | Hi, do you know website that offer hosting for code with bzr for proprietary code ? | 12:26 |
| lifeless | abosamoor: launchpad can do that | 13:19 |
| abosamoor | lifeless: your code must be an open source to host it on lp, is not it ? | 13:19 |
| lifeless | for free hosting, yes | 13:20 |
| abosamoor | lifeless: I want free hosting using bzr for closed source project | 13:22 |
| === Guest57883 is now known as Xavura | ||
| === abeaumont_ is now known as abeaumont | ||
| * garyvdm is at a package jam updating qbzr in karmic! | 15:22 | |
| LarstiQ | jam: I don't know about rebase, but for bzr-svn and subvertpy 0.6.2 and 0.6.8 afaik | 15:27 |
| mathrick | hiya | 15:31 |
| mathrick | is it possible to ignore a versioned file? | 15:32 |
| mathrick | ie. there's an editor's project file, and while it's useful to keep its contents, it's completely boring for the purpose of bzr diff | 15:32 |
| ddaa | AFAIK, it's not possible. | 15:36 |
| ddaa | You can approximate it with a plugin. | 15:36 |
| ddaa | If | 15:37 |
| mathrick | aha, is there one that already provides that? | 15:37 |
| ddaa | I guess, if you go as far as writing your own custom branch format, you might even get transparent support in third party tools, such as "bzr vis". | 15:37 |
| ddaa | mathrick: not as far as I know. | 15:37 |
| mathrick | hmm, that's kinda extreme though | 15:37 |
| mathrick | ok | 15:37 |
| ddaa | The alternative is to make it a simple add-on, but then you need to modify bzr vis etc. to support it. | 15:38 |
| mathrick | right, but just making diff shut up is enough to cover the 90% case | 15:38 |
| ddaa | That should be a pretty straightforward plugin. Maybe a hundred lines of code. | 15:39 |
| ddaa | (upper bound) | 15:39 |
| mathrick | yah, I expect it to be simple to do | 15:40 |
| mathrick | and a different question, albeit plugin-related | 15:41 |
| mathrick | who wants to help me implementing git's rebase --interactive functionality (ie. retroactive history shaping)? | 15:41 |
| mathrick | I'm not exactly sure where to begine | 15:42 |
| mathrick | *begin | 15:42 |
| LarstiQ | mathrick: I'm happy to us the template solution for that usecase | 15:49 |
| mathrick | what template solution? | 15:49 |
| LarstiQ | mathrick: versio foo.template, for local use copy foo.template to foo, and ignore foo | 15:53 |
| mathrick | but it's useful to keep the changes that happen to the file | 15:54 |
| mathrick | it's just not interesting to see that in diff by default | 15:54 |
| LarstiQ | right, but to me this is a good way of handling it with what's there | 15:55 |
| LarstiQ | mathrick: alternative is to symlink it to something else | 15:55 |
| LarstiQ | mathrick: and then version it in a different branch | 15:55 |
| mathrick | that loses the connection between changes then | 15:56 |
| mathrick | the template is good when you have files that rarely change and are edited by hand mostly | 15:56 |
| mathrick | not so much for automatically generated and managed foo | 15:56 |
| * LarstiQ nods | 15:59 | |
| === Kissaki^0ff is now known as Kissaki | ||
| === vxnick_ is now known as vxnick | ||
| === vxnick is now known as vxnick-AFK | ||
| flvr8 | hi...both loggerhead and trac-bzr fail on the same repository (which we migrated from svn). however, the repository branches check out just fine. the error that both loggerhead and trac-bzr give is KeyError: ... | 18:57 |
| flvr8 | is there a way to fix that in the branch? | 18:57 |
| LarstiQ | flvr8: you could try `bzr reconcile` (as rather general advice) | 19:28 |
| flvr8 | heh, yeah that crapped out with a KeyError too | 19:53 |
| flvr8 | i'm trying an svn -> git -> bzr run on the module. that fixed my problems with one of the others | 19:54 |
| cyberixae | Btw | 21:07 |
| cyberixae | my actual use case | 21:09 |
| cyberixae | I needed to find out whether some one already did --fixes | 21:10 |
| cyberixae | in the end I had to ask him | 21:10 |
| luks | you could have used bzr qlog | 21:11 |
| cyberixae | gløg? | 21:11 |
| cyberixae | bzr: ERROR: unknown command "glog" | 21:12 |
| luks | well, I said qlog, not glog | 21:12 |
| luks | but you would need to have qbzr installed | 21:12 |
| cyberixae | oh | 21:12 |
| luks | it has an option to search by bug number | 21:13 |
| cyberixae | ah | 21:13 |
| cyberixae | thanks | 21:13 |
| cyberixae | doesn't seem to have that feature | 21:16 |
| cyberixae | maybe Ubuntu has an old version | 21:16 |
| thewrath | wats going on with this bzr stats plugin | 21:49 |
| jelmer | thewrath: what about it? | 21:54 |
| thewrath | trying to get this done for bzr | 21:56 |
| thewrath | http://www.statsvn.org/ | 21:56 |
| thewrath | i have bzr here at work we have svn | 21:57 |
| thewrath | ? | 22:01 |
| thewrath | jelmer: you still around | 22:56 |
| thewrath | i have a questiona bout creating my own bzr server | 22:56 |
| flvr8 | yep, svn -> git -> bzr fixed my KeyError problem | 23:56 |
| flvr8 | it seems to be a safer migration path | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!