[00:00] luke-jr: You want to replay the revisions from each incompatible branch onto the canonical history, mapping file IDs. [00:01] that would be ugly. :/ [00:01] can't just sed the branch? :p [00:01] It would be ugly. But a lot less ugly than maintaining incompatible branches or your own aliasable repository format. [00:01] It is a one-time cost. [00:02] ok, how about pasting on missing history? [00:02] What do you mean? [00:05] bzr-svn only got the last N revisions of the history [00:05] we need to restore the full history too [00:06] Do any of the bzr branches have the full history? [00:06] no [00:07] except the prototype ones I'm making now with cvsps-import [00:07] Why didn't bzr-svn catch it all? [00:07] it doesn't follow hierarchial changes [00:08] after moving to Subversion from CVS, we rearranged the repository structure to be nicer [00:09] Are the old CVS and Subversion repos no longer in use? [00:09] the Subversion one is, but not for the branches in Bazaar right now [00:10] Even so, that's fairly inconvenient as it means compatibility has to be maintained somehow. [00:10] not really [00:11] So, what I would do: [00:12] - Somehow get a consistent and complete copy of the history into a bzr branch. [00:12] - Hack rebase so it maps the file IDs (as in the bug). [00:13] - Rebase all of the branches on top of the new history. [00:13] can I get cvsps-import to use a file-id file? [00:13] (or some prefix of the new history) [00:13] I don't know. [00:14] can current-trunk-revision-2 be made to sit cleanly on top of a revision N? [00:15] "current-trunk-revision-2"? [00:15] I'm trying to get a very simple installation of bzr onto my shared web host. I don't have root access, but all I need to be able to do is list files in a repo. [00:16] I only have FTP access to the host; no telnet, ssh, etc. [00:16] How can I do it? [00:16] TheMusicGuy: Why do you want bzr on there? You don't actually need bzr on the server just to host a branch. [00:17] because webbzr needs it [00:17] I want to be able to browse branches with a web interface [00:18] Ah. [00:19] Any reason you can't use LaunchPad? [00:19] its not for a project. Its for homework. [00:20] Trying to get a web interface like that up on a shared host with only FTP access sounds like more trouble than it's worth. [00:20] I use bzr and my personal web host for backing up school work. [00:20] Although it is more than likely doable. [00:21] sorry, I didn't see your last post [00:21] webbzr seems like it would work, but I need to have a bzr install on there somewhere [00:21] Do you really need webbzr? [00:22] that looked like the simplest solution. Its just three files, only one of which is actually a PHP file. Configuration is as simple as changing a few lines in the top of the script. [00:24] For three files, I really doubt you need a web interface [00:24] Oh [00:24] webbzr not your project [00:24] Nevermind, I misunderstood. [00:24] How big is your project/homework? [00:25] pretty big. [00:25] Can't I just upload an install of bzr into some directory on my server and tell webbzr to use that? [00:26] I don't need to make any changes or create any files from the web interface. [00:26] read-only is fine. [00:26] Where can I find the source of webbzr [00:27] http://bazaar.enseed.com/app/webbzr/ [00:28] Why exactly do you need a web interface anyway [00:29] so I can access the repo from workstations that don't have bzr installed while still using bzr [00:40] btw, hg's web ui has an interesting feature, you can donwload a whole tree using a single link where you specify a revision/tag, loggerhead could have the same thing :) [00:41] I mean, the tree is packaged as .zip or so [00:45] Stupid question: How do I switch to the last commit with a given nick (branch?) [00:45] ? [00:46] is there some way to check what percentage of the code is contributed by each developer? [00:46] I just saw that [00:46] somewhere [00:46] just looking around Synaptic [00:46] This might do it [00:46] bzr-stats [00:46] "This is a simple plugin for Bazaar that can list the contributors to a [00:46] branch and what they worked on." [00:47] I don't know if it does percents though [00:47] thanks [00:47] I don't think that works by line if that is what you are looking for [00:47] though perhaps it has a mode for that [00:48] I don't understand why Canonical never updated the bzr in the Ubuntu repository [00:49] You have to use the bzr in the PPA for 2a (and thus LaunchPad) [00:49] mathepic: Launchpad doesn't force you to use 2a. [00:50] mathepic: And the bzr team can't push inappropriate updates into Ubuntu releases just because both have Canonical involvement. [00:50] Ubuntu has a strict stable release update policy. [00:52] Ah, nevermind. I just figured out that the filesystem layout of my host won't work for webbzr. I'll have to rework it before I can do this... [00:53] mathepic: bzr's new (and IMO less insane) release schedule should be a bit nicer to distros. [00:54] I just took a look at the policy [00:54] Ugh [00:54] It is necessary. [01:09] wgrant: weeeel [01:09] wgrant: it is what is [01:10] lifeless: That much is clear. [01:11] lifeless: (what are we talking about? the SRU policy?) [01:53] wgrant: yes [02:05] lifeless: I'm sure you know the disasters that have come about. [02:05] But it is perhaps overly strict for less core components. [02:06] Although it would be particularly foolish to ever SRU 2.0.0, because of the default format change. [02:15] wgrant: I'd call it tricky rather than foolish [02:15] wgrant: 'needs to be one with vare' [02:16] lifeless: I don't want my Jaunty system to one day start creating incompatible repositories. [02:17] it does that right now ;) [02:17] Does it? [02:17] yes, it will be making pack-0.92, which can't pull in a growing number of projects [02:17] at some point the fraction will pass 50% [02:18] but we could do 2.0.0 with a plugin for the default back, or other such techniques [02:18] Pulling an existing branch into a new branch doesn't seem like a very common case. [02:18] regardless, I think the concept of a 2.0.0 SRU is not foolish [02:18] wgrant: you said repository [02:18] lifeless: Shh. [02:18] 2.0.0-sans-default-change would be nice, but I can't really see it happening. [02:19] wgrant: all the upstream code imports are going to be moved to 2a [02:19] the ubuntu branches are 2a [02:20] I know. [02:48] johnf: hi [05:18] Does anyone have the 'fileid' or 'graft' plugins mentioned at the end of http://bazaar-vcs.org/BzrPlugins ? [05:37] luke-jr: Those links have them... [05:37] Oh, wow, they are old. [05:37] A weave repo! === abentley1 is now known as abentley === abentley1 is now known as abentley === abentley1 is now known as abentley [09:47] wgrant: those links are empty and "unauthorized" [10:03] luke-jr: Not quite - try checking them out with bzr [13:30] Hello all... Does anyone have a URL to hand where someone has documented their usage of qbzr-eclipse? I've [13:32] I've never even heard of qbzr-eclipse [13:33] mathepic: Not that you are necessarily interested but this is what I am 'trying' to use http://bazaar-vcs.org/QBzrEclipse [13:35] I'm evaluating bzr for our project and the Bazaar Explorer gui seems great and makes sense but we use an Eclipse based IDE for microcontroller code and I just can't see what the workflow should be between bzr and Eclipse. [13:36] I don't use eclipse, but I get along just fine switching between my editor and the terminal [13:36] I tried bzr-eclipse when I was using eclipse and it wasn't very good [13:37] I just took a look at the page for qbzr-eclipse [13:37] Scrolled down [13:38] Found a link to this bug [13:38] https://bugs.edge.launchpad.net/bzr-eclipse/+bug/121936 [13:38] Ubuntu bug 121936 in bzr-eclipse "Eclipse hangs in bazaar operations that require user input" [High,Triaged] [13:38] Yep, thats the same one I just posted [13:38] Oh wait, that one was for bzr-eclipse [13:39] Yes... I had seen that which is why I opted to try qbzr-eclipse which doesn't seem to have the same issues documented (presumably because it uses the more standard qbzr gui widgets) [13:40] I never had a problem pushing with bzr-eclipse when I used it [13:40] It just didn't have all the commands [13:40] And was super slow [13:40] My problem seems to stem from the fact that using a standard text editor I could just work with files in whatever directory (branch) I want but in Eclipse when I branch I'd have to re-import the project directory again each time which doesn;t seem like a seemless workflow. [13:42] Maybe its my lack of experience with VCSs in general but there seems to be a conflict between bzr which has a directory per branch and eclipse which expects a single directory per project and has no way to easily switch that project view toa different directory (branch) [13:42] Can't you just refresh the directory in Eclipse? [13:43] Project = Branch in general [13:43] Do you need more than one Branch? [13:44] Say I have a project called 'Project' and I go to bzr explorer and create a branch called 'Project-Feature'.... bzr explorer creates a new directory for that new branch but the Eclipse project is still pointing at the original directory. [13:44] Can Bzr Explorer turn an existing project into a branch [13:44] I'm not sure [13:44] I don't use it [13:44] Go to terminal, go to the directory of the project [13:45] And use the command "bzr init" [13:45] It will turn your project into a branch [13:45] Then use "bzr ignore ...." for files you want to be ignored [13:45] then "bzr add" to add the rest [13:45] And its set up [13:47] OK.. but just so I understand, if you were to then branch from that (to work on a new feature without immediately affecting the main/original branch) then what would you do? I 'think' branching will create a new directory that the Eclipse project will not be pointed to - yes? [13:48] You probably wouldn't want two branches in the same project [13:48] Just create a new project for the second branch [13:51] Zand3r: you could set up an eclipse workspace for a lightweight checkout and then bind that checkout to different branches using 'bzr switch' [13:52] I was considering this workflow at some point, I think [13:53] hmm... ahh... so I just understood what mathepic is suggesting I think.... using the terminal (or bazaar explorer) I could branch the project which would create a new directory and then import that into Eclipse as a new project, work on it.... then using the terminal (or bazaar explorer again) merge the tested changes into the original project at which time i should be able to 'refresh' the project in Eclipse which will cause it to update. [13:54] You don't have to create a new directory to branch [13:54] You can use the existing directory, which happens to be the directory of your project [13:54] Oh wait [13:55] For the first step you could either branch from anotther branch or you could use an existing local project [13:55] Depending on whether the branch already exists somewhere [13:55] dorins: Thank you - not ignoring what you have suggested, am looking for details of lightweight checkouts [13:55] this might help: http://doc.bazaar-vcs.org/latest/en/user-guide/reusing_a_checkout.html [14:00] I've never dealt with those - Is that basically having multiple branches in one directory and being able to switch between which ones you are using [14:01] It says there are no local commits; that is a signifigant disadvantage. [14:05] dorins: Thanks... I will run through the lightweight checkout workflow to familiarise myself with it... it looks like it would solve the issue of working across multiple branches without having to manually import each one into Eclipse as a new project (I could just refresh the one project after switching) but as mathepic suggests there does appear to be several disadvantages associated with that approach (including the fact that I'd have to make sur [14:05] committed work on a branch before switching to another branch) [14:07] It looks like it takes away the whole distributed side [14:09] mathepic: the branches can be local themselves, each in it's own directory. But the working tree is a lightweight checkout that you bint to any of the branches as you work on them. This way you can share a single eclipse workspace for all branches. [14:10] arr, wifi on linux is still causing me greef [14:10] s/greef/grief === dorins_ is now known as dorins [14:17] ok... well I've realised that Eclipse can not import projects (branches) that are already in the Eclipse workspace so it seems that branching, etc. needs to take place outside of the Eclipse workspace in which case dorins' lightweight checkout approach might work best in the context of using Eclipse (keeping in mind that I'm [a] new to all this and [b] haven't run through and actually tried it yet) [14:18] Unless i'm totally misunderstanding how to use qbzr-eclipse which does add a 'branch' option to the Eclipse IDE but doesn't seem to then let me use the branch it creates. [14:19] Thanks for the help both of you - I do really appreciate it - I'll continue to work through this === abentley1 is now known as abentley === ubott2 is now known as ubottu === SamB_XP_ is now known as SamB_XP [19:10] moin moin [19:42] how does the bzr-git plugin work? [19:42] can't find any docs on it [19:47] itistoday: do you mean 'as a user how do I use it' or 'what does the code do' ? [19:48] lifeless: the former [19:48] sorry for not being more specific [19:48] have you installed it? [19:48] yeah i think so [19:48] itistoday: nothing to apologise for, I just want to answer the right question :) [19:49] ok, 'bzr plugins' should list 'git' if you've installed it [19:49] yeah it's there [19:49] cool [19:49] so, generally you can just give git:// or git+ssh:// urls to bzr now [19:50] and then use bzr with it? [19:50] there is a new command to do bulk imports from git I think, 'bzr help git' should give some info on that, or perhaps 'bzr help commands | grep git' [19:50] itistoday: yes [19:50] itistoday: it aims to be transparent [19:50] hmm... will git still work? [19:50] yes [19:50] ah that's good to konw [19:51] what if i've already imported something with git? [19:51] do i have to re-check it out with bzr? === Adys_ is now known as Adys [19:52] itistoday: to use it with bzr? its recommended I think [19:52] you can just cd to the git tree and run commands like 'bzr diff' 'bzr commit' etc [19:52] but I don't think that 'bzr ignore ' will do the right thing yet ;) [19:53] lifeless: thanks, i'll give it a shot, seems like i need to install dulwich, will do that now [19:57] well neat [19:57] it seems to work like magic [19:57] i'm so happy i can stay in bzr land [19:58] :) [19:58] Gehm's Corollary :p [19:58] there's a bzr-hg too :-) [19:59] hey cool, bzr 2.0 has been released, need to get that [20:15] how do i install dulwich, or any other plugin, and make sure that it only installs into ~/.bazaar? [20:24] doesn't seem to be a way... at least for dulwich [20:26] dulwich is more a support library than a plugin [20:26] itistoday: it's a python libgit [20:27] ah [20:27] bzr-hg seemed to work nicely though [20:27] guess they work differently [20:31] hg itself is written in python, no need to write an implementation/wrappers for it :) [20:32] itistoday: you'll note that bzr-svn uses subvertpy which wraps libsvn [20:32] LarstiQ: ah gotcha [20:33] wonder what came first, hg or bzr [20:33] they're pretty similar [20:33] think the hg guys should just team up with bzr ;-) [20:33] too many vcs' give developers headaches [20:34] That's on the schedule for right after the X radeon and radeonhd drivers merge, and MySQL and Postgres combine efforts. [20:34] hehe [20:51] itistoday: bzr came first [20:54] Hg started when that one guy stopped giving free BitKeeper licenses to Linux Kernel devs, right? [20:54] I have no idea when Bazaar started though [20:59] lifeless: thanks [20:59] mathepic: thats when git started; hg started a little earlier than that [21:00] I thought they both started in response to it [21:02] Where is your source? I can't find a "reliable" one [21:02] my memory :) [21:03] Go fix Wikipedia then :) [21:06] mpm - the hg author - is the guy to ask [21:06] I *thought* he started sketching stuff out back in feb that year [21:11] Someone said here that diff 2.0 2.1 > 1.18 2.0, so what's so new in 2.0 to not justify a 1.19? [21:15] RenatoSilva: the default format has changed [21:16] this is a very user visible alteration that we want to make sure people are aware of and take the time to upgrade properly; major releases signal such things [21:17] if I upgrade to 2.0, will the old branches be converted automatically? [21:17] No [21:17] bzr upgrade [21:18] mathepic: does it work fine? or have you been receiving some trouble reports? [21:18] I didn't have to [21:18] run bzr upgrade [21:18] then bzr check [21:19] RenatoSilva: what are you really asking [21:24] lifeless: if upgrading to the new format using bzr upgrage will always work fine [21:24] RenatoSilva: you should read the upgrade guide [21:24] ok it's not trivial then, I'll google for that, thanks [21:27] RenatoSilva: it often is. sometimes its not. [21:27] ok [21:37] is there a way that i can check whether two branches are different? [21:39] itistoday: "bzr missing"? [21:44] Peng_: thanks, that worked [21:45] is there anything special i should do to remove a branch? [21:45] or will just rm'ing it work fine? [21:45] (it's part of a shared repo) === khmarbaise_ is now known as khmarbaise [21:59] itistoday: Just rm it. If the branch had any unique revisions, they'll still be in the repo, but it's not worth the effort of removing them. [21:59] Unless you, like, added an ISO. [22:24] Peng_: thanks === spm` is now known as spm