=== jaypipes_mysql is now known as jaypipes [00:07] lifeless: in a structure like /repo/tom/feature1/ for example, tom is a branch? or only feature1 ? [00:07] i need to create tom/ withg 'bzr init tom' ? [00:09] nefertum: both can be, it's more usual to have only feature1/ be the branch though [00:09] LarstiQ: i have the next problem...i have in a machine a repo and in local i've created a new branch that i've just pushed to the server [00:10] but now i don't know if i can get all the content of the repository [00:10] in the remote server the repo is /bazaar, and i've created the branch /bazaar/main [00:11] but if i created /bazaar/feature1 i'd like in the future to get all the repository content in another machine, for example [00:11] you mean you want to get all the branches instead of specific ones? [00:12] yes, all the repo tree [00:12] i have to do a checkout? [00:12] nefertum: no [00:13] nefertum: maybe I don't really understand what your goal is [00:14] like in svn, i can do svn co url/svn/repo/ and this gives me all the repo [00:14] i don't know how to do this in bazaar [00:15] fwiw, I think you can just copy it [00:17] nefertum: in bazaar branches are much more loosely coupled with a repository [00:17] (than in subversion) [00:17] aham.. [00:18] nefertum: but even in svn, there are usually only a couple of branches you care about, and not the rest [00:19] yes...that's what i've seen [00:20] nefertum: unlike svn, in bzr a repository is just a place to store revisions. you can have standalone branches (without a separate repository) [00:21] Verterok: the idea is that i'd like to have a remote server with a repository and i don't know if i should create it first in the remote machine or push the repository from my local repo... [00:22] basic things i supose... [00:22] you can just create it on the remote side [00:22] nefertum: first, we should clarify what a repository means :) [00:23] mmmm, well, in bazaar is also my local branches, but i mean about a server that stores the main branches in a project [00:23] so the developers push the changes in it [00:24] nefertum: in that case, as AmanicA said, you can create it in the remote side [00:24] aham... [00:24] ok, but i should create with --no-trees or --trees ? [00:25] nefertum: and probably you would have a local repository in you workstation [00:25] nefertum: if its on a central server, --no-trees [00:25] I prefer --no-trees on the central server [00:25] yes, actually i have a local repo [00:25] ok, so i can create an empty repo with --no-trees an later push my branches in it? [00:25] nefertum: if its on your workstation, and you want to edit your code inside the repo (rather than doing a checkout), --trees [00:26] nefertum: yeap [00:26] i'll try... [00:43] i find myself wanting to do cd :this [00:44] will `bzr cd :this` work ? :) [01:10] markh: I recently got a very cryptic bzr-svn message on windows, is there a list somewhere (I looked at http://bazaar-vcs.org/WindowsDownloads and regular Downloads) that mentions what components go into a specific installer release? [01:13] LarstiQ: not really :( There is a wiki that describes the parts needed, but the version numbers are often stale - eg, bzr-svn is now using svn-1.5.x rather than 1.4.x. [01:14] markh: that's exactly what I ran into btw, a "upgrade your Subversion client" message [01:14] LarstiQ: that wiki page is http://bazaar-vcs.org/WindowsInstall [01:14] markh: thanks! [01:14] I've seen that error on my local svn repos lately too (ie, without bzr-svn) [01:14] markh: so the installer has it's own subversion library? [01:14] yeah [01:15] aaah, ok [01:15] markh: the problem was that I had a svn 1.5 working copy [01:15] LarstiQ: you using 1.7 binaries? [01:15] or 1.6? [01:15] markh: and then tried to bzr diff on that, but I guess it must have been with 1.4 [01:15] markh: 1.5 [01:15] 1.6 was built with 1.4 [01:15] right! [01:15] 1,7 is built with later libs [01:15] * LarstiQ nods [01:15] that should fix it in this case then [01:16] IIUC, 1.5 used the "pysvn" bindings - now bzr-svn uses its own bindings [01:16] markh: Would it be possible to detect if TortoiseSvn is installed and use those libraries? [01:16] markh: right, but it steel needs an svn library to talk to? [01:16] still even [01:16] it would be a bit of a qa nightmare. But for 1.7 etc, we should be using the latest available anyway... [01:17] yeah - but what svn library was used was outside the control of bzr-svn - it just relied on whatever pysvn uses. Now things are directly under bzr-svn's control [01:17] it bundles the full svn runtim [01:17] ah ok, so less problems there [01:18] markh: the main thing to do I guess is to catch that message thrown by svn and display something that makes more sense to the user [01:18] markh: since upgrading Tortoise makes the problem of incompatible working copies worse :) [01:19] LarstiQ: but IIUC, only old bzr clients will display that message, and its too late to fix them? [01:19] * LarstiQ will file a bug/patch for that tomorrow [01:19] markh: I'll test it [01:19] markh: for svn 1.5, yes. But if I use svn trunk I think I'd get the same message [01:20] IIUC, the problem is the old version of bzr you have uses old versions of svn libs? And newer TSVN and bzr versions use a later version? [01:20] markh: correct [01:20] LarstiQ: right - so you want to upgrade just the bzr-svn for your old bzr binary? [01:21] I mean, your old 'svn.exe' copies will no longer work either. All the other tools need an upgrade to work - same with bzr [01:21] markh: for my concrete problem, I'll just install bzr 1.7 [01:21] (fyi, 1.6 uses old svn too - only 1.7 has svn 1.5) [01:22] markh: but when the next svn release comes out and is incompatible, there is a window for confusing errors until we can say "use the latest bzr installer, that will work" [01:22] markh: ok [01:22] markh: so I'd like to nail that confusing message before the next incompatible svn release comes out [01:23] right. === kiko is now known as kiko-zzz [01:58] what-da-fark ? [01:58] bzr: ERROR: No module named chkmap [01:58] You may need to install this Python library separately. [02:08] lifeless: that dependency issue has caused a lot of failed marriages when it crops up while driving [02:09] hhe [02:09] heh* [02:09] spiv, are your around? [02:09] you* [02:09] typo city [02:10] oh, is that where we're going? i'm pretty sure it's the next left. no need to get the map out ... [02:10] * mneptok accelerates and turns up the radio [02:17] poolie: yeah [02:22] would my comment at the end of https://bugs.edge.launchpad.net/bzr/+bug/260335 be allright? [02:22] Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid] [02:25] poolie: that seems ok. We certainly don't want to advise downgrading :) === jaypipes is now known as jaypipes-afk [03:33] out to lunch, biab [04:49] I'm pushing a new revision up to a stacked branch and getting a "Revision {...} not present" error. [04:50] I had just created that branch, did a local commit, and then pushed again. [04:50] board 1 [04:50] * fullermd twitches. [04:53] I get the same thing even if I don't commit :( [04:53] oh, branchformat6... [05:01] i guess someone should file a report for that bug :( [05:24] after upgrading to bzr 1.7, I won't be able to push to a remote ssh repository anymore. Any ideas? [05:24] leo2007: why won't you be able to? [05:39] lifeless: I've just posted the error here: http://pastebin.com/d7f25357c [05:40] markh: see leo2007's traceback [05:40] thats a new one :) [05:42] leo2007: do you use putty or ssh? [05:42] leo2007: your use of the future tense was quite confusing :) [05:43] markh: sorry for my English. I used to be able to push to remote server with version 1.5. But couldn't. I use putty. [05:44] leo2007: Try setting BZR_SSH=plink and trying again [05:44] ie, at the cmd-prompt [05:44] set BZR_SSH=plink [05:44] and try again [05:47] markh: same error [05:48] hrm - is plink.exe on your path? The traceback shouldn't reference paramiko if putty's plink is being used (I think :) [05:48] markh: paramiko provides our sfp:// implementation, FWIW [05:49] lifeless: right - sftp:// urls? But ssh+... ones use ssh/putty? [05:49] hrm [05:50] * markh thinks he is confused... [05:50] putty/ssh only used for auth, not for "remote file-system" work? [05:51] The windows error message for that error code is the (not very helpful) "'Key not valid for use in specified state." [05:52] oh [05:52] I've seen this error before :( [05:52] The new error is here: http://pastebin.com/d5fe02026 [05:52] markh: if you use bzr+ssh then paramiko shouldn't be needed; but if you use sftp then paramiko gives use the parsing logic, still use putty or whatever for the transport [05:53] plink is in my path [05:56] poolie: ping [05:57] poolie: I need to decide where to put some tests; you've moved the pack repository specific tests out of test_repository, but these tests I am writing are not really pack specific [05:57] poolie: rather they are the actual format I'm working on specific [05:57] I would have previously put them in test_repository, I'm just not sure why the pack ones got moved out, I'm confused and wondering if I should be doing the same [05:58] markh: I vaguely recall a thread or two on the paramiko list about random number sources, perhaps that's related? [05:58] ah yes, its all coming back to me now :) Its a bug I reported in pycrypto a while back [06:00] hrmph - the bug was #1343753 at sourceforge, but apparently the project is now managed at launchpad - and there are 20 bugs in total ever reported. It is as if the bugs didn't migrate. [06:01] so I can't work out the status of the bug in that package at the moment :( [06:01] a copy of the sourceforge bug message is at http://osdir.com/ml/python.cryptography.cvs/2005-11/msg00000.html [06:03] so what's the solution? [06:04] good question :( Use the version you were in the past for now I guess... [06:08] the bug still exists in pycrypto best I can tell. I guess I better open a new bug. [06:09] where to get older versions? [06:11] leo2007: https://edge.launchpad.net/bzr/+download [06:11] (Or just https://launchpad.net/bzr/+download) [06:12] spiv: of pycrypto ? :P [06:12] lifeless: (back) [06:12] lifeless: I thought it was bundled in the win32 installer? [06:13] re test_repository: as i recall, test_repository was just getting too big [06:14] and, i think having one file or module per scope of parameterization is probably something good to aim for [06:15] leo2007: I might be able to get a fix in an hour or so - will you be around? The error doesn't happen everywhere, so having someone to repro it is important... [06:15] poolie: on the former, mmm, possibly. On the latter, I disagree [06:16] poolie: because, it makes choosing to parameterise a heavier task than it should be [06:16] markh: I'll be around and happy to test [06:16] it's (just) over a thousand lines, that's the point where i start wondering if it can easily be split [06:17] do you mean that if parameterizing means adding a new file it'll make people not do it? [06:18] poolie: yes [06:18] poolie: jam has complained about the cost already, comparing it to mixins [06:18] I am restarting my computer. [06:18] poolie: not to mention that we have lots of examples of parameterisation within a single module already [06:19] so, my thinking was basically "hm this is getting big; oh, these tests are somewhat logically separate so i'll hive them off" [06:19] this is not to say they must always be that way [06:20] as i see it the cost is in understanding how to set it up - like that 20-25 line function we looked at yesterday [06:37] so a recent bug on pycrypto's launchpad page has just been marked "fix committed" - but the points points at some *git* repository! [06:38] there are 4 bzr branches on launchpad, but none are marked as "trunk" nor owned by the project itself. I'm really not sure *where* the trunk is! [06:45] markh: the homepage linked from launchpad.net/pycrypto does list a git branch, so I guess that is the current trunk. [06:48] right - so the "problem" seems to be a new maintainer. The most recent version looks like it came from amk's launchpad branch [06:57] hi all [07:01] vila: good afternoon [07:12] leo2007: grab http://starship.python.net/crew/mhammond/Crypto.Util.winrandom.pyd and replace the existing copy of that file in the bzr directory with the new copy (take a copy of the old one first though!) [07:16] jelmer: i have a self-contained local reproduction now. === jfroy is now known as BahamutZERO [07:19] vila: thanks for that review === BahamutZERO is now known as jfroy [07:26] jelmer: this is the weirdest crash i've seen in a long time [07:31] leo2007: any joy? [07:35] spiv: thanks for yours :) [07:36] anyone want to try and reproduce bug #276219 with the tarball i posted? [07:37] Launchpad bug 276219 in bzr-svn "Segmentation fault in the calling of subversion libraries." [Undecided,New] https://launchpad.net/bugs/276219 [07:37] just wanna make sure i've done enough for others to reproduce, and it reproduces it on my machine, but that's hardly a good sample [07:46] markh: I will test it in a minute. [07:46] markh: need to reinstall version 1.u [07:46] s/1.u/1.7/ [08:05] spiv/lifeless: re your comment on bug 260335 - we're still issuing this error about Repository.get_parent_map in 1.8pre [08:05] Launchpad bug 260335 in launchpad-bazaar "Server is too old for streaming pull, reconnecting. (Upgrade the server to Bazaar 1.2 to avoid this) " [Undecided,Invalid] https://launchpad.net/bugs/260335 [08:11] jml, are you still here? [08:14] poolie: yes. [08:14] poolie: you mean when the client is 1.8pre? What version is the server? [08:15] so jml said that error still occurs if you use 1.5 against a 1.6 server [08:15] the error seems to be issued from inside get_parent_map [08:15] did we really remove that, and if so why is the client still trying to call it? [08:16] and, kind of related to that, the conclusion the client draws if its unsupported is that the server is older than 1.2 [08:16] so if what was said in that bug is correct, maybe the other code is wrong? [08:19] Any idea why the signature tab of bzr-gtk's visualize would say "Revision committer is not the same as the signer." for all the revisions for which I just did `sign-my-commits`? [08:19] I'm confused. The error in that bug will be emitted by 1.5 against a 1.6 server because the streaming pull verb (Repository.stream_revision_chunked) was removed as fallout of the versionedfiles work. [08:19] I don't see anything in that bug talking about get_parent_map or get_revision_graph? [08:20] ok i might just be confused... [08:21] poolie: the guy that filed it is running 1.5 [08:21] poolie: he says 'i want to run whats in debian stable' or something like that [08:23] in other news, I've written a dumb CHKMap [08:23] and am fixing repository so it can work with a CHKMapInventory [08:24] poolie: was here something you wanted in particular? [08:24] jml, i was just going to ask you about your comment on that bug [08:24] AfC: maybe it's verifying that the committer ID (i.e. the 'bzr whoami' of the committer) matches an ID on the GPG key that signed it? [08:24] but it's fine [08:24] * spiv -> yoga [08:24] ok :) [08:29] spiv: not sure. Have a happy downwards dog. [08:34] afc, that would be my guess too that it's used the wrong userid [08:34] does it show which one did sign it? [08:34] poolie: yeah, it does [08:34] poolie: and it notes that that one is ultimately trusted [08:34] but is it the same as the committer userid? [08:35] um [08:35] huh? [08:35] I'm not really sure what you're asking. I issued `bzr sign-my-commits` and it chugged away for a while. [08:35] so [08:35] you said that bzr-gtk complains that "revision committer is not the same as the signer" [08:36] and i'm wondering if they are actually different, or if it's just misunderstanding them [08:36] poolie: that's what it's saying [08:36] and if they are different, in what way they're wrong [08:36] poolie: I'd assume so [08:36] but does it show you which key was used to sign it? [08:36] Yes its does. [08:37] I mean, it could only have identified what key to use to sign what commits if sign-my-commits made the correlation. So is bzr-gtk not using the same logic maybe? [08:37] that's what i'm wondering [08:37] Yes its does -> mine [08:39] [This is in the category of "I'd file a bug if I knew I wasn't doing something wrong and if I knew what to report"] [08:40] could it be that your gpg key does not have a uid for precisely the same address that was used to make the commits? [08:41] Hm. [08:41] Yes, I guess that's the case. [08:41] bzr whoami : Andrew Cowie [08:42] gpg --fingerprint ... : uid Andrew Frederick Cowie [08:42] So, like, the fact that `sign-my-commits` figured out what key to use is sorta damning as far as `visualize` is concerned, right? [08:45] well, they should be consistent with each other [08:45] Or, put the other way, how on earth did `sign-my-commits` know what to use if it is going to be so pedantic as to try and match the stuff outside the email address? [08:45] yeah [08:45] i'd be inclined to say that sign-my-commits should complain if there's no key that corresponds to your committer address [08:45] AfC: gpg has a default key for signing [08:45] Well, it's too late now. The testaments are made, and I'm sure not about to change my key. [08:46] lifeless: ah, yes, I have that set. [08:47] poolie: (though I point out that there IS a key that corresponds to my committer _email_ address. I had assumed that was what it looked up until Robert pointed out that maybe gpg did the default thing) [08:49] AfC: well, it shouldn't sign somebody else's revisions with your key [08:50] I would hope not :) [08:50] and as far as gpg is concerned, the uid was different so technically it's somebody else [08:50] * luks would report a bug against bzr sign-my-commits [08:50] {shrug} [08:50] * AfC hopes sign-my-commits keeps doing what it's doing, actually. [08:50] otherwise I won't be able to use it anymore. [08:51] you can have multiple uids on your key, can't you? [08:51] so, there is a separate key (not uid) that it's used instead? [08:52] luks: I've worked hard not to pollute my key. I'll keep it that way, thanks. [08:52] ok [08:52] poolie: no, I only have one uid on one key. [08:52] poolie: the email address of the uid matches `whoami` [08:56] Huh. My key is back into the top 100. How about that. Can't say as I've been doing _that_ many signings lately. I guess a bunch of keys must have expired. [08:56] afc, and it's the same uid as on the revisions? [08:58] poolie: `bzr vis` reports key 57F6E7BD was used to sign the revisions. That is indeed me. Judging by what flew by when I ran `bzr sign-my-commits`, I'd say that my key was in fact used to sign, correlating what visualize is saying. [08:59] poolie: The only crink in the works is that something is not recognizing that 57F6E7BD is me (or, more to the point, the same person as "Andrew Cowie ") [08:59] ok, so it seems like there's a bug in bzr-gtk displaying that warning when in fact the key does correspond to the author [09:56] when bzr tries to delete a directory during a merge or pull, it baulks if the directory is not empty [09:56] does it factor in whether or not the files in question are "ignored"? [09:58] sabdfl: i think so; if not that would be a bug [09:58] hi btw [09:59] howdy! [10:03] hi, we have a branch where a binary directory (about 30M) has been checked in (a while back) which makes the whole thing much larger than it needs to be. Is there any surgery I can do that drops this directory from the history and the branch? [10:03] (it is not a public branch) [10:03] arnarl: you can use launchpad.net/bzr-rebase to make a new history in which "that never happened" [10:04] but carrying across your later commits [10:04] you'll have to get everyone to restart their work based on that branch [10:04] poolis: sounds great [10:04] what do you mean by restart? [10:04] check it out again? [10:04] yes, [10:04] ah, that shouldn't be a problem [10:04] poolie: thnx [10:24] Hello all. I'm trying to "bzr init" in an existing directory and I'm getting an error saying "No repository present". Any idea what I'm doing wrong? [10:27] lllama: what does 'bzr info' show there? [10:27] lllama: what version of Bazaar are you running? [10:32] poolie: Same error [10:32] AfC: 1.6.1 [10:33] lllama: that's certainly reasonably recent. [10:33] is there a traceback? [10:33] lllama: is there a .bzr directory in any parent directory above where you are trying to `bzr init` [10:33] lllama: ? [10:33] poolie: Nope. Just a "bzr: ERROR" line. [10:33] AfC: checking.... [10:34] AfC: Ah. There is. There shouldn't be though. [10:34] If I do a bzr st in the parent then I get told it's not a branch. [10:35] same with info. [10:36] I'll try moving the .bzr dir out of the parent and see what breaks... [10:38] Hm. Same error. I think I'll try a big clean out. [10:40] lllama: if pain persists can you look in ~/.bzr.log, see if there's a traceback at the end, and put it in answers.launchpad.net/bzr [10:43] markh: sorry I won't be able to test the new BZR. [10:43] poolie: will do. Thanks for the help. === kiko-zzz is now known as kiko === Ng_ is now known as Ng [11:56] Folks, i got bzr-synchronized dev and live setups of php app. Problem is, there are certain parts of few configuration files that have to differ on those installations, but leaving those files entirely out is not a good solution. I was wondering if there was way to mark part of file to be "ignored" by bzr, or how is such situation best handled? [11:57] zrg_needsjob: that's not possible [11:58] zrg_needsjob: the usual ways are to have a .local file which is included in to the main one, if possible with the format [11:58] zrg_needsjob: or have a .template which is copied and customised in each branch [12:00] james_w: including unfortunately not possible but would be good solution, what do you mean by template? [12:01] zrg_needsjob: can you just merge only one way? [12:02] zrg_needsjob: the same file basically, but with blanks for the passwords or whatever. When you make a new branch you copy the file and make any changes necessary. It's a pain to update the common bits then though [12:04] bob_2: there are occasional changes in live setup too that have to be backported and actually now i have 2 dev setups. they all use same remote repository, so commits and updates go whichever way. === jamesh_ is now known as jamesh [12:06] ignore blocks would be cool feature tho i think :) [12:21] does trac-bzr work with trac 0.11? [12:52] is it possible to get colored difs with bzr? [12:52] thrope: Yes, look at the cdiff command in bzrtools. [12:54] Odd_Bloke: great - had it installed just didnt know the command, thanks === jaypipes-afk is now known as jaypipes === kiko is now known as kiko-phone [13:51] hi people [13:52] when using bzr-svn, how does one specify the username to authenticate? [13:52] nosklo: http://user@host/svn/... is one way [13:55] LarstiQ: is there another? :) [13:56] trotek: yes, but it depends on what you are trying to do [13:56] when I do it. It segfaults :( [14:00] bzr-svn just segfaults, no traceback. http://dpaste.com/81664/ === kiko-phone is now known as kiko [14:07] nosklo, what version of bzr-svn? === thunderstruck is now known as gnomefreak [14:08] jelmer, bzr 1.3.1, bzr-svn 0.4.9 [14:08] jelmer, ubuntu default [14:08] nosklo, 0.4.13 should work better [14:09] jelmer, okay. updating. [14:36] Heh, mercurial still can't cut it for my use case [14:36] It still goes "boink" on long paths with lots of caps in them [14:38] They're getting way ahead of us. bzr still doesn't even have a prototype "boink" feature :| [14:38] I'll try to make a plugin [14:39] I think I'd prefer "boink" to be written in Erlang, not Python [14:39] That way you can work on other implementations of "boink" and replace them at runtime without interfering with other instances [14:39] Although doesn't stackless Python achieve that also? [14:39] Quick, let's rewrite bzr in Erlang. [14:39] True. We could be the only VCS on the planet that supports massively-parallel boinking. [14:40] Only then can it be truly distributed version control. [14:40] sabdfl, poolie: We don not factor in if the files are ignored. We don't know if they are ignored because they are private (your secret passwords) or because they are junk (your .pyc cruft) [14:40] so when we delete a directory, it must be fully empty [14:41] "boink" ? [14:41] it is an open bug that we want to solve [14:41] I think we were talking about putting things in a "lost+found" or something like that === thunderstruck is now known as gnomefreak === toytoy_ is now known as toytoy === thunderstruck is now known as gnomefreak === jaypipes_mysql is now known as jaypipes [15:55] * fullermd contemplates being left in a darkened room with `log -v` and a blunt object. [15:57] Gaah. Stupid inability-to-refer-to-historical-files bug! [15:57] * fullermd stabbies. [16:00] fix it [16:01] I have had many clients that have asked the following question with many vcs's, any idea how to do with bzr? Q: How do I export *only* the files changed since the last revision or a specific revision? [16:02] The idea is they only want to push the smallest set of changes when version production-type deployments. [16:02] davidmac: use bzr-upload? [16:03] You could wrap a little scripting around 'stat' to do it, I s'pose. [16:03] Or just use bzr diff | patch [16:03] Or what LarstiQ said. Depends on just what's involved in the deployment. [16:03] hmmm. I'll check into that. I don't think diff is the answer they want. I'll explain deployment... [16:04] Just an example: They version production which has a lot of binaries: executables, images, etc. on linux and it is very large to do a full export from stage to prode. They only want to export the changed binaries so they can zip them up and send them from stage. [16:05] I'm new to bzr so I'll check in to bzr-upload and stat. [16:06] 'zip them up and send them from staging', is there some difficulty in getting something to production? [16:07] Yes, in many cases. This specific client has that case. They are in a hosting environment where they can make changes in dev and stage, but have to provide a tgz file when pushing to prod. [16:07] How does that handle deletions or moves? [16:07] Ops team doesn't want them sending the entire 2 gig file every time, just the changes files. [16:08] It doesn't handle deletions and moves, pretty problematic as I see it. I'm encouraging them to use bzr in production too to export a tagged build. [16:09] I was thinking as a temporary workaround, since they have control of stage, they could just do a find -mtime type of approach to create a zip. [16:10] Anyway, wrapping some scripting around 'stat' to figure out what to export is probably the easiest way to work up a tarball. Still won't do well at moves, or at all at deletions. Dunno how you could do that easily. shar, maybe. [16:10] thx [16:10] You can use bzr stat -rx..y to see what files were touched between those revs, and go from there. [16:10] very kewl fullermd, I'll check that out [16:10] One more piece of advice I need, then I'll leave you guys alone :) [16:11] (for scriptability, especially see stat -S) [16:12] This is the logical description of what they want to do: They have a program.cfg config file for dev, same name but different contents for dev, also for prod. How would you recommend they do an export and get only the correct config file in each environment? [16:12] They have done this with clearcase filters before. [16:13] Well, I do similar things by having a dev.conf and a live.conf under version control, and just choose which is applied in each case by a symlink. Whether that's an option in your environment... [16:14] k, anything is an option at this point, just looking for inputs in case there is some elegant semi-automatic way to do it in bzr. [16:15] Not really. What's versioned is what's versioned. You could have the contents of the files be different in different branches, but that would take careful manual maintenance merging between them. [16:15] I find it easier to just have the separate files, and have the program load a "conf.conf" or something that's a symlink to one or the other. [16:16] (it also means I can craft up custom conf.conf files for certain places to have different settings, without having to worry about them being local changes not to commit) [16:16] Okay, thanks. And thanks for all your help. I like what I've seen so far of bzr, so much that I'll probably start hacking some plugins or scripts myself, and maybe a ulipad integration :) [16:18] y'all have a good one! === thunderstruck is now known as gnomefreak [16:44] º [16:44] ups [16:48] hi - I am using bzr-svn in what I think it the recommended way - I have a checkout of my svn trunk, which I branch to do work, then merge updates, then merge into my bazaar checkout and commit to svn [16:48] this is working great - it is really nice to be able to work with subversion in this way [16:48] but I loose all the information about the commits in the branch - in subversion I just see the merge commit [16:49] thrope: Check out the 'rebase' plugin. [16:49] I wondered if there is a better way of working - or perhaps a bazaar plugin to automatically propograte the commit message with some infromation about the seperate commits. [16:49] Odd_Bloke: I have the rebase plugin - but I must admit I have some trouble understanding what it does [16:50] Odd_Bloke: do you mean I should rebase my trunk bzr checkout before comitting [16:50] thrope: I'm not entirely sure myself, I don't use it. But you should 'rebase' your branch onto the trunk. [16:50] no - you mean rebase my branch to the trunk checkout before merging (then I could push in theory) back and committing to svn [16:51] thrope: Yes. [16:51] That essentially throws away the commits in your branch and creates new, similar ones based on a different revision. [16:51] right I think I get it [16:52] Which is fine, so long as you haven't branched from the commits that are being thrown away. [16:52] I didn't want that initially because it's nice to have the branch structure in my bzr trunk, but I loose it in svn. If I do the rebase, I have all the commits in svn (and my bzr trunk) but I loose the branch structure in my trunk [16:53] thrope: Why are you using SVN? [16:53] You could perhaps push your branches to SVN branches... [16:53] jelmer will know better. [16:53] partly habit, got all my stuff in there at the moment, partly because it's easier to work with other people and has nice things like viewvcs [16:54] thrope: For the latter, have you seen Loggerhead? [16:54] also I didn't quite figure out how to have a central bazaar repo that works like svn - I work on a lot of different machines and use svn to keep them in sync [16:54] thrope: bzr-snv will set the meta data so at least the bzr revisions will be known, even if you only see the merge commit in svn [16:54] ok [16:54] you can set push-merged-revisions in newer versions of bzr-svn [16:54] LarstiQ: But the bzr revisions won't be pulled into a new branch, you'll get ghosts, right? [16:54] and it'll push the merged revisions as well, not just the mainline [16:55] jelmer: So, to answer my own question, 'no'? [16:55] Odd_Bloke: right, but you could distribute your bzr branch for other bzr users to pull from, or apparently set push-merged-revisions ;) [16:56] Odd_Bloke: I had a look at loggerhead and will try and install it - but it wasn't clear to me how to run a centralised bzr branch on a remote server... If I understand to update I need to merge 'into' that central branch to maintain the mainline - which would require logging onto the server... I couldn't see anyway to push a merge and resolve conflicts remotely [16:57] thrope: The way to do it is to keep a pristine copy of the branch locally. [16:57] So you merge into the pristine copy and push from there. [16:58] thrope: If you've been doing that and it hasn't been working, something's going wrong somewhere along the line. [16:59] Odd_Bloke: no I haven't really tried because everythings in svn at the moment anyway... I will have a look though [17:00] jelmer: where do I set push-merged-revisions? [17:01] thrope, in ~/.bazaar/subversion.conf for the relevant repository [17:01] ok thanks [17:01] thrope: s/push-merged-revisions/push_merged_revisions/ === kiko is now known as kiko-fud [17:37]