[00:57] I am trying to add svn folders to bzr, I got this message "bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/svn/trunk'" [01:08] see my reply in #launchpad === Spaz is now known as Paradoxataur === AfC1 is now known as AfC [03:55] Err.. bzr just did an autopack. .bzr.log said it was packing from 14 packs to 10, but instead it packed them down to...3. I don't get it. [03:56] (I mean, it was right about there being 14 initially.) [09:08] Peng_: it lied [09:08] Peng_: please file a bug [09:09] Peng_: (what it really meant was 'all but two of the packs needs to be combined' -> 3 (its simpler and more efficient than the original code [09:09] but the debug output is the original plan of what would happen [09:15] Oh. [09:17] It should've combined them into 2 packs anyway. It left one with only like 2 revisions in it. :\ [09:23] Peng_ well, could be a bug [09:24] Wait...what do you mean? It was originally going to leave 10 packs, but changed its mind after writing the debug message? [09:25] Well, I filed bug 295486. Kinda crappy title though. [09:25] Launchpad bug 295486 in bzr "Autopack's debug output is wrong about how many packs will be left" [Undecided,New] https://launchpad.net/bugs/295486 [09:51] lifeless: Not to be a stalker, but you seem to have identical branches at lp:~lifeless/+junk/bzr-index2 and lp:~lifeless/+junk/index2. === jszakmeister|awa is now known as jszakmeister [10:30] Peng_: Don't try and act innocent. We all saw you checking out his branches. === jszakmeister is now known as jszakmeister|awa [13:50] What is usually done with a feature branch once the feature is stable and has been merged into the trunk? I don't want it to clutter the branch namespace for all eternity, yet I do want it available for all eternity. [13:54] RedLizard: I usually do nothing to it, or move it out of the way. [13:54] Hello, I am having some hard time to understand how to make bzr happy after a big reorganisation in my project. [13:55] LarstiQ: i would like to mark it as "closed for development" in some way [13:55] RedLizard: mv it to done/ ? [13:55] In fact I have moved/rename some folder in the terminal an now I try to make bzr aware of this modification [13:56] yml: bzr mv --after oldname newname [13:56] yml: this may be a little tricky if you have also done renames of children of that directory, it is doable but a bit more work than ideal [13:56] LarstiQ: thanks I am going to try this [13:57] LarstiQ: I have not done any renaming of the children [13:57] LarstiQ: that should work, i think [13:57] yml: good :) [13:57] LarstiQ: bzr mv --after django_glue/* projects/simple_project/ [13:57] bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned. [13:58] RedLizard: ime that is enough to clear the namespace isssue. [13:58] yml: are you sure that is what you want? [13:58] yml: could you describe the rename you did? [13:59] LarstiQ: optimally, i'd like the branch to be destroyed, and its history contained in the history of the trunk, available by "zooming in" on the merge commit [13:59] RedLizard: if not, you can always delete a branch, since it's revisions are all merged into trunk, you can always recreate it when necessary [13:59] RedLizard: but why bother? [13:59] the burden of keeping around old branhces is very low [14:00] Bzr was aware of a folder named django-glue in the root of my bzr directory then I did mv django_glue projects/simple_project [14:00] yml: right, so it looks to me that should be 'bzr mv --after django_glue projects/simple_project' then [14:00] LarstiQ: because otherwise, i'd have to keep my branch names unique for all eternity [14:00] yml: without the /* wildcard, that would be moving the children of django_glue, not django_glue itself [14:01] LarstiQ: i can't call my branches 'test' or something similar [14:01] LarstiQ: bzr mv --after django_glue projects/simple_project [14:01] bzr: ERROR: Could not move to simple_project: projects/simple_project is not versioned. [14:01] same thing [14:01] RedLizard: eh, a branch called 'test' imo is not worthy of staying around, nuke it :) [14:01] yml: what version of bzr are you using? and is projects/ versioned? [14:01] LarstiQ: but the history will still be available in the trunk? great :) [14:02] RedLizard: yes, absolutely [14:02] :) [14:02] no project is not yet versionned [14:02] `bzr branch trunk -r tip_revision_of_test resurrected-test` to bring it back [14:03] and I amusing bzr : Bazaar (bzr) 1.3.1 [14:03] yml: did projects/ previously exist, or did you mkdir it for this reorginasation? [14:04] I mkdir project [14:04] for this reorganisation [14:05] yml: try 'bzr add --no-recurse projects/' before you do the mv --after [14:06] same thing [14:07] I also try to bzr add projects/simple_project before doing the mv but it also didn't work [14:08] right, that you do not want to do [14:08] yml: in my small test it worked, but let me try with 1.3.1 instead of 1.9 [14:10] LarstiQ: Is there an easy way to update to 1.9 on ubuntu [14:10] by easy I mean sudo apt-get install ... :-) [14:11] yml: yes, there is [14:11] 'morning yml, LarstiQ [14:11] moguh jelmer [14:11] ok so might be an option if you found out that it is not working with 1.3.1 [14:11] yml: use the bzr ppa, https://launchpad.net/~bzr/+archive [14:12] yml: just a moment though [14:12] yml: I'll give you my test script, maybe what I'm doing is too simplistic and doesn't actually cover your case [14:13] ok [14:16] yml: indeed, 1.5 and up succeed where 1.3 does not [14:17] yml: http://rafb.net/p/AFkUPw64.html fwiw [14:18] LarstiQ: Excellent news [14:19] LarstiQ: so now I just have to move to the latest bzr [14:19] does bzr-svn is working on 1.9 ? [14:19] yml: yes, with bzr-svn 0.4.14 [14:20] jelmer: oh! you did a release, sweet! [14:20] jelmer: How can I install it on ubuntu ? [14:20] apt-get install ? [14:21] I don't think it's been uploaded to the PPA yet or synced from Debian [14:21] the ppa has 0.4.13-2 [14:21] you may be able to install the Debian package or otherwise install from source [14:30] LarstiQ: thank you very much for your help [14:30] 1.9 solve my issue [14:31] Is it just me and my happyness or does bzr status is faster ? [14:31] jelmer: do you have an idea when the PPA will be updated? [14:32] yml: there have been improvements to status speed between 1.3 and 1.9, so that's entirely possible :) [14:35] Thank you so much for your effort in bzr [14:35] for some reason that I cannot explain I just feel good with it [14:36] the only thing missing to me at the moment is a bzr-git [14:36] it is such a pain for me each time I have to work with git [14:37] yml: you may want to subscribe to bug 293009 [14:37] Launchpad bug 293009 in bzr-svn "Bzr-svn conflicts with bzr in the PPA" [Undecided,New] https://launchpad.net/bugs/293009 [14:41] jelmer: I am actually on hardy [14:42] but I get the same error message when I try to apt-get install bzr-svn [14:42] the packages are always uploaded for all ubuntu releases at the same time [14:44] thank I will wait for its resolution [15:05] Hi. is it possible to use bzr for my local repository and then push it to a remote svn server? === abadger19991 is now known as abadger1999 [15:16] Flyser_, hi [15:16] Flyser_, yes [17:16] jszakmeister|awa, hi [18:47] How can I restore a branch that I merged into some other branch in the past? [18:49] RedLizard: get the latest revision number of the merged branch and run: bzr branch -rX orig new [18:51] and how do I get the latest revision number of the merged branch? [18:51] it doesn't appear in `bzr log` [18:53] it should, if the branch was merged [18:53] (and you don't have bzr log aliased to something like bzr log --short) [18:54] http://pastebin.com/m60c521ed [18:54] no revision number there [18:57] RedLizard: revid:redlizard@ruud0-20081108134022-03073670ea55866a [18:57] RedLizard: what version of bzr is that? [18:57] or, what custom logformatter are you using? [18:57] what version of bzr is it? [18:57] 0.11.0 [18:57] right :) [18:57] RedLizard: etch? [18:58] yup [18:58] * LarstiQ hasn't seen that log output in a loooong time [18:58] me neither :) [18:58] I was confused by the merged line [18:58] RedLizard: anyway, `bzr branch -r revid:redlizard@ruud0-20081108134022-03073670ea55866a resurrect` [18:58] RedLizard: veel plezier :) [18:59] RedLizard: (fwiw, we're up to 1.9 now) [18:59] * RedLizard wonders what gave him away [18:59] RedLizard: 'gemerged' [18:59] ah :) [19:01] it works [19:02] good :) [19:05] Is there any reason I should _really_ upgrade from 0.11.0? [19:06] If you're not interacting with anyone else, 0.11 will work fine. [19:06] That is, other bzr branches might be in a format 0.11 does not understand. [19:07] And, if you're asking for help, it pays to mention the version you're using :) [19:07] yes, i noticed [19:07] (stupid debian testing on development servers :p) [19:08] hmm, isn't testing lenny by now? [19:08] yes [19:09] that should have bzr 1.5 [19:09] it does [19:09] which, for this discussion, has a logformat that looks more familiar to us ;) [19:12] are the ubuntu packages on launchpad debian etch compatible? [19:13] in the ppa? I believe not [19:14] RedLizard: do you need a system wide bzr? Or is running from source good enough? [19:14] RedLizard: 1.5 is in etch-backports fwiw [19:14] etch-backports has 1.5 [19:14] he [19:15] * luks is too slow [19:15] LarstiQ: yeah, but then i'd get the entire backports repository [19:16] RedLizard: personally, I run bzr from ~/src/bzr//bzr [19:18] hm, given that bzr depends only on python, the ubuntu packages will probably work fine on etch [19:18] * RedLizard tries [19:18] it contains compiled code [19:19] and the packaging standards might be different, say python-central === Toksyuryel` is now known as Toksyuryel [19:19] you might have better luck just dpkg -i the deb from backports [19:20] why doesn't launchpad contain a debian repos as well, by the way? [19:20] how to release al stale lock ? [19:20] held by strk@gnash on host gnash [process #32194] [19:20] bzr break-lock [19:21] thx [19:21] hm, the ubuntu package doesn't work :( [19:22] RedLizard: that is something that may happen in the future, but it requires buildd maintenance per suite. [19:23] RedLizard: as well as the entire archive. [19:25] true [19:26] RedLizard: so, I'd either try the etch backports .deb, or download and unpack a tarball, and run from that [19:26] LarstiQ: actually, i think i will build my own debian package [19:27] ok :) [19:30] will `bzr branch` respect the repos format of the origin? [19:30] RedLizard: if it can, yes. [19:31] so branching from 0.11, hack hack, 0.11 should be able to pull the changes back [19:31] RedLizard: just don't `bzr upgrade` it with 1.9 :) [19:31] LarstiQ: of course [19:31] or branch it into a shared repo that uses a different format [19:33] hm, you really have to be quite careful when working together using different bzr versions [19:34] especially if you don't use a single repository for everything [19:35] * LarstiQ blinks [19:35] RedLizard: what do you mean? Having one repository for all your branches would make collaborating with older clients almost impossible. [19:37] RedLizard: do note 0.11 is over 2 years old (roughly half the projects lifetime) and pre 1.0 [19:37] LarstiQ: unless the repository is in an old format [19:37] RedLizard: which then makes other things impossible, like, say, bzr-svn [19:38] LarstiQ: so, the only solution is to make sure everyone uses the latest version at all times? [19:39] RedLizard, the current default format has been supported since version 0.92, which is about a year old [19:39] RedLizard: no, if you have one repository per project (which is good practice anyway), you should have an easy time of staying compatible with the least capable clients that work on that project [19:39] RedLizard: that should reduce the friction to a level of not having to think about it [19:41] LarstiQ: good point [19:41] jelmer: good, that makes things easier... getting everyone to run >= 0.92 looks reasonable [19:41] RedLizard: if you just have standalone branches, the only point where you run into trouble is by running upgrade yourself. [19:44] RedLizard: but yeah, there is room for error [19:45] LarstiQ: not much if the default format is quite old [19:45] RedLizard: right, in default cases you're safe [19:46] RedLizard: but it's still possible to have a non-default repo, branch something old into that, work, try to get it back in, and notice the format got upgraded when you branched it [19:47] LarstiQ: won't it be saved in the default format again when merging it back in? [19:48] RedLizard: if it's compatible, yeah. Not so when you are trying to stuff rich-root in non-rich-root [19:48] [19:48] * LarstiQ has some dinner and goes off to a verdiepingsfeetsje [19:48] modulo spelling bugs [19:49] have fun [19:49] thanks [19:57] How can I init a branch on a remote server? [19:58] bzr init sftp://blahblahblah [19:58] :-) [19:58] RedLizard: bzr init remote/path, or (my preference) work locally and publish changes when you have them [19:58] Kinnison! [19:58] Kinnison: how are you? [19:58] LarstiQ: Good thanks, busy busy busy :-) [19:58] bzr: ERROR: sftp://$PATH/.bzr/ is not a local path. [19:59] Kinnison: that explains the not having seen you in a while ;) [19:59] LarstiQ: well that, and not going to any ubuntu/canonical confs due to lack of cash :-) [19:59] RedLizard: yeah, I may have fixed that post 0.11 [19:59] LarstiQ: this is using 1.5 [19:59] * LarstiQ blinks [20:00] RedLizard: do you have paramiko installed? [20:00] LarstiQ: yes [20:00] LarstiQ: i do have a bazaar config file automatically created with 0.11, if that matters [20:01] RedLizard: it works for me, what exact command did you try? (~/src/bzr/1.5/bzr init sftp://localhost/tmp/hagedis in my case) [20:01] LarstiQ: which, on inspection, does not contain anything relevant [20:02] LarstiQ: update: it gives me that error message, but it has in fact succeeded [20:02] LarstiQ: that is, on trying it a second time (unmodified), i get: [20:02] bzr: ERROR: Already a branch: "sftp://10.0.2.100/home/redlizard/repo". [20:03] LarstiQ: also, i forgot: i init-repo'd that directory just before init'ing it [20:03] I recall old code trying to open a workingtree on the branch that just got inited, even when remote. It sounds roughly like that. [20:03] RedLizard: ah. [20:05] RedLizard: was that a mistake, or did you conciously do it that way? [20:05] LarstiQ: i did it conciously [20:05] ok, in that case, why? :) [20:06] * LarstiQ files a bug that co-locating a branch and a shared repo remotely gives a confusing message [20:06] RedLizard: it is not a normal thing to do [20:06] LarstiQ: really? I thought it is a common optimization [20:07] LarstiQ: appearantly i misunderstood something; what exactly IS the common optimization using init-repo? [20:08] RedLizard: the optimization only helps if you store multiple branches in a repository, at which point having the root of repo _also_ be a branch is weird. [20:08] RedLizard: bzr init-repo sftp://host/repo; bzr init sftp://host/repo/branch; [20:09] LarstiQ: i use (read: am planning to use) the "nested branches" layout [20:10] LarstiQ: in which case having the shared repo also being the root branch sounds logical [20:10] RedLizard: it could be. I still doubt it. [20:11] LarstiQ: what's so strange about it? [20:12] RedLizard: the relation of the branch at the root to the other branches. [20:12] LarstiQ: otherwise, i would have /host/project (a --no-trees repo) containing only a directory trunk (a branch) containing other branches (recursively) [20:12] *containing only a directory "trunk" [20:13] RedLizard: ah, I think I see what is going on here. [20:14] RedLizard: what branches are in trunk/ then? [20:14] LarstiQ: feature branches, probably [20:14] LarstiQ: see section 10.2.2 of the user guide [20:14] RedLizard: why wouldn't they be siblings of trunk, instead of children? [20:15] RedLizard: just a moment, still filing that bug [20:16] LarstiQ: because they are created from trunk, and will ultimately be merged back into the trunk (a clear parent-child relation) [20:18] LarstiQ: and child objects residing in the parent directory is a Good Thing from a logical standpoint [20:19] RedLizard: hmja. I disagree about there existing a parent/child relationship, but I see your point. [20:19] * LarstiQ looks at the user guide [20:19] LarstiQ: permanent forks (say, splitting off 2.6 (the new unstable) from 2.4 (stable)) would be siblings of trunk [20:20] LarstiQ: which, come to think of it, is a good reason not to have trunk equal the repository root [20:21] RedLizard: right. From my point of view any branch is equal in footing to trunk. [20:22] LarstiQ: even feature branches, which only exist for a short period of time, only to be merged back into the trunk? [20:23] RedLizard: yes. But they're not very likely to exist in a central repository anyway, but live on my machine. [20:23] LarstiQ: unless you work on a project on multiple machines [20:24] RedLizard: but I see some merit in nesting like that. [20:24] RedLizard: https://bugs.edge.launchpad.net/bzr/+bug/295704 btw [20:24] Launchpad bug 295704 in bzr "Colocating a branch a repository remotely complains about .bzr not being a local path" [Undecided,New] [20:25] hello people [20:25] hmm, should be 'and' instead of 'a', a well [20:25] me needs some numbers about bzr if possible [20:27] anyone awake? :) [20:27] pygi: you didn't ask a question yet ;P [20:27] truuue :) [20:28] basically, number of projects using bzr, and some high-profile names of projects ;) [20:28] RedLizard: I still think it's unnatural, but I might be oldfashioned ;) [20:29] * LarstiQ doesn't know of research into the former [20:29] pygi, http://bazaar-vcs.org/WhoUsesBzr [20:30] jelmer, ok, and how about number of downloads? :) [20:30] pygi, I don't think that's easy to track [20:30] jelmer, indeed it isn't [20:30] as most people get bzr from their distribution [20:31] jelmer, right [20:32] jelmer, just trying to convince some people to do some bzr stuff, and this will help ;) [20:32] pygi: who are those people? Are they convinced by 'ubuntu, launchpad, mysql'? [20:33] LarstiQ, O'Reilly :) [20:33] pygi: aha :) [20:33] pygi, you may want to check ubuntu's popcon [20:34] LarstiQ, I think mysql accounts for lot more then ubuntu & LP ;) [20:34] pygi, IIRC that lists bzr as the second most popular DVCS [20:34] pygi: depends what they are looking for [20:35] LarstiQ, true that too [20:36] LarstiQ, I guess adoption rate by external projects [20:37] pygi: right [20:37] LarstiQ, and we can't really consider LP & ubuntu external :p [20:38] pygi: tried the very scientific approach of looking at amount of google hits? [20:41] * LarstiQ now really is off [20:41] LarstiQ, laters, and thanks [20:45] jelmer, thank you too, data sent ;) [20:45] np, hope you can convince them :-) [20:46] Peng_: yeah, its the 'locations defaults override remember values' annoyance; I really must fix that [20:47] everyone wants to do a Git book, but bzr one is different stuff... [20:48] pygi: probably because bazaar is easy enough that you can use it without a book :p [20:49] RedLizard, actually, I'm talking from publishers POV ... [20:50] I'd guess it is because there are more git users [20:50] Pieter, indeed [20:50] pygi: I was just kidding. I guess git is popular for one reason: that the linux development team uses (and wrote) it ;) [20:50] therefore, instant fame [20:51] afaik there was a bzr book on the way [20:51] git didn't become really popular until about a year ago, and it's been in use for the kernel for 2-3 years now [20:51] not sure how far they got though [20:51] jelmer, yea, I heard that too ... but nothing new on it since ages ... [20:52] I talked about the book with few people here some time ago :) [20:53] Pieter, well, it was VERY unfriendly before [20:58] * jelmer still uses git reluctantly [21:01] jelmer, what project do you use it for? [21:02] samba mainly, but also several other projects I've contributed to (ikiwiki, loudmouth, etckeeper, btslink) [21:03] aha [21:03] this is one of the reasons why picking a vcs is so different than picking an editor - it affects not just you, but the rest of the project as well [21:04] true [21:14] you can always use git-bzr ;) [21:18] :-) [21:18] Seriously though, I'm not sure how that helps me, it still forces me to use the git UI [21:20] only to push to git, you can use bzr for all the other stuff [21:21] Doesn't gain me an awful lot, it still e.g. requires a local copy of the git repo and a more complex way to upload to the remote git repo [21:21] bzr-git should come close, once I finish implementing remote fetch support [21:24] :) I guess it's more useful the other way around, as git has real branch and remote support [21:24] I would say it the other way around, being the bzr adept that I am :-) [21:25] git requires you to fetch data locally before you can do anything with it, bzr allows you to work directly on remote data [21:26] it would indeed be nice to have git-like branches in bzr, I think that's actually my top-wishlist-item atm [21:31] jelmer, wasn't there some work going on getting those? [21:33] not afaik [21:33] it shouldn't be too hard to implement, just nobody hasn't done it yet [21:33] and it would require a format change [21:33] In other news: this is the best use of the internets ever... live web cam of PUPPIES. http://cdn1.ustream.tv/swf/4/viewer.45.swf?cid=317016 [21:34] * emmajane apologies and encourages you to resume normal activities. :) [21:34] lol :-) [21:34] :) [21:36] * jelmer fears he'll just end up looking at puppies all evening, rather than adding new awesome bzr features [21:36] LOL [21:36] +1 [21:38] jelmer, screen casting has just taken a dramatic back seat to puppy watching. :) [21:39] it has sound too \o/ [21:40] emmajane, :-) [21:40] Pieter, yup :) [21:40] must be supper time? [21:40] that's what they thought [21:40] and there's 8000 more people watching, amazing [21:40] one of them have been assigned box duty... for our viewing pleasure. :) [21:42] back later. :) [21:46] jelmer, more format changes :P [21:48] jelmer, I don't think people would like that :) [22:21] beer o'clock [22:22] g'night *