[01:26] what the crap? [01:26] bzr: ERROR: exceptions.AttributeError: 'Inter1and2Helper' object has no attribute 'source_repo' [02:16] I was hoping bzr serve would permit some kind of minor password authentication. [02:17] I want to setup some people with TortoiseBZR because they are major lusers who can not cope with plink, etc. stuff. [02:17] Is there some option for this? I'll resort to IP address restrictions if I have to, but ... [02:26] No, the bzr:// protocol doesn't have any of that. There've been occasional discussions on the list; I think somebody posted some WIP patches once. [02:26] You could try setting up the bzr+http:// smart server, and using HTTP auth via Apache etc. [02:29] Does Windows really still not have a good SSH story? [02:33] Oh, c'mon, just put the ball ON the tee for us, why doncha... === timchen119 is now known as nasloc__ [05:42] is there a solution for nested projects as part of bzr yet? [08:04] lp:~canonical-bazaar/udd/hottest100/ [08:04] lifeless, poolie, vila: ^^ [08:04] lp:~canonical-bazaar/udd/hottest100/ [08:04] lp:~canonical-bazaar/udd/hottest100/ === sven is now known as Guest18727 [09:20] I created a branch with bzr clone, but I want to treat that branch as if it's the original source now, how do I remove the "parent repo" relationship from it? [09:24] You can edit it out of the branch.conf. But what makes you think you need to? [09:25] 'parent' doesn't mean any sort of dependancy; it's just the default place that 'pull' looks to. [09:25] when I try to pull from the new location from a client, it's giving me an error about being unable to write to the original parent [09:26] Being a parent branch will never make it try to write there. That's something else; you have it bound, maybe. [09:26] What does 'info' say it is? [09:28] oh, must be my client spewing that, because the error is about an https: repo, and the new repo shows it with a bzr+ssh: on the old location [09:28] the client had formerly checked out from the old repo, and I was trying to update it with bzr pull --remember (new repo location) [09:28] Try "bzr switch". [09:30] ok, that almost works. [09:30] Yes, pull probably isn't what you want to do in a checkout there. [09:30] my cleint's too old. [09:30] client* [09:30] Eep, too old for what? How old is it? [09:30] Bazaar (bzr) 1.18 [09:30] repository format is 2a [09:31] 1.18 can grok 2a (but definitely not as well as a recent 2.0.x, true) [09:33] bzr: ERROR: KnitPackRepository('file:///(local checkout)') is not compatible with RemoteRepository(bzr+ssh://(new repo)) different rich-root support [09:33] Hm, can you "bzr upgrade" a checkout to a rich-root format? [09:33] That's not a bzr version problem; that's because your checkout is a poor-root format (e.g., pack-0.92 or the like), and the upstream you're wanting to move to is rich-root (probably 2a) [09:34] Peng: yes [09:34] ok, so upgrading the local checkout first might work === jam1 is now known as jam [09:36] lifeless: Oh, nice. That makes sense, but it's kind of the thing I'd expect to blow up. :P [09:36] justdave: It will work. Have faith! :D [09:36] yeah, it's converting now [09:37] fullermd: cat /proc/cpuinfo :P [09:37] hi there, is there anything I can do to fix this? [09:37] bzr: warning: unsupported locale setting [09:37] Could not determine what text encoding to use. [09:37] This error usually means your Python interpreter [09:37] doesn't support the locale set by $LANG (en_NZ.UTF-8) [09:37] Continuing with ascii encoding. [09:37] timClicks: sudo dpkg-reconfigure locales, or whatever it is. [09:37] timClicks: yes, make sure that you have po files for that locale. [09:37] timClicks: if thats turning up when you push, talk to the sysadmin of the server you are pushing to [09:38] okay, should be fine [09:38] is this a warning or an error? [09:38] is it fatal? [09:38] * timClicks reads text... warning [09:39] Also "Continuing". :D [09:39] :) [09:39] Nah, it just means bzr won't give you Unicodey goodness. [09:39] Other software is likely to complain about the same thing. [09:40] hrm [09:40] i don't have sudo rights to this machine [09:40] So you really should fix it. It's not hard. [09:40] Ah. [09:41] ...If the sysadmin hasn't fixed this, maybe it's running a kernel vulnerable to those privilege escalation vulnerabilities? :D [09:42] lifeless: cat: /proc/cpuinfo: No such file or directory :p [09:43] Wait, why are we talking about /proc/cpuinfo? [09:43] timClicks: Are you sure that's a valid locale in your system in the first place? Check `locale -a`. [09:43] I presume he's poking at my bug comments. So I poke back ;> [09:44] Peng: bug tracker fun [09:44] well, it's my own machine's locale [09:44] i've sshed into another [09:44] and am trying to run bzr within it [09:44] Sure, but locale names can differ by platforms. [09:44] Peng: what privilege escalation vulnerabilities? [09:44] lifeless: Linux kernel. Past few months. [09:44] You have have en_NZ.UTF-8, while another platform may call it en_NZ.UTF8 or something. [09:44] * Peng waves hands [09:44] Peng: for /locales/ ? [09:45] fullermd: they generally Just Work [09:45] lifeless: No, so you can get root and fix the locales. :D [09:45] Well, using zh_CN locales makes you vulnerable to Google, doesn't it? 8-} [09:45] (This is probably illegal and not actually recommended.) [09:45] Peng: oh, groan. [09:45] timClicks: you can also tell ssh not to pass all your env variables over [09:45] Sorry. When I have nothing useful to say, I make bad jokes. [09:45] I don't recall how to do that offhand. [09:45] grep LANG /etc/ssh/ssh_config [09:46] I'm pretty sure ssh doesn't pass locale stuff like that. It would probably be in shell rc files on the other side... [09:46] Ah, SendEnv apparently. [09:46] (leastwise, it never has for me) [09:46] lifeless: locally or from within ssh ? [09:46] fullermd: It can, and it often does by default, depending on your distro. [09:47] fullermd: The server doesn't necessarily care, though. [09:47] timClicks: see SendEnv in the ssh config as Peng says [09:48] AcceptEnv is off by default in sshd, looks like. [09:48] jml, i want to know if i should be pushing tribunal stuff into trunk or what [09:48] "i need to think about it" is totally acceptable of course [09:48] fullermd: The manpage suggests Debian turns it on, though. [09:49] Mmph. Damn crazy commie hackers... [09:49] I wish openssh would give some lovin' to cleaning up connection sharing infrastructure (apropos of nothing) [09:49] poolie, I'll think about it :) [09:49] hrm.. [09:49] just checked locale -a [09:49] fullermd: What's wrong with it? [09:50] and then export LANG="en_GB.utf-8" [09:50] Ah, yeah. UTF-8 vs utf-8 is one of those things I've seen vary a good bit, along with with/without "-". [09:50] jam: http://pastebin.ubuntu.com/363128/ [09:50] Peng: Too manual. I've got a lot of fudgery and manual work just to get it working in a few places. [09:51] Peng: If it would grow (a) detection and replacement of stale sockets, and (b) automatic spawning and backgrounding, that would fix things nicely. [09:54] ok, conversion finished, now trying to "switch" tells me: [09:54] bzr: ERROR: Cannot switch a branch, only a checkout. [09:55] justdave: pastebin bzr info somewhere please [09:55] on the other hand, bzr pull --remember actually works now [09:55] it's update [09:55] d [09:57] ('course, on the list of software features needing polish, that winds up WAY below !@&$ suexec...) [09:57] fullermd: Ahh, good point. My favorite part is the big race condition: if you start two SSH processes with no socket, the second one will start a connection, then error out because the other created the socket. [10:02] justdave: Oh, I was going to paste info about how to resolve your exact situation, after we switched. [10:02] s/paste/write/ [10:02] mkanat: yeah, was my checkout of bmo I was trying to update :) [10:02] justdave: Yeah, I figured. [10:03] justdave: It just takes a "bzr upgrade" then probably a "bzr bind" I'd guess. [10:03] so the main trick is I need to update my local repo to 2a format first before trying to reparent it [10:03] * mkanat nods. [10:05] tells me "conflicting tags" though... I get that a lot (because the current-production tag floats, and gets moved along with what's on the production server) [10:06] is there a way to tell it "use the parent's version of the tags" [10:06] ? [10:06] justdave: Oh, that's interesting. Are you using pull or update? [10:06] pull [10:06] I think pull --overwrite will force overwrite the tags. [10:06] * mkanat was just about to suggest that. [10:07] justdave: pull is only usually for unbound branches, though. [10:07] justdave: Usually for checkouts I use update. [10:07] You can also "rm .bzr/branch/tags && bzr pull". :D [10:08] I keep a local branch so I can work on stuff when I don't have internet [10:08] push the whole thing back when I get online again [10:08] Makes sense. [10:08] jam: debian_bundle.changelog.Version [10:16] hi jelmer [10:17] hey bialix [10:17] what do you mean by: "qbzr command for importing svn/hg/git repositories? " [10:17] from http://wiki.bazaar.canonical.com/BzrForeignBranches/Infrastructure [10:19] jelmer: ^ [10:19] :/ i have an error 13 (permissions) popping up. have used ssh to get into a machine and bzr refuses to do anything [10:19] can i do anything to help it along from my end? [10:20] bialix: a qbzr command that does svn-import/git-import [10:20] bialix: if you're familiar with those bzr subcommands [10:20] jelmer: I've used svn-import [10:21] jelmer: do you want to have generic dialog? [10:21] e.g. Import wizard? [10:22] there is also plain import command from bzrtools, what about it? [10:23] bialix: yeah, generic dialog [10:23] bialix: plain import is completely different [10:24] jelmer:why? [10:25] bialix: for ease of use [10:26] no, I've asked why about bzrtools' import [10:28] poolie, I'll try to devote some concentrated time to tribunal today [10:28] bialix: Why it is completely unrelated? It imports trees from directories or zip files [10:28] or tarballs [10:32] jelmer: if you have some sketch in the mind, can you send it to qbzr@googlegroups.com ? ascii art will be fine [10:32] btw, what's the current status of bzr-gtk? [10:32] jml: we could do a conerence call after work, if you want [10:32] bialix: we should probably add the required infrastructure in Bazaar first [10:32] lifeless, thanks, but I've already got plans for this evening. [10:32] that's great [10:34] jml: :P [10:37] jml, actually i don't want to demand a lot of time from you [10:37] just [10:37] s//also, we can talk easily in london [10:37] i feel a bit like i'm forking your project so just wanted some reassurance that you're ok with where it's going [10:37] but you seemed to basically agree in sinny [10:39] poolie, ok. the context-switch overhead is basically my biggest blocker atm :) [10:39] yeah i thought so [10:39] just say "I trust you, poolie" and I'll continue :) [10:44] poolie, I trust you [10:45] Just don't sign anything in blood after saying that... [11:02] evening igc [11:08] hi bialix [11:08] heya lifeless! [11:08] how you guys& [11:08] ? [11:09] we're good; spriting at vila's place [11:10] cool! [11:10] * bialix waves at vila [11:11] I will give a talk next saturday about using gettext in python, based on our work in qbzr and bzr-explorer [11:11] want to chat with igc, but can't catch it here [11:13] bialix: hello, he is here [11:13] heya poolie [11:14] hi there [11:17] poolie, I know this is not any high or medium priority for bzr itself, but do you think we can just reuse our i18n work from bzr-explorer? [11:25] in core bzr? [11:25] i haven't looked at the code at all but i'd love to do it [11:25] yes [11:25] now would be an excellent time to do it in 2.2 [11:25] because we have time to shake out any problems [11:26] can we do a tiny patch that starts adding it in? [11:27] perhaps [11:28] Ian has suggested to use special ZzzTranslations class which we can use for testing if we want to really test gettext stuff [11:33] poolie: we can start with tiny patch [11:33] just need to figure out what is the good target for it? [11:33] error messages, maybe [11:34] command helps kept in docstrings -- this will require serious rework [11:34] jam: https://edge.launchpad.net/+apidoc/ [11:38] jam, the url's like that because it's looking at docstrings in the running app aiu [11:38] aiui* [11:38] bialix: i think errors would be good [11:39] i don't know what ZzzTranslations means [11:39] anybody has idea what's wrong? http://doc.bazaar.canonical.com/plugins/en/push_and_update-plugin.html [11:39] the link above from BzrPlugins page [11:39] http://doc.bazaar.canonical.com/plugins/en/push-and-update-plugin.html [11:39] poolie: zzz is special decorator wich used instead of real translations [11:39] i guess that ian just renamed it [11:40] oh [11:40] poolie: so in the tests if we need to ensure we properly translate the string we can self.assertEqual('zz{{Hello}}', gettext('Hello')) [11:41] igc: there is many links at http://wiki.bazaar.canonical.com/BzrPlugins which does not work now [11:43] poolie: https://bugs.edge.launchpad.net/launchpad-code/+bug/386596 [11:44] Ubuntu bug 386596 in launchpad-code "pushing to a packaging branch can't create a new package" [Medium,Triaged] [12:02] * vila waves back at bialix [12:02] heya vila :-D [12:33] igc: can you paste the url for hte upstream bug report [12:36] how can I do bzr annotate on a revision in the past, where subsequent revisions have renamed or removed the file in question? [12:40] huh, I could've sworn "bzr ann -r old/path/to/file" worked [12:40] bzr annotate -r unless I'm screwing up one of my arguments it fails with an "is not versioned" message [12:40] Ng: use current name, you're in bzr, not in hg ;-) [12:40] bialix: yes, but what if the file no longer exists? [12:41] I [12:41] I branched at the revision I care about and that worked ;) [12:41] oh, yes, that's a workaround [12:41] mzz: then I'd open qbrowse and launch qannotate from there ;-P [12:43] hmm, bzr cat has the option --name-from-revision [12:43] perhaps annotate should provides such option too [12:43] care to file a bug? === mrevell is now known as mrevell-lunch [12:45] mzz: it should use the path of the file in that revision [12:45] if it doesn't please file a bug [12:46] well, it's possible I'm screwing up my arguments, but I don't think so [12:46] lemme try with a test branch, just in case [12:47] Well, you wouldn't want it to ALWAYS use the path from the revision... [12:48] yes, sometimes when I'm backtracking I want to see an annotate for a file that's still there [12:48] fullermd: its more sophisticated than that :P [12:48] Well, yeah, should be. I'm not aware that it IS, though; seems I've run across it before. [12:48] while simultaneously I can imagine wanting to annotate an old file while a different file with the same name is currently present [12:48] that's probably pretty rare though. [12:50] * mzz is filing [12:51] err, or not. I wonder why my bug search missed this [12:51] * fullermd is fliing. [12:51] it's part of https://bugs.launchpad.net/bzr/+bug/255687 [12:51] Ubuntu bug 255687 in bzr "log and annotate should work on removed files" [Medium,Confirmed] === mrevell-lunch is now known as mrevell === sven is now known as Guest32809 [14:01] hi, the bzr join command fails with the error "File id {TREE_ROOT} already exists in inventory as InventoryDirectory...." [14:01] is the python code given in https://answers.launchpad.net/bzr/+question/71563 safe to use to make it work ? [14:25] jbrouault: probably [14:27] Always reassuring. :D [14:32] lifeless: the parameter to set_root_id must be a "unique" string that's all ? [14:35] not "unique", Unique [14:35] there is a guid generator in bzr that you should use [14:35] we use it to generate file ids [14:35] How does changing the root id not involve rewriting all historical revisions? [14:36] maxb: why should it involve that? [14:36] I thought file ids were recorded as part of revisions? [14:36] yes [14:37] * fullermd suspects semantic clash. [14:38] oh... is bzr's view of this operation somewhat as if you've mkdir'ed a fresh root in the resulting tree, and moved all the content of the tree being joined into it? [14:38] "changing the root id" can mean both "changing the file-id of the existing root (which requires rewriting whatever's based on that)" and "switching the root to be a different file{,-id}", which doesn't require rewriting any more than "bzr mv a b ; bzr mv c a" requires rewriting all the previous revs that had a. [14:40] I think I begin to understand [14:46] lifeless: ok thanks :) === salgado is now known as salgado-afk === beuno is now known as beuno-lunch === radoe_ is now known as radoe === salgado-afk is now known as salgado [16:03] hi [16:04] I want to branch from an SVN repository using -r parameter, I understand I should specify the bazaar rev number rather than the svn one, but I don't know how to figure it out without having the checkout first [16:12] nyu: create shared repository, checkout everything, then create new local branch from desired revision [16:13] is it OK for you? [16:13] bialix: I wanted to branch only a subdir of the SVN repo. can I get that at the end of this process somehow? [16:14] it depends: do you need to push changes from local repo back? [16:14] no [16:14] fast-export? [16:15] just branch from the desired subdir [16:15] bzr branch http://svn/repo/dir/subdir [16:15] bialix: problem is, in current head this subdir no longer exists [16:16] taht's why I wanted to use -r [16:16] then get everything, after that use fast-import-filter or split [16:16] fast-import-filter should be the right thing [16:17] or maybe you can run log (qlog) against svn repo, remember the revision number as bzr see it and then branch [16:18] did you try it? [16:18] it will be double conversion and maybe slow though [16:26] bialix: you mean svn log or bzr log? [16:26] bzr log [16:26] on repo root or on removed subdir? [16:26] on your trunk [16:26] or parent dir of missing dir [16:28] * bialix gotta go, waves bye [16:58] Hi, I have one question concerning a migration from a subversion repository. [17:01] adrien_: then you should ask it :) [17:01] I fact I have screwed up the conversion process and the history is incomplete in generated bzr branches. However the final state of each branch is correct (same as in each svn branch) [17:02] lifeless: it's a long problem ... [17:03] So the question is: can I still hack on the branches with incomplete history and then later apply each patch on a correct bzr branch when I understand how to create it [17:04] or is this incomplete history problem a top priority problem that I really need to solve before even thinking about starting programming new features ? [17:04] thanks :) [17:09] you should probably fix it first [17:10] this may take a long time [17:13] I have thought about bzr rebase, but maybe this command only works on branches that share a common history [17:13] indeed, it prefers common history [17:14] you can in the worst case use 'bzr diff' + 'patch' to migrate across [17:14] it would depend on the amount of work you do [17:21] I see. It could even be automated and apply patches + commit iteratively. But then I would have to manage cases when files are created, and call bzr add before commiting. [17:22] adrien_: that sounds like you're describing the "tailor" tool [17:24] can tailor import from bzr branches to bzr branches ? [17:28] I think so, as well as it can bzr->anything && anything->bzr anyway. [17:31] personally I would keep working on svn till the import is good [17:32] I am workin on a large webbased project in a medium size company here. some 200 people are using it and I use bzr to manage the php source code. So far so good, but I want to be able to work on multiple versions of our system. [17:33] that is to say, there is a 0.8 in production already, we must work on revisions there.. there is a 0.9 planned to be released next month, we must work on that to build it.. there is a 0.10 planned for in 2 months and also there we must be able to work on it to prepare it [17:33] So Im thinking how to do that, I was thinking to have 3 repositories with their WTs, so I have project/0.8, project/0.9 andp project/0.10 [17:34] I also have the same structure on the server, where 0.10 is a checkout of 0.9, and 0.9 is a chekcout of 0.8 [17:35] In the 0.8 checkout we will only add bugfixes (and also revision tags), which we can merge to the 0.9 and 0.10 checkout [17:35] lifeless: I think that I'll follow your advice. Unfortunately the subversion server is down so I took this opportunity to migrate to a distributed vcs. I'll try harder to convert our subversion history before going too far with the corrupted bzr branches. [17:35] phoenixz: Well, (a), 3 _branches_, not 3 _repositories_, and (b) that last sentence with the chain of checkouts doesn't make sense... [17:35] Is this setup a good idea or am I totally off here? [17:36] fullermd: sounds like Im off here :) [17:36] fullermd: okay, so how would I take this up then? [17:36] Well, the first part was reasonable; just a terminological quibble. [17:36] The latter isn't really parseable; it's like saying "then I'll coffee wibble venetian blinds" [17:36] fullermd: I agree with that I need 3 branches, but the thing is that I don't see ATM how I can have multiple WTs from multiple branches from one checkout [17:37] thanks to lifeless, mzz and fullermd for your advices :) [17:38] Right, that second clause right there; it makes me go all cross-eyed, because it doesn't make sense 8-} [17:38] fullermd: Sure, make fun of me! :) anyway, how can I then, have only one checkout? because AFAIK, a checkout == branch, not? can I have multiple branches in one checkout? [17:38] Not that it's a bad way to set it up, or that it won't do what you want; it doesn't _mean_ anything. [17:39] "multiply branches in one checkout" is gibberish. What is it you need to DO? [17:39] fullermd: well, I think you need my glasses to see it :) [17:39] I mean, it sounds like you just want 3 branches. So where does this extra layer of complication come from? [17:39] fullermd: okay, let me rephrase.. is it possible to have multiple branches in one checkout? [17:40] because AFAIK, it was not.. thats where the complication comes from [17:40] The answer has to be "no", because it's nonsensical. You can't have ONE branch in a checkout. Branches don't go in checkouts. [17:41] fullermd: I need three branches of the same project (versions 0.8, 0.9, 0.10, and in the future also other versions) to work on [17:41] OK. So far, so good. Sounds like just what you'd want. [17:41] fullermd: okay, Im using the wrong term then.. When I do bzr checkout, what is the .bzr directory called? [17:41] fullermd: crap [17:42] fullermd: when I do bzr branch originalrepo targetrepo... I'll have a new project directory with its own .bzr directory in it, right? [17:42] Nothing in particular, really. ".bzr" I guess... [17:42] fullermd: my bad, I'm a mess today with terminology [17:43] Right, you'll have a new branch (technically; socially, you may really just intend the second branch to remain a mirror of the first branch, but it's technically separate) [17:43] And terminologically, you'd "bzr branch originalbranch targetbranch", not [...]repo. Repository is a different thing, which you generally don't touch explicitly. [17:44] fullermd: alright.. So, I have a projects/kas directory, (kas is the projects name), I want to have projects/kas/0.8, projects/kas/0.9, and projects/kas/0.10 so that I can work on each version as needed.. [17:45] fullermd: so far, so good? [17:46] fullermd: thing is, 0.8 can only contain bugfixes.. 0.9, in development can contain new stuff.. 0.10 will contain new stuff in another area of the project.. [17:46] (phone; I'll read backlog) [17:46] fullermd: Now, on the server, where we have the branches designated to be trunk, what would I d [17:46] fullermd: sure, np, I'll keep writing [17:46] Now, on the server, where we have the branches designated to be trunk, what would I do? [17:47] would I also set up the same projects/kas/0.8, projects/kas/0.9 etc. layout? or is that, as I understood from you, overly complicated and should we only have one trunk? [17:49] Because my next problem then is.. Im also working with other people on it, they'll have the same layout on their computers.. so if they make a 0.8 version fix, that needs to be sent a) to me, and b) to the server too.. if we all make changes to 0.8, 0.9 and 0.10, and we all merge those to that trunk, how can we separate the bugfixes for 0.8 and the new changes for 0.10? I can tag 0.8.x here on my computer, but AFAIK, the trunk repo on the server would contain [17:49] all chages [17:50] OK, well, "trunk" is a purely social construct. It's useful when there's essentially one branch, and everything is aimed to go there. [17:50] Here, you have something like 2.5 "trunks". So using that term probably clouds more than it helps. [17:51] Basically, you've just got 3 branches, and you need at least some subset of people to work on all 3. [17:51] So... well, it's pretty much the same as having 1 branch, and having a bunch of people work on it. Just 3 times. [17:52] One central branch, everybody has a checkout of it. Alternately, 1 branch that everybody pushes too. The former's probably simpler to explain and manage. [17:56] Hm, am I missing something or is there really no difference between "bzr version" and "bzr version -v"? [17:58] $ diff <( bzr version ) <( bzr version -v ) Gives me no output [17:58] So apparently not [18:05] fullermd: ah, okay.. so basically, the setup with 3... master branches? on a central server, one for each version, is correct then? [18:05] and every developer branches from one or more of those 3 to their own machine.. [18:06] fullermd: and then.. if we make a fix to 0.8, I'd like to send that fix also to 0.9 and 0.10.. if those are also branches from eachother, I can just push the changes from 0.8 to 0.9 then, correct? [18:07] 'push' in a metaphorical sense presumably; not in the sense of "bzr push" certainly. [18:07] Perhaps in a "bzr merge" way, depending on your topology. Wouldn't make sense to me. === beuno-lunch is now known as beuno [18:08] fullermd: well, push / pull depend on which branch you are, and if you are taking it from another or sending it, not? [18:08] fullermd: Anyway, the setup would be correct? [18:08] push/pull only work when the source branch is a superset of the target; that wouldn't be the case here. [18:08] But yeah; 3 branches, checkout/branch whichever is appropriate for what you're working on. [18:11] fullermd: well, since the idea of "trunk" is more social, and branches are just copies with a shared history of eachother (i say that correctly?), I ought to be able to send (using push, pull, merge, whatever) from any branch to any other branch, no? practically, If I am A, my coworker B, the central "trunk" C... then if I have something on A0.8, I can push it to C0.8, and then send it to C0.9 and C0.10, right? [18:11] and from there, b0.9 could receive that change from B0.9 [18:11] and from there, B0.9 could receive that change from C0.9 [18:11] (fixed) [18:12] push/pull don't make sense, because the result is to make the destination branch identical to the source. If you wanted that, you wouldnt' want 3 branches in the first place. [18:12] merge probably doesn't make sense either, because it requires fully connected graphs. Same problem. [18:13] Doing a 'bzr merge' that actually does a cherrypick is more likely. [18:13] That's functionally identical to manually making the change in each branch, though it does give you some help with doing so. [18:22] fullermd: so in that case, if I have on the "trunk" the versions 0.8, 0.9, etc.. How can I send fixes from 0.8 to 0.9? [18:23] fullermd: basically, if 0.9 is a branch of 0.8, everything that was added to 0.8 AFTER the branch can be considdered a fix and could be sent to the 0.9 branch [18:24] fullermd: changes from 0.9 would NOT have to be send back to 0.8 because they are not related to the 0.8 version [18:24] fullermd: same thing goes for 0.9 and 0.10.. How could I somehow send these fixes to the versions above? 0.8 > 0.9 > 0.10 [18:25] * fullermd shrugs. [18:25] That becomes a project topology question. It's a way to go; it's just not one that makes visceral sense to me. If it works for you, then run with it. [18:30] fullermd: well, thats the thing.. AFAIK, it would work.. but Im wondering if its the best way to go, and because of that Im asking if it is.. If its not, how could I do this better? [18:31] fullermd: I need to get the code bases of each version separated as to not mix new functionalities with fixes.. but at the same time I don't want to do work double.. If I fix somehting in 0.8, I'd like to send it to 0.9 without having to redo all that work.. [18:31] fullermd: how would you recommend to do this then? [18:35] I wouldn't want to prejudice you. There are as many opinions on that as there are developers, MULTIPLED by projects. [18:36] If you're mentally, socially, and technically comfortable with declaring that 0.9 will always include everything 0.8 does... well, then that'll probably work for you. [18:37] I wouldn't be; I consider that the two branches go off in their own directions, and from the branch point neither is ever again a layer on top of the other. [18:37] But I'm neither you, nor working on your project. [18:37] fullermd: Well, how would you do it then, when you find problems in version A, which have 100% shared code with B.. you fix A, you'd fix B separately? [18:38] fullermd: and again, NOFI, I'm just asking your opinion here [18:39] But I'd never have 100% shared code. If I did, I wouldn't have A and B, I'd just have A. [18:40] Unstable branches always get changes that aren't appropriate for the stable branch, and vice versa. [18:43] If that doesn't happen for you, then it can work. It's just a different world from where I sit, so I can't have much of an opinion. [18:48] fullermd: okay, thanks for your opinion, everybody can always add their ideas I guess.. More opinions can only result in better decisions being made.. [18:48] All you can do is try it and see how it works. [18:48] Keep merging 0.8 into 0.9, 0.9 into 0.10, and do it until it breaks down. Then figure out what else to try. [18:49] It's not like starting out that way commits you to sticking with it forever after all. [18:56] How can I change the default push path without actually pushing? [18:57] fullermd: nah, maybe we'll change this later on, who knows.. but I'd prefer starting out good than having to realize 6 months later that we've been on a very bad road.. [19:03] phoenixz, you can edit ~/.bazaar/locations.conf [19:04] or and/or [19:04] yourbanch/.bzr/branch/branch.conf [19:04] beuno: yeah, just found it myself as well.. thanks anyway! [19:09] can one add post commit/receive... hook scripts in bazaar ? [19:18] AnAnt: AFAIK, yes, you can [19:18] AnAnt: not too much time to look it up now, but try google > "bzr hook scripts" [19:18] AnAnt, yes, you can. [19:27] thanks [19:57] hey all, if bzr svn-import is spewing "inconsistent details in skipped record", is this a problem or can I expect to have a usable repository at the end? [20:02] mrooney: if you look at one, and the difference appears to be () versus [] in one location, then you can likely ignore it (and this is the most likely case) [20:06] jam: hm, it seems to be more parens or something: http://bzr.pastebin.com/d3e0aefed, any thoughts? [20:07] mrooney: the first one has ..... , ((( and the other has ....., ([( [20:07] ignore it [20:09]