| jam | spiv: Yeah, trying to clear out my inbox generally has good results for others :) | 00:03 |
|---|---|---|
| jam | abentley: BB doesn't seem to be noticing my reviews, nor is it giving me the automatic :approve for patches from me? Can you tell why? | 00:13 |
| abentley | jam: The mail queue is pretty deep: http://bundlebuggy.aaronbentley.com/mail | 00:14 |
| jam | ah, ok | 00:14 |
| jam | I guess me landing 5 patches in bzr.dev doesn't help | 00:14 |
| jam | According to your earlier comments | 00:14 |
| abentley | yeah. | 00:14 |
| jam | abentley: also, some of them are pretty old: Tue Jul 15 04:50:37 2008 | 00:15 |
| jam | That is about 2 days? | 00:15 |
| jam | ah, maybe that is 'frozen' | 00:15 |
| abentley | The ones in the 'frozen' list will not be processed without my intervention. | 00:16 |
| colbrac | Jelmers bb:approve messages on the bzr-gtk list today are also not coming through | 00:18 |
| abentley | jam: I've tweaked the branch scanner to run set membership tests to find out whether a request was merged, as you suggested. Much faster! | 00:30 |
| FallenPegasus | is there a way to configure bzr to say something like "warning: you are about to push with uncommitted changes" | 00:43 |
| jelmer | FallenPegasus, not at the moment afaik | 00:44 |
| jelmer | if you think that is a useful feature, please file a bug | 00:44 |
| colbrac | jelmer: Any idea how to fix that push PushResult problem? | 00:46 |
| jelmer | colbrac, this appears to be a bug in bzr itself | 00:48 |
| jelmer | colbrac, I see one implementation of pull() that doesn't return a PullResult | 00:48 |
| jelmer | while the API clearly states that it should | 00:48 |
| === abentley1 is now known as abentley | ||
| colbrac | doh.. | 00:49 |
| jelmer | Sorry, my bad - it's actually inside of a try so I missed it | 00:50 |
| === mw is now known as mw|out | ||
| jelmer | I'm not quite sure what causes it then | 00:51 |
| jelmer | though it seems like a bad idea to work around unexpected behaviour while it's unknown what's causing that unexpected behaviour | 00:52 |
| colbrac | Which one of those BrzBranch#'s in bzrlib/branch.py is used you think? | 00:54 |
| colbrac | LP page of the branch says format 6.. so I'd assume BzrBranch6 :P | 00:55 |
| colbrac | hum.. I give up.. way too much abstractions for this time of night | 00:57 |
| jelmer | colbrac, shouldn't be too hard to figure out if you use pdb | 01:03 |
| colbrac | jelmer: you mean, after I learn to use pdb? :) | 01:04 |
| jelmer | (-: | 01:04 |
| colbrac | jelmer: That will be for another day. The dialogs took more time than I expected already. | 01:04 |
| jelmer | colbrac, k | 01:05 |
| jelmer | colbrac, thanks for those changes, btw. I'm really happy to see that happen | 01:05 |
| colbrac | jelmer: The main window GUI will be more like removing a bandaid though... :o) | 01:05 |
| colbrac | jelmer: One quick big pull | 01:06 |
| colbrac | changing way too many lines in __init__ | 01:06 |
| colbrac | jelmer: But I'll wait till I have some comments on the changes I made to the locationbar location and the Bookmarks appearance | 01:07 |
| jelmer | ok | 01:08 |
| colbrac | jelmer: One more thing before I go: There were some approved merges on the vernstok BB that are not in the new BB. Will you merge them or must they first be resend to this BB? | 01:12 |
| jelmer | colbrac, please resend them | 01:17 |
| colbrac | jelmer: Tomorrow.. or like.. after some sleep :o) G'night all | 01:18 |
| jelmer | :-) | 01:18 |
| jelmer | weltrusten | 01:18 |
| Peng | Hmmm. | 03:14 |
| * igc lunch | 03:15 | |
| Peng | On Ubuntu with the PPA 1.6b3, bzrbashprompt.sh is running and making my shell slow, even though I'm not using it. | 03:16 |
| jam | Peng: It seems the debian system auto installs everything in contrib/bash to /etc/bash....d/ | 03:27 |
| jam | you can rm the one file | 03:27 |
| jam | and I think the packaging is going to be updated. | 03:27 |
| Peng | If I rm it, it will be reinstalled next time I upgrade bzr, right? | 03:27 |
| Peng | I replaced it with an empty file. All is right in the world now. :) | 03:28 |
| jam | Peng: well, the next bzr version should *not* install that file anymore. | 03:38 |
| jam | We didn't intend it to be installed, but didn't realize the installer said "install contrib/bash/*" | 03:38 |
| jam | which used to just install a path-completion stuff | 03:38 |
| Peng | jam: Ah. | 03:48 |
| Grantbow | I'm getting the feeling that instead of using the CVS $Id:$ trick I have to do something like bzr version-info --python and check it in - am I getting warm? | 04:10 |
| mwhudson | this doesn't look very happy: http://pastebin.ubuntu.com/28180/ :( | 04:10 |
| mwhudson | bzr log --short over the hpss is broken? | 04:12 |
| GaryvdM | Is it possible to add an option to a builtin command from a plugin? | 04:28 |
| GaryvdM | I want to fix Bug 241889 | 04:29 |
| ubottu | Launchpad bug 241889 in qbzr "show merge --preview in qdiff window?" [Undecided,New] https://launchpad.net/bugs/241889 | 04:29 |
| GaryvdM | bzr merge --qpreview | 04:29 |
| mwhudson | GaryvdM: yes | 04:31 |
| mwhudson | unfortunately i don't really know the best way how... | 04:31 |
| GaryvdM | Do you know of some where else that it has been done? | 04:32 |
| mwhudson | https://bugs.edge.launchpad.net/bzr/+bug/249690 | 04:34 |
| ubottu | Launchpad bug 249690 in bzr "bzr log --short broken over hpss" [Undecided,New] | 04:34 |
| Verterok | GaryvdM: xmloutput (0.4 series) adds --xml option to status, etc. It's not the best way to do it, but it seems to work ok. | 04:34 |
| mwhudson | GaryvdM: i did this once: http://pastebin.ubuntu.com/28183/ | 04:35 |
| GaryvdM | Ok - that would work | 04:35 |
| === sm_ is now known as sm | ||
| GaryvdM | Thanks mwhudson. I was able to do it. | 05:01 |
| mwhudson | GaryvdM: cool | 05:01 |
| === jamesh_ is now known as jamesh | ||
| jml | poolie: I've encountered an issue with the stacking stuff. | 06:28 |
| jml | poolie: can I call you about it? | 06:28 |
| * spiv ducks out for an hour | 06:34 | |
| lifeless | poolie: ping | 06:39 |
| poolie | jml, sure | 06:49 |
| poolie | lifeless: pong | 06:49 |
| poolie | i fall off irc and everyone wants me :) | 06:51 |
| jml | we always want you poolie | 06:51 |
| igc | GrantBow: yes | 06:52 |
| jml | poolie: skype or pots? | 06:52 |
| lifeless | poolie: we have about 50 tshirts left; how do you feel about us giving them out at LRL | 06:53 |
| poolie | lifeless: go crazy | 06:53 |
| lifeless | thanks | 06:53 |
| lifeless | erm wtf http://bazaar-vcs.org/ZoomQuiet | 06:55 |
| lifeless | it doesn't seem quite spam | 06:55 |
| lifeless | but its surely not topical | 06:55 |
| lifeless | poolie: also, any feedback on the RFC: review support and partial commits would be nice | 06:56 |
| lifeless | (doesn't have to be deep feedback) | 06:56 |
| lifeless | ZoomQuiet is also doing japanese translations of bzr wiki pages. *blink* | 06:57 |
| poolie | jml, let me reply to vila first | 06:57 |
| jml | poolie: ok | 06:57 |
| poolie | jml, call me? pots? | 07:23 |
| jml | poolie: sure. | 07:23 |
| kiorky | jelmer (and others): hello, i have strange segfault error on bzr-svn and i cant figure out why it comes. (li. 675 in ra.c seems to be problematic for me (where the segfault seems to appen). But i run in a special env. (all underlying libraries are compiled with prefix) and i want t be sure that it is not the env rather than bzr which is in fault. How can i debug efficiently that ? With gdb (then how?) | 07:30 |
| kiorky | jelmer: what i want to do is just "import pdb;pdb.set_trace()", C way | 07:31 |
| kiorky | jelmer: http://www.friendpaste.com/xjJTVvNv i get that as a start, must go out to work, seeya. | 07:36 |
| lifeless | kiorky: hi, jelmer will be around in an hour or two; its early morning here in the UK | 08:10 |
| kiorky | lifeless: one hour less from me :p (france) | 08:22 |
| kiorky | /B 29 | 08:49 |
| poolie | lifeless: ping | 08:59 |
| poolie | lifeless: do stacking branches still actually require supports_external_lookups in the repository? | 08:59 |
| poolie | i'm guessing yes, so that check knows it's ok for them to have outward-pointing references? | 08:59 |
| lifeless | poolie: yes | 08:59 |
| poolie | so to make stacking a non-development feature, we need a non-development repository format too | 09:00 |
| === jamesh_ is now known as jamesh | ||
| poolie | with that set | 09:00 |
| lifeless | poolie: yes, branch and repo format both | 09:15 |
| lifeless | you can just take the development one and rename/tweak it if you want the shortest path. Ideally though you'd add another format, marked stable, and leave the devleopment one as is until 1.7 when it can be removed | 09:16 |
| lifeless | poolie: did you see the rfc on review support in bzr? | 09:16 |
| fullermd | Is there a reason not to pull the rich-root switch at the same time? I thought that was targetted to 1.6 originally anyway... | 09:16 |
| lifeless | fullermd: aaron said to me last week there were about 2 bugs remaining | 09:17 |
| fullermd | Ah. That's a good reason :) | 09:17 |
| lifeless | -> checkout | 09:18 |
| poolie | lifeless: i did | 09:19 |
| poolie | when i read it last night i was a bit averse to putting it in the core | 09:19 |
| poolie | but, i guess it depends on whether you mean 'shipped with bzr' or 'getting its fingers in everywhere' | 09:20 |
| lifeless | well | 09:20 |
| lifeless | putting implementation aside | 09:20 |
| lifeless | did it sound nice, would you use it | 09:20 |
| poolie | it seems like it would integrate in an interesting way with content filtering, doesn't it? | 09:20 |
| lifeless | would it be easy to use | 09:20 |
| poolie | so 'the convenient form of this file has these extra hunks but pretend you can't see them' | 09:21 |
| poolie | it does sound pretty nice | 09:21 |
| poolie | i had a case for this just the other day with the pdb stuff in selftest | 09:21 |
| poolie | i guess i could have made it into a loom thread | 09:21 |
| poolie | i agree with you that the git index is interesting but the wrong way around imo | 09:21 |
| lifeless | back after I checkout | 09:22 |
| lifeless | back | 09:44 |
| lifeless | poolie: so I want to preserve the 'what diff shows you is what is committed' assertion | 09:44 |
| lifeless | I don't know that content transformation is a good fit with hunk marking | 09:45 |
| jelmer | 'morning | 09:53 |
| awilkins | Morning | 09:54 |
| awilkins | I see win32 became a first-class beta citizen | 09:54 |
| awilkins | A shame that configuring it to compile those extensions is such a PITA | 09:55 |
| jelmer | hi awilkins | 09:57 |
| awilkins | jelmer: So, bzr-svn ; my thoughts are that 1) Update is redundant, because switch also works within a branch as well as across branches ; 2) Replay is probably easier once you get the path remapping working | 09:57 |
| awilkins | BUt you've probably got my mail already :-) | 09:57 |
| jelmer | awilkins: replay can only be used if the server has svn >= 1.4 | 09:58 |
| awilkins | jelmer: True, I wonder how many servers have not been upgraded. I think svn has been at 1.4 for some time. | 09:59 |
| awilkins | jelmer: I suppose getting switch to work well and then implementing replay stops you ignoring bugs in the switch implementation :-| | 10:00 |
| jelmer | awilkins: There's quite some out there | 10:03 |
| awilkins | I suppose the last 1.3 release was only last June | 10:03 |
| awilkins | I upgraded specifically for replay ; the bosses wanted a redundant backup server, so it mirrors to a second box using svnsync after every commit. | 10:04 |
| jelmer | yeah, that's not something we can rely on unfortunately | 10:05 |
| awilkins | Phhoey. Anyway, dis you test my patch? Does it produce a similar dramatic drop in bug count on Linux? | 10:05 |
| jelmer | awilkins: No, that patch isn't required on Linux | 10:05 |
| jelmer | I also couldn't find any indication that that was necessary in the Subversion headers | 10:05 |
| awilkins | jelmer: This svn 1.5 or 1.4.6? | 10:05 |
| jelmer | both | 10:06 |
| awilkins | Hmm. | 10:06 |
| jelmer | so I suspect there's something else going wrong | 10:06 |
| awilkins | Ok, I'll shelve it and maybe we'll find something else wrong. | 10:07 |
| uws | What is the fastest bzr repository format? rich-root-pack is deemed the smallest, but is it also the fastest? | 10:16 |
| lifeless | well, gc-plain is the smallest, but its alpha today | 10:16 |
| uws | Rebasing 3 revisions I have (3 minor patches) on top 4 newly added ones in the upstream tree takes like a few minutes | 10:17 |
| lifeless | it should end up being the fastest too ;) | 10:17 |
| lifeless | uws: please file bugs on performance things; generally you souldn't need to worry about formats. | 10:17 |
| uws | lifeless: I wouldn't know what to say | 10:17 |
| lifeless | uws: rich-root-pack is the best format to be using _today_ for bzr-svn branches | 10:17 |
| lifeless | uws: 'I rebased and it was slow' | 10:17 |
| lifeless | uws: :) - givint the branch url for what you rebased would help, and the command you ran | 10:18 |
| uws | lifeless: I'm using bzr-svn branches indeed. pulling from svn is quite slow as well, but rebasing is bzr only right? | 10:18 |
| lifeless | uws: I don't know if it is or isn't bzr only :) | 10:18 |
| uws | the bzr-svn branch I'm using is NOT online :( | 10:18 |
| uws | I've mirrored WebKit trunk | 10:18 |
| uws | and launchpad doesn't have it in the vcs-mirror | 10:18 |
| lifeless | uws: ah, thats ok. Just filing a bug is sufficient to start with | 10:19 |
| uws | it took me a few days to build this branch | 10:19 |
| lifeless | whee | 10:19 |
| uws | I'll happily share it with launchpad if they want to | 10:19 |
| uws | I can upload/bzr push, pas de probleme | 10:19 |
| lifeless | uws: you could just push it to the bzr playground, or launchpad or .. | 10:19 |
| uws | yeah, but having the "official" webkit mirror seems better | 10:19 |
| uws | but the conversion hasn't been trivial :) | 10:20 |
| lifeless | is webkit in gnome svn? | 10:20 |
| uws | lifeless: can I push my ~1GB .bzr to launchpad? :s | 10:20 |
| uws | lifeless: No, webkit svn | 10:20 |
| lifeless | uws: sure | 10:20 |
| * AfC recalls the 2 days it took to build the initial gtk+ branch... | 10:20 | |
| lifeless | uws: what was the command you ran? 'bzr rebase ... ...' ? | 10:21 |
| uws | lifeless: "bzr rebase" ;) | 10:21 |
| proppy | Hi, is there a way to convert a mercurial repository to bzr | 10:21 |
| uws | lifeless: I'll explain my setup | 10:21 |
| uws | repo in webkit/ | 10:21 |
| proppy | (one way for importing the code to launchpad) | 10:21 |
| uws | the .bzr/ dir in there is ~1GB | 10:21 |
| lifeless | proppy: I think there is an hg fastexport frontend | 10:21 |
| uws | 2 branches: webkit.trunk (without tree, parent is upstream svn+http url, I use this to pull upstream) | 10:21 |
| lifeless | proppy: so the bzr fastimport plugin is the best way to do a one-shot conversion | 10:21 |
| uws | other branch is webkit.uws, which is branch of the webkit.trunk branch | 10:22 |
| uws | I have 3 small patches in webkit.uws. when I update webkit.trunk, I run "bzr rebase" in webkit.uws to stack my own patches on top of the upstream trunk version | 10:22 |
| proppy | lifeless: ho just noticed there is also an hg convert to GNU arch | 10:22 |
| uws | gnu arch is dead, proppy ;) | 10:23 |
| proppy | :) | 10:23 |
| proppy | googling for fastimport | 10:23 |
| AfC | For what it's worth: I ran some experiments with rebase a few weeks ago. While it "works", the form of the command line UI seems to be very different than the rest of the code bzr commands. I kept getting tripped up as to what would happen to which branch. | 10:23 |
| AfC | (and instead settled on good old `bzr merge -r X..Y` for cherry picks) | 10:24 |
| uws | AfC: I think of "rebase" as a "shelve away all my own commits, then pull the other branch, and unshelve all my own commits" | 10:24 |
| AfC | uws: yeah, I sorta got that at the end. | 10:24 |
| uws | I want my patches to be on top of upstream, so that I can keep then in sync (and attach to bugzilla blah blah) | 10:25 |
| AfC | uws: I think matters were complicated by the fact that I was also trying to cherry pick selected revisions at the same time. It made a loud splat noise. | 10:25 |
| lifeless | uws: so, leaving aside the philosophical 'why rebase at all' discussion :) - | 10:25 |
| uws | not sure what happens once they commit one of my patches upstream | 10:25 |
| AfC | lifeless: :) | 10:25 |
| lifeless | uws: all you run is 'bzr rebase', no arguments at all ? | 10:25 |
| uws | lifeless: (I rebase because my patches need to be on top of trunk to keep them clean for upstream submission) | 10:25 |
| lifeless | uws: you don't need to rebase to achieve that :) | 10:26 |
| lifeless | uws: is http://svn.webkit.org/repository/webkit/trunk the url you bzr-svn'd ? | 10:26 |
| AfC | Just merging trunk into your branch and then `bzr diff -r branch:../trunk` (?) should do it, no? | 10:26 |
| lifeless | AfC: its the loom use case really, one thread per patch, serial merges | 10:27 |
| lifeless | AfC: with a flatten operation at the final commit to trunk, for folk that want that | 10:27 |
| AfC | lifeless: you say so :) | 10:27 |
| uws | lifeless: Yes, that's the url. | 10:27 |
| lifeless | AfC: I do! | 10:27 |
| lifeless | uws: how many files do your patches change? | 10:28 |
| uws | lifeless: all three of them just touch 1 file (3 different files in total). | 10:28 |
| proppy | lifeless: what is bzr fastimport frontend for mercurial | 10:28 |
| uws | all <5 line changes | 10:28 |
| proppy | front-end | bzr fast-import - | 10:28 |
| lifeless | proppy: yes; http://modular.math.washington.edu/home/mhansen/fast-export/hg-fast-export.txt has some stuff about hg-fast-export | 10:29 |
| lifeless | proppy: fast-export is a standard for exporting and importing between many different VCS systems | 10:29 |
| proppy | These front-ends are bundled in the exporters/ directory of bzr-fastimport. | 10:30 |
| proppy | :) | 10:30 |
| proppy | ../bzr-fastimport/exporters/hg-fast-export.py -r ../protobuf-test/ | bzr fast-import - | 10:32 |
| proppy | done thanks :) | 10:32 |
| AfC | There are two possibilities, then: either the one shipping with bzr-fastimport is tweaked and fixed, being specific to Bazaar, or the one available from [someone in the] Mercurial [community] is newer and better, being from the foreign system who perhaps know their own system better. | 10:32 |
| lifeless | uws: I have filed a bug | 10:35 |
| uws | lifeless: CC me please, uws+launchpad@xs4all.nl | 10:36 |
| uws | lifeless: I'm currently trying to push my webkit.trunk mirror to lp:~uws/webkit-open-source/webkit.trunk | 10:37 |
| uws | wonder whether it'll work, and how long it'll take ;) | 10:37 |
| lifeless | :> | 10:37 |
| uws | at least I'm on 100MBit for the rest of the day :) | 10:37 |
| uws | I created the branch in launchpad using the web page, and I had to supply --use-existing-dir to bzr push | 10:38 |
| lifeless | yes, I think this is ugly :) | 10:38 |
| uws | Hmmm. "copying inventory texts 2/5" | 10:39 |
| awilkins | jelmer: I might be prepared to disagree with you on this "set_path" thing ; can you show me where the API says you _don't_ have to describe the revisions of every path? | 10:49 |
| proppy | importing to lp done, thanks lifeless and AfC | 10:49 |
| awilkins | jelmer: Of course, if the tests work on Linux, it's clear that something is behvaing differently ; but still, I can't find anything that says "if you don't pass any paths, it assumes that everything is revision N" | 10:50 |
| lifeless | proppy: cool | 10:57 |
| lifeless | uws: you are copied now | 11:01 |
| uws | lifeless: Hm? | 11:31 |
| uws | lifeless: ah, cc on the bug | 11:31 |
| uws | lifeless: I'm at "copying content texts 3/5" for my webkit.trunk push ;) | 11:31 |
| uws | but the repo is ~1GB ;) | 11:32 |
| === thekorn_ is now known as thekorn | ||
| LeoNerd | It's likely been asked a hundred times before, but... Why-oh-why do I have to give a 'push' URL the first time I push a branch..? Can it not default to the parent, the place I branched it from..? | 11:37 |
| LeoNerd | Similar for missing/pull/update/etc... | 11:38 |
| luks | that's not always the place you want to push to | 11:38 |
| LeoNerd | Not always, no. I suppose I could consider various other use-cases. But every time I've ever done it, that's what I've done. I imagine that's the most likely place. | 11:39 |
| luks | I think in most open source projects people branch over http | 11:39 |
| LeoNerd | OK... So just apply the default to the missing/pull/update case then... | 11:40 |
| LeoNerd | bzr branch http://foo/bar. ... wait a few days... bzr missing => "bzr missing: no URL specified" | 11:40 |
| LeoNerd | It would be nice if it just filled that in by default... even if I had to do the push one myself | 11:40 |
| fullermd | Don't forget the location aliases abentley put in for 1.6... very nice. I just wish they were documented somewhere other than NEWS. | 11:41 |
| jelmer | beuno, ping | 11:41 |
| awilkins | jelmer: I'm trying to test bzr-svn on Linux and it just says "Aborted" | 11:57 |
| jelmer | awilkins, what version of python? | 11:58 |
| awilkins | 2.5.2 | 11:58 |
| jelmer | hmm, not sure then | 11:58 |
| thumper | hi jelmer | 11:58 |
| jelmer | any chance you can run it inside a debugger to see what it is aborting on? | 11:58 |
| jelmer | thumper: Hi | 11:58 |
| thumper | can bzr-svn import subtrees as branches? | 11:58 |
| thumper | jelmer: I'm thinking of kde | 11:58 |
| jelmer | thumper: yeah | 11:58 |
| awilkins | jelmer: You'd have to give me a quick pointer as to how | 11:58 |
| jelmer | awilkins: "make gdb-check" should do that for you | 11:59 |
| thumper | jelmer: any idea on how it would perform with 750K revisions (kde has one big repo) | 11:59 |
| thumper | jelmer: any given subtree will only have a fraction of those | 11:59 |
| jelmer | thumper, apparently it does work - some people have used it, but the building of the cache takes a long time apparently | 12:00 |
| jelmer | there has been work on allowing bzr-svn to not even look at the rest of the repository | 12:00 |
| jelmer | but that's not finished yet | 12:00 |
| thumper | jelmer: how long will it take? | 12:00 |
| thumper | no pressure ;-) | 12:00 |
| awilkins | jelmer: My installed bzr is not compatible with bzr-svn now, should I edit the makefile to point at my bzr.dev? | 12:00 |
| jelmer | thumper, Not sure, it's not one of the highest things on the list | 12:01 |
| jelmer | awilkins: yeah | 12:01 |
| thumper | jelmer: where's the list? | 12:01 |
| * thumper waves the priority wand :) | 12:01 | |
| jelmer | thumper, It's the bugs list in lp :-) | 12:01 |
| jelmer | awilkins: Or just export the BZR environment variable to point at your bzr.dev | 12:01 |
| thumper | jelmer: is the cache reusable across multiple subtree imports? | 12:02 |
| jelmer | yes | 12:02 |
| thumper | ok, not so bad then | 12:02 |
| jelmer | It's about 2 gig though, from what I've heard | 12:02 |
| thumper | memory or disk? | 12:02 |
| awilkins | jelmer: Yup, figured that ; I'm now at a (gdb) prompt | 12:03 |
| jelmer | awilkins, just run | 12:03 |
| thumper | jelmer: thanks, gotta go now | 12:03 |
| thumper | jelmer: I may well be in touch again later :) | 12:04 |
| * awilkins pines for GUI debuggers | 12:04 | |
| jelmer | thumper: ok | 12:04 |
| awilkins | I think I may need to install some more symbols | 12:04 |
| jelmer | awilkins: There's a good GTK+ based one now I think | 12:04 |
| * jelmer tries to remember the name | 12:04 | |
| awilkins | lots of "no debugging symbols" | 12:05 |
| lifeless | LeoNerd: push is normally *not the place you branched from; at least IME | 12:05 |
| awilkins | It's stopped in libc.so.6 | 12:05 |
| lifeless | LeoNerd: its only the single-developer case that you *can* push back to the place you branch from | 12:05 |
| awilkins | Yes, doing these things "raw" makes you a real man... I'd rather be wimp with a cyborg exo-suit than a real man naked in the desert.... | 12:06 |
| lifeless | ;) | 12:06 |
| awilkins | jelmer: Are you testing on x86_32 or x86_64 ? | 12:11 |
| jelmer | I'm on 32bit | 12:11 |
| awilkins | I'm on 64 | 12:12 |
| awilkins | I'm also trying to find th right debug symbols | 12:13 |
| * awilkins installs the debug python interpreter | 12:14 | |
| awilkins | Well, that seemed to remove all the "no symbols" errors | 12:16 |
| awilkins | Still about as clear as mud | 12:16 |
| * awilkins has been spoiled by working in environment where the debugger just shows you the code that's busted :-) | 12:16 | |
| * awilkins installs insight and ddd | 12:21 | |
| jelmer | bug 127945 | 12:29 |
| ubottu | Launchpad bug 127945 in bzr-svn "Integrate creating new branch functionality into standard push/branch" [Low,Triaged] https://launchpad.net/bugs/127945 | 12:29 |
| jelmer | lifeless, ^ | 12:29 |
| colbrac | jelmer: What are the chances of you merging the OliveGui? :) | 12:47 |
| jelmer | colbrac, I'd like to at least wait for phanatic to comment | 12:47 |
| colbrac | jelmer: Ok.. at least it stills merges without conflict to the new trunk | 12:48 |
| colbrac | colbrac: The pending 'status for folders' and 'fix for broken symlink' will cause conflicts me thinks | 12:49 |
| colbrac | jelmer: ^ (doh.. stop talking to myself :P) | 12:50 |
| * colbrac needs more coffee: 'fix for broken symlink' is already merged. | 12:53 | |
| colbrac | jelmer: Could the 'sort bookmarks by title bundle' be merged? I promise I will remove the code duplication (which is present already) after the merge of OliveGui. | 13:14 |
| jelmer | re | 13:14 |
| jelmer | colbrac: You're yourself also free to merge changes into trunk (if they have been approved) | 13:14 |
| colbrac | wow! Didn't know that about that. So you change your stance from resubmit to approve? | 13:15 |
| jelmer | colbrac: If I voted resubmit I'd like to see a new submission to the list :-) | 13:18 |
| jelmer | tweak means I'm fine to see the bundle go in iff the indicated changes in my review are made (without the need for further review) | 13:18 |
| jelmer | I think I would actually like to see that one resubmitted | 13:18 |
| colbrac | jelmer: Did you read my reply on the list about this? I still think adding another helper function now, while the whole duplication between _load_left / refresh_left will be removed soon is not really useful. | 13:20 |
| jelmer | colbrac: I guess I could live with it then | 13:27 |
| colbrac | k thx :) | 13:28 |
| jelmer | colbrac, any chance you can review http://bundlebuggy.aaronbentley.com/project/bzr-gtk/request/%3C20080717123155.GA14537@vernstok.nl%3E? | 13:44 |
| colbrac | jelmer: Will take a look at it, but it's unknown territory for me | 13:46 |
| jelmer | It's a relatively trivial change | 13:49 |
| colbrac | still.. I can't even figure out how to open that 'Search revisions' dialog :P | 13:51 |
| colbrac | or is it that list that opens on the history button in olive? | 13:51 |
| jelmer | colbrac, you need to have bzr-search installed | 13:55 |
| jelmer | and that, in turn, needs bzr.dev or one of the 1.6 betas | 13:55 |
| jelmer | mvo, hi | 14:13 |
| colbrac | jelmer: The dialog doesn't disappear for me :/ | 14:35 |
| colbrac | jelmer: add .destroy() somewhere | 14:37 |
| matkor | Is any transport faster thatn sftp: ?? | 14:44 |
| matkor | it takes minutes do update checkout with few lines changes ... | 14:46 |
| lifeless | matkor: what project? | 14:48 |
| matkor | lifeless: mine | 15:03 |
| matkor | just I have big lattency link (crowded vpn) | 15:03 |
| matkor | but it is still long time I think .. I wonder perhaps ssh+bzr: would be better choice ? | 15:03 |
| mvo | hey jelmer! you pinged me earlier? | 15:12 |
| jelmer | mvo: Yeah, I was trying to find some way to retrieve "Vcs-*" fields from the apt cache using python-apt | 15:13 |
| jelmer | mvo: Is it correct that that's not possible atm? | 15:14 |
| mvo | jelmer: give me a minute, I should be able to sent you a example | 15:14 |
| lifeless | matkor: should be about the same usually; however latency hurts :( | 15:15 |
| mvo | jelmer: you are right, its currently not accessable because there is no way to access the full record. let me add it to the python-apt source | 15:21 |
| jelmer | mvo, Cool | 15:21 |
| mvo | jelmer: I can put a new version into my ppa, do you need hardy or intrepid debs? | 15:25 |
| jelmer | mvo: I'm actually on sid but I guess hardy is most useful for me at this point :-) | 15:25 |
| jelmer | colbrac, are you sure you meant resubmit rather than tweak? | 15:27 |
| colbrac | :) hum, yeah you are right.. I trust you can handle this without further review :o) | 15:28 |
| jelmer | mvo, where is the main python-apt branch? | 15:36 |
| mvo | jelmer: my development tree is at http://people.ubuntu.com/~mvo/bzr/python-apt/mvo/ | 15:37 |
| colbrac | I installed bzr 1.6b3 from the bzr-beta ppa but now I seem to have a bzr prompt as soon as I start a gnome-terminal for every folder I enter :/ | 15:37 |
| colbrac | that's a nice *feature* people :P | 15:39 |
| Odd_Bloke | colbrac: I _believe_ that's an issue with the packaging. Look in /etc/bash.d, perhaps. | 15:39 |
| mvo | jelmer: I have a pbuilder sid environemnet here, I can build you a package if that is more convenient | 15:39 |
| Odd_Bloke | ubottu: paste | 15:40 |
| mvo | jelmer: I added a "Record" attribute to the PkgSrcRecord that gives you the full record | 15:40 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 15:40 |
| colbrac | thanks to etckeeper I know it's done in /etc/bash_completion.d/bzrbashprompt.sh | 15:40 |
| jelmer | mvo: Thanks | 15:40 |
| Odd_Bloke | ja1: I'm getting http://paste.ubuntu.com/28287/ when I attempt to send you mail. | 15:41 |
| jelmer | mvo: A sid package would be quite nice if it's not too much trouble :-) | 15:41 |
| === ja1 is now known as jam | ||
| jam | Odd_Bloke: odd.. can you try sending directly to john@mail.arbash-meinel.com? | 15:42 |
| jam | Love to put that in traceback ... ugh | 15:42 |
| jam | anyway | 15:42 |
| jam | try it | 15:42 |
| jam | Odd_Bloke: I know I have a greylist which requires messages to be re-sent the first time they come through | 15:44 |
| jam | but 550 doesn't look like the right error for that. | 15:44 |
| jelmer | mvo: nevermind, bzr builddeb also seems happy with your branch | 15:44 |
| Odd_Bloke | jam: I got http://paste.ubuntu.com/28288/ in my logs when I sent the email to john@mail.arbash-meinel.com. | 15:44 |
| Odd_Bloke | jam: Though it's deferred (rather than bounced as previously) so I may have just hit the greylist for that. | 15:46 |
| jam | Odd_Bloke: sounds like. | 15:47 |
| jam | You can send again in a couple minutes | 15:47 |
| jam | or just wait for it to retransmit | 15:47 |
| Odd_Bloke | jam: I'll wait. :) The initial error seems weird though. | 15:48 |
| jam | yeah the 550 you were getting seems bad | 15:49 |
| jam | I know I have a private mail server, and domainpeople just relay it to me | 15:49 |
| jam | as a backup | 15:49 |
| jelmer | mvo, The Vcs-Bzr fields still appears to be missing | 15:54 |
| jelmer | mvo:while it does contain other fields such as Maintainer and Homepage | 15:55 |
| jelmer | mvo, e.g. Cache()["bzr"].installedRecord["Maintainer"] works but Cache()["bzr"].installedRecord["Vcs-Bzr"] doesn't | 15:56 |
| TejasPP | hi, is there any tutorial on how to write a plugin/hook? both user reference and user guide doesn't contain many information. they both say "look at the builtins.py". having a tutorial would be great | 16:01 |
| NfNitLoop | TejasPP: I think you just volunteered to write one? ;) | 16:04 |
| mvo | jelmer: right, the vcs-bzr information is only available in the source package record, that is slightly more work to extract | 16:04 |
| TejasPP | first I should figure it out! :D | 16:04 |
| colbrac | exactly! :) That's what I did before I added info about giving back for bzr-gtk on the bzr wiki | 16:05 |
| mvo | jelmer: http://paste.ubuntu.com/28291/ is a example, its rather primitive compared to the interface that works with binary packages | 16:06 |
| TejasPP | so, there is no documentation on this other than user guide/reference and writingplugins page | 16:11 |
| jelmer | mvo, Ah, my bad | 16:11 |
| colbrac | jelmer: If I was going to try to move some import statements to the top of files in bzr-gtk and I find licence-less py files (like window.py), should I add a licence? | 16:11 |
| jelmer | mvo, Thanks, that seems to work | 16:11 |
| jelmer | mvo, that returns the data from the latest known version? | 16:11 |
| jelmer | since Lookup() seems to return only a single object, rather than multiple | 16:12 |
| mvo | jelmer: its a bad interface, you can run Lookup() multiple times and it will return multiple records (it will return false when there are no records left) | 16:13 |
| mvo | jelmer: /usr/share/doc/python-apt/examples/sources.py is a example | 16:13 |
| mvo | jelmer: on how to use it (this code predates my involvement with the project :) | 16:14 |
| jelmer | mvo: Heh, ok | 16:14 |
| jelmer | mvo, Thanks | 16:14 |
| mvo | cheers! let me know if you need anything else | 16:15 |
| jelmer | I'm fine for now... "bzr branch deb:<package-name>" seems to work | 16:16 |
| lifeless | ooooooo | 16:16 |
| TejasPP | do you know any example plugin which is well commented and easy to understand? or which functions I should look in builtins.py | 16:17 |
| jelmer | TejasPP: any particular sort of plugin you're looking to implement | 16:19 |
| jelmer | ? | 16:19 |
| jelmer | TejasPP: New command, push hook, etc? | 16:20 |
| TejasPP | jelmer: actually I'm trying to write a hook to indent files before commit | 16:20 |
| TejasPP | but it would be good opportinuty for me to learn writing plugins | 16:21 |
| TejasPP | jelmer: I'm reading docs and codes since last night and all I can is that: http://pastebin.ubuntu.com/28293/ | 16:23 |
| TejasPP | /all i can/all i can do | 16:25 |
| jelmer | TejasPP, If you would like to do it pre-commit, you may want to add a start-commit hook | 16:26 |
| jelmer | TejasPP, see http://pastebin.ubuntu.com/28294/ | 16:26 |
| mvo | jelmer: oh? that bzr branch deb:stuff is a plugin that looks for the vcs- header? | 16:29 |
| mvo | jelmer: if so, where can I download the plugin :) | 16:30 |
| jelmer | mvo: yeah - it works in a similar fashion to lp: | 16:30 |
| mvo | (or bzr get it) :) | 16:30 |
| mvo | that sounds *very* cool! | 16:30 |
| jelmer | mvo: I've implemented it as patch to bzr-builddeb | 16:30 |
| jelmer | http://people.samba.org/bzr/jelmer/bzr-builddeb/directoryservice/ | 16:31 |
| jelmer | mvo: ^ | 16:31 |
| * mvo bzr gets | 16:31 | |
| === menesis1 is now known as menesis | ||
| mvo | jelmer: works for me, that is hot stuff :) | 16:37 |
| jelmer | cool :-) | 16:37 |
| TejasPP | jelmer: I've wrote that: http://pastebin.ubuntu.com/28297/ | 16:41 |
| TejasPP | I think I need a list of files which is modified | 16:41 |
| === edcrypt1 is now known as edcrypt | ||
| * lamont has a randomly-strange use case... bzr update against a tree that has had an uncommit fails (for good reasons). I want to force it to do the uncommit here as well. is that doable short of rm -rf .bzr and re-branch? | 16:53 | |
| === Pieter|Paris is now known as Pieter|Brussel | ||
| awilkins | That fast-wak-win32 patch is awesome | 17:04 |
| awilkins | *walk | 17:04 |
| awilkins | Status on a 28,469 element tree - 2 seconds | 17:04 |
| lifeless | bit slow | 17:06 |
| awilkins | :-P | 17:06 |
| awilkins | Yeah, I'm doing this java thing that eats am XML model and spits ASP pages ... it's IO bound... well, it is on Windows | 17:07 |
| awilkins | On Linux it takes the same time whether you output to RAM disk or real disk | 17:07 |
| awilkins | And 1:35 instead of 2:30 | 17:07 |
| lifeless | jelmer: ping | 17:07 |
| lifeless | jam: ping | 17:09 |
| awilkins | I don't think jam is even here | 17:09 |
| lifeless | lamont: for mirrors, don't use update; use a normal branch and pull --overwrite && bzr revert | 17:09 |
| lamont | lifeless: cool | 17:10 |
| lifeless | (I told Ng already) | 17:10 |
| lamont | yeah | 17:10 |
| lamont | fixing it is so much easier than teaching people to not use bzr uncommit on a published branch. :( | 17:11 |
| lamont | and do I really not have a way to have per-branch hook scripts? | 17:11 |
| liw | http://www.reddit.com/info/6sf0l/comments/ | 17:11 |
| awilkins | lamont: You could do a hook script that examines the revid of the first revision in the branch | 17:12 |
| lamont | awilkins: I want diff hook scripts for diff repos, and don't want to have to change the hook script each time... | 17:12 |
| lamont | I'd be more inclined to have a hook script that examined .bzr/$MUMBLE and ran it if it was there. | 17:13 |
| lifeless | lamont: exactly | 17:13 |
| liw | (interesting question on that reddit page, nothing interesting in the answers yet) | 17:13 |
| lifeless | lamont: for instance, bzr-email checks for a email_to configuration item | 17:13 |
| lamont | because lack of per-branch hook scripts is something that even clearcase didn't do. | 17:13 |
| lamont | lifeless: that's a good place to start | 17:13 |
| lifeless | lamont: which will pickup from branch.conf or locations.conf or bazaar.conf automatically | 17:14 |
| lifeless | ladon't conflate 'per branch' with 'code is instanlled locally' | 17:14 |
| lifeless | damn, I mean globally. damn australian saturated email link fuckage | 17:14 |
| lamont | lifeless: what I really want is something to bolt into uncommit that says 'no, you already published this, you ninny' | 17:14 |
| lamont | lifeless: one of these days I'll take the time and corner the right people/docs to figure out how to get my use model in bzr: one directory, lots of branches and switch between them when I want. this one directory-per-branch thing offends my sensibilities. (while I recognize that many people prefer that)( | 17:15 |
| lamont | so yeah, what I really mean is "per repo" :-) | 17:15 |
| lamont | and _that_ is conflation at its finest | 17:16 |
| lifeless | lamont: so why should that *not* work on every branch? just check the public_ocation of the branch and if it is nothing cancel, otherwise try to connect and check | 17:16 |
| lifeless | lamont - or better yet, record the last revision pushed in a hook, and then you can check locally | 17:16 |
| awilkins | lamont: Make a no-trees repo, make a subfolder for the branches, put branches in it. Then make a checkout folder, and use `bzr switch` when you please | 17:17 |
| lamont | awilkins: concept understood. about 20% of the words in that sentence obviously require recursion... hence "sometime when I'm not at work" :) | 17:17 |
| lifeless | lamont: and yes, as awilkins says, we *totally* support lots of branches and switch | 17:17 |
| lifeless | lamont: it is : | 17:18 |
| lifeless | $bzr init-repo foo --no-trees | 17:18 |
| lifeless | bzr branch THING foo/branch1 | 17:18 |
| lifeless | bzr branch foo/branch1 foo/branch2 | 17:18 |
| lifeless | ... | 17:18 |
| lifeless | bzr checkout --lightweight foo/branch1 place-to-edit-source | 17:18 |
| lifeless | cd place-to-edit-source | 17:18 |
| lifeless | hack | 17:18 |
| lifeless | bzr commit | 17:18 |
| lifeless | bzr switch branch2 | 17:18 |
| lifeless | etc | 17:18 |
| lamont | ah, and --no-trees means that it doesn't create a foo/branch1 directory mess under $CWD | 17:18 |
| lifeless | no-trees means that 'bzr branch' does not give you the source code to edit in the branch directoy | 17:19 |
| lamont | and can place-to-edit-source be "."? (I expect not) | 17:19 |
| awilkins | You still have a branch1 directory but it has no sources in it | 17:19 |
| lifeless | lamont: yes it can be . | 17:19 |
| lamont | ah, ok | 17:19 |
| lamont | I'll play later, and hug my scrollback | 17:20 |
| lifeless | lamont: (but I would tend not to use . because you wouldoften want several working trees with different CFLAG options etc | 17:20 |
| lamont | those go in the exported source tree, which has .bzr nuked... | 17:20 |
| lamont | and then sbuild chroots into the right place and does the build for me | 17:20 |
| lifeless | right, well - give it a play | 17:21 |
| lifeless | file bugs as appropriate | 17:21 |
| lifeless | you'll prbably mneed to ignore foo if you have the checkout above it :) | 17:22 |
| VSpike | If I want to split a source file into two smaller parts, is there any way to tell bzr of this? | 17:26 |
| liw | that reddit thread makes it pretty clear already that people using cvs and svn really hate branching and merging | 17:30 |
| liw | (news at 11) | 17:30 |
| liw | VSpike, I was going to suggest "bzr copy" but it doesn't seem to exist, hmm | 17:31 |
| LarstiQ | lifeless: speaking about copy, how are path tokens or a replacement scheme doing? | 17:32 |
| VSpike | liw: I can't see any commands that apply, but yeah copy would make sense if it existed | 17:36 |
| Odd_Bloke | liw: :D | 17:37 |
| liw | VSpike, yeah, I'm thinking you should just start a new file and "bzr add" that as if it were completely new | 17:37 |
| liw | VSpike, but you may want to wait a bit in case one of the people who actually know bzr wake up | 17:37 |
| Odd_Bloke | AFAIK, it's not possible ATM. | 17:40 |
| Odd_Bloke | The things LarstiQ mentioned would be ways of making it possible. | 17:40 |
| LarstiQ | last time I paid attention there were concerns about troublesome copy semantics, but that was a while ago. | 17:42 |
| liw | Odd_Bloke, I see you on that thread! | 17:44 |
| pickscrape | Yesterday I accidentally upgraded to 1.6b3 because of it being accidentally uploaded to the wrong PPA, but now I can't get 1.5 to install again | 17:51 |
| pickscrape | I uninstalled bzr, but reinstalling it just brings in the hardy version (1.3.1) | 17:51 |
| pickscrape | I still have the PPA in my sources.list | 17:52 |
| pickscrape | Oh wait... | 17:52 |
| pickscrape | 1.5 isn't in the PPA for hardy | 17:52 |
| pickscrape | That explains it. :) Anyone know when 1.5 for hardy will be uploaded to the PPA again? | 17:53 |
| james_w | pickscrape: you could check /var/cache/apt/archives/ to see if it has the 1.5 version | 17:53 |
| james_w | Martin seemed to hint that he was going to re-upload 1.5 to ~bzr and put 1.6b3 in ~bzr-beta-ppa | 17:54 |
| pickscrape | james_w: unfortunately not :( | 17:54 |
| pickscrape | We're going to be migrating from svk to bzr within the next week. Scary. | 17:55 |
| awilkins | To be honest, I've used both and svk is much scarier than bzr | 17:56 |
| pickscrape | Oh, I don't mean that bzr is more scary than svk | 17:56 |
| awilkins | No, the conversion! | 17:56 |
| * awilkins fears | 17:56 | |
| pickscrape | It's just a big change, and most of our developers really don't care about version control at all. | 17:57 |
| awilkins | I'm having to teach bzr to a team of business modellers who've only ever used MKS (which is a sort of eveil propritary hybrid CVS) but automated via a huge lump of Java | 17:57 |
| awilkins | Currently their tools sit still for 10 minutes every time you open them synching their files to MKS | 17:58 |
| awilkins | Contrast this to about 10 seconds doing a bzr pull and they start to care about version control | 17:58 |
| awilkins | I mean, the other team I work for had been contemplating for 2 years whether to use VSS or CVS, so I converted them to SVN in my first two weeks of employment and was accused of "having made the single greatest contribution to production quality on the project" | 18:00 |
| awilkins | TortoiseSVN taking most of the credit for making it understandable to mere mortals | 18:01 |
| pickscrape | nice | 18:01 |
| * awilkins is a bit of a VCS geek | 18:01 | |
| pickscrape | Right now I'm struggling to get everyone to even have a play with bzr using the demo migration I've already performed for them. | 18:01 |
| pickscrape | no doubt when we actually bite the bullet they'll then complain that they don't know how to use it | 18:02 |
| awilkins | Any like-minded "pathfinders" in the group? | 18:02 |
| pickscrape | You mean people who actually care? :) | 18:02 |
| pickscrape | There are a few, yes | 18:03 |
| awilkins | It took me a few days to get my head round it, and I've been admin-ing SVN and VSS for years, but it was less painful than learning to merge in svk | 18:03 |
| awilkins | Concentrate on the few, not the many. A choir sings better than a soloist | 18:03 |
| awilkins | better/louder | 18:04 |
| pickscrape | svk has become unscalable for us. The depot size is now 12GB. pulling some branches is now impossible because it exhausts memory. Syncing some revisions also becomes a massive memory drain that people struggle to complete. | 18:04 |
| awilkins | svk was a major improvement for me because I could take work home in a version-controlled way | 18:04 |
| awilkins | Ouch | 18:04 |
| pickscrape | Our main draw to svk was for the merge tracking. | 18:04 |
| awilkins | Yes, I found that SVK really, really ate CPU for no discernible reason | 18:05 |
| pickscrape | I even contributed to the SVK book a few years back. | 18:05 |
| pickscrape | My name's still on it I think | 18:05 |
| pickscrape | It just seems to have died though | 18:05 |
| awilkins | I mean, it's pulling deltas from the server which it should be able to just shove back into your local depot raw ; why does it eat so much CPU? | 18:05 |
| pickscrape | Yes, that confuses me too. And it seems to have got much worse of late too, inexplicably. | 18:06 |
| awilkins | Esp. the Linux builds which actually work when using replay API | 18:06 |
| pickscrape | The best thing though is that when you add, say, an image to trunk, that image gets duplicated every time you pull trunk to a branch | 18:06 |
| awilkins | Replay doesn't save much though, it just means you don't have to report when you start a transaction | 18:06 |
| pickscrape | One of the reasons why our depot got to 12G :) | 18:06 |
| awilkins | That's... yuck | 18:07 |
| pickscrape | Can you imagine the fun we have setting up a new developer? :) | 18:07 |
| awilkins | How big is your converted bzr repo? | 18:07 |
| pickscrape | We haven't imported history: too much chaff. the shared repo of the import of HEAD takes up about 79M, spread over a few separate repositories | 18:08 |
| awilkins | I think my biggest repo is still under 2GB, but people are working on it, they keep checking in huge trees of XMLSpy documentation output and the like | 18:08 |
| awilkins | If I can get the tip of 0.4 working properly in windows, I'll convert it over using bzr-svn and see where it goes from there | 18:09 |
| pickscrape | following over 40k revisions of doing it wrong, we figured we'd start afresh and do it right :) | 18:09 |
| awilkins | Any ideas about why that problem is occurring, jelmer? | 18:10 |
| awilkins | pickscrape: Depends on how many branches you are supporting actively in the old depot I suppose | 18:10 |
| pickscrape | awilkins: I think I need to migrate about 20 at the moment. | 18:11 |
| === edcrypt1 is now known as edcrypt | ||
| === mw is now known as mw|food | ||
| Percept | Hi, can anyone direct me to some information how to use bzr (or any other CVS for that matter) with webprojects which have a database like MySQL? | 20:22 |
| Percept | since the database is always located at another place then the folder with my files | 20:22 |
| Percept | realises this is prolly a stupid question) | 20:22 |
| Odd_Bloke | Percept: Normally you would only keep your database schema in version control, with something else to take care of backing your database up. | 20:23 |
| Percept | Odd_Bloke: ah so it's not common practice to have the DB with content in version control then? | 20:24 |
| Percept | Odd_Bloke: doesn't sepperating the db-backup from vc make the whole thing less managable? I'm really new to VCS but I really need to learn | 20:25 |
| Percept | I read the user guide ... seems easy enough just didn't get how to deal with databases | 20:27 |
| Percept | getting your database under VCS http://www.codinghorror.com/blog/archives/000743.html and http://www.martinfowler.com/articles/evodb.html | 20:46 |
| jam | Percept: well, that also sounds like it is someone selling a product :) | 20:51 |
| jam | I would generally always keep the schema under VCS | 20:51 |
| jam | It sort of depends on how critical the *data* in the database is | 20:52 |
| Percept | jam: the ccomments are interesting :) | 20:52 |
| jam | Most DB's I've seen the database itself should be backed up, but the actual *data* wasn't something I would version | 20:52 |
| Percept | which referred me to the second lin | 20:52 |
| Percept | link* | 20:52 |
| jam | Just like I would version the program I'm writing | 20:52 |
| jam | but I wouldn't version the generated output | 20:52 |
| jam | Reading the comments, they seem to be saying approx the same thing | 20:53 |
| Percept | jam ok sounds logic (now ... was really lost on how people managed their DB's) | 20:53 |
| jam | that it is the *schema* that they care about | 20:53 |
| jam | The DBs I worked with had everything written in .sql files, and some python scripts to load that into the DB, and take care of stuff like upgrading. | 20:54 |
| jam | I know Launchpad even has stricter rules for versioning. In that patches that make changes to the schema can only be landed at certain times, etc. | 20:55 |
| === mw|food is now known as mw | ||
| Percept | I read something about luanchpad in the user docs but I don't really kno what it is yet | 20:56 |
| Percept | gotta start ith the basics first :) | 20:56 |
| Percept | with* | 20:56 |
| === mark2 is now known as Guest60896 | ||
| === mw is now known as mw|out | ||
| LaserJock | is there a way to branch a specific range of revisions? | 23:41 |
| LaserJock | I want to branch everything up to a certain revision | 23:41 |
| cody-somerville | LaserJock, -r | 23:42 |
| LaserJock | that only gets a specific revision | 23:42 |
| beuno | LaserJock, -r ..X? | 23:43 |
| LaserJock | wait no, cody was right | 23:43 |
| LaserJock | the documentation messed me up | 23:44 |
| TejasPP | jelmer, recently I saw your shell-hooks plugin and it's great | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!